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 August 29, 2012.
--------------------------------------------------------------------------------------------------------------------------------
This entry is a bit different than ones I have previously posted as it is an ongoing discussion (or in some cases, rants, diatribes, etc.) in the LinkedIn group "The Enterprise Architecture Network." You will need a LinkedIn account and apply for membership in the group to see the discussion (should be no problem with either, as the group has close to 81,000 members). Once you are accepted into the group, look for the discussion "EA ≠EITA is a myth that dinosaur EAs cling to." EITA is an acronym for "Enterprise Information Technology Architecture." Many interesting concepts discussed in this thread if you can overlook/ignore some of the churlish posts and responses in the thread. In my opinion, the discussion warrants inclusion here not because of strict definition of EA, but a very interesting debate on what EA is today and what the future holds for it (and of course, all of us as practitioners). Added August 29, 2012.
--------------------------------------------------------------------------------------------------------------------------------
Typically the focus of Enterprise Architecture is on:
- Increasing the return on business and IT investments by more closely aligning them with business needs.
- Identifying areas for consolidating and reducing costs
- Improving executive decision making
- Increasing the benefits from innovation
- Delivering strategic change initiatives
- Managing business transformation activities
...
The Enterprise Architecture is also characterised across the following multiple dimensions:
- Direction: Enterprise Architecture is focused on strategic planning (i.e. business transformation, strategic change programmes) and not on operational change (i.e. run the business, six sigma, lean processes)
- Scope: Enterprise Architecture is focused on the whole of the business (i.e. the Business Model and Business Operating Model) for all business and IS/IT functions, and not just on the IS/IT components.
- Timeline: Enterprise Architecture is focused on the long term view of the future scenarios (up to 3/5 years in the future) and not just on a short term view of current state. Enterprise Architecture is focused on a roadmap of changes to an organisation’s capabilities.
- Value Chain: Enterprise Architecture is focused on the whole of the enterprise (i.e. the extended organization and value chain) and not just on the scope of a delivery project
- Stakeholders: Enterprise Architecture is focused on the needs and concerns of the C-level executives (CEO, CIO, COO etc.), business executives, corporate and business strategists, investors, strategic planners.
Adrian Campbell, in his blog post The Purpose of Enterprise Architecture, January 12, 2012.
--------------------------------------------------------------------------------------------------------------------------------
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
