2                       Enterprise Architecture

2.1                Why Enterprise Architecture?

The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. Further, it details the structure and relationships of the enterprise, its business models, the way an organization will work, and how and in what way information, information systems, and technology will support the organization’s business objectives and goals. This makes IT a responsive asset for a successful modern business strategy.

Today’s CEOs know that the effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation; in essence, it aligns IT with the business. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it assures the needs of the organization for an integrated IT strategy, permitting the closest possible synergy across the extended enterprise.

The technical advantages that result from a good enterprise architecture bring important business benefits, which are clearly visible in the bottom line:

         A more efficient IT operation:

—     Lower software development, support, and maintenance costs

—     Increased portability of applications

—     Improved interoperability and easier system and network management

—     Improved ability to address critical enterprise-wide issues like security

—     Easier upgrade and exchange of system components

         Better return on existing investment, reduced risk for future investment:

—     Reduced complexity in IT infrastructure

—     Maximum return on investment in existing IT infrastructure

—     The flexibility to make, buy, or outsource IT solutions

—     Reduced risk overall in new investment, and the cost of IT ownership

         Faster, simpler, and cheaper procurement:

—  Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan

—  The procurement process is faster – maximizing procurement speed and flexibility without sacrificing architectural coherence

Using an architecture framework will speed up and simplify architecture development, and communication with non-architects, ensuring more complete coverage and understanding of the designed solution. The additional understanding across the enterprise enables faster response to changing business needs.

2.2                Definitions

A good definition of enterprise in the context of this Technical Standard is any collection of organizations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The term “enterprise” in the context of “enterprise architecture” can be used to denote both an entire enterprise, encompassing all of its information systems, and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

The definition of an architecture used in ISO/IEC 42010:2007 [2] is:

“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”

As in TOGAF, ArchiMate embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology [2]. We use “architecture” in two different meanings, depending on its contextual usage:

1.          A formal description of a system, or a detailed plan of the system at component level to guide its implementation.

2.          The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

We endeavor to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 – ensuring that our usage of terms is consistent with the standard – and retaining other commonly accepted terminology that is familiar to the majority of the ArchiMate and TOGAF readership.

An architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.

An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

2.3                ArchiMate and TOGAF

TOGAF is an architecture framework – a set of methods and tools for developing a broad range of different IT architectures. It enables IT users to design, evaluate, and build the right architecture for their organization, and reduces the costs of planning, designing, and implementing architectures based on open systems solutions.

The key to TOGAF is the Architecture Development Method (ADM) – a reliable, proven method for developing an IT enterprise architecture that meets the needs of your business. The TOGAF framework considers an overall enterprise architecture as composed of a set of closely inter-related architectures: Business Architecture, Information Systems Architecture (comprising Data Architecture and Application Architecture), and Technology (IT) Architecture. The ADM consists of a stepwise cyclic iterative approach for the development of the overall enterprise architecture.

The ArchiMate language, as described in this Technical Standard, complements TOGAF in that it provides a vendor-independent set of concepts, including a graphical representation, that helps to create a consistent, integrated model “below the waterline”, which can be depicted in the form of TOGAF’s views.

The structure of the ArchiMate language neatly corresponds with the three main architectures as addressed in the TOGAF ADM. This is illustrated in Figure 1. This correspondence would suggest a fairly easy mapping between TOGAF’s views and the ArchiMate viewpoints.

Figure 1: Correspondence between ArchiMate and TOGAF

Some TOGAF views are not matched in ArchiMate, however. Partially, this is because TOGAF’s scope is broader and in particular addresses more of the high-level strategic issues and the lower-level engineering aspects of system development, whereas ArchiMate is limited to the enterprise architecture level of abstraction and refers to other techniques both for strategies, principles, and objectives, and for more detailed, implementation-oriented aspects (however, Chapter 11 gives some suggestions for possible extensions of the ArchiMate language in these areas). Secondly, although some of the TOGAF views cannot easily be mapped onto ArchiMate viewpoints, the ArchiMate language and its analysis techniques do support the concepts addressed in these viewpoints. Conversely, ArchiMate viewpoints that deal with the relationships between architectural layers, such as the product and application usage viewpoints, are difficult to map onto TOGAF’s structure, in which views are confined to a single architectural layer.

Although there is no one-to-one mapping between them, there is still a fair amount of correspondence between the ArchiMate viewpoints and the views that are defined in TOGAF. Although corresponding viewpoints from ArchiMate and TOGAF do not necessarily have identical coverage, we can see that many viewpoints from both methods address largely the same issues.

TOGAF and ArchiMate can easily be used in conjunction and they appear to cover much of the same ground, be it with some differences in scope and approach.