We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Aristotle and Enterprise Architecture

Originally published December 24, 2012

Never trust a discipline that is not able to predict its own demise.

It seems that every system integrator, consultancy and analyst house has its own “maturity model.” They help organizations measure how far along they are in certain disciplines, such as in systems administration, security, content management, integration and so forth. These models typically start with a stage called ad hoc or reactive, then go through stages such as departmental or focused, then almost invariably there is a stage indicating some kind of integration, and finally the situation is optimized.

There is No Such Thing as “Optimized”

The appeal of these models is easy to spot. Wouldn’t we all want to be in the optimized stage? And if there are consultants who can help us spot where we are, where we want to be, and plot how we get there, isn’t this the groundwork for any good strategy? Still, I think these models simply miss the mark. I don’t think that at one moment you can say that you’re done, that you have reached a state of being a high-performance organization, or being optimized in any way. I don’t believe that there is any steady state, for that matter. Progress comes with ebbs and flows. At most moments in time, you will reach some kind of equilibrium, where the system, process, program or whatever supports what it needs to support.  Then something changes again, disturbing the equilibrium. Technology moves on, user requirements progress, competitors raise the bar, customer demands shift, economic circumstances change, the regulatory environment tightens, and so forth. The list of potential changes is endless. These changes disrupt the current balance, and then you try to create a new equilibrium. Sometimes this is an improvement, and sometimes it is a step back, like with many things in life.1 And if we must think in stages, where are the stages of decay and death? Technologies get absorbed into other ones, and some user requirements simply disappear. When was the last time you sent a fax?

In short, everything you don’t put energy into decays – buildings, living creatures, friendships, relationships, systems, processes, everything. If you keep putting effort in, there may be improvement along the way, but you’re never done. There is no such thing as optimized. Every manager knows that if you move your attention to one area, another area suffers. To use a metaphor, there is always one more plate turning than you can manage.

There is an underlying law of nature called entropy. Everything in nature flows from a concentrated form into some kind of disorder. In fact, entropy is a force of evolution. Evolution is based on a number of principles. First, there needs to be genetic variation. Every plant or animal, although belonging to a species, needs to be slightly different. Otherwise, there is no competitive advantage. Then, it needs to be possible to create new random permutations, based on inheritance. Lastly, there needs to be a competitive natural environment, in which only the most adaptive survive and in which the random permutations that do not have an environmental fit die. In a way, entropy drives change in nature and, at the same time, allows random permutations to occur.

Evolution and Enterprise Architecture

Evolution and enterprise architecture are very much related. From a cynical point of view, you could say that the forces of evolution have shaped most enterprise architectures. To quote one famous analyst2: “Most of you have an accidental architecture. I mean, I can only hope you didn’t deliberately design what you have in place.”

Enterprise architecture (EA) can formally be defined as “a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g., the behavior) between them. EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems.”

This definition already contains the word “evolution.” When we focus on that, we can define enterprise architecture as all activities to counter the forces of entropy and keep our enterprise focused and composed. Enterprise architecture maintains order and battles the decay and chaos that entropy causes. This means an enterprise architecture needs to be resilient to resist entropy. In many cases, this is done by building a rigorous and robust enterprise architecture that will stand the test of time. Obviously, an enterprise architecture is a reference model. It takes time to get there, and practicalities under way may force you to make decisions that are not supported by the enterprise architecture. For instance, certain business applications may have their own workflow or content management, or come with their own reporting tools. But the goal of the enterprise architecture is to come as close as possible to an ideal state. Again, like with maturity models, we think in states.

Aristotle has the Answer

This thinking in states is deeply rooted in Western philosophy. Parmenides (5th century BC), a Greek philosopher predating Plato, felt that any motion and change in nature were nothing more than manifestations of an unchanging reality. In reality, everything “is.” If something changes, it needs to move from what it is to something else that “is.” In between, change would mean a mix between “to be” and “to not be.” Impossible, according to Parmenides. Plato continued on this path. Real knowledge about objects in this world is universal too, and doesn’t change. Plato felt the process of such objects becoming was not accessible to human beings. The idea of the underlying truth of being has dominated Western philosophy ever since. Heraclitus (535 – 475 BC) took a different approach. He is most famous for his words “panta rhei, kai ouden menei,” meaning “everything flows, and nothing remains still.”3 Heraclitus didn’t think in states, but rather much more in terms of continuous movement. Unfortunately, the work of Heraclitus has been less influential.

