An enterprise architecture consists of the vision, principles, standards, and processes that guide the purchase, design, and deployment of technology in an enterprise. Enterprise architecture describes the interrelationships between business processes, information, applications, and underlying infrastructure for that enterprise and provides best practices for technology purchase, design, and deployment.

EA structures and processes govern adherence to an organization’s technology strategy and provide a managed environment for using new technology.

The purpose of enterprise architecture is to achieve the following:

• Allow alignment with the company’s business model and strategy
• Enable business changes and technology-based business opportunities
• Allow easier introduction of new technologies and standardization
• Drive information/data consolidation
• Reduce enterprise application integration complexity
• Facilitate outsourcing as appropriate
• Utilize assets more efficiently
• Provide the facility to assess the impact of changes better
• Ultimately reduce time-to-market

Architecture governance is essentially a control or series of controls in the development process that is efficient when supported by good documentation (principles, guidelines, standards) and communicated effectively.

To build such an enterprise architecture companies may consider using The Open Group’s Architecture Framework, or TOGAF. TOGAF is the most evolved and appropriate framework for a company that is process-oriented. Other frameworks sometimes refer to process, but aren’t as detailed as this one.

Developed in 1995, TOGAF provides the most comprehensive methodology for producing architecture deliverables. With its most recent version (8.1.1), also known as TOGAF Enterprise Edition, TOGAF’s Architecture Development Method (ADM) was substantially expanded beyond technology architecture to include business architecture, information architecture, and application architecture. TOGAF has been evolved continuously in The Open Group’s Architecture Forum over the last 12 years, drawing on the knowledge and experience of The Open Group members who are themselves practicing architects working for a wide range of large global enterprises.

It’s an open framework and highly customizable. The core components of TOGAF are its Architecture Development Method (ADM) and Foundation Architecture. The ADM defines a process for developing and maintaining an organization’s enterprise architecture and for implementing it through a planned program of work. It is non-prescriptive about how to build the models that represent the architecture and supports all standard modeling technologies, such as the Unified Modelling Language (UML), Business Process Modelling Notation (BPMN), and Integrated Computer-Aided Manufacturing (ICAM), Definition (IDEF).

The Foundation Architecture describes an enterprise continuum through which the developing architecture progresses from the general (foundation) to the organization-specific.

What makes TOGAF popular is that it’s a definitive and proven step-by-step method for developing and maintaining the enterprise architecture. It covers the four principal architecture domains of business, information systems (application and data), and technology infrastructure. It also focuses strongly on the need for the architecture to support the business objectives and requirements.

TOGAF takes into account establishing the goals and objectives of the EA effort itself. It guides users in determining how much of the enterprise is needed to model to realize significant gains and the realities of getting buy-in throughout the organization.

Running an enterprise architecture program requires solid processes with ownership and accountability. Enterprise architecture is a component of IT governance that interacts with most of the other frameworks such as project and portfolio management (PPM), quality, maturity, and security management.

EA and ITSM
Many people are now interested in understanding how enterprise architecture fits in with IT Service Management (ITSM). There’s a high level of correlation between success with enterprise architecture and commitment to ITIL. ITIL is a standardized approach and series of documents used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied in an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management, among others.

Enterprise architecture describes the interrelationships between business processes, information, applications, and the underlying infrastructure for that enterprise. Processes such as availability management, change management, or release management are just business processes particular to IT. So we can think of ITSM as another use case or usage scenario for enterprise architecture.

Many frameworks such as FEAF, DODAF, Zachman, and TOGAF do not yet consider a relationship to service management. Any architectural component has to change, solve a problem, or relate to a set of software and infrastructure. Business architecture is all about documenting, changing, and viewing specific business processes and making them more efficient. Business architecture also allows understanding the business impact of new product introductions or modifications. Products should be delivered as services and be manages by Service Level Agreements (SLAs).

New products also have to consider its availability and its capacity to perform, based on user requirements.

Clearly, running an enterprise architecture program is intimately tied to service management. Service management also has a lot to learn from enterprise architecture – for example, the definition of EA technical services can help build departmental IT service catalogs related to customer service catalogs.

EA Repository and CMDB
There are also similarities between a configuration management database (CMDB) and an enterprise architecture repository. They both integrate and analyze information from a wide range of sources, but they differ in their primary use and address, for the time being, different user needs. A CMDB contains information related to hardware, software, documentation, and the relationships between them. Any enterprise architecture tool repository should be able to import this information to avoid duplicate effort.

Both should be able to provide impact analyses but at different levels. A CMDB provides views of IT services and its associated components, while an enterprise architecture repository provides various views or viewpoints of the different architecture layers to improve the strategic alignment. The CMDB is a valuable source of EA information, particularly from the current technology architecture viewpoint as it contains hardware and software, databases, middleware, server, and security directories, network, and system management tools. In the future, some vendors might consider either the integration or the extension of their solutions to include the missing functionalities from one or the other domain.

TOGAF and ITIL
For all these reasons and the increasing interest in enterprise architecture, there was a need to compare these two frameworks and identify where the touch points exist. A white paper has recently been published by The Open Group explaining when and where ITIL and TOGAF may work together and what the synergies between them are.

This document can be downloaded at http://www.opengroup.org/bookstore/catalog/w071.htm. It specifically defines the touch points between ITIL v2 and TOGAF 8.1.1.