Enterprise architecture

The term, Enterprise Architecture, refers to many things. Like architecture in general, it can refer to a description, a process or a profession.

To some, "Enterprise Architecture" refers either to the "structure" of a business, or the documents and diagrams that describe that structure. To others, "Enterprise Architecture" refers to the "business methods" that seek to understand and document that structure. A third use of "Enterprise Architecture" is a reference to a "business team" that uses EA methods to produce architectural descriptions of the structure of an enterprise.

A formal definition of the structure of an enterprise comes from the MIT Center for Information Systems Research:

Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. [MIT Center for Information Systems Research, Peter Weill, Director, as presented at the Sixth e-Business Conference, Barcelona Spain, 27 March 2007 [http://www.iese.edu/en/files/6_29338.pdf] ]

It is often said that the architecture of an enterprise exists, whether it is described explicitly or not. This makes sense if you regard the architecture as existing in the system itself, rather than in a description of it. Certainly, the business practice of Enterprise Architecture has emerged to make the system structures explicit in abstract architecture descriptions. Practitioners are called "enterprise architects."

Methods and Frameworks

Enterprise Architects use various business methods and tools to understand and document the structure of an enterprise. In doing so, they produce documents and models, together called artifacts. These artifacts describe the logical organization of business strategies, metrics, business capabilities, business processes, information resources, business systems, and networking infrastructure within the enterprise.

A complete collection of these artifacts, sufficient to describe the enterprise in useful ways, could be considered an ‘Enterprise’ level architectural description, or an Enterprise Architecture, for short. This is the definition of Enterprise Architecture implied by the popular TOGAF architectural framework.

An Enterprise Architecture framework is a collection of tools, process models, and guidance used by architects to assist in the production of organization-specific architectural descriptions. See the related article on Enterprise Architecture Frameworks for further information.

Enterprise Architecture Areas of Practice

Many Enterprise Architecture frameworks break down the practice of developing artifacts into four practice areas. This allows the enterprise to be described from four important viewpoints. By taking this approach, Enterprise Architects can assure their business stakeholders that they have provided sufficient information for effective decision making.

These practice areas are:

# Business:
##Strategy maps, goals, corporate policies, Operating Model
##Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models
##Business processes
##Organization cycles, periods and timing
##Suppliers of hardware, software, and services
# Applications:
##Application software inventories and diagrams
##Interfaces between applications - that is: events, messages and data flows
##Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
# Information:
##Metadata - data that describes your enterprise data elements
##Data models: conceptual, logical, and physical
# Technology:
##Hardware, platforms, and hosting: servers, and where they are kept
##Local and wide area networks, Internet connectivity diagrams
##Operating System
##Infrastructure software: Application servers, DBMS
##Programming Languages, etc..

Using an Enterprise Architecture

The primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself. This includes innovations in the structure of an organization, the centralization or federation of business processes, the quality and timeliness of business information, or insuring that money spent on information technology (IT) can be justified.

There are many different ways to use this information to improve the functioning of a business. One method, described in the popular TOGAF architectural framework, is to develop an Architectural Vision, which is a description of the business that represents a “target” or “future state” goal. Once this vision is well understood, a set of intermediate steps are created that illustrate the process of changing from the present situation to the target. These intermediate steps are called “Transitional Architectures” by TOGAF. Similar methods have been described in other Enterprise Architecture frameworks.

The Growing Use of Enterprise Architecture

Documenting the architecture of enterprises is becoming a common practice within the U.S. Federal Government in the context of the Capital Planning and Investment Control (CPIC) process. The Federal Enterprise Architecture (FEA) reference models serve as a framework to guide Federal agencies in the development of their architectures. Companies such as Independence Blue Cross, Intel and Volkswagen AG ["Volkswagen of America: Managing IT Priorities," Harvard Business Review, October 5, 2005, Robert D. Austin, Warren Ritchie, Greggory Garrett] have also applied enterprise architecture to improve their business architectures as well as to improve business performance and productivity.

Relationship to other disciplines

Enterprise architecture has become a key component of the information technology governance process in many organizations. These companies have implemented a formal enterprise architecture process as part of their IT management strategy. While this may imply that Enterprise Architecture is closely tied to IT, it should be viewed in the broader context of business optimization in that it addresses business architecture, performance management and process architecture as well as more technical subjects. Depending on the organization, Enterprise Architecture teams may also be responsible for some aspects of performance engineering, IT portfolio management and metadata management.

The following image from the 2006 FEA Practice Guidance of US OMB sheds light on the relationship between enterprise architecture and segment(BPR) or solution architectures. (From this figure and a bit of thinking one can see that software architecture is truly a solution architecture discipline, for example.)
Activities such as software architecture, network architecture, database architecture may be seen as partial contributions to a solution architecture.

Published examples of enterprise architecture

It is uncommon for a commercial organization to publish rich detail from their Enterprise Architecture descriptions. Doing so can provide competitors information on weaknesses and organizational flaws that could hinder the company's market position. However, many government agencies around the world have begun to publish the architectural descriptions that they have developed. Good examples can be found at the US Department of the Interior [US Department of the Interior Enterprise Architecture [http://www.doi.gov/ocio/architecture/] ] , and the US Department of Defense business transformation agency [US Department of Defense Business Enterprise Architecture, September 2006 [http://www.defenselink.mil/dbt/] ] .

ee also

*Enterprise Architect -- a practitioner of Enterprise Architecture methods
*Enterprise Architecture framework -- A set of Enterprise Architecture tools
*IT Governance -- decisions rights and control points for managing Information Technology
*IT Portfolio Management -- tools for managing all projects or assets as a financial portfolio
*IT Service Management -- techniques for managing Information Technology as a separate business

References

External links

* [http://www.govtech.com/gt/articles/418008 Enterprise Architecture for Beginners]