But Aristotle (384–322 BC) argues that we can also observe all the changes in the world around us.  Aristotle starts, like Plato and Parmenides, by pointing out that the most important characteristic of any object is its existence. But change and movement – in other words the becoming of the object – is a transition from its potential to be to the act of being, with a certain degree of perfection. This transition has a certain internal or external cause. In short, Aristotle suggests for each change or movement, we should ask four questions. What did change? What caused that change? What is the result of the change? What is the purpose of the change?

To answer these questions, Aristotle identified four “causes.” Causes are best translated as "explanatory conditions and factors." The four causes are the material cause (causa materialis), the efficient cause (causa efficiens), the formal cause (causa formalis) and the final cause (causa finalis).

It turns out that these causes are a very useful framework for a resilient enterprise architecture. Not resilient in terms of being robust, but built in terms of cause and effect. Not based on an ideal state that is to be pursued, but built on the assumption of continuous change and movement.

The First Two of the Four Causes

Aristotle was not the first to ask the question “why” in trying to understand the world. In fact, “why” is one of the most important philosophical questions one can ask. Others before Aristotle had explored the “why” of things. Although, according to Aristotle, others had come up with all elements of causality that Aristotle mentioned but Aristotle was the first to describe the four causes as a comprehensive theory.

The term that Aristotle used was aition, which is “an explanation for how something came to be.” This is a wider term than the English term “cause,” which comes the closest. Today “cause” is very much connected to “effect,” through cause-and-effect relationships. If we increase prices by x%, sales will go down by y%. If we bump our head, we get a bruise. If we leave the steak on the barbeque too long, it will burn. This is what Aristotle would call the efficient cause, but there are other causes as well.

The four causes are usually explained with the example of a statue. The material cause of the statue is marble, the material of which the statue is made. The efficient cause is the sculptor and his chisel, how the statue was made. The formal cause consists of what the statue portrays, for instance a woman. The final cause describes the purpose of the statue, such as depicting love or, more mundane, highlighting the center of a square.

Or take the example of mankind itself. A human being is made of flesh and bones, which constitutes the material cause. It is produced by its father and mother, which is the efficient cause. A human being is recognizable by its features. We all have legs and arms, a nose and the ability to reason, which is the formal cause. For what purpose, the final cause, is a question that has many different answers, ranging from simply sustaining the species (biological) to fulfilling your full potential (humanistic) to living a life worthy of deserving a place in heaven (religious).

Finally, let’s take another example, a little closer to enterprise architecture, by asking “Why did the house collapse?” The material cause might be the quality of the stones that were used. The efficient cause is that the builders didn’t do a good job using the materials or that bad weather caused the collapse. The formal cause might be the blueprint that contained errors. The final cause in this example is that cost was preferred over quality.

In all examples, multiple causes can play a role in the explanation of an object or an event. Leaving out one cause, or choosing a different explanation as a result of one of the four causes, would lead to different results.

Material Cause

There has to be an unmoved mover, the thing that comes first. In Aristotle’s view, what we can assume to be present are the materials of which the object is composed. We can define this broadly and refer to bronze as the raw material of a statue, or define multiple levels of material causes, where the bronze is caused by its elements, ultimately leading to the atomic level of the material. The statue is caused by its raw materials because without the bronze it wouldn’t be there. As Aristotle tries to describe change through his four causes, the raw material undergoes change as well. For instance, the bronze needs to be melted and molded to become part of the statue. The material cause is not limited to a single type of material. The material cause of the house, in the example I used, includes concrete, wood, glass and spikes (notice that a spike in itself has four causes as well – it consists of material, it was produced, it has a form, and a meaning). Materials can cause certain things, but others not. Bronze is only suitable for a certain type of statue; from the point of view of the other causes, another statue might benefit more from marble.

