The business of EA

After a quarter century of intense and costly investment in enterprise architecture (EA), many companies are still struggling to identify actual value. This is extraordinary. EA's benefits have been well documented, and it seems absurd that anyone should have to struggle to prove the reasons for implementing EA, or to have to quantify its benefits.

Yet, and this is reasonably widespread, many companies which embark on an EA initiative find themselves a year or two down the line losing interest and discontinuing the investment.

The reason for this, almost always, is that EA has been driven by IT, when it is a business issue.

EA should always arise from or at least be supported by business. When IT is the originator and owner of EA, it becomes a departmental, or siloed, initiative focused mostly on the software architecture rather than the business need.

It should be patently clear to any observer that EA, as its name implies, is an architectural imperative that spans the entire enterprise.

This is the way John Zachman, the father of EA, envisaged it. EA does not begin and end with IT. Limiting it to IT reduces the benefits and again creates a technology view of the business rather than a business view and how it is supported, with IT just one of the supporting services.

To understand where EA begins and ends, consider a battleship, a skyscraper or even a motorcar.

These examples would not be designed or manufactured without a blueprint - an architecture. Manufacturers would typically conceptualise, architect, build, test and then deploy or manufacture.

A bridge or highway could not be built without such an approach. People would die if this was done.

So how is it that companies are allowed to begin life without an architectural approach?

The answer, of course, is that almost always an entrepreneur comes across an idea, sees a market opportunity, launches a company and starts turning a profit quite quickly. Starting a business is about identifying risk, mitigating it, and turning a profit as soon as possible.

The big issue regarding change is the ability to anticipate its impact before it occurs.

Freda du Toit is director of Kgali Investment Holdings.

Depending on the skill, experience and qualifications of the entrepreneur in question, the business could be very formally structured, or less so. The CEO is looking for one thing: profitability as soon as possible; and fine-tuning of structures will be done subsequently.

This approach makes change inordinately difficult to implement. So, often, an insurance company will be created out of the blue, and when change occurs, as it always does, it is exceptionally difficult and costly to accommodate.

Had the organisation been architected from day one, this would not be the case. The big issue regarding change is the ability to anticipate its impact before it occurs. This implies an ability to understand the linkages between the various aspects of business and how they impact each other. Even though it is more difficult, it is not impossible to define the architecture of a business, even if it has been running for many years. The value of doing this is usually higher than anticipated - it forces the organisation to look from the outside in, which tends to create new insight.

To go back to the beginnings of EA, it is necessary to look at the very basis of knowledge, and this goes back to the ancients, the Greeks, who understood thousands of years ago that all of knowledge could be broken down into a few, logical structures. Zachman brought these structures back into the public domain in the late 80s in a manner that was logical and intuitive: a true “aha”, or “Satori” moment:

* EA can be viewed as “the intersection between two historical classifications that have been in use for literally thousands of years”.
* "The first is the fundamentals of communication found in the primitive interrogatives: What, how, when, who, where, and why. It is the integration of answers to these questions that enables the comprehensive, composite description of complex ideas.”
* "The second is derived from reification, the transformation of an abstract idea into an instantiation that was initially postulated by ancient Greek philosophers and is labelled in the (Zachman) Framework: Identification, definition, representation, specification, configuration and instantiation."

If this all sounds complex, it isn't. It's all perfectly logical, and it finds its expression in business quite logically in questions such as: What do I need to fulfil my mission? Where is it? How much money do I make? How many people do I have and do I need? What plant, material and capital do I require?

In future Industry Insights in this series, I'll look further at enterprise architecture and how to align it with business imperatives and ensure that IT is subservient to it, and not vice versa.