The Enterprise Architecture Definition Collection - Part I

Update: I've been collecting a lot of definitions lately, so I'm going to tie this post off as "Part I' and start Part II here. If you've read this post before, all new definitions and descriptions  from January 31,2007 forward are listed in Part II.

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. Updated January 23, 2007.

----------------------------------------------------------------------------------------------------------------------

Enterprise architecture is the planning process of an organization that leads to the implementation of business strategy and processes.

I've intentionally left out the words technology and models.  Models are tools for communication and doucmentation.  Technology is a tool that is often used these days to achieve the ultimate goal of enterprise architecture.  EA could be equally applied to a lemonade stand as it could to a multi-national corporation, the methodology remains the same.  Architecture is not, ultimately, about technology... though it is very practical to use EA as a planning tool that, of course, often includes technology as a very important aspect.

Stephen Anthony in his blog, January 23, 2007. Posted January 23, 2007.

----------------------------------------------------------------------------------------------------------------------

In the spirit of agility, I propose a single sentence definition:

   

Enterprise

architecture is a set of models describing the technical implementation of business strategy and processes.

Bill Barr, in his blog, November 29, 2006. Posted January 23. 2007.

----------------------------------------------------------------------------------------------------------------------

The FEA (Federal Enterprise Architecture) consists of a set of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of the FEA in a common and consistent way. Through the use of this common framework and vocabulary, IT portfolios can be better managed and leveraged across the federal government. This chapter introduces the purposes and structures of the five FEA reference models:

• Performance Reference Model (PRM)
• Business Reference Model (BRM)
• Service Component Reference Model (SRM)
• Technical Reference Model (TRM)
• Data Reference Model (DRM)

PRM: The PRM is a framework for performance measurement providing common output measurements throughout the federal government. It allows agencies to better manage the business of government at a strategic level, by providing a means for using an agency’s EA to measure the success of IT investments and their impact on strategic outcomes. The PRM accomplishes these goals by establishing a common language by which agency EAs can describe the outputs and measures used to achieve program and business objectives. The model articulates the linkage between internal business components and the achievement of business and customer-centric outputs. Most importantly, it facilitates resource-allocation decisions based on comparative determinations of which programs and organizations are more efficient and effective.

BRM: The BRM provides a framework facilitating a functional (rather than organizational) view of the federal government’s lines of business (LoBs), including its internal operations and its services for citizens, independent of the agencies, bureaus and offices performing them. The BRM describes the federal government around common business areas instead of through a stovepiped, agency-by-agency view. It thus promotes agency collaboration and serves as the
underlying foundation for the FEA and E-Gov strategies.

SRM: The SRM is a business-driven, functional framework classifying Service Components according to how they support business and performance objectives. It serves to identify and classify horizontal and vertical Service Components supporting federal agencies and their IT investments and assets. The model aids in recommending service capabilities to support the reuse of business components and services across the federal government. IT investments can be service providers or consumers. Service providers allow consumers to reuse their business and technical capabilities. The SRM is organized across horizontal service areas, independent of the business functions, providing a leverage-able foundation for reuse of applications, application capabilities, components, and business services.

TRM: The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective. Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability.

DRM: The DRM is a flexible and standards-based framework to enable information sharing and reuse across the federal government via the standard description and discovery of common data and the promotion of uniform data management practices. The DRM provides a standard means by which data may be described, categorized, and shared.

United States Government, FEA Consolidated Reference Model Document, Version 2.1 (edited), December, 2006. The PDF of the entire document can be viewed and/or downloaded here. Posted January 6, 2007.

----------------------------------------------------------------------------------------------------------------------

Maybe the problem is that the word enterprise is abused. Some folks consider the word to refer to size of organization, while others thinks that it refers to a class of software in terms of its ability to scale along a variety of dimensions. Of course, as someone who has been called enterprisey on multiple occasions, I don't subscribe to any of these definitions. The best definition and the one I subscribe to is that the real meaning of enterprise refers to a sales model. If some non-technical guy shows up in a suit ready and willing to do chock-a-block eye candy Powerpoint presentations that lack substance for a solution, then it is enterprise. If the solution simply works and doesn't require talking with sales folks then it isn't enterprise.

Self-proclaimed "Thought Leader" James McGovern in his blog, November 5, 2006. Posted November 5, 2006

----------------------------------------------------------------------------------------------------------------------

An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.

Microsoft's Michael Platt offers a view of enterprise architecture as containing four points-of-view, called the business perspective, the application perspective, the information perspective, and the technology perspective. The business perspective defines the processes and standards by which the business operates on a day-to-day basis. The application perspective defines the interactions among the processes and standards used by the organization. The information perspective defines and classifies the raw data (such as document files, databases, images, presentations, and spreadsheets) that the organization requires in order to efficiently operate. The technology perspective defines the hardware, operating systems, programming, and networking solutions used by the organization.

