In a recent blog posting, we provided a guide for standing up and XI52 as an integral component to an enterprise like laboratory environment. This was the beginning several activities, which spawned an idea for a continuing series of articles around IBM SOA appliances, and the use of the The Open Group Architecture Framework (TOGAF) and its supporting Architecture Development Method (ADM). Which together are used to evolve an existing enterprise architecture. In this sense, by building the XI52 as an ESB; We have selected a key component of an infrastructure technology that will be used in an SOA based integration project. The idea now is to use the TOGAF and ADM to build out an EA that will inform and guide an integrations projects solution architecture using Datapower and other Websphere technologies.
So, by using the XI52 as an ESB, it became the genesis of a “target first” architectural context. Which has now become the starting point for a EA Preliminary phase, which we will follow with a Visioning phase, and then proceed with the execution of an EA life-cycle for this integration project.
As an short introduction I’d like to state that A priori enterprise architecture is not done in a vacuum, but rather it starts with an existing landscape of enterprise capabilities and assets. In this project, as in typical projects, we will be drawing from building blocks that were created in previous EA efforts. These are assets which make up the companies business, data, application, and technical architectures respectively. So our next steps will be to flesh out additional EA elements for the projects problem domain as we work through the ADM process, as well ultimately deliver various EA artifacts that will be utilized in architecture governance, and solution.
Before we begin let’s review some contextual information pertaining TOGAF and the use of this framework in this effort. In the discipline or practice of Enterprise Architecture, the Open Group has developed and matured its own architecture framework known as TOGAF. Historically the framework is based largely on TI models developed for the Department of Defense. To date TOGAF has evolved with the current version being TOGAF 9.1. In a brief statement; TOGAF is a foundational framework of generic services and functions from which a set of specific architectural building blocks are created and reused.
Additionally, the framework offers a comprehensive guide and process that provides a development life-cycle approach known as the Architectural Development Method (ADM). The ADM is an iterative process with guidelines for building Enterprise Architectures (EA) for organizations. TOGAF also provides a number of IT level meta-models and Reference Models as tools that are used in the process. Each iteration covers all phases of ADM process, as well as iterations that occur within a phase. A fundamental concept of the ADM process, is that for each iteration a new decision must be made as to:
-
What is the breadth of coverage for the defined enterprise.
-
What level of detail will be expressed in terms of artifact and models.
-
Schedule in terms of iterating over the whole process, as well as the intermediate iterations.
-
What assets will be leveraged from the organizations existing architectural building blocks.
-
Architectural assets that may be external to the current organization. Which may include other frameworks, systems, or assets from vertical industry models.
In our future series of articles we intent to flesh out varying levels details of framework as well as the artifacts created in the ADM process. But in this first article, we’ll take the the proverbial 20 thousand foot view. TOGAF is comprised of six sections; along with the ADM, an Enterprise Continuum which is a repository of architecture information and building blocks, which also includes what is called the architecture continuum. Which in turn is a related set of solutions that will range from industry common solutions to more organizationally specific solutions; Then there is the Architecture Content Meta Model, which describes TOGAF viewpoints and their associated artifacts. TOGAF also provides two Reference Models, the Technical Reference Model and an Information Reference Model or what is referred to as (3IRM). These Models makeup what is called the Foundation Architecture of the Architecture Continuum.
Next, the Reference Models and ADM guidelines, tools and techniques, comprise a set of best practices for an Architecture Capability Framework, that is used as method for assessing the readiness of an organizations EA practices and related governance models. Now, in our our particular area of focus, we will be executing the ADM life-cycle for an integration project, which will be designed around an SOA architectural style.
Over the course of these articles, we will build out a reference implementation of our architecture using various aspects of framework and process. Along the way we will also reference the Banking Industry Architecture Network (BAIN) framework, and we will also tie in the IBM Websphere Reference Model, tailoring the deliverables with a particular emphasis on IBM’s Datapower SOA appliances.
So, in using the ADM as a guideline, we have our comprehensive approach for planning, building, governing, and maintaining an architecture, as well as providing a means for maturing the organizations services development practice and systems integration capabilities. This is just one noteworthy aspect of the ADM. In that it provides us with a continuous improvement approach, by incorporating change management, along with the various techniques, tools and procedures. Which are also enablers in determining when to modify or rebuild an EA, in response to changing business and technological requirements.
Figure 1. TOGAF ADM
The project is a Portal integration for FYI Bank. Well get into the project details in the next article, where we will provide some additional context. Such as Drivers, Goals, Objectives and Requirements. And in each article we will build and add to various artifacts.
So, lets get started with a project package structure that is aligned to each phase of the ADM. In subsequent blog articles we will flesh out the details for each work package . The goal! Well, by the time we reach phase E., which is Opportunities and Solutions; we will have a comprehensive set of artifacts to transition into the solution architecture. Which means within each work package we will include various architectural deliverable’s.
Figure 2. Portal Integration Project – ADM Process and Work Packages
Along the way we will also provide concrete examples of how one might include multiple projects within the structure of an ADM process model, using some 3rd party EA modeling tools. So, welcome to the journey and I hope you will find it both informative and interesting! I’m also looking forward to your comments and questions on the this topic, as well as any suggestions on what you would like to see.
