Implement DoDAF 2 architectures with IBM Rational System Architect workspaces

Model multiple versions of an architecture by using this feature

By implementing workspaces, you can model multiple versions of an architecture in IBM® Rational® System Architect. This article explains the different versions that can be created for the following scenarios, along with the benefits for each: implementing an enterprise architecture, implementing an as-is and to-be architecture, integrating a system of system architecture, and trade-off analysis. It also describes four software tools that can analyze workspaces.


Franki Schafrik (, Senior Enterprise Architect, IBM

Photo of Franki SchafrikFranki Schafrik has 17 years of experience using Rational System Architect. She has 20 years experience consulting on Enterprise Architecture with government and commercial clients around the world. She teaches DoDAF and EA methodologies internationally.

26 July 2011

Also available in Chinese

Introduction to workspaces

Basic concepts

By implementing workspaces, you can model multiple versions of an architecture in IBM® Rational® System Architect. You can create different versions of an architecture for these scenarios:

  • Implementing an enterprise architecture
  • Implementing an as-is and to-be architecture
  • Integrating a system of systems architecture
  • Performing trade-off analysis

The concept of a workspace is simple. Workspaces are similar in concept to an encyclopedia. Implementing workspaces enables you to open, in effect, different versions of an encyclopedia. Changes in one workspace will not affect the other workspaces. This provides traceability, comparisons between an original and an evolved encyclopedia version, and workspace merging (see section Resources for references to how to implement workspaces).

The way they work is simple, too:

  1. A read-only baseline is created that contains information that will not change (a list of organization names, for example).
  2. The information from the baseline is then copied to a workspace when the workspace is created.

You can change or elaborate on the information in a workspace, and you can report within a workspace or across a workspace, for analysis.

Figure 1. Workspaces concept
Example baseline with two workspaces

It is important to remember this information regarding workspaces:

  • There is only one root (baseline) workspace for an encyclopedia.
  • All workspaces created from the root workspace inherit the parent baseline; therefore, they inherit all of the diagrams and definitions.
  • You can view an encyclopedia baseline, but you cannot edit it, because it is read-only.
  • Users can open only one workspace at a time. When you change the active workspace, all open items in the active workspace will close.
  • Multiple people can model in the same workspace.

You also need to consider these workspace restrictions:

  • Is not intended to allow you to take multiple encyclopedias and bring them into one encyclopedia under a pseudo folder structure
  • Does not allow different property sets within a single encyclopedia (all workspaces use the same usrprops file)
  • Does not enable packaging or namespaces for objects (allowing more than one object of the same name)
  • Does not enable access control grouping at a higher level
  • Should not be used to solve orthogonal issues

Developing formal and informal DoDAF 2 architectures for workspaces

The scenarios in this article are based on the concept of formal and informal architectures and what those architectures should contain, as described in the DoDAF 2 standard. This section provides information on the formal and informal architecture tiers and describes a generic approach to modeling these architectures using workspaces.

There are three formal architecture tiers defined in DoDAF 2.0:

  1. Department architecture provides governance for the other two tiers. It's developed at the organizational level or the joint staff level, so, for example, it could be an architecture for the whole US Coast Guard or a department of the Coast Guard, such as Logistics. It should include the global information grid and the DoD Information enterprise architecture to make sure that the requirements and dependencies are taken into account in lower-level architectures. The department-level architecture is where the vision and mission are defined.
  2. Capability or segment architecture describes the use of specific capabilities in these areas:
    • Business (for example, how do Logistics developers do their day-to-day jobs).
    • Procurement (what components or services need to be procured to meet the logistics department's assigned capabilities).
    • Tactical operations (for example, defining an architecture to describe how logistics supports performing operations for national security). This architecture explains how day-to-day business is done, either for a specific organizational unit or for a specific environment (such as fighting a war in Iraq).
  3. Component architecture looks at a specific need (for example, when performing operations for national security, what systems or services are needed in Logistics). This is where the supporting technologies and services for the operational environment are defined. The component architecture shows either what new services and technologies are needed to support operations or what services and technologies are currently being used. This is the traditional "project" architecture, or solution architecture.

These three levels help control the model elements in the architecture to create a standard use of terminology. For example, organizational units are defined at the department level. When a capability level architecture is created, it should reuse the organizational units already defined at the department level. That will make modeling faster and more accurate. It will also provide the ability at the department level for a decision maker to query for common data used in multiple capability or solution architectures. The advantage is that, for example, if an organizational unit is being renamed, eliminated, or reorganized, the impact can be assessed across the whole enterprise, rather than being in the situation that's common today, where something changes in one department and breaks something in another department.

There are four informal architecture tiers in DoDAF 2 used to define, at each formal tier, what type of architecture is being created.

DoDAF models in workspaces

This article covers the basic DoDAF 2 products that might be created for a project. Additional views can be used, but to keep the example simple, only the following products will be addressed (the System View products are analogous to Service View products, so the limitation is not to imply that services are not addressed):

  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3
  1. Operational architecture describes the business and tactical operations and focuses n the capability view, project view, and operational view.
  2. Systems architecture describes the systems, networks, and communications capabilities and focuses on the system view and the standard view. It should be based on the operational architecture.
  3. Services architecture describes internal and external service capabilities and focuses on the service view and the standard view. It should be based on the operational architecture.
  4. Solution architecture looks at an existing architecture and determines, in the future, what changes need to be made. It uses all of the views necessary to define the solution.

As Figure 2 shows, informal architectures exist at every formal architecture tier.

Figure 2. Formal and informal architecture tiers
Informal exists in every formal architecture

Workspaces will help ensure consistency within the architectures and also enforce naming conventions and other architectural governance requirements.

Implementing formal and informal architectures using workspaces

Formal architecture:

  • Department architecture (baseline)
  • Capability or segment architecture (workspace)
  • Component architecture (capability as baseline, component as workspace, can be divided by development cycles)
Figure 3. Department architecture decomposed into capability architectures
Before and After diagrams

Informal architecture

  • Operational (baseline)
  • System (baseline)
  • Service (baseline)
  • Solution (workspace)
Figure 4. Capability architecture decomposed to multiple solution architectures
Before and After diagrams

Scenarios for using workspaces

The scenarios presented in this article are based on real-world experience working on projects, but there is no implication that this is the only approach to modeling these types of projects nor that certain models will always be in the baseline.

Scenario 1: Implementation of an enterprise architecture

Enterprise architectures have been implemented within most DoD components. An issue that often arises is how to document the levels of formal architecture in System Architect and then how to govern changes.

For example, the US Coast Guard has implemented an enterprise architecture. They have a standard list of activities, systems, and organizations within a department architecture. These standard names are used by the lines of business to develop the capability or segment architectures (Logistics or Finance, for example). This ensures that every line of business is using the same terminology. It also helps the lines of business understand their interaction points (for example, how Logistics interacts with Finance).

Using workspaces, an enterprise level set of diagrams and definitions can be created that will constrain the development of lower-level architectures. This ensures, for example, that a system name is used consistently throughout all architecture projects. It will also allow for reporting across multiple architectures, because the same names are used throughout the organization (for example, creating a report to see the effect of eliminating or automating a role).

Enterprise architectures can be created one of two ways to develop a list of standard enterprise artifacts. The best-case scenario is that architecture elements (lists of systems, organization names, and so on) are created in a department level architecture that is then expanded at the capability/segment level and the solution level. In some cases, it's easier to define the solution or capability/segment level and then filter common elements from the various architectures up to the department level (example: take a list of systems from three capability/segment architectures and create a complete list in the department architecture).

Figure 5. Decomposition of formal architecture tiers using workspaces
Diagrams: from department to solution architecture

For simplicity, this example assumes a top-down approach.

The baseline root workspace (department level) within an enterprise architecture (EA) project should contain the following:

  • CV-1 (list of capabilities available across the entire organization)
  • OV-4 (organizational chart for the entire organization)
  • OV-5a/b (high-level activities performed by the organization)
  • DIV-2 (enterprise-wide data model of entities common across the organization)
  • List of systems and technologies (Technical Reference Model)

The baseline should also contain any architecture elements or diagrams that constrain lower-level architectures. For example, if the department must follow the Federal Enterprise Architecture Framework (FEAF), FEAF data elements should be included in the baseline. Another example is an organization constrained by another organization, as is the case with the US Coast Guard and Homeland Security. Elements that need to be consistent between the two architectures should be included (for example, by using Homeland Security's enterprise data model).

The workspaces will consist of the capability/segment architecture, which should expand on the information available in the baseline. For example, one capability might add additional entities to the enterprise data model to handle their specific needs.

Capability/segment architecture workspaces should include:

  • AV-1 (explaining the viewpoint and so on of the architecture being created, for example, the logistics capability)
  • OV-1 (depiction of how the capability or segment must operate)
  • OV-2 (resource flows between the performers within a capability or segment)
  • OV-5a/b decomposition (taking the high-level activities from the baseline and providing further detail)
  • SV-1 (depicting the resource flows between the systems supporting the capability or segment -- systems should be based on the list of systems from the baseline)
  • SV-2 (depicting the physical interfaces between the systems in the SV-1 -- systems should be based on the list of systems from the baseline)
  • DIV-2 (enhancing the enterprise data model)
  • DIV-3 (to reflect physical databases being used within that capability/segment)

After the capability or segment architectures are finished and approved and any changes required are made to the department architecture, the capability or segment architecture can then be broken down into multiple solution architectures, with the capability or segment as a baseline.

Figure 6. Example of an activity broken down to solution level, the lowest formal architecture tier
3 diagrams showing decomposition

Benefits of using workspaces to define an enterprise architecture

  • The same terminology is used consistently within the organization, eliminating confusion and allowing for reporting at the department level across the organization.
  • Architecture development will be faster, because each lower-level architecture is populated with predefined definitions and diagrams.
  • Reporting can be done across the workspaces to ensure consistency (to make sure a that system name was not changed, for instance).
  • Populating a new encyclopedia (a new capability/segment encyclopedia, for example) with enterprise-wide data is simple, requiring only that a new workspace be created.
  • Better integration of systems, because underlying data elements have the same name and data format.
  • Reduced duplication of system functionality and reuse of existing system functionality

Scenario 2: Implementation of an as-is and to-be architecture

The DoD is not only interested in looking at the current state of the organization. They must also create plans for the future to ensure that future capabilities are identified and funded so they can be developed. The timeline for the planning is usually 1, 5, 10, or 20 years ahead.

An example is the US space reconnaissance and surveillance program. Capabilities, such as more powerful processing and improved collection abilities, were planned ahead before technology was available to meet those capabilities. When the technology was available (better cameras and the ability to launch a larger satellite), programs were put in place to implement the new capabilities, and, for 30 years, the requirements of the space program did not change.

Workspaces make this kind of planning simple, in that each workspace within the encyclopedia can represent one of the future time periods that the DoD is planning for. Because changing a definition or diagram in one workspace does not impact the same-named definition or diagram in other workspaces, changes and updates can be made for each time period, and then reports will identify what has changed across the workspaces.

Figure 7. Capability architecture defined at different time frames
Diagram shows current year to year 10

The baseline architecture will normally be the capability/segment architecture, because planning is done at that level (assuming that the capability/segment maps to a component within an organization, such as Logistics in the US Coast Guard). It should include the current (as-is) models:

  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3

The workspaces will be based on the to-be timeline. Products that will be modified in the workspaces include:

  • CV-1 (adding future capabilities)
  • OV-1 (depicting the new operations with the new capabilities)
  • OV-2 (showing additional performers and resource flows needed; performers and resource flows might also be eliminated)
  • OV-4 (showing over time a reorganization, elimination, or addition of performers or people)
  • OV-5 (additional low-level activities might be added, but most of the changes in the OV-5 will be for data produced and consumed by the activities)
  • SV-1 (this will show changes in system interfaces over time, as well as the addition or deletion of systems)
  • SV-2 (this will show changes in the physical communications between performers or systems)
  • SV-4 (additional system functionality might be added to meet a new capability or to take advantage of new technologies)
  • DIV-2 (additional entities and attributes needed for new capabilities)
  • DIV-3 (potential changes to the physical database implementation when database technology is improved)

Benefits of using workspaces for as-is and to-be architectures

  • Tracking a change in a performance measure (for example: 86% availability increased to 95% availability in year 5)
  • Tracking a change in a system interface
  • Tracking the replacement of a system with a service
  • Analyzing impact of the elimination or introduction of a new performer or role
  • Forecasting a budget better
  • Identifying new assets needed to meet a new capability

Scenario 3: System integration architecture

Large scale projects, or systems of systems, are often broken down into smaller, more manageable projects. These projects are normally undertaken by one or more contractors who specialize in developing that component of the system. But all of the projects eventually have to be integrated to make the entire system interoperable.

The development of a new plane is an example of this type of system. One contractor will build the engines, another the plane body, another the avionics, and so forth. All of these systems have to be brought together into an integrated system. By documenting the subsystems in a standard way and providing a high-level integration plan, the integration of the system should require less rework and be easier to achieve.

Figure 8. Solution architectures defined for integrated subsystems
Diagram shows component (root) with 4 subsystems

The baseline architecture will normally be the component architecture, which identifies the system or system of systems to be built. It should include the high-level design models:

  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3

The workspaces will be the subsystems and can be divided by subcontractor responsibilities. The baseline models will be decomposed in further detail to show the subsystem design. Models that will be modified in the workspaces include:

  • OV-2 (showing additional performers and resource flows needed for the subsystem; the baseline OV-2 will show detail only at a high level)
  • OV-5 (additional low-level activities can be added if the detail is necessary for the activities assigned to each subcontractor)
  • SV-1 (showing additional details on the subsystems and resource flows for a particular subsystem)
  • SV-2 (this will show additional detail on the physical communications used within the subsystem)
  • SV-4 (system functionality can be decomposed to identify the internal resource flows between low-level system functions of the subsystem)
  • DIV-2 (additional entities and attributes needed to provide detail on the data required by the subsystem)
  • DIV-3 (physical database implementation of the subsystem)

Benefits of using workspaces for integrated architectures

  • Governance of the design
  • Ease of integration, because integration points are clearly understood
  • Analysis to ensure that the requirements for each subsystem have been met
  • Identification and management of risk of integration points
  • Clear definition of subcontractor system boundaries
  • Common terminology across system boundaries
  • Impact analysis if there is a change in a subsystem
  • Timeline for integration of systems can be identified, because the system interdependencies are clearly understood

Scenario 4: Trade-off analysis

The DoD often requests studies to do trade-off analysis on potential solutions to a capability gap. They often do studies to test the possibility of using new technologies, as well.

The US Air Force intelligence collection program is a good example of this. In the early history of reconnaissance, after World War II, there was a debate about the use of balloons, modified bombers (the RB-29), and modified fighters (the RF-84) to collect intelligence. The pluses and minuses of each capability were analyzed (range/penetration, reliability, risk of detection and capture), and a decision was made about which assets to fund to provide the most successful outcome.

Workspaces simplify the analysis of different potential solutions by providing a baseline operational scenario and then detailing the feasibility of each potential solution (in the case of the Air Force, which asset to use to collect intelligence). The technical feasibility of a solution becomes apparent, as does the ability to meet the operational requirements and performance measures. A decision can be made based on the results for each potential solution.

Figure 9. Component architecture example with four trade-off solutions
Diagram of trade-off analysis architecture

The baseline architecture will normally be the component architecture, because the component architecture contains the high-level operational requirements that the solutions must be able to meet. This architecture can be the current (as-is) one, or it can be a future state (to-be) architecture. It should include these current (as-is) or future (to-be) models:

  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3

The workspaces will be based on the different options being analyzed. Most of the engineering work will be looking at different system view-related options; the information in the operational environment should not change. Products that will be modified in the workspaces include:

  • SV-1 (this will show additional, or revised, system interfaces)
  • SV-2 (this will show changes in the physical communications between performers or systems potentially, based on new technologies being analyzed for feasibility)
  • SV-4 (additional system functionality can be added to take advantage of new technologies)
  • DIV-3 (potential changes to the physical database implementation due to new capabilities being added or to structure the database for a new technology being introduced)

Benefits of using workspaces for trade-off analysis

  • Ability to report on costs of various options
  • Ability to report on performance measures and related requirements for various options to avoid under- or over-engineering the solution
  • Ensuring that nothing in the operational environment has been changed to make an option look more feasible
  • Ability to track risks associated with different options
  • Standardization across the different options for easy analysis (definition names stay the same; diagrams contain consistent data)

Workspace analysis tools

SA Compare feature

You can use the Rational System Architect SA Compare utility to show changes across workspaces. For example, SA Compare might be used with a DoDAF 2 architecture to identify any of these changes:

  • Changes to names of items in the root within a workspace (example: the name of an organization in the root was later changed in a workspace)
  • Additions or deletions between the root and workspaces (examples: additional system functionality added in a workspace or the deletion of a system in a workspace)
  • Additions or deletions over time (if the workspaces are time-based)
  • Changes to properties within a definition

For more information see the SA Compare section in the Rational System Architect information center, cited in Resources.

IBM Cognos software

IBM® Cognos® business intelligence and performance management software allows for reporting across workspaces. It can also be used to run reports that perform a calculation. Example uses of Cognos with a DoDAF 2 architecture include:

  • Reporting on a complete list of activities contained within two workspaces (SA Report Generator can only report within a workspace, not across workspaces)
  • Providing a list of the highest cost system functionality across multiple workspaces
  • Providing an overall cost for the system functions and activities across all workspaces (in the case of trade off analysis a report can be run to see which option is the highest and lowest cost)
  • Reporting on all the resources flows required for a system (in the case of system integration a report can be run to show all of the resource flows required to create the integrated system)

For more information see the SA Compare documentation in the Rational System Architect Information Center, cited in Resources.

Rational Focal Point software

IBM® Rational® Focal Point software offers market- and business-driven product and portfolio management. Example uses of using Focal Point with a DoDAF 2 architecture include:

  • Dashboards for a specific workspace or across workspaces to help manage project risk, schedules, and cost
  • Use of objective information to make a design decision based on quantitative analysis, rather than a best guess of which is the most cost-effective or lowest-risk approach
  • Capture of prioritization of customer requirements so the architecture reflects the highest- priority capabilities.
  • Road-mapping and planning capabilities to allow for what-if analysis on potential future projects

For more information see the Rational Focal Point overview citation in Resources.

Rational DOORS software

IBM® Rational® DOORS is a tool that provides a comprehensive requirements management environment. Requirements can be linked from the Department Level down to the Component Level to show that a component architecture meets all the high level requirements for the Capability and Department. Example uses of DOORS with a DoDAF 2 architecture include:

  • Graphic indicator on a diagram that a symbol or definition has an associated requirement
  • Reporting to show architecture elements without an associated requirement (over-engineering the system) or requirements without links to the architecture (forgotten requirement).
  • Management of 3 formal architecture tier level requirements, with traceability between the levels.
  • Standards and governance on architectures can be placed in DOORS and linked to the architecture.
  • Impact analysis on an architecture change or requirement change can be easily done using a report.

For more information see Rational DOORS overview page cited in Resources.



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=Implement DoDAF 2 architectures with IBM Rational System Architect workspaces