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?"

Tragically, this seems to be the prevailing attitude in the technology world today.  Even if we don't actually believe it, this mis-perception still tends to govern many people's behavior even when the absence of architecture lies at the heart of so many of the modern enterprise problems.  The technology culture that has evolved over the last 50 years or so, so aptly captured in the cartoon caption, "You start writing the code and I'll go find out what the users have in mind" seems impossible to change.  I heard someone say that one definition of insanity is continuing to do the same thing and expecting different results!

I would argue, we are never going to solve the enterprise problems of dealing with orders of magnitude increases in complexity and orders of magnitude increases in the rate of change until we not only believe that architecture is practical but we actually change our behavior and DO it.

In this vein, we have run three public conferences in the U.S. -- the ZIFA Forums -- on the subject of Enterprise Architecture under the auspices of the Zachman Institute for Framework Advancement (ZIFA).

In an effort to dispel the notion that Architecture is "theoretical," intellectual entertainment -- some idea dreamed up by a bunch of consultants and vendors in an effort to sell more product and services -- I deliberately populated the ZIFA Forum program for the first two years with ONLY implementing enterprise speakers ... no consultants and vendors.  I asked the implementers to describe what architectural work they had actually done, what was the result (good and/or bad), what they had learned, what they would do differently the next time, etc.  The only requirement I had was that they preface their comments by mapping the work they had done against the Framework so everyone in the room would have a precise and concise understanding of what Architecture work they were actually talking about.

Some speakers talked about a Row, some about a Column, some a Cell, some a set of Cells, some talked about slivers of Cells ... no one was doing it all.  I deliberately tried to ensure a variety ... that is, I tried to minimize duplication, such that over the period of the conference, a lot of different Rows and Columns and Cells were talked about.

The programs for the first two years were extremely well received.  The practical implementation experience, I'm sure, came as a revelation in many cases but when someone says, "this is what I did and these were the results," it is pretty hard to argue that it is theoretical or impractical!  If anyone is interested, the abstracts for all of the presentations for all of the ZIFA Forums are on the ZIFA web-site (www.ZIFA.com).

In 1998, the ZIFA Forum was held in August at the Camelback Inn in Scottsdale, Arizona.  If anything, that year's program was even more enthusiastically received than previous years, although my program strategy was completely different from the past.

Several things happened that influenced me to change the program strategy.  First, Bernie Boar, who was at AT&T at the time, sent me the manuscript of a book that he had just written, Constructing Blueprints for Enterprise IT Architectures (John Wiley and Sons 1998.) This was a book about application process models (Column 2, Row 3, and a high-level sliver of Row 4) and technology architecture models (Column 3, Row 3, and a high-level sliver of Row 4).  Bernie is a student of strategy.  He interprets Sun Tzu, The Art of War, in the context of the modern Enterprise ... "A war of rapid, disruptive movement replaces a war of defending strongholds."  It is the enterprise that can introduce continuous, disruptive change into the marketplace that wins the game.  It becomes a war of information systems.  The Enterprise that can change its systems fastest is the Enterprise that dominates.  All the other players are relegated to playing 'catch-up.'  Bernie's observation is, if you don't have a graphic depiction of your systems in terms of their functionality, hardware, systems software, connectivity (etc.) that enables you to tell at a glance what can change and what cannot change ... you are forever destined to play catch-up!  It is inevitable, you are going to be ... one of the losers!

I was excited when I saw Bernie's book.  It was the first definitive book on how to graphically depict Column 3 (Location) models such that you can determine the Enterprise propensity for change.  He had plugged a VERY large hole in Column 3 for us!!

Within a month of receiving the IT Blueprinting manuscript, I received a copy of Chris Loosley's book, High Performance Client/Server (published in 1998 by John Wiley & Sons).  This was the most lucid discussion I have ever read on how performance is a function of where the Data (Column 1) is relative to Location (Column 3), where the Process (Column 2) is relative to Location (Column 3), and where the Presentation (Column 4) is relative to Location (Column 3).  Chris makes the point that the performance of the implementation is determined at Row 2!  If you are trying to deal with performance at Row 4 or 5, it is too late.  In fact, the implementation is likely NOT to perform adequately.