The link with enterprise architecture is pretty obvious. The material cause describes the technology level. All technologies in use by the organization together form the material cause. This includes business technologies such as content management and business intelligence; hardcore technologies such as development environments and integration tools; and supporting technologies taking care of systems management, security and so forth. If you lack certain technologies, it is not possible to create enterprise architectures that deem those technologies necessary. Some organizations may be able to invest in their own technologies, but for most organizations the technologies available are indeed the unmoved mover. They are assumed to be there.

Yet, it is not that simple. Others would argue that technologies are not the cause of an architecture. They are the effect. One would choose the technologies needed to compile a certain enterprise architecture. Still, they are the material cause, as Aristotle defined “cause” in a broader sense. The technologies, chosen or already available, form a description of the enterprise architecture envisioned or in place. Furthermore, enterprise architects work within certain paradigms as well. It is hard to include technologies you are not aware of. In strategy, this debate was summarized as “strategy follows structure,” or “structure follows strategy.” The only conclusion that remains in such a heated debate is that both are interdependent. New strategies come out of existing structures, and new structures are the result of new strategies. The relationship between enterprise architecture and technologies is the same.

I also include skills and organizational capabilities in the material cause. This seems to be in contradiction to Aristotle. He regarded the sculptor and his skills as the efficient cause. However, there is an important difference. In the case of a statue, the sculptor is external to the statue; he creates it. In the case of organizational capabilities, they are part of the enterprise architecture itself and therefore part of the material cause. Obviously, it is not enough to own technologies. It is equally important to master them  or to know where to get the right skills. Another essential organizational capability in an adaptive enterprise architecture is being able to spot new and innovative technologies, and use them in a meaningful way. Consequently, organizations need to be able to absorb those new technologies into the architecture, as part of absorbing all external and internal change to existing systems and processes.

Efficient Cause

The efficient cause comes closest to what we today would call cause-and-effect. The bad weather causes the house to be flooded or the sculptor with his chisel creates a statue. To be more precise, according to Aristotle, it is the knowledge and the skills of the sculptor that form the efficient cause, the art of sculpting in general. The efficient cause is the primary source of change.

This cause is different from what I have seen in other enterprise architecture frameworks. Most frameworks take a closed-system approach, describing only the elements within the frameworks, all other things being equal. If the primary source of change is the efficient cause, then the external factors that shape and reshape the organization deserve quite some attention. Understanding the efficient cause of enterprise architecture can be accomplished through a stakeholder analysis. A very useful framework to do this is the Performance Prism that was developed at Cranfield University in the UK. This framework defines both stakeholder contributions and requirements. Stakeholders include customers, suppliers, employees, investors, authorities and society at large.

Stakeholders each have contributions. As a stakeholder, they have an interest in the success of the organization. By offering their business, opinions and trust, customers fuel the organization's growth. In addition to good products and services, suppliers should offer an efficient buying process that is reliable, fast, easy and leads to the right price. Employees offer their hands, their minds, their hearts and their voices in the market. Investors offer capital and their support, but also take credit risk. Authorities ensure there is a fair market, with clear rules, and can provide advice. Lastly, the community provides an infrastructure within which to do business. This includes access to skills and the means to create positive public relations through the media.

An enterprise architecture describes the impact of these contributions on the organizational structure, its systems and processes; and it describes how changing contributions affect the enterprise architecture. But there is more. In order to count on stakeholder contributions, we need to take stakeholder requirements into account as well.

Customers require what you demand from your suppliers. Next to good products and services, you should offer an efficient buying process that is reliable, fast, easy and leads to the right price. Suppliers require what you have to offer as a customer: profit, growth, your opinion and trust. Employees require pay and care, but also the opportunity to build skills and receive feedback on how their work is contributing to organizational success. Investors obviously expect a return, but also transparency so they can keep faith in their investment. Authorities expect organizations to obey the law, conduct business in a fair way, run safe operations and be truthful in their reporting. The community is looking for jobs, a share of the wealth that is created and a certain amount of fidelity.

As the Performance Prism describes these stakeholder contributions and requirements in great detail, the change that they bring can be detected, to a certain extent predicted, and taken into account to build an agile enterprise architecture. It is important to remember that relationships with the environment are reciprocal. Simply extracting value from the larger ecosystem is not sustainable.

