An open question about Enterprise Architecture, the noun

I frequently discuss EA as a business function, including in my last post.  However, one request that comes up sometimes is the view of Enterprise Architecture as a thing... a noun.  Many papers and some books refer to 'the" enterprise architecture.  But what is this thing, and how would you share it?

A little context.  Back in high school, I was planning to become a (building) architect.  I was fascinated by the subject and spent two years in vocational training.  I became a fairly good draftsman.  At the same time, I discovered that the community college had a course in programming in BASIC, which I took.  I fell into technology and the rest is history.  But I still think back on the days spent drawing house plans, and I occasionally reflect on the lessons I learned.

If someone were to ask me to describe the architecture of my house, the best I would be able to do is produce a SET of house plans, not a single image.  There would be elevations and floor plans and detail plans that highlighted plumbing and electrical.  There would be "wall sections" and specifications for fixtures, surfaces, and materials.  All of it, together, is necessary.  Any one view, without the other views, is incomplete.

Yet, for some key audiences, and in some situations, a single view is necessary.  When you want to get agreement on high level goals, or set a vision for an entire organization, you need one picture.  One image to rally around. 

For house plans, I'd produce a rendering (a color perspective drawing).  If someone wants more information, then the elevations (each side, directly) and the floor plans with minimal detail could be produced. 

This is plenty for anyone who just wants to compare or understand, but doesn't need to actually construct the house.  This level of detail allows you to review choices.  Add some detail, and this is sufficient for a ballpark estimate.  You'd need a LOT more detail to build it.  (Special thanks to HouseOfTheWeek.com where you can see this house, and buy these and many other house plans).

By comparison, there is no standard approach for Enterprise Architecture.   Has anyone tried to create a consensus about what is in a single-picture representation of an enterprise architecture?  If so, I'd love to see that attempt.  There has been an attempt at describing the entire set, many attempts in fact.  The Zachman framework stakes the most comprehensive position.  Yet, even then, there is little consensus on what a single view of an enterprise architecture should have in it, and we have a fairly uneven track record for setting standards for any one view, even in something like the Zachman Framework.

For an all-up view, I believe the requirements are as follows: sufficient detail to allow top-level people to understand the problem and make choices about a solution.  Simply representing information is not sufficient, if it doesn't lead to hard choices.  In other words, it is not sufficient that we present a model that indicates that "water is wet" or that we store customer information in a database.  We must be able to present many different models, and have the business react to what they see, selecting one. 

If you were to do that... if you were to present a single model that represents your enterprise architecture, what details would you put on it? What detail would you leave off?

I'd like to hear your opinion.

Comments

• Anonymous
  June 12, 2008
  The comment has been removed

• Anonymous
  June 12, 2008
  Nick, I’m not sure such a view can be created without knowing the context: the audience, the purpose, etc. Here is my opinion about how different views are created: I would like to think that when an architect designs the architecture, he/she has some set of design goals. Those goals come from different stakeholders. To achieve different goals the architect might need to think about different aspects of the system and create different set of structures. Each set then can be documented. So, by looking at such a document (that can be a diagram, text, etc.) an interested stakeholder can see how his/her specific concerns are addressed. But those documents will most likely present different information. For example, let’s say a solution architect has two design goals – maintainability and performance (of course each of them should be defined in more details). To achieve maintainability (design time issue) the architect will be concerned about how the system is decomposed in modules (classes in OO) and interfaces between the modules. However to achieve performance (run time issue) the architect will probably think about things like processes, threads, synchronization, time budget, etc. The documented views then will look differently and different stakeholders would be more interested to look at the views that address their concerns. So, I’m not sure how one can come with a single view that addresses different concerns. Thanks.

• Anonymous
  June 12, 2008
  The comment has been removed

• Anonymous
  June 12, 2008
  A good question Nick, and one I have pondered in the last issue of the GEAO journal. At the company I used to work for, Avolution (www.avolution.com.au), we embraced the view that the Enterprise architecture is embodied in the model itself - not the views. Using a static, size-bounded 2D drawing to view an entire EA is fundamentally problematic. Which is why there is no standard form. To overcome this, Avolution built the ABACUS tool to allow you to view architectures in 3D. By using hierarchy, and a dynamic interactive environment, you can have your entire EA in one view. Additionally, you can still have the usual (but consistent) 2Ds view of the same model. Of course 3D takes a little getting used to, and it's not much good on paper. But paper is so nineties... and the execs love colorful 3D.

• Anonymous
  June 13, 2008
  BTW, if you really wanted only one view, the operating model for an organization (as defined in the book "Enterprise Architecture as Strategy")would get my vote. Gaining agreement to it provides the best guidance for an enterprise architect.  It allows you to understand business resolve for process standardization and integration expectations.

• Anonymous
  June 13, 2008
  Thank you mrollings.  Recognize, however, that the operating model for the organization is a statement, not an image.   Perhaps detailing out what this means, which becomes something of an organizational - functional business model, would be sufficient as a single view... hmmm... Interestingly, the authors of that book do NOT suggest the operating model as the "single picture" view of enterprise architecture.  They illustrate different "styles" of pictures, one for each type of operating model, but do not assert that the operational model itself is interesting.  Oversight? Makes me wonder.

• Anonymous
  June 14, 2008
  Hi Max, Does the perspective drawing of the house illustrate the plumbing viewpoint?  Can you tell what the size of the living room is?   This is a "pick one" exercise.  There are many views possible.  We need to pick one. Let's resign ourselves to the fact that a single view of an enterprise architecture will NOT communicate everything.  But it does need to communicate something, and most importantly, it needs to be distinct enough that I can think up five different choices and, assuming the choices are substantial, they will look different on that top-level view. Let's say you are deciding what house to build.  If you are looking through a catalog of house plans, where every page has house pictured on it, you have enough information to order a set of plans.  You might order three sets (but at $100 each, you won't order 20).   You made a very important decision by picking one or two alteratives. The top-level view of an Enterprise Architecture, IMHO, should illustrate the organization, and it's tradeoffs, well enough to make a top-level decision like that.   --- N

• Anonymous
  June 17, 2008
  The comment has been removed

• Anonymous
  June 17, 2008
  The comment has been removed

• Anonymous
  June 17, 2008
  The comment has been removed

• Anonymous
  June 18, 2008
  Agreed.  And it will depend on what you might put on that diagram, but at a minimum, you'd be able to convey at least the following with the top-level value chains diagram: -Industry -Position/Role within the Supply Chain (Manufacturer, Distributor, Retailer, eCommerce) -Sources of Income/Expenses I think, like you mentioned, it would likely be combined with another diagram (or two) to give a bit more detail about the implementation of the organization if you were going window shopping (ie..the sketch plus floor plans you show above).  The equivalent of the floor plans for this scenario I'd have to think about a bit more though (structural vs behavioral, etc). ;-)

• Anonymous
  June 20, 2008
  The comment has been removed