Enterprise Architecture seminar thoughts

This posting is about the most complex object that humankind can come up with; an Enterprise. At least that is what John Zachman states at his one day seminar about Enterprise Architecture (physics 101 – Monday 23rd of August 2010 – Sydney). The first rule for the way of working is defined right at the start: when doing anything with an enterprise or start designing anything for an enterprise; make sure you understand the enterprise first. The problem is that usually people saying ‘yeah we ought to do that, but today we have got actual work to do’. In other words: the significance is often overlooked.

Zachman believes that there are laws of nature that govern and determine the success of an enterprise or company: ‘enterprise physics’. These are rules that are often not understood, but are there anyway. This can be compared with gravity, you can go ahead and defy (deny?) gravity and jump out of the window, but you will get hurt! Understanding these physics will enable you to make calculated (even scientific) decisions. Without understanding these fundaments however, nothing can be predictable. Many areas of interest and science have their own ‘framework’ to enable them to (consistently) predict outcomes, but none of this exists for enterprises.

A comparison can be made with the engineering world; by meticulously describing every aspect of a design in a language that is shared and understood by all (without ambiguity) it is perfectly possible to have more than one person working on the same project (for instance a new airplane). Every part is versioned and maintained and through this shared language many people are able to construct these huge and complex machines. This could be true for other things, including Information Technology as well, and it comes down to the same base values as many frameworks: 

  • Flexibility
  • Interoperability
  • Platform independence 

Enterprise Architecture is not Information Technology

Enterprise Architecture is an enterprise issue, not an IT issue. That said, it expresses itself often through the information systems community. And for some reasons, the IT departments seem to have the right skills if any Enterprise Architecture is to be done. The fact that IT more often than not takes responsibility (if taken at all) fuels any discussions about what Enterprise Architecture really is. This issue will be addressed later. Another reason is the fact that especially the IT departments are in the frontline of facing the problems with integration issues and ever decreasing time to market. 

But why is it not an IT issue? Because IT does not matter (see article Nicholas Carr):

  • Anyone can build systems
  • Anyone can run systems 

This is why Information Technology is moving outside of the Enterprise (to the cloud?). Nevertheless, Information Technology still needs to be managed. IT tends to focus on systems, but focussing on systems leads to … lots of legacy systems. When addressing data integration, it’s probably the best idea to start over with a new fully engineered system rather than try to integrate it. ‘Scrap and restart’.

Enterprise physics

Enterprises are not designed: they happen! They are not engineered and that is why they are not lean, mean and flexible. Enterprise structure usually expresses itself through its systems, because the systems themselves have replaced the (business processes done by) people. From this point of view, enterprise have been manufactured and not engineered. The only way to solve this is to start from scratch; or you will end up with an inflexible structure anyway.

An example can be found in the car industry. It has evolved from an ‘order and then build’ concept (create from order business). Customers had to order first and once the order has been received staff would be hired, raw materials would be bought and so on. Many months would pass before the goods were shipped to the customer. Later on, this was gradually replaced by mass production where customers could buy ‘off the shelf’. Duration and delivery times were shortened by a significant amount. Even later the concept of ‘mass customisation’ was introduced. This is done by having parts predesigned and pre-manufactured so they can be combined in many ways to customize the end product. The Dell laptop is another example of this concept.

The parallel with computer systems is that here too; parts can be predesigned and pre-manufactured so that they can be used in a variety of situations and goals. A different enterprise at the click of a button! Changes in this area can include linking to (integrating with) customer systems and business processes. For instance a data warehouse system that both uses and supplies information to customers. The same concepts of interoperability and flexibility are true here. Without understanding the physics of the enterprise no calculated decision can be made for it. Say, if another company is acquired with the goal to enable better integration, you better make sure that the cost of the actual integration does not outweigh the cost of buying the company. This is an example where Enterprise Architecture can be applied.

Managing change

So who is going to do Enterprise Architecture? If you want to integrate the enterprise, somebody is going to have to do that. The main problem enterprises are facing is change; while moving into the information age enterprises need to focus more on customers and are coping with an ever increasing faster time to market. You will have to accommodate for faster rate of change of extreme complex environments. Additionally, the other two major components are an increase of the degree of demands by customers and an increase in complexity. This can be seen all around in numerous ways. For instance in the constant increase of developing and delivery cycles of IT; which as discussed earlier often is first to express these changes.

How can this be done? By creating pre-engineered parts, enterprise wide. These parts have to be engineered because they should be created to be used more than once and in various situations. Having parts engineered also means that they are described in a way that is detailed, solution independent, unambiguous and widely recognized. The resulting designs should be viewed as assets, rather than an expense. They do not save money, but they are things that earn you money later one: an investment.

