//Go Build an Enterprise Architecture

Go Build an Enterprise Architecture

The word “architecture” is an odd one. It is used in many ways, including to describe the interrelationship of components within a system. 

But does it apply to the enterprise?  Not sure. 

Many times, the practice of Enterprise Architecture has been compared to city planning.  We’ve been compared to zoning boards, and planning councils and even electric utilities. 

None of those organizations call their work “architecture.”

This is probably because the analogies to architecture, at the city level, fall apart.  Cities change constantly.  They grow organically.  The limits on a city’s growth are not normally a result of the zoning process.  Limits are much more likely to come from geography, or even acts of nature like fire, flood, and earthquake, than they are by a group of planners in a city office.

So when we talk about Architecture, at the enterprise level, are we mixing our metaphors?  Are we making an assumption about the nature of change, and the nature of the ecosystem, that doesn’t make sense?  Worse, are we misleading our customers, and ourselves, by using this word?

To most people, architecture is ‘hard edged.’  Architects design things that you can touch.  Their buildings have boundaries and walls and light fixtures and those things last for decades..  But in IT, at the enterprise level, this comparison doesn’t make sense.  The boundaries of an enterprise IT infrastructure are like the boundaries of a community.  They change, sometimes very quickly, to respond to the needs of the business.

So why do we call this “Enterprise Architecture?” 

At the moment, I’m not sure. 

By |2007-05-27T00:28:00+00:00May 27th, 2007|Enterprise Architecture|4 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 Comments

  1. lynuzzle May 28, 2007 at 11:40 am - Reply

    Enterprises *are* like cities in that they change constantly, grow organically, and are subject to external constraints like law, natural and other external events(e.g., disasters). Both are systems in the "cosmic" sense; not the box-full-of-logic sense. They evolve continously. In both cases, the trick is to have clarity about your current reality, its reasonable evolutionary trajectories, and how you respond to random as well as anticipated contingencies.

  2. NickMalik May 29, 2007 at 5:20 am - Reply

    Glad to see you agree.  So why call this work architecture?

  3. Jack van Hoof May 31, 2007 at 4:28 am - Reply

    In my lingo architecture means "purposeful composition". This implies components, arrangement, connections and purpose. It doesn’t say anything of domains. It can be about a piece of music, electronic circuits, buildings, IT, organisations. Everywhere you determine components and arrange them based on (concurrent) purposes I mention it architecture. So a tree is has not an architecture (not based on predefined purpose), but a garden does. The architecture of a building combines purposes with regard to estetics, function, stability, construction, material, etcetera.

    The enterprise may be your scope of the architecture. But that is too fuzzy. Enterprise IT would be a more suitable scope in our context. But be carefull with Enterprise IT architecture. The enterprise IT is fading into a bigger global IT in the context of Internet, SaaS, Service Orientation, outsourcing, off-shoring, and so on.

    One of the purposes of IT architecture at the enterprise level is the ability to follow changes in the context. So the components must be connected in a way that makes it possible to deconnect and reconnect them with other components. This puts constraints on the components themself. That is were autonomy and loose coupling comes in place.

    So what do we call "the enterprise" and based on what purposes do we identify and arrange IT components of the enterprise. Once defined the components and how they are arranged, you might say you got an architectural description of the enterprise IT.

    See also a nice posting of our data architect: http://senseofdata.blogspot.com/2006/09/architect.html

    This is the way I look at enterprise (IT) architecture…

  4. NickMalik May 31, 2007 at 12:18 pm - Reply

    Wow, Jack.  Excellent response.  

    I will grok this and post again.

Leave A Comment

10 + twelve =