This is Part III of my collection of enterprise architecture definitions. Parts I and II can be viewed here and here.
It's interesting, at least to me, to get a sense for all the different definitions of enterprise architecture out there. So, over time, I will post other people's definitions of enterprise architecture (and their sources) as I run across them in the literature, blogs, and websites. If you find something that should be added, please send me an e-mail (see my profile) or DM on twitter (@rmcilree). Updated February 24, 2011.
--------------------------------------------------------------------------------------------------------------------------------
The latest musty old relic to be raised from the grave is "enterprise architecture" -- the idea that all IT should be centrally planned from a top-down view. You start with a very high-level view of the organization, identify major entities and functions, and then decompose these necessarily abstract views into increasingly detailed views until you end up with executable systems.
Along the way you will be able to specify all the data and processing requirements for the entire enterprise, as well as standardize hardware requirements, software platforms, and system-development tools. When you are done, IT's path has been set and all you have to do is follow it.
Enterprise architecture had its last run from the late '70s through the early '90s. It most commonly appeared under the Information Engineering banner, but other methodologies also promoted it. Regardless of source, the goal was to develop a comprehensive model of the information needs of the entire organization -- the lofty "enterprise" -- and then drive all information-systems planning and development with that model.
Building such a model required starting with the CEO and other senior executives and modeling their view of the company. Other "stakeholders" were included as necessary. It was all a very high-level, grandiose affair that required multiple all-day sessions and lots of catered lunches. Once the high-level boys had their cut at it, other (lower-level) employees would be included in subsequent analysis and design processes to flesh out the enterprise architecture. Over time other deliverables were spawned by the process, but the enterprise architecture was the starting point and backbone -- the anchor -- of IT strategy, planning, and execution.
Chris Pickering, in the article Enterprise Architecture, RIP, Datamation/internet.com, February 24, 2011
-------------------------------------------------------------------------------------------------------------------------------
So here's my take. There are (at least) five perspectives of what enterprise architecture is.
1. EA as instrument. It's something that is used as a means-to-an-end. (Like a tool, but more general and perhaps less mechanistic than a tool.) It is wielded with such-and-such intentions to produce or maintain such-and-such outcomes. If you don't have these intentions, or you don't believe EA can produce these outcomes, then you shouldn't be doing EA at all.
2. EA as discourse. It is a language (way of talking) that expresses (and focuses attention upon) a particular set of concerns and issues. This is what establishes a certain agenda for EA, and helps to differentiate EA from various other practices (such as programme management or requirements engineering or risk management) which might appear to address much of the same problem space.
3. EA as community (of practice). There is a large number of individuals and organizations that identify themselves as part of this community, including several groups and organizations that claim to represent this community and its interests. In practice, EA can be regarded as the totality of what the EA community does in the name of EA.
4. EA as body of knowledge. Among other things, EA bodies of knowledge include various prescribed processes, but it is important to distinguish between the espoused processes (what the book says you should do) and the processes-in-use (what the community actually practises).
5. EA as trade or profession. Enterprise architecture provides a set of paid-for services to the enterprise, or to senior business managers, or to some other individual and collective stakeholders. (Payment can be in the form of salary or consultancy contract.) The commercial viability of EA and the careers of EA specialists depend on a sustainable demand for these services.
Richard Veryard, in his blog, January 13, 2011. Updated February 1, 2011
Comments