With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system. This paper defines information systems architecture by creating a descriptive framework from disciplines quite independent of information systems, then by analogy specifies information systems architecture based upon the neutral, objective framework. Also, some preliminary conclusions about the implications of the resultant descriptive framework are drawn. The discussion is limited to architecture and does not include a strategic planning methodology.
I recently received a note from a friend of mine who was valiantly trying to initiate some architectural activity in a very large enterprise within a very important industry sector. The note outlined all of the objections to doing architecture that my friend was encountering. The note is not significant because of one particular enterprise, nor of one particular industry. The note is significant because these are the kind of objections I hear day after day from many enterprises in many industries and the objections are coming from IT, not the Enterprise! I have copied the objections almost verbatim below. Here is his intro: Dear John - By the way - I am getting some pretty significant pushback from the IT leaders. They do not want to do architecture (i.e. create models) for the business!
All of a sudden, I have been encountering a lot of confusion between Enterprise Architecture and classic Application Development Work Products, probably because the stark reality of the Information Age is upon us! There are likely several reasons for the confusion. One thing is, historically, in the Industrial Age, we have not been very precise about the definition of Enterprise Architecture. To some people, Architecture is simply a high level description (model) of the system to be built. To others, Architecture is conceptual or logical as opposed to physical. To others, Architecture is requirements and to others, Architecture is simply principles. Probably the most confusing factor is that some of the work products (models) themselves that may be produced over the process of building traditional applications systems may actually look like architectural representations and it is hard to tell the difference.
There is always a lot discussion about talking to management about architecture and models and systems and technology and the like, and there seems to be two schools of thought.
I don't know why everybody has so much trouble figuring out the difference between conceptual, logical and physical ... let me explain this one more time ...
I am very concerned about Data Warehouse. It addresses a very real and immediate problem. It has potential far beyond its current implementationn.
Although it was from my friend Bill Inmon that I (along with many) learned about data warehouse, I am sure that there were others that were “inventing” the concept at the same time, because data warehouse is clearly an idea whose time has come. It is representative of the Thomas Kuhn “Theory of Scientific Revolutions” in which he observed that inventions are a function of the times as opposed to a function of the personalities. We have recently seen this same phenomenon where Peter Chen, Charlie Bachman, Bob Brown, Clive Finkelstein (and I am sure, others that I don’t personally know) were simultaneously inventing data modeling. Likewise, data warehouse is such a function of the times.
Recently, there has been quite a bit of discussion in the U.S. Federal Government on the subject of Enterprise Architecture. In fact, there is a Congressional order, the Clinger-Cohen Act, that requires each of the Federal Bureaucracies to produce an Architecture Strategy, which precipitated circulation of set of questions for discussion, as follows: 1. What are the most important issues raised by Architecture? 2. What are the biggest inhibitors to Architecture? 3. What are the business drivers for Architecture?
The Information Age is unfolding just as predicted by many of the sociological prognosticators of this Century. Information issues are in everyone’s mind and on multitudes of lips. It is hard to pick up a newspaper or current affairs magazine without seeing a feature on the Internet, Web Pages, E-Mail, Television Terminals or some other new technology. In fact, technology innovation is relentless and escalating and technology stocks continually drive the stock market to high after high. There is no field of human endeavor that is exempt from the onslaught of information technology
I am discovering four corruptions of architectural principles being inadvertently executed by well-meaning folks, who are thinking they are doing Enterprise Architecture, using the Zachman Framework, but that inevitably will lead them unsuspectingly into a cataclysmic disaster. First, they are renaming the Rows or Columns of the Framework in an effort to accommodate the current inventory of artifacts created during the Industrial Age. Second, they are taking model-based approaches to implementations and presuming that the models constitute the Enterprise Architecture. Third, they are integrating Frameworks by a process of aggregation. Fourth, they are separating the services of the Enterprise from the Enterprise on the basis that the Service is the equivalent of a Product. Each of the above is a kind-of Architectural malapropism. They all sound like Architecture but they actually are not Architecture and invariably will result in the classic Silver Bullet syndrome: The Zachman Framework? Well, we tried that and that didn't work!! Or, even worse, Enterprise Architecture? Well, we tried that and that didn't work!! Then it will be a decade or more before that Enterprise will be able to re-address this incredibly critical issue so vital to its survival in the Information Age. These are the Fatal Distractions!
The older I get, the more I am aware that life is a series of trade-offs and as much as we would like to have our cake and eat it too, that is a figment of our imagination. It is simply not realistic. As soon as we start thinking we can have it both ways … we are positioning ourselves for the inevitable, rude awakening! We would be far better served to clearly understand the choices we are making, set our expectations correctly and mitigate the downstream impacts of the choices we make.
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!
I hear people all the time say, Well, we bought the XYZ (usually an ERP-type) package so therefore we don't have to worry about Architecture anymore, the package vendor has done it all for us, or something like that. I usually respond by saying, Packages are really good, but they are NOT a substitute for Architecture. However, before I develop any ideas about packages, let me review some things about Enterprise Architecture.
All of a sudden, there seems to be an increased interest in the subject of Security Architecture. I would judge that this interest is being precipitated by the increased interest in Architecture in general, coupled with the Information Age characteristic of the Powershift, where everybody has access to the same information at the same time. Security becomes important because, sometimes you simply don't want to allow anybody or everybody to have access to any or all of your information (or other systems components, for that matter) at any time! Therefore, Security Architecture!
Selected articles (Concepts for Framework for EA, Enterprise Architecture And Legacy Systems, The Challenge Is Change: A Management Paper).
How do you intend to assimilate ever increasing rates of change? Change is happening. Few thoughtful people would argue with this observation as multitudes of people are being impacted personally as well as organizationally. Virtually every enterprise is being stretched to the limit, attempting to maintain its viability and/or profitability in the face of unparalleled uncertainty and change in every dimension of its environment ... from consumer to supplier, from competition and regulation to its own culture ... and, there is no respite in sight. Credible social and business prognosticators, notably Alvin Toffler (Future Shock 1970) and Peter Drucker (Managing in Turbulent Times 1980) have been anticipating this ever- increasing rate of change for decades, so no enterprise, no manager, no person should allow themselves to be caught by surprise.
In the early '80's, there was little interest in the idea of Enterprise Reengineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community. The subject of architecture was acknowledged at that time, however, there was little definition to support the concept. This lack of definition precipitated the initial investigation that ultimately resulted in the Framework for Information Systems Architecture. Although from the outset, it was clear that it should have been referred to as a Framework for Enterprise Architecture, that enlarged perspective could only now begin to be generally understood as a result of the relatively recent and increased, worldwide focus on Enterprise engineering.
The Framework for Enterprise Architecture (The Zachman Framework) and the search for The Owner’s View of Business Rules
The question has been asked, is the Zachman Framework designed to sell Business Rules? In fact, the Zachman Framework is not designed to sell anything. It is simply a classification scheme for descriptive representations of complex objects. Actually, it is a classification scheme for descriptive representations of anything, subjects or objects. In fact, it hypothesizes some descriptive representations of subjects or objects where no empirical precedent exists, much like the periodic table hypothesized chemical elements that had not yet been discovered. In a similar fashion, the Zachman Framework suggests that there is a set of models (specifically, Column 6 models) that are relevant for describing the motivation of the enterprise among which it is reasonable to expect that we would find Business Rules as at least part of the description.
In the early '80s, there was little interest in the idea of Enterprise Reengineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community. The subject of architecture was acknowledged at that time, however, there was little definition to support the concept. This lack of definition precipitated the initial investigation that ultimately resulted in the Framework for Information Systems Architecture. Although from the outset, it was clear that it should have been referred to as a Framework for Enterprise Architecture, that enlarged perspective could only now begin to be generally understood as a result of the relatively recent and increased, worldwide focus on Enterprise engineering.
I am hearing the words Knowledge Management more and more often. It always seems to have a kind-of mystique about it … kind of like oooooooOOOOoo (a little spooky) Knowledge Management ... key to innovation” ... competitive differentiator ... all ya gotta do is … Knowledge Management.
I have recently been in Europe where I spoke at a public conference and after speaking, a man came up to me and was very complimentary. He said something like, I have heard you speak a number of times and it is always great!! It makes so much sense. And, I love your passion on the subject … BUT, r e a l l y now, ... this architecture stuff, you're just kidding, right? I mean, it's really just theory, of course. That is, it's so impractical ... all this 'documentation,' models, I mean, reality is all about code ... right?
Wherever I go and talk about Enterprise Architecture, the most frequently asked question I get is, Well, how do you ‘cost-justify’ Architecture? The reason I keep getting this question is, people are having a difficult time cost-justifying Architecture. The common perception is, it takes too long and it costs too much to do Architecture and besides that, you have to do too much work before you can deliver some end results. Anyone who has these perceptions simply does not understand the concept of, nor the implementation strategies for, Architecture, nor do they understand that the Industrial Age is now and forever over and that the game has forever changed!