![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Assessing the need for enterprise architecture
According to The Open Group Architecture Framework, an architecture is either a formal description of the system or a detailed plan of the system at component level to guide its implementation. Depending on the context, architecture can also be the structure of the components, their interrelationships, and the principles and guidelines governing their design and evolution over time. In other words, it creates order from the chaos that can sometimes be an enterprise information technology environment. Expanding this definition to include enterprise architecture, the system for which we're creating these detailed plans is not just the IT infrastructure, but instead, the actual business and all the services and interactions it entails.
Developing such an architecture is quite an undertaking, even under the best of circumstances.
So let's assume you are a large organization. If you have reached a significant size, this alone suggests you are doing something right. So, that naturally raises the question: Why suffer the trouble and expense of developing an enterprise architecture? Consider these reasons:
- Control: Even before the Sarbanes-Oxley Act, there was a need for greater accountability in the enterprise. A good enterprise architecture provides transparency at all levels of the enterprise.
- Operational efficiency: Enterprise architecture means more portability of applications and an increased ability to handle enterprise-level issues, such as security.
- Cost savings: An enterprise architecture makes it less expensive to maintain existing systems by reducing complexity. It also provides for easier acquisition or development of additional functionality.
But once you're convinced that developing an enterprise architecture is the right thing to do, how do you go about it? You can strike out on your own, or you can use an industry standard.
That's where TOGAF comes in.
Defining The Open Group Architecture Framework (TOGAF)
The Open Group Architecture Framework, or TOGAF, is a complete package for creating an enterprise architecture. It is based on a decade of refinements to the U.S. Department of Defense Technical Architecture For Information Management (TAFIM). TOGAF, now at version 8, provides both a method and the structure for developing an enterprise architecture.
TOGAF is a framework, which typically means it defines the deliverables your work should produce and perhaps the means by which you should produce them. In the case of TOGAF, however, things are just a bit different. TOGAF is actually broken down into the following parts:
- The Architecture Development Method (ADM): The ADM, which makes up the first third or so of the TOGAF specification, consists of eight phases of analysis and implementation to bring you from the start to the completed, implemented enterprise architecture. The ADM is a generic methodology, which means it's not geared toward any particular set of deliverables. You can even use ADM to design an enterprise architecture based on another framework. (And, in fact, TOGAF provides guidance for doing just that.)
- The Enterprise Continuum: The Enterprise Continuum is a repository of artifacts involved in the design and implementation of your system, such as models, patterns, and other architectural work. TOGAF defines a Technical Reference Model (TRM) that can form a foundation on which you can build your repository, as well as a second reference model and set of solutions and standards with which you can work.
- Additional Resources: TOGAF also provides a wealth of information to help you build an architecture, such as business scenarios, case studies, and various models, views, and guidelines.
Take a look at these pieces in greater detail.
Using the Architecture Development Method
The ADM is designed as an iterative process that takes you through the eight phases of development, starting with Architecture Vision and ending with Implementation Governance and Architecture Change Management. The idea is to build your system in stages, completing one cycle and embarking on the process again to improve what you built on the last go-round.
Each phase contributes to and draws from the pool of requirements, as shown in Figure 1.
Figure 1. Eight phases of the Architecture Development Method.
Not only is the overall method meant to be iterative, but so is each phase. Let's look at each of them.
Asking preliminary questions: framework and principles
Before you can start work, you need to answer basic questions about the project, such as, "How long will we spend on this project?" "What level of detail do we want to accomplish?" "What are the business goals?" Before the architecture work actually begins, you need to determine the principles that will govern the remainder of your work, as well as specifying the methodology and framework to be used. Most important, you will need to specify the business principles, goals, and drivers for the overall project.
In phase A, you determine what you're going to do in this round of development. This process includes determining the scope of the project and the stakeholders involved, as well as making sure the project receives required approvals and the necessary support (and supporters). In this phase, you document the current architecture baseline and the target architecture, both in a fairly general way.
Phase B: Business Architecture
In phase B you examine, in depth, the business aspects of your project. This phase is where you do extensive modeling of your present and desired architectures using tools such as business process models and use-case models. You also perform gap analysis to determine what needs to be done to bring your current, baseline system in line with your target architecture. TOGAF provides information on various industry architectures and common systems architectures that can be useful in this phase.
Phase C: Information System Architecture
Just as phase B elaborates on the business architecture you defined in phase A, phase C elaborates on the Technical Architecture you create in phase A. In phase C, you analyze the data and application architectures. You document the present and desired flows of information and the applications that facilitate them, breaking down the system into building blocks that may or may not yet exist. TOGAF points to several existing models and frameworks, but you are not required to use them.
Phase D: Technology Architecture
In phase D, you develop the technology architecture that implements the business and information architectures you create in phases B and C. You first create a baseline for your existing technical architecture, using the TOGAF format. This involves breaking down functionality into reusable architectural building blocks and describing the pieces in terms of the foundation architecture, whether or not it's the TOGAF Foundation Architecture's Technical Reference Model. This gives all who are working on the project, whether they are technical or administrative, experience in this environment. You then drill down, creating a target model of building blocks, specifying what each of those blocks must do, and so on. You also conduct a gap analysis to ensure that you cover all bases.
Phase E: Opportunities and Solutions
In previous phases, you identify both the baseline and a target architecture, breaking them down into building blocks. In phase E, you look at all these building blocks and determine what you can reuse, what you must replace, and what you must provide, either by buying it or building it. This phase also considers whether or not existing systems should be replaced all at once, and gives options so that the new and old systems can coexist. According to TOGAF, "The most successful strategy for the Opportunities and Solutions phase is to focus on projects that will deliver short-term payoffs and so create an impetus for proceeding with longer-term projects." This phase can also uncover additional application opportunities, in which case you may find yourself iterating between this phase and earlier phases.
At this point you should have a very good idea of where you are and what you're trying to achieve. In phase F, you determine how you'll get there. Phase E provides you with all of the pieces of your target architecture (at least on paper), but you rarely implement the entire system at once. (And if you did, the result would likely be chaos.) In this phase, you determine the order in which you will implement the new systems.
Phase G: Implementation Governance
Finally, you're almost ready to start building. The actual development process is outside of TOGAF, but it's not actually separate. In this phase, you put into place the processes that will ensure that all development, whether it is part of the architecture implementation or an ongoing project, is in compliance with the target architecture. This step involves the creation of an architecture contract -- and requires the signatures of those working on development. At the end of this phase, your target architecture should be in place.
Phase H: Architecture Change Management
An enterprise architecture, once completed, is rarely a static system. Rather, the need (or perceived need) for change is inevitable and is the reason for phase H. You enter phase H upon completion of the Implementation Governance phase, and thus, the completion of the system. In this phase, you monitor requests for change and determine if and how they will proceed. Some changes, such as the simplification of a process, can be handled by a good change management policy and won't necessitate moving from this phase. Other types of changes, such as a new standards initiative or new technology, require only a partial rearchitecting, perhaps starting with phase D, Technology Architecture. Other changes, such as those involving the underlying business process, require you to go back to phase A, with your existing architecture becoming the new baseline. In that case, development proceeds just as it did the first time, until you arrive back at this point.
Each of these phases involves interaction with the Enterprise Continuum.
Building on the Enterprise Continuum
The second major part of TOGAF is the Enterprise Continuum, which provides a repository for all the models, patterns, and other artifacts you create while iterating through the ADM. You will be referencing it throughout the project. More than just a registry, however, the TOGAF Enterprise Continuum provides a base on which you can build your own enterprise architecture.
Conceptually, the Enterprise Continuum consists of the Architecture Continuum (models, patterns, and so on) and the Solutions Continuum (consisting of documentation of how the models and patterns in the Architecture Continuum are to be achieved). Each of these continuums runs from the general to the specific. This means the Architecture Continuum starts with the most general, a foundation architecture. It also includes a common systems architecture (such as security or network architecture) and an industry architecture (such as retail's Active Store) or the Petrochemical Open Software Corporation's data model. Finally, it includes an enterprise architecture, which can be customized for a specific organization. The Solutions Continuum starts with Products and Services, which are combined into System Solutions, which are used in Industry Solutions, which can be customized to create an Enterprise Solution.
TOGAF provides two different foundation architectures, which can serve as starting points for development and implementation. The first is the TOGAF Foundation Architecture, which is a general foundation architecture you can adapt for most situations. The Integrated Information Infrastructure Reference Model (IIIRM), a more specialized foundation architecture, is designed for the Open Group's Boundaryless Information Flow vision and is not appropriate for every situation.
Because it's more general than IIIRM and more likely to apply to your situation, let's discuss the TOGAF Foundation Architecture.
Starting with the TOGAF Foundation Architecture
A foundation architecture is a starting point. It's not meant to be the complete solution to all of your problems, or even a solution, but it does give you a place to start. At the beginning of your TOGAF effort, your Enterprise Continuum will likely be empty except for the models and other artifacts that make up your foundation architecture. As you go along, you will pull pieces out to use as a starting point, adapt them to your own purposes, and put them back in as pieces of your own enterprise architecture.
The TOGAF Foundation Architecture provides a complete architecture, reflecting general requirements and building blocks, and providing guidance for implementing the overall system. It consists of the Technical Reference Model (TRM) and the Standards Information Base (SIB).
The purpose of the TRM is to provide more than just a foundation for future development, but also to provide a common project vocabulary for all involved. This common vocabulary is both structural (the TRM defines a model architecture) and lexical (the TRM provides a taxonomy) for all involved in the project to use.
The structural model of the TRM, which forms the basis for your TOGAF-managed enterprise architecture, is fairly straightforward, as shown in Figure 2.
Figure 2. The TRM structural model
The application software (Applications in Figure 2) tier consists of the following:
- Business applications (which handle enterprise specific functions, such as inventory management)
- Infrastructure applications (which provide more general functionality, such as payment processing)
The application platform can be conceptualized as the space in which all applications and all services are available. It is, in a way, the aggregation of all services in the application software tier.
These two tiers communicate through the Application Platform Interface, which provides a standard means of interaction, enabling maximum portability of applications.
Applications communicate with each other over the communications infrastructure, which increasingly involves the Internet. They use the communications infrastructure interface, which is intentionally less diverse than the overall structure. This is to provide maximum interoperability.
The other part of the TRM is the taxonomy, which consists of a long list of categories, such as "Data Interchange Services," "Software Engineering Services," and "Object Request Broker (ORB) Services." It also provides a variety of terms, such as "document generic data typing and conversion services," "electronic-mail services," and "installation and activation services." Each term is defined by TOGAF so that ambiguity in conversations and documentation is eliminated.
The Standards Information Base
TOGAF is a product of the Open Group, so it should come as no surprise that its preference is for architectures to use open standards wherever possible. Adhering to this goal gives you the additional advantage of enabling better interoperability and preventing vendor lock-in.
The Standards Information Base is simply a list of recommended standards and information about them. It includes standards such as HTTP, SQL, HTML, and RIFF Waveform Audio Format (otherwise known as WAV files). The SIB also links each entry to a list of products that conform to that particular standard so you can choose without worrying about interoperability problems. This way, when you're putting together the building blocks of your architecture, you can choose products that will provide the maximum amount of flexibility and interoperability.
Accessing additional information
Part IV of the TOGAF specification is the Resource Base, a collection of documents designed to help you create and implement your enterprise architecture. These documents include guidelines for establishing an architecture board, tools for architecture development, and a mapping of the ADM to the Zachman Framework. These documents are designed to help you most effectively use both the ADM and the Enterprise Continuum.
Summary: Creating an IT system with maximum business benefits
You can use TOGAF to create a comprehensive enterprise architecture that enables you to get more control of your business in terms of both technology and process. The end result is a system that is not just robust and well documented, but also designed to provide the maximum benefit to your business. What's more, the process of analyzing your enterprise often has the positive effect of providing insight into ways in which you can improve the business itself.
We encourage you to learn more about TOGAF, both to enhance your knowledge of the IT architecture discipline and to better align your IT systems with the needs of your business.
Learn
-
Examine the TOGAF 8.1 specification, from The Open Group
-
Find out how to get TOGAF Certified.
-
For information about The Open Group IT Architect Certification program and its announcement, check out this press release.
-
See an additional press release about The Open Group IT Architect Certification program.
-
Learn more about SOA in the developerWorks SOA and Web Services zone.
-
Stay current with
developerWorks
technical events and webcasts.
- Search for more information about IT architecture at Safari Bookshelf.
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Troubleshoot, brainstorm, and collaborate with your peers. Check out developerWorks blogs and get involved with the developerWorks community.
Nicholas Chase has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, an Oracle instructor, and the chief technology officer of an interactive communications company. He is the author of several books, including XML Primer Plus (Sams).
Table of contents
- Assessing the need for enterprise architecture
- Defining The Open Group Architecture Framework (TOGAF)
- Using the Architecture Development Method
- Asking preliminary questions: framework and principles
- Building on the Enterprise Continuum
- Starting with the TOGAF Foundation Architecture
- Accessing additional information
- Summary: Creating an IT system with maximum business benefits
- Resources
- About the author
- Comments