The Formal Cause and Final Cause

The formal cause describes how the object of analysis looks – its form. A statue can depict a human being, a horse, or an abstract three-dimensional pattern called “happiness.” Understanding an object’s form is needed to describe that particular object. In order for something to be called a house, it usually has a roof, a door, windows and, in some houses, a chimney and a garden. Without this explanation and a clear blueprint, the house could look totally different or – in the absence of any formal cause – be just a collection of materials neatly packed on a piece of land.

With the knowledge we have today, the formal cause doesn’t have to be a static result, like a statue, a house or – in terms of an enterprise architecture – a description of all the organizational functions the architecture supports.

With the advent of service-oriented architectures, we can take the formal cause one step further and create an agile enterprise architecture that is continuously being recomposed. Service-oriented architecture may form the technology component, but the thinking behind it can also be applied to organizations, creating a service-oriented organization. If all activities are seen as a business service, not as a step in a process, they can be put together in multiple, probably countless, ways. A business service is a unit of work that leads to a transferable result: The result is sufficient for the next person to continue, even if the next person is the customer. Viewed from the IT perspective, a business service represents the functionality to be developed to support the task. From the perspective of the organization model, a business service represents the role an employee performs to complete the task. Business services are not focused on specific processes and products, but focused on competencies that can be used for a multitude of things. There are many business examples available. Since the beginning, breweries have realized that their distilling process can be used for other spirits as well, such as whisky. Amazon realized its infrastructure is not only capable of selling books, but also of selling second-hand books, goods other than books, and even IT capacity itself (cloud computing). Utility companies, such as the electricity company, sometimes offer invoicing services for other utilities, such as water and gas. The capability is at the center, not the product.4

Seen this way, it is not very interesting to define the formal cause as a full description of all business services. This can be done on an aggregated level, and other than that the enterprise architecture can declare to “let there be business services.” A far more interesting approach would be to describe how business services should look (the form they have!), how they can be standardized and how they can interact.

If you think this through, this approach actually reconciles the opposing forces of entropy and evolution on one hand and enterprise architecture on the other. Enterprise architecture is no longer fighting evolution and entropy, but rather embraces it. In fact, service orientation on any level is very much like evolution. In order for biological components to mix, they need extreme standardization on the DNA level too. Random variation is nothing other than trying all kinds of DNA combinations.

It should be said that you can argue whether evolution belongs in the formal cause. Evolution creates random variation and doesn’t concern itself with how something should look. And evolution certainly doesn’t seem to belong in the final cause, as there is no meaning to random variation. Aren’t the latter two causes more the territory of “intelligent design”? This argument is relatively easy to counter. Adaptation exists by the grace of evolution, and the form that fits its natural environment best will succeed and procreate.

Final Cause

The final cause is the most important. It describes the purpose of the object, the essence of its being. Once a final cause is in place, the material cause, efficient cause and formal cause can, in principle, be derived. They follow from the goal. If the final cause of a statue is to show the magnificence of the emperor going to battle on his horse, the first step is to make a wax model. Then the bronze is melted, poured, and further treated. Each and every step is bringing the idea of the statue closer to becoming reality.

At first, it is a bit odd that the final cause is a cause. Isn’t it the result? The final effect? Aristotle maybe called the final cause the most important one because it is the initial idea that triggered the other causes. Because you wanted it to be reality, it becomes reality. Because you want to be an entrepreneur, you start your own business.

Still, the causality isn’t that simple. Let’s return for a second to the “structure follows strategy” debate. You may want to be the world’s best basketball player; but if you are not tall and athletic, it is unlikely it is going to happen. And if you don’t have an athletic posture, you probably would never have the idea to become the world’s best basketball player. The final cause closes the loop. It is what triggers change, and it is the result of change.

One of the best books I read on the subject, Enterprise Architecture as Strategy, by Jeanne Ross, Peter Weill and David Robertson, elaborates greatly on different business operating models (different final causes) and how that leads to different enterprise architectures. Ross et al describe a two-by-two matrix, with one axis describing an increasing integration of business processes and the other describing increased business process standardization. Low standardization and low integration mean a diversified business strategy and operating model. The key capability for any enterprise architecture is to provide economies of scale, without limiting independence.

