Enterprise architecture

From Wikipedia, the free encyclopedia

Jump to: navigation, search
This article has multiple issues. Please help improve the article or discuss these issues on the talk page.

In management, enterprise architecture (EA) is the art and science of enterprise design. The hope for enterprise architecture is that applying systematic rational methods to the design of an enterprise will produce one that more effectively and efficiently pursues its purposes.

The phrase "enterprise architecture" can refer to both the process and the product of this application of systematic methods. As a complex process, enterprise architecture may use a framework of methods and conceptual tools.

The concept of Enterprise Architecture goes back at least to the early 1980s when it entered the research scope of Nolan, Norton & Co. (a now defunct, in the US, management consultancy). By the mid-80's both Nolan, Norton and Index Systems were delivering "IT Architectures" at major corporate clients such as Aetna, Merrill Lynch, Burlington Northern and Ford of Europe. These efforts included deep linkages to Critical Success Factors (the Index term) or Strategic Vectors (the Nolan, Norton term) of the business. From these general "design principals" were derived as well as an overall design for the business (Nolan, Norton had a concept of "Logical Locations), the overall applications, data and technology structures needed to support it. Often, due to Michael Hammer's influence at Index, Business Process Redesign was the driver of or an aspect of an Enterprise or IT Architecture effort.

Though both firms wrote about these efforts in their marketing material an early published coining of the term "enterprise architecture" to refer to both the process and product was by Steven Spewak in his 1992 book "Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology".[1] This book defined one of the earliest process frameworks for enterprise architecture.

One formal definition of the architecture 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.[2]

The Enterprise Architecture Research Forum[3] defines EA as ".. the continuous practice of describing the essential elements of a socio-technical organization, their relationships to each other and to the environment, in order to understand complexity and manage change".

The IFEAD (Institute for Enterprise Architecture Developments)[4] provides another comprehensive definition of enterprise architecture:

Enterprise architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.[5]

The National Institute of Health elaborates:

Enterprise architecture is a comprehensive framework used to manage and align an organization's Information Technology (IT) assets, people, operations, and projects with its operational characteristics. In other words, the enterprise architecture defines how information and technology will support the business operations and provide benefit for the business. It illustrates the organization’s core mission, each component critical to performing that mission, and how each of these components is interrelated. These components include: * Guiding principles * Organization structure * Business processes * People or stakeholders * Applications, data, and infrastructure * Technologies upon which networks, applications and systems are built Guiding principles, organization structure, business processes, and people don’t sound very technical. That’s because enterprise architecture is about more than technology. It is about the entire organization (or enterprise) and identifying all of the bits and pieces that make the organization work. Enterprise Architecture’s Benefits A well-documented, well-understood enterprise architecture enables the organization to respond quickly to changes in the environment in which the organization operates. It serves as a ready reference that enables the organization to assess the impact of the changes on each of the enterprise architecture components. It also ensures the components continue to operate smoothly through the changes.[6]

Practitioners of EA call themselves "enterprise architects."

An enterprise architecture description gives a holistic, systematic description of an enterprise. It encompasses business functions, business process, people, organisation, business information, software applications and computer systems with their relationships to enterprise goals.

Contents

[edit] Terminology and Terminological Distinctions

An enterprise is a complex system and its description requires the precise use of language. The discipline of enterprise architecture has developed some terminology to allow for precise description and this terminology often expresses some important distinctions. Importantly, is the use of the term, "Enterprise." The term enterprise refers to a complex, socio-technical system that comprises interdependent resources of people, information, and technology that must interact with each other and their environment in support of a common mission [7]. The term enterprise is used because it can refer to all types of organizations including businesses, government agencies, divisions of large corporations, or non-profits. The term "enterprise" is preferred by EA practitioners compared to these other names because it is generally applicable in cicumstances where the enterprise being considered is public or private sector, a whole business or corporation or a part or division of one such as a strategic business unit or a conglomerate of several organisations such as a joint venture or partnership or multiply-outsourced business operation. Defining the boundary or 'scope' of the enterprise to be described is an important first step in the EA process. It should also be noted, the term "enterprise" as used in enterprise architecture generally means more than the information systems employed by an organization.

[edit] Methods and frameworks

Enterprise architects use various business methods, analytical techniques and conceptual tools to understand and document the structure and dynamics of an enterprise. In doing so, they produce lists, drawings, documents and models, together called "artifacts". These artifacts describe the logical organization of business functions, business capabilities, business processes, people, information resources, business systems, software applications, computing capabilities, information exchange and communications infrastructure within the enterprise.

A collection of these artifacts, sufficiently complete to describe the enterprise in useful ways, is considered by EA practitioners an ‘enterprise’ level architectural description, or enterprise architecture, for short. The UK National Computing Centre EA best practice guidance [8] states

Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise.

and continues

The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organisation; its systems and data; the technology used and any other relevant spheres of interest.

This is the definition of enterprise architecture implicit in several EA frameworks including the popular TOGAF architectural framework.

An enterprise architecture framework collects together tools, techniques, artifact descriptions, process models, reference models and guidance used by architects in the production of enterprise-specific architectural description.

See the related article on enterprise architecture frameworks for further information.

