Related Links

Web Seminars

This article is featured in the 2000 Resource Guide, a supplement to the December issue of DM Review.

For those readers who have heard me talk about the subject of Enterprise Architecture, you will probably remember the frog. I have a lot of years of my professional life invested in architecture and related subjects! These are not new ideas. However, historically, as most information professionals would also recognize, in spite of the overwhelming logic of architectural concepts, those of us who care about these issues have not exactly been doing a "land office business" putting these ideas into practice.

I can think of four reasons why the reality of the deplorable lack of architecture defies the logic of architecture itself – the information age enterprise imperative.

Countercultural

First, architecture is countercultural. For the first 50 years of experience in the discipline of information systems, it has been challenging enough to simply get the systems to run. Our whole focus has been on producing running code. In fact, all of the typical performance measures are directed to that end including lines of code, function points, up time, down time, response time, mean time, expenses, budget, etc., etc. Whatever you measure, that is what you get – running code.

Although we pay verbal homage to standards, reuse, interchangeable parts, integration, design for change, administering change, alignment, assets, investments, and so on, the practical fact is we are not doing any of them. Our deficiency in this regard is complicated by the fact that the accountants, I believe, are really not that adept at putting values on things that are going to be used more than one time, with the possible exception of used cars. There is not a ready secondary market to help put residual values on bridges, roads, armies, aircraft carriers, information, models, repositories, architecture, business rules or many assets in general. The problem with many of these kinds of assets is that when you need them for survival, you might not have them unless someone has had sufficient foresight to acquire them beforehand – whether they can be "cost-justified" in a classic IT manner or not.

Thus, architecture is countercultural. We don't know how to measure it, so we are not getting it. No one yet sees acquiring it as a sufficiently critical survival issue. This brings me to the second reason we don't have Enterprise Architecture in place.

Perception

The enterprise has not associated Enterprise Architecture with survival. Making money during the industrial age has been relatively easy. This is clearly a gross over- simplification; but, basically, what was needed in the industrial age was a good product and somebody to sell it. The marketplace was big enough to absorb whatever products or services could be produced. You could spill more than you made and still make a profit. The advent of the computer contributed immensely by removing labor constraints. An enterprise could reduce costs and lower prices by replacing labor with technology. There was a great deal of room for productivity improvements through the use of automation.

As the industrial age has matured, the marketplace has become saturated. Products have become commoditized. It is pretty hard to tell the difference between Southern California Edison's electricity and Cleen 'n Green's electricity. You can shop for Guess Jeans in Johannesburg or in Los Angeles. Benneton Colors stores look the same in Stockholm as they do in Freeport, Maine. The concept of a local market is now defunct. The game has changed. Competition is global and intense. The "system" no longer is a productivity aid. The "system" is the price of entry into the game. You cannot even play in the game without extensive automation. The systems are no longer discretionary support to the enterprise. They are mandatory. Systems have replaced the people of the enterprise and are doing the work of the enterprise. In fact, many of the folks that have been in my seminars or at my presentations have heard me say time and again, "The systems are the enterprise."

In any case, the second reason for lack of architecture is the enterprise has not yet discovered that the design of the system is the design of the enterprise; and if the system can't change, the enterprise can't change! However, be that as it may, architecture still is not perceived by the enterprise to be a survival issue.

Know How

The third reason we don't see a lot of architecture in reality is that we simply haven't known how to do architecture. We owe Tom DeMarco¹ a huge debt of gratitude for teaching us how to describe the functional aspects of Enterprise Architecture, certainly at Rows 3 and 4 of the Zachman Framework.² In fact, we know how to design those cells, and I might add that the laws of coupling and cohesion are still as valid today as they ever were. Actually, Mike Hammer and Jim Champy³ have more recently brought Row 2 of the process column into focus with the concentration on business process reengineering.

Peter Chen⁴ and Bob Brown,⁵ Clive Finkelstein⁶ and Charlie Bachman⁷ have taught us how to describe and how to design the Column 1 models, the data models. And, the laws of semantic integrity have not gone away any more than coupling and cohesion have gone away.

But, beyond process and data, the state of the art has been a little thin. We don't know a lot about describing or designing the Column 3 models (the distribution models, the technology architecture, the "infrastructure," the hardware/systems software models, etc.).

We are also a little thin in the area of work flow, presentation architecture, etc., the Column 4 models. Peter Drucker⁸ has made major contributions in organizational concepts in Row 2 of Column 4; but below that, there is a lot to be learned.