After receiving these two exceptional books, it dawned on me, I personally know authors ... in many cases, authors of seminal works that describe how to actually DO the work of designing and describing almost every cell of the Framework!!  So, I populated the ZIFA Forum program largely with authors, some of whom were 'authors' of tools, and I rounded out the program with some Enterprise implementers.  In addition to Bernie Boar and Chris Loosley, I enlisted the following speakers:

Tom Bruce -- who was at the Bank of America when he wrote Designing Quality Databases Using IDEF1X Information Modeling, a seminal work on Column 1 (data) models.  The basic idea of the book is that if you want the end result to represent what the 'Owners' have in mind, each model has to accurately reflect the intent of the next higher row model.  In his presentation, Tom also was making some incredibly interesting observations about designing the data models to accommodate downstream Enterprise change.

Melissa Cook -- who is at Hewlett Packard and wrote Building Enterprise Information Architectures, a book on Rows 1 (Scope) and a high-level sliver of Row 2 (Models of the Business) for Columns 1 (Data), 2 (Process) and 3 (Location).  This is a very easy-to-read book on using classification theory to establish architectural boundaries for all ensuing implementations.  It contains one of the clearest discussions I have ever read on why architecture is so critical for the Column 3 (Network) design.  In 1998, Melissa was recounting her experience in implementing her ideas at HP.

Don Hodge -- from the Bank of America, currently building a very large set of Row 2 models (Models of the Business).  He was very interesting, not only because he represents an 'implementing Enterprise,' but also because the model they are building is very large (something over 5,000 objects at present) and also, he is using a modeling tool supplied by NCR called METIS, to capture and manipulate the model.

Tom Hokel -- from Framework Software, who built an 'Artifact Management' tool, specifically using the Framework as the basis for classifying and accessing any kind of artifact.  You can associate a document, a model, a standard, an application, or whatever with a Cell or set of Cells and then retrieve it later through the Framework.  Click on the Cell, find the artifact, launch the application where it is stored, and present it through the Framework Cell.  This tool is receiving wide acceptance and, specifically, it is being heavily used in the U.S. Air Force, Health Information Resources System.

Judi Reeder and Howard Jachter -- of Knowledge Partners and Lucent Technologies (respectively) who are building a set of Row 2 models (Models of the Business) for Lucent Technologies.  This is another 'implementing Enterprise' experience where they are building very large models to serve as a basis for bounding all ensuing 'systems' implementations and accumulating a 'meta-data' repository to serve as a control point for all I.T. decision making.  This was very interesting in that it is a kind of 'prototype' effort at Lucent to accumulate knowledge on architectures and architectural practices for subsequent deployment broadly in the corporation.

Ron Buck -- of the South Bay Group who, as CEO of IVI Publishing, produced all of the publications for the Mayo Clinic, including the very innovative "Prime Practice:  CD-ROM Series for Primary Care Practitioners."  This continuing education program for physicians is a model of Column 4, Presentation Architecture concepts that employs the practices of the publishing industry in designing 'user interfaces.'  Ron described even more interesting execution of these ideas in several Knowledge Management projects on which he is currently working.

Tom DeMarco -- who wrote Structured Analysis and System Specification (published by Yourdon Press in 1978), a seminal piece of work on Process models, Column 2, Rows 4 and 5. He could attend only by video and had some very interesting observations on architecture and reusability.  He also observed that 'Architecture' is such a powerful concept that when it is employed publicly (as a product in the marketplace), the government launches anti-trust actions to break up the implementers because they have so much dominance -- for example, IBM and its System 360 architecture, AT&T and its telephone network architecture, Microsoft and its operating system architecture.

