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.
4 thoughts on “Go Build an Enterprise Architecture”
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.
Glad to see you agree. So why call this work architecture?
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…
Wow, Jack. Excellent response.
I will grok this and post again.