Video: Using Rational System Architect with TOGAF for enterprise architecture

An introduction to a video demonstration

This article introduces a video demonstration of how to use Rational System Architect to apply The Open Group Architecture Framework (TOGAF).in enterprise architecture.


Sami Salkosuo, Software Architect, IBM

Sami Salkosuo is a Software IT Architect in the Software Group at IBM Finland. He works mainly with industrial customers. He is an IBM developerWorks Contributing Author and the author of "Command Line Email Client for Lotus Notes" (CLENotes), an open source project available at Sami also writes and publishes science fiction stories set in a parallel universe called the Strangers' Universe. The stories are available at

12 April 2011

After a brief overview of enterprise architecture (EA) and The Open Group Architecture Framework (TOGAF), this article describes the TOGAF metamodel ("The Key," capitalized on purpose). It then introduces a video demonstration of how to work with Rational System Architect in using TOGAF for enterprise architecture.

Enterprise architecture and TOGAF

These definitions are borrowed, with permission, from the introduction to TOGAF, Version 9 (cited in Resources).

What is an enterprise?

TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could 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.

What is enterprise architecture?

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

Why do I need enterprise architecture?

The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

What is an architecture framework

An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise 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.

What is TOGAF?

TOGAF is an architecture framework - The Open Group Architecture Framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

What kind of architecture does TOGAF deal with?

There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:

  • The Business Architecture defines the business strategy, governance, organization, and key business processes.
  • The Data Architecture describes the structure of an organization's logical and physical data assets and data management resources.
  • The Application Architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
  • The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Why do I need TOGAF?

TOGAF has been developed through the collaborative efforts of 300 Architecture Forum member companies from some of the world's leading IT customers and vendors and represents best practice in architecture development. Using TOGAF as the architecture framework will allow architectures to be developed that are consistent, reflect the needs of stakeholders, employ best practice, and give due consideration both to current requirements and to the likely future needs of the business.

Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to "de-mystify" and de-risk the architecture development process. TOGAF provides a platform for adding value, and enables users to build genuinely open systems-based solutions to address their business issues and needs.

TOGAF metamodel

TOGAF, as a whole, is not easy to explain in a short way. TOGAF, Version 9 requires 700 pages to explain what TOGAF is and how to apply it, plus there are classroom courses available that last several days. And it takes real-life practice to apply TOGAF to your enterprise.

However, there is one thing that will "open your mind" to TOGAF (and to enterprise architecture and Rational System Architect, as well). That is Chapter 34 of the TOGAF book, the chapter about the TOGAF Content Metamodel. More specifically, it’s Figure 34-8 in that book, with a caption of "Relationships between Entities in the Full Metamodel." Figure 1, below, shows that diagram (with permission). This metamodel is The Key to understanding TOGAF and to using Rational System Architect.

Figure 1. The TOGAF Content Metamodel
TOGAF metamodel

Of course, there's lot more than just a single metamodel diagram that you need to understand TOGAF and to fully use Rational System Architect. But the Content Metamodel is The Key, map, road (or whatever you want to call it) to understanding TOGAF and enterprise architecture. You can start with metamodel and learn, as needed and when necessary, everything that surrounds the metamodel, including entities, the Architecture Development Method (ADM), and the entire Open Group Architecture Framework. So keep the metamodel and TOGAF book close by.

The video demonstrates how to apply metamodel with Rational System Architect software.

Getting started

Before starting the enterprise architecture work with Rational System Architect and TOGAF, it might help to have high-level guidelines for what to do. These are a few that I have found important:

  1. Have a vision. Typically, and not just when dealing with EA, you need to have a vision of what you want to achieve. In the EA context, a vision might be to show how your applications support your organization’s financial goals. See the path from Driver to Physical Application Component in the metamodel.
  2. Select a metamodel. You need some way to model your organization. You have the data already in the form of documents, architectural diagrams, process diagrams, and so on. But you need some kind of model to put that data in structured form. The TOGAF metamodel is a good choice.
  3. Define how to work. In addition to the metamodel, you need a structured way of approaching the enterprise architecture. TOGAF includes the Architecture Development Method (ADM) that defines for developing enterprise architecture. You can use ADM as it is or tailor it to your own use. Or you could define your own method, of course.
  4. Gather the data into the repository. This is where the bulk of the work is. Here, you need to add all relevant data about your organization into the repository (guided by the metamodel that you choose). This is basically manual work, unless you have something available already that you can use to import the data into the Rational System Architect, such as an IBM® Tivoli® Change and Configuration Management Database (CCMDB).
  5. Visualization. After you have the data in the repository, the next steps are semiautomatic. The data in the repository has some value, but the real value comes when you can visualize what you have in the repository in various ways. You need to know what you want to visualize (illustrate) and then, basically, just do it. Rational System Architect has architecture and process diagrams, matrices, and views for you to use and methods to customize the illustrations, based on the data that you have in the repository.
  6. Communication. With the help of Rational System Architect and visualization, it is easy to convey your vision to others, whether that’s how your applications support the financial goals of your organization, or another goal
  7. Realization. With a plan in place, shared, and available for all to use, you can start realizing the enterprise architecture. Implementing the EA vision might include anything from new processes or new IT systems to entirely restructuring the organization.