A high level of standardization with low integration is the main characteristic of a business model based on replication. Business units share best practices, and the enterprise architecture focuses on creating, managing and disseminating standard components.

A high level of integration with a low level of standardization is the hallmark of a coordinated business, where various specialized business units need to collaborate. Enterprise architecture in this model is all about providing access to shared data and data exchange. Highly integrated and standardized businesses benefit most from an enterprise architecture that reinforces standard processes and enterprise systems.

Depending on the operating model you have, a certain enterprise architecture will follow. The final cause. Yet, new technologies and more agile enterprise architectures also enable new blends in operating models, and once in a while completely new business models. The final effect.

The Ultimate Enterprise Architecture Framework?

Aristotle aimed to explain all form and matter with his four causes. This includes enterprise architecture, even though obviously the concept didn’t exist in Aristotle’s time. Does this mean that the four causes are the ultimate enterprise architecture framework? Probably not. Existing leading frameworks such as Zachman and TOGAF are generic frameworks to cover all sorts of enterprise architectures, while at the same time being very specific in covering aspects of enterprise architecture only. They are not theories-of-everything. This makes existing enterprise architecture frameworks particularly valuable.

In fact, the Zachman Framework is almost structured in terms of causes. It introduces a number of levels (contextual, conceptual, logical, physical and detailed) and then introduces a series of questions for each level. These questions are: Why? How? What? Who? Where? When? This is a very structured approach toward creating a detailed explanation, very much like Aristotle’s causes but practically applied and offering much more guidance specifically toward creating an enterprise architecture.

Still, there is always room for improvement, even when the advice is 2500 years old. For instance, it took TOGAF until version 9 to become more business focused, and therewith introduce what we here call the final cause. Before version 9, TOGAF was really IT focused, architecture for its own sake. And although Zachman offers a comprehensive framework, it could do better in emphasizing the efficient cause. The “who” question is still very much about the material cause, identifying the roles and skills within the organization. The same goes for the stakeholders that are connected to the various levels in the framework – largely internal to the business. The contextual level could (should?) develop more into the direction of the efficient cause.

One thing is certain: Enterprise architecture and philosophy are very much related. One of the oldest fascinations in philosophy is about what defines beauty. Aesthetics. A fascination that most enterprise architects will share.

End Notes:
  1. When you create a model that contains an optimized end state, you live within the paradigm of that model, and you are not able to look beyond the borders of it. This is exactly like examining our own lives. As human beings, we are not able to look beyond our own deaths and need to accept existing only within our own paradigm of life. However, if you are able to look beyond the borders of your own discipline, you master it and are potentially able to also grasp a new paradigm.

  2. Andy Kyte, Gartner Fellow, Gartner Symposium/ITxpo, 2010, France

  3. It is not recorded that Heraclitus spoke or wrote those words, but they were attributed to him later to describe his philosophy.

  4. Much of the description of what I call “business services” is based on the work I did with Emiel van Bockel around his concept of business elements.

  • Frank BuytendijkFrank Buytendijk

    Frank's professional background in strategy, performance management and organizational behavior gives him a strong perspective across many domains in business and IT. He is an entertaining speaker at conferences all over the world, and was recently called an “intellectual provocateur” and described as “having an unusual warm tone of voice.” His work is frequently labeled as provocative, deep, truly original, and out of the box. More down to earth, his daughter once described it as “My daddy sits in airplanes, stands on stages, and tells jokes.” Frank is a former Gartner Research VP, and a seasoned IT executive. Frank is also a visiting fellow at Cranfield University School of Management, and author of various books, including Performance Leadership (McGraw-Hill, September 2008), and Dealing with Dilemmas (Wiley & Sons, August 2010). Frank's newest book, Socrates Reloaded, is now available and is highly recommended. Click here for more information on how to get your copy today.

    Editor's Note: More articles and a link to his popular blog are available in Frank's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Frank Buytendijk



Want to post a comment? Login or become a member today!

Be the first to comment!