![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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:
- A read-only baseline is created that contains information that will not change (a list of organization names, for example).
- 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
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:
- 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.
- 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).
- 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.
- Operational architecture describes the business and tactical operations and focuses n the capability view, project view, and operational view.
- 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.
- 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.
- 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
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
Informal architecture
- Operational (baseline)
- System (baseline)
- Service (baseline)
- Solution (workspace)
Figure 4. Capability architecture decomposed to multiple solution architectures
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
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
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
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
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
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)
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® 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.
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.
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.
Learn
- Additional information about workspaces:
- Configuring SA workspaces
- How to work with IBM Rational System Architect workspace scenarios, by Ian Hancock, Jog Raj, and Ed Vail (developerWorks, November 2010)
- Demo: Using workspaces with Rational System Architect by Jason A. Green (developerWorks, October 2009)
- developerWorks Technical Library for Rational System Architect:
- For information on the IBM Rational Software mentioned in this
article:
- Rational System Architect developerWorks web page and the online demonstration, plus the SA Compare documentation in the Information Center
- Rational Focal Point developerWorks page and the overview page
- Rational DOORS developerWorks page and the overview page
- Visit the Rational software area on developerWorks for technical resources and best practices
for all Rational Software Delivery Platform products.
- Stay current with developerWorks
technical events and webcasts focused on a variety of IBM products and IT industry
topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Improve your skills. Check the Rational training and
certification catalog, which includes many types of courses on a wide range of topics.
You can take some of them anywhere, any time, and many of the "Getting Started" ones are
free.
Get products and technologies
- Download a free, fully enabled trial version of Rational System Architect.
- Evaluate IBM software in the way
that suits you best: Download it for a trial, try it online, use it in a cloud environment, or
spend a few hours in the SOA Sandbox
learning how to implement service-oriented architecture efficiently.
Discuss
- For Rational System Architect, join the Enterprise
Architecture and Business Architecture forum hosted by developerWorks, plus the Rational System
Architect User Group on LinkedIn.
- Share your knowledge and help others who use Rational
software by writing a developerWorks article. You'll get worldwide exposure, RSS syndication, a
byline and a bio, and the benefit of professional editing and production on the developerWorks
Rational website. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and
requests.
- Ask and answer questions and increase your expertise when
you get involved in the Rational forums, cafés, and wikis.
- Connect with others who share your interests by joining the
developerWorks community and
responding to the developer-driven blogs.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