The video scenario

The demo scenario is that a multibillion dollar corporation needs to find a way to align IT and business in order to achieve enterprise-wide business agility. The IT architecture team has been asked to demonstrate how to apply TOGAF in enterprise architecture. The team has selected Rational System Architect as the tool that they want to use, because it includes TOGAF support, so it is a natural choice.

The IT team members have chosen to model their own team to validate Rational System Architect. Based on the TOGAF metamodel, the team uses the software to model functions, business services, application components, and the processes of their own organization. The team also uses it to show system architecture, a business process diagram, an explorer diagram, heat maps, and matrices.

Figure 2 shows what the architects are planning to model in the context of the TOGAF metamodel. The architects start by adding definitions of the Organization Unit and then add the definitions of unit's Function and Business Service. They also want to show how the business service is implemented, so they will add these definitions:

  • Information System Service
  • Logical Application Component
  • Physical Application Component
  • Physical Technology Component

Finally, they will also model one Process that is part of the Organization Unit's Function.

Figure 2. Scope of the scenario in the TOGAF metamodel
Scope from Organization to Service to Technology

With a vision clearly in mind, it is easy to start working, using Rational System Architect. The sections that follow briefly describe the video demonstration of the modeling work, titled "Using Rational System Architect with TOGAF for enterprise architecture" (see the Resources section for a link).

Figure 3. Starting screen of the demonstration video
Directory-style menu on left

The video demonstration shows how to model enterprise architecture by using the TOGAF metamodel. Reporting, process simulation, and other features of the Rational System Architect are beyond the scope of the demonstration.

Here are the chapters of the video, which is available on YouTube. Brief descriptions of each follow.

00:00 - 00:29 Add definitions, Part 1

The work starts by adding a definition of the Organization Unit (at the top of the TOGAF metamodel) named "IT Department." Initially, only the name field is added for the definition,

All definitions are stored in the repository database where they can be linked and queried and put to use. Because it’s a database, the repository can be accessed by multiple users, so the whole team can work on the same model at the same time. An additional benefit is that there is "a single version of truth" stored in the repository, rather than multiple standalone documents stored on hard drives and flying around as email attachments.

00:29 - 00:49 Add definitions, Part 2

The second definition is a Function (remember the TOGAF metamodel), named "Application Support." The idea here is that the Function describes the Organization Unit's purpose, and it is owned by the Organization Unit.

00:49 - 01:45 Add definitions, Part 3