There is a management issue here: the trade-off between short term money saving and long term reusability and investment. Zachman is not too cynical on this topic however; he says CEOs and senior management want to do more on this than we give them credit for. He does state that that it requires continuous attention and a considerable time investment from the start to fully appreciate the subject. In his words the issue cannot be captured in a management summary but requires detailed discussion. And since all people generally have short term memories; the message has to be repeated at frequent intervals. Here, too, are parallels with any company education and standardization. It’s simply the only way to establish a standard way of thinking. To illustrate this topic Zachman refers to the educational system and the amount of time and training it takes to educate engineers from all over the world to use the same standards for describing the characteristics of design (decades).

So, management has to be convinced of the urgency. A good way to do this is to use the metaphor for building construction. Say if you have a building and you want to invite 5000 people at some point you have a couple of options:

  • Removing the pillars in the room; this is high risk since you don’t know how the building is designed and constructed (architected).
  • Ask another architect and reverse-engineer; since the first one asks ‘what does your architecture’ look like?
  • Create a new building

The bottom line is: if you deal with complexity and change, you deal with architecture.

Who should be the owner of Enterprise Architecture? Almost 99% of the CEOs say that the biggest problem of the enterprise is change.  The default solution is to make the one who is in charge of change owner of Enterprise Architecture. This is typically senior management because you need to have in-depth knowledge of your business. Research done by Zachman indicates that the CEO or the management level beneath the CEO has to be responsible, otherwise not enough mandate is present to effectuate Enterprise Architecture. The more management levels there are, the more people have to be aligned and convinced.

Enterprise architecture framework ontology

If you want to describe something (anything) you have to answer the following six questions:

  • What
  • How
  • Where
  • Who
  • When
  • Why

Zachman states that this is universal and can be traced back to many languages and science. These questions are the foundation for the framework for Enterprise Architecture. An implemented Zachman framework is considered an ontology, meaning a fixed set of components from which any every compound must be composed. From this finite set of precise definitions of existence, an almost infinite amount of combinations can be created. Zachman states that this is the ‘order of the universe’ which is present everywhere but we don’t always know it yet. An ontology is needed to define and to make things reproducible (and therefore enables science).

A comparison can be made to the periodical table; every element has been described with its characteristics. It is a normalized schema, so every element goes to one (and only one) cell. The periodical table doesn’t do anything, it just reflects (the order of) nature. Based on the periodical table you can predict the results of combining the elements. This proposed ontology of enterprises is the definition of enterprise architecture. Zachman says he’s very dogmatic about this and states that this is the one and only definition of enterprise architecture. Any methodology (which states how to do things) is by definition not enterprise architecture. He pleas to stop the discussion of the definition of enterprise architecture (because there cannot be a discussion) and focus on creating the content. As an example he cites the difference between ‘orality and literacy’: without written language complex ideas cannot be created (article Walter Ong).

In conclusion: a breakthrough has to be done on the ontological foundation, without this enterprise cannot mature further. ‘Perhaps we’ll know in 50 years’. 

Applying the framework

Getting the right grain for the design is difficult. The grain of the subjects is important, but an atomic level of detail is not always the solution: you just end with… a lot of grain! The broader the grain of analysis the less complex the result will become, at the cost of leverage (usability in other situations) and flexibility. Flexibility can be achieved by ‘late binding’ (at runtime). A good example is the OSI layer model for networking; every layer addresses a specific purpose and is (technology) independent of the others. Another example would be: don’t mix up data structures, UI and logic; have users define their own screen format but don’t bind it with the business process.

Using Enterprise Architecture can be compared with constructing high rise buildings and performing the safety checks for an airplane. Nobody can see this being done without having any architecture and (mandatory) control. These checks are often even defined by government legislation. Enterprise themselves also see their ‘plans’ getting checked when things go wrong (SOX, Basel2). Enterprise Architecture could enable this and perhaps in the future it will be made mandatory for enterprises, in the same way construction and airplanes are regulated. To pursue this example further: in airplane design you can literally follow a single wire throughout the complete design and all proposed changes can be calculated in simulations. This is the level of detail Zachman would like to see for enterprises. For instance: if you move the company headquarters to another city, which business processes are impacted? Which entities are changed? How will the distribution be different? 

Final thoughts

Zachman explains that he has not ‘created’ or ‘defined’ this framework, but it has simply manifested itself by looking at the patterns from other (more established) industries (planes, trains, automobiles). And by referring to other fields of work, especially science. Every field of work has an ontology in some way or another and in time perhaps a similar ontology will become visible for enterprises.

Roelant Vos

Roelant Vos

You may also like...

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.