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. 

House Plan P5362D

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. 

House Plan P5362D

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 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 (12)

  1. Dave Beverlin says:

    Nick, this is a really interesting question. But I don’t think your example of the rendering of a house and the house plans is really the right one to use in relation to Enterprise Architecture. If we were talking about the architecture of single application or solution, I think the comparison would be valid and that you’d get (and probably have yourself) lots of examples of what that single picture might look like.

    I think a better example might be to ask what the single-picture representation for a city planner might be. They might show a high level city map as a starting point, maybe with zoning laws, but I doubt if much of the city infrastructure would be there at the highest level. I’m going to spend some looking for examples from the city planning profession that might be relevant for your question about a single-picture representation of the EA.

  2. Max says:


    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.


  3. peter foley says:

    I have been advocating the use of a process diagram (I work in a government statistical org so the main process is a bit like a factory production line). Underneath the process I represent the capabilities used by each process step. This diagram has several uses –

    a) grey out steps that the organisation can opt to outsource e.g. data collection, depending on different business models (strategic planning)

    b) overlay investment, system health etc so managers can use it for financial planning

    c) identify capability gaps

    Only at early stages of this but getting some traction.

  4. Kyle Dunsire says:

    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 (, 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.

  5. mrollings says:

    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.

  6. NickMalik says:

    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.

  7. NickMalik says:

    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

  8. Evan says:

    If you look closely at the house sketch above, you’ll notice a couple facts.  Namely, it doesn’t communicate internal detail.  Secondly, it does communicate the presence of the house in it’s surrounding environment.  The lack of internal details (the house’s implementation) is important if you are attempting to convey (at a glance) the outermost, top-level representation of the house (it with it’s relationships to the environment around it).

    I’m just going to assume here that you are aware of the immense value in seeing this high level of detail (a thing in its environment).

    One potential equivalent in the architecture world might be a diagram which depicts the organization in relationship to the environment in which it exists.  Some variant of a value chain diagram might work well here–where the organization is the central focus in the diagram, the other boxes represent external entities (vendors, customers, etc), and the connectors represent the inbound and/or outbound flow of value.

    A diagram like this would be high enough to depict the organization in it’s environment without getting bogged down into the details of the organization’s implementation.

    In addition, since design is recursive, this diagram also gives us a natural place to begin drilling into the more detailed diagrams of the organization (much like many UML tools let us do in the software world).

  9. Max says:


    I’m not sure why it‘s so important to pick a single view. I think the real goal is to design an architecture that addresses the stakeholder’s needs and effectively communicate that solution to them (by means of views for example), so they can evaluate the solution or make other decisions; or to influence your stakeholders to make certain decisions. In any case the architect (or a sales person) needs to present them some information.

    I do appreciate the fact that top level managers probably don’t need to see the details, but rather would be interested in a high-level information, but I still don’t understand why it’s important to have a single view for such an audience.

    If all they want/need to see fits on a single view that’s fine, but what if there are two important distinct aspects of the architecture that cannot be represented on a single view? Or what if those two aspects would be much easier to understand and communicate if they are separated?

    In the example with the floor plans, I think the reason the view works is because it’s mostly for people who buy houses. Those people are mostly concerned about the room layout and the size. And the view is perfectly communicates that information. But I doubt it would be very useful to say an electrician.

    Now, if we know what the stakeholders really care about, then we can see if that information can be expressed on a single view. But trying to answer a question about a single view in general for entire enterprise architecture for any kind of organization can probably be difficult.

    So, I guess the right question to ask would be what are specific organization stakeholder’s needs and priorities.


  10. NickMalik says:

    Hi Evan,

    I was thinking of something to that effect. Back to the picture of the house: let’s say that we own a plot of land with trees and a slope on it.  We want a house, but the style of house is "up in the air."  Then images of this kind would be VERY helpful to make a quick choice between things like "modern" and "colonial style."

    My concern is that a model that shows the enterprise in relation to its environment is the place to start, but I want enough detail to present alternatives to top-level folks.  A set of alternatives has to have some detail about the house itself (the enterprise) so that it is clear how the enterprise is specifically adapted to that environment, and by implication, what it would be like to "live in the house" that we are describing.

    So I’d start with the notion of the enterprise in its environment, but I’d like more detail about the enterprise itself than is commonly illustrated in the diagrams you refer to (that I have seen).

    — N

  11. Evan says:

    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:


    -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). 😉

  12. I think I would start with the global domain areas and the standardized relationship technologies between the components to be… I would leave out the component implementations.


Skip to main content