[edit] Areas of practice

Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or "domains". Spewak's EAP divides the practice into two domains at 'level 2': "Business Modelling" and "Current Systems and Technology" and three subordinate domains at 'level 3': "Data Architecture", "Applications Architecture" and "Technology Architecture". The final level of Spewak's EAP is the "Implementation" or "Methods" level, which deals with "how" to migrate the Enterprise to match the new model.[citation needed] The popular TOGAF framework divides the practice into three domains: "Business Architecture", "Information Systems Architecture" and "Technology Architecture" and then subdivides the information systems architecture into "Information Architecture and "Applications Architecture". The Strategic Architecture Model allows for a flexible division into up to ten domains covering many aspects of an enterprise from its objectives and goals through its projects and programmes to its software applications and technology.[citation needed]

The dividing of the practice into a number of domains allows enterprise architects to describe an enterprise from a number of important perspectives, dividing the descriptive task between a number of individuals and allowing the practice as a whole to make good use of individual domain-specific expertise and knowledge. By taking this approach, enterprise architects can ensure a holistic description of the design of the enterprise is produced.

The popular and most common four domains and their component parts look like this:

  1. Business:
    1. Strategy maps, goals, corporate policies, Operating Model
    2. Functional decompositions (e.g. IDEF0, SADT), business capabilities and organizational models expressed as enterprise / line of business business architecture
    3. Business processes, Workflow and Rules that articulate the assigned authorities, responsibilities and policies
    4. Organization cycles, periods and timing
    5. Suppliers of hardware, software, and services
  2. Information:
    1. Metadata - data that describes your enterprise data elements
    2. Data models: conceptual expressed as enterprise information architectures, logical, and physical
  3. Applications:
    1. Application software inventories and diagrams, expressed as conceptual / functional or system enterprise / line of business architectures
    2. Interfaces between applications - that is: events, messages and data flows
  4. Technology:
    1. Inter-application mediating software or 'middleware'.
    2. Application execution environments and operating frameworks including applications server environments and operating systems, authentication and authorisation environments, security systems and operating and monitoring systems.
    3. Hardware, platforms, and hosting: servers, datacentres and computer rooms
    4. Local and wide area networks, Internet connectivity diagrams
    5. Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
    6. Operating System
    7. Infrastructure software: Application servers, DBMS
    8. Programming Languages, etc. expressed as enterprise / line of business technology architecture.

[edit] Using an enterprise architecture

Describing the architecture of an enterprise aims primarily 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 ensuring that money spent on information technology (IT) can be justified.

One method of using this information to improve the functioning of a business, as described in the TOGAF architectural framework, involves developing an "architectural vision": 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.

[edit] The growing use of enterprise architecture

Documenting the architecture of enterprises is becoming[when?] 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.[citation needed] Companies such as Independence Blue Cross, Intel, Volkswagen AG[9] and InterContinental Hotels Group have also applied enterprise architecture to improve their business architectures[citation needed] as well as to improve business performance and productivity.

[edit] Relationship to other disciplines

Enterprise architecture has become[when?] a key component of the information technology governance process in many[which?] organizations. These companies have implemented a formal enterprise architecture process as part of their IT management strategy.[citation needed] 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[which?] one can see that software architecture is truly a solution architecture discipline, for example.)

Architectural Levels and Attributes.jpg

Activities such as software architecture, network architecture, database architecture may be seen[by whom?] as partial contributions to a solution architecture.

[edit] 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 include the US Department of the Interior,[10] and the US Department of Defense business transformation agency.[11]

[edit] See also

Wikipedia Books Book:Enterprise Architecture
Books are collections of articles which can be downloaded or ordered in print.

[edit] References

  1. ^ Spewak, Steven H. and Hill, Steven C. , Enterprise Architecture Planning - Developing a Blueprint for Data Applications and Technology,(1992), John Wiley
  2. ^ MIT Center for Information Systems Research, Peter Weill, Director, as presented at the Sixth e-Business Conference, Barcelona Spain, 27 March 2007 [1]
  3. ^ http://hufee.meraka.org.za/Hufeesite/collaborations/earf
  4. ^ "IFEAD About". Institute For Enterprise Architecture Developments. Institute For Enterprise Architecture Developments. 2010. http://www.enterprise-architecture.info/ifead%20about.htm. Retrieved 2010-01-28. "IFEAD is a not for profit research and information exchange organization working on the future state of Enterprise Architecture." 
  5. ^ IFEAD's Enterprise Architecture Standards Overview
  6. ^ http://enterprisearchitecture.nih.gov/About/What/
  7. ^ Giachetti, R.E., Design of Enterprise Systems, Theory, Architecture, and Methods, CRC Press, Boca Raton, FL, 2010.
  8. ^ Jarvis, R, Enterprise Architecture: Understanding the Bigger Picture - A Best Practice Guide for Decision Makers in IT, The UK National Computing Centre, Manchester, UK
  9. ^ "Volkswagen of America: Managing IT Priorities," Harvard Business Review, October 5, 2005, Robert D. Austin, Warren Ritchie, Greggory Garrett
  10. ^ US Department of the Interior Enterprise Architecture
  11. ^ US Department of Defense Business Enterprise Architecture, (September 2006 [2], or the 2008 BEAv5.0 version [3])

[edit] See also

[edit] External links

Search Wikimedia Commons Wikimedia Commons has media related to: Enterprise architecture
v • d • e
Software engineering
Fields
Concepts
Orientations
Models

Development models: Agile • Iterative model • RUP • Scrum • Spiral model • Waterfall model • XP • V-Model
Other models: Automotive SPICE • CMMI • Data model • Function model • Information model • Metamodeling • Object model • Systems model • View model

Modeling languages: IDEF • UML
Software
engineers
Related fields
Retrieved from "http://en.wikipedia.org/wiki/Enterprise_architecture"