Purported advantages of having an enterprise architecture include improved decision making, improved adaptability to changing demands or market conditions, elimination of inefficient and redundant processes, optimization of the use of organizational assets, and minimization of employee turnover.

SearchCIO.com - CIO Definitions, June 8, 2005. Posted October 13, 2006.

------------------------------------------------------------------------------------------------------------------

The enterprise architecture is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the company's operating model (where the operating model is defined as the necessary level of business process integration and standardization for delivering goods and services to customers). The enterprise architecture provides a long-term view of a company's processes, systems, and technologies so that individual projects can build capabilities - not just fulfill immediate needs.

Jeanne W. Ross, Peter Weill, David C. Robertson, Enterprise Architecture As Strategy, Harvard Business School Press, 2006. Posted October 3, 2006.

---------------------------------------------------------------------------------------------------------------

Definition: Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate. An Enterprise in this context is any collection of organizations that has a common set of goals/principles and/or single bottom line. In that sense, an enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, or a network of geographically distant organizations linked together by common objectives. Elements in this context are all the elements that enclose the areas of People, Processes, Business and Technology. In that sense, examples of elements are: strategies, business drivers, principles, stakeholders, units, locations, budgets, domains, functions, processes, services, information, communications, applications, systems, infrastructure, etc.

Institute For Enterprise Architecture Developments (IFEAD), "Trends in Enterprise Architecture 2005: How Are Organizations Progressing?" Posted June 9, 2006

--------------------------------------------------------------------------------------------------------------

Good Enterprise Architecture:

• Improves internal communications by providing a common language for describing how technology can support business initiatives.
• Helps companies link business and IT priorities by creating road maps for decisionmaking about technology initiatives.
• Helps reduce costs by encouraging technology standards throughout the organization, thus allowing IT to pinpoint trade-offs in project costs based on adherence to architectural requirements.
• Improves the quality of technology initiatives for business by easily explaining plans to a broad range of constituents.

Poor Enterprise Architecture:

• Enforces the use of technical terms and jargon that confuse both business and IT.
• Creates such a high level of detail for defining technology initiatives that decisionmaking is paralyzed.
• Requires a level of standardization that can potentially limit business-unit flexibility and speed to market.
• Has unrealistic goals for transition to new corporate technologies.

CIO Insight magazine (website), "Enterprise Architecture Fact Sheet"

--------------------------------------------------------------------------------------------------------------

Enterprise Architecture is an infrastructure and a set of Machines constructed in order to manage a chaotic, dynamic, unpredictable, complex, organic, prone to error, frustrating, Enterprise IT, which has to support an ever increasing, dynamic portfolio of products and services, through constant "ASAP, Now, Right-Away" modifications of business processes.

Muli Koppel, Muli Koppel's Blog, published February 22, 2006

----------------------------------------------------------------------------------------------------------------

Enterprise architecture (EA) refers to the manner in which the operations, systems, and technology components of a business are organized and integrated. It defines many of the standards and structures of these components and is a critical aspect of allowing capabilities and their supporting applications to develop independently while all work together as part of an end-to-end solution. An EA consists of several compenent architectures which often go by different names. Some of the common ones are: business/functional architecture; data/information architecture; applications/systems architecture; infrastructure/technology architecture; operations and execution architecture.

John Schmidt, David Lyle, Integration Competency Center: An Implementation Methodology, 2005, Informatica Corporation. Posted January 29, 2006.

Enterprise Architecture

Comments

[Aurélien]

Check out the page "How Do You Define Software Architecture?" (http://www.sei.cmu.edu/architecture/definitions.html)

It is a huge list of definition from different person. They define "software architecture" but like in "enterprise architecture" the key word is architecture.

One of my favorite from this list is

"Software Architecture is a way of developing software systems. It facilitates migration from problem space (Requirements) to solution space (Working system)"
Niraj Trivedi

[Natalija]

Robert, making a collection od definitions of EA is a worthwhile effort.
Too many deffinitions could mean that nobody knows the real essence of EA.
I'm interested in finding the true nature of things, relations and ideas.
I'd love to know what EA really is and what is it's purpose and I will continue to read your posts with great interest.

[Tanya]

A long list of definitions shows that EA's a very complex and integrated process and undergoes changers and improvement. Summing up all the definitions EA is a constant infrastructure and the manner of systems and technical components operations' development based on the logic for business.

[John Wu]

Nice collection. let me add one more.
EA is the architecture effort with enterprise consideration to overcome the chanllenge of stovepipe. It is essentail to see the whole and know the enterprise. The goal of EA is to encapsulate the complexity of IT and enable agile, simple and cost efficient IT managment. The goal can be achieved by establishing common foundation and building blocks by leaning experience from the others via reusable and predictable patterns. Reference models are the tools to learn from the others. Pleas visit http://e-cio.org/lea_book.htm for more detail.