The third definition is a Business Service (see the metamodel again) named "Messaging Service." As you can see, we are following the path from top to bottom in the diagram shown in Figure 2 (there's a link from Function to Business Service).

After defining the Business Service, we add a definition for Information System Service (IS Service), named "Messaging Platform." The IS Service fully automates a business service (see the metamodel). In this case, think of the IS Service as a collection of several applications that, together, make up the platform named "Messaging Platform." And the platform, as IS Service, realizes the Business Service in terms of, for example, service-oriented architecture (SOA).

01:45 - 02:09 Add definitions, Part 4

The next definition is a logical application component named "ESB" (enterprise service bus). This component realizes the IS Service and, when you look at the metamodel, you will see a link between the IS Service and Logical Application Component, stating "Is realized through." The link is visible in the definition under one of the tabs when editing a definition.

Rational System Architect uses the TOGAF metamodel to provide correct data in the definition dialog. The software will not let anyone include links that are not allowed in TOGAF metamodel.

02:09 - 03:08 Add definitions, Part 5

After the logical application component, we need physical application components, so we add these three: WebSphere DataPower, WebSphere Message Broker, and Cast Iron (see Resources for more information). These three realize the logical application component called "ESB."

03:08 - 03:38 Add definitions, Part 6

Referring to Figure 2, the physical technology component is not yet added to the repository, so we add it now and call it "zEnterprise." It supports the WebSphere Message Broker physical application component. The other two physical application components, Cast Iron and WebSphere DataPower, are not supported by zEnterprise, because they are physical appliances themselves.

03:38 - 04:14 Start to illustrate the vision

After adding the definitions, we want to illustrate what we have. Here, we create an explorer diagram that is used to view the components and their relationships in various ways. The diagram is generic, which makes it possible to create very different kinds of diagrams, depending what you have in mind. For example, a diagram may show all business services related to the Organization Unit or all processes of a function, and so on.

04:14 - 05:08 Add definitions to a diagram

Here, we drag definitions to the diagram. Remembering the metamodel, we added definitions from the Organization Unit to the Technology Component to the Explorer diagram. We also include all of the application components, both logical and physical, but that's not what we wanted. We wanted to separate logical and physical application components, which we do in the next step.

05:08 - 06:02 Separate logical and physical application components

First, we delete all application components from the diagram, and then we add the Explorer Object Report, which is a customizable selection of definitions that we want to include. There were already object reports available for logical application components and physical application components.

After adding logical and physical application components, we have the entire stack, from organization to physical server in the Explorer diagram (see the metamodel again).

06:02 - 09:27 Add relationships

We want to visualize the relationships, but we don't have all of them yet. We have just added the definition type and name, so we add a relationship (see the metamodel again). For example: The Organization Unit owns Functions, Function provides access to Business Service, and so on.

This section shows a typical working session, At one point, the mouse cursor guided by the author seems to wander aimlessly around the tool, because there are times when we have to pause and think what to do and how to do it.

09:27 - 10:42 Show relationships

After adding relationships to the definitions, we can show them in the Explorer diagram. The definition called Explorer Relationship Report is used to display a relationship between definitions. Rational System Architect includes many relationships, which can be customized as needed

10:42 - 14:07 Add new relationship reports

In some cases, there is no existing Relationship report for our purposes, so we can create new relationship reports. We add relationships for following relations: logical application component to physical application component, IS Service to logical application component, and Business Service to IS Service. Relationships are added to Explorer diagram by dragging the Relationships report to diagram.

14:07 - 16:15 Draw the system architecture

We can also draw architectural diagrams with Rational System Architect. Some moments ago, we entered an Information System Service called "Messaging Platform." Now we want to visualize it by using a normal architecture diagram. We populate the system architecture diagram with our application component definitions by dragging them to the diagram. In the architectural diagram, we also specify external components and interactions between application components.

16:15 - 16:54 Use matrices

Using matrices is one aid to visualize the enterprise architecture. Rational System Architect defines several matrices, and it makes it easy to see how components are related, such as what physical application components make up logical application component.

16:54 - 18:15 Define heat maps

Heat maps are used to analyze diagrams. Here, we define a heat map that selects all application components in the diagram with names that include "WebSphere" and then apply the color blue to all selected components. We also define a new collection of analytics called "MyHeatmaps," that is visible in the Heat Map Manager.

18:15 - 21:09 Model a business process

Last but not least, we model a business process. The process is called "Development," and it is a sequence of steps that you need to successfully build and deploy a custom application. The process is modeled by using a standard Business Process Model and Notation (BPMN).


Enterprise architecture is what many organizations around the world want to implement, and TOGAF is the de facto standard for development. TOGAF itself is not architecture but a framework on which to build the architecture. You could use TOGAF as a shopping list, though, by selecting what is suitable to your organization, removing unnecessary parts, and modifying it to your own needs.

You can design enterprise architecture without tools. But a tool like Rational System Architect will make your easier when planning, modeling, visualizing, communicating, and implementing it.

Using Rational System Architect enterprise architecture software in the context of TOGAF is not difficult (the software also supports other frameworks, such as NAF and MODAF). The support for TOGAF is built into the tool, so it makes Rational System Architect easy to use for this purpose. The difficult parts might be deciding what you really want to model with TOGAF, what to add to the Rational System Architect repository, and how you want to illustrate and communicate your vision.


TOGAF® Version 9. USA: © 2009-2011 The Open Group. TOGAF is a registered trademark of The Open Group in the United States and other countries.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Video: Using Rational System Architect with TOGAF for enterprise architecture