Paula Pahos -- who, along with Prakash Rao of Metadata Management Corporation, is the author of a Repository product, "Design Bank."  If there is one technology dependency for making 'Architecture' a reality, it is a database for storing architectural models -- a Repository.  Design Bank was designed from the bottom up as a model manager and uses the Framework to organize the metamodel so that you can access the Repository contents through the Framework.  Another interesting feature of this presentation was the observation that Design Bank has been successfully implemented by the U.S. Air Force Air Mobility Command -- a huge, global, decentralized organization.

John Hall -- of Model Systems, a UK-based Architecture-consulting firm. He was the principle author of SSADM, a development methodology widely used in Europe.  As part of SSADM, Entity Life History Analysis has been modernized to become 'Event-Driven Behavior of Entities' which models the behavior of entities based on business events (Column 5) and transforms the behavior models into process specifications.  John's presentation integrated very rigorously-defined theoretical structures with a depth of practical implementation experience that can only come from decades of hands-on work.

Leo Genders -- of the Ohio Bureau of Workers' Compensation, who have adopted a top-down, Enterprise Architecture approach.  Leo was one of the 'implementing Enterprise' speakers, and he was eloquent in describing their history and current state of affairs.  The 'legacy' was eating them alive, and everything takes too long and costs too much.  It was deja vu all over again!  He was describing any and every I/S shop you have ever seen.  They have tried everything:  all the new technologies, outsourcing, packages, consultants, and the problem only keeps getting worse.  As a kind of last resort, they turned to Enterprise Architecture and are experiencing some early-on, unanticipated benefits.  It is strengthening I/S and beginning to restore their credibility with the management/user communities.

Ron Ross -- of Business Rule Solutions wrote the seminal work, The Business Rule Book:  Classifying, Defining and Modeling Rules (published by the Database Research Group).  This book describes a notation for Column 6, Row 3, 'Business Rules.'  I know of no one who has spent as much time exploring the issues of Business Rules as Ron Ross.  He continues to drive the state of the art by defining approaches for identifying and formalizing the Business Rules as derivatives of the objectives and strategies of the Enterprise (Column 6, Row 2).  Although he didn't explicitly mention this, I happen to know this new work on the derivation of rules currently is being done as an actual implementation in a large financial industry organization.

Jonathan Geiger -- who is the principle author of Data Warehousing and the Zachman Framework.  Although Bill Inmon and I authored chapters of this book (I wrote the one on 'Knowledge Management'), the book was basically a description of Jon Geiger's Data Warehousing implementation methodology, which he used while responsible for Data Warehouse at Florida Power and Light.  I continuously have people come up and tell me what a great book this is ... "the best Data Warehouse book (they) have ever read."  I am somewhat reluctant to take too much credit because Jon was the one who did the lion's share of the work!

My strategy in preparing this year's ZIFA Forum program was to remove any methodological obstacles to making Architecture a reality.  I was trying to make it clear that there is publicly available documentation that explains how to do almost every cell of the Framework and commercially available tools for building models and storing models.  (All of the books referenced are included in my bibliography which can be found on the ZIFA web-site (www.ZIFA.com).

I am not suggesting that presently, we know ALL the answers nor that we have all the tools we would like to have.  Clearly, there is A LOT more to learn.  But also clearly, we know a lot more ... and have a lot more tool capability than is generally being used.  If anyone really wanted to do Architecture, there is NOTHING that is keeping them from doing it short of actually doing the work.

1998's program, if anything, was received with even greater enthusiasm than previous years.  Even though many of the presenters are presently consultants or vendors, in virtually every case their methodologies or tools were born out of implementation experience.  In a real sense, these were 'implementing enterprise' speakers who have simply generalized their experience for general consumption.  In every case, they 'dripped with authority.'  You got the clear impression that they had been there and actually done that!

Yes Virginia, there REALLY is Enterprise Architecture.  There is NOTHING keeping you from doing it, and anytime this afternoon is not too early to get started!!

# # #