This post addresses the capabilities and requirements for enterprise architecture workspaces & versioning. When envisioning and planning out any initiative, especially an architectural driven one, its important to keep an overall enterprise blueprint (model) up to date and maintained. Various initiatives and plans may impact upon the blueprint over its lifetime.
As an enterprise evolves, then so does its architecture. A strategy for maintaining the enterprise architecture over its lifetime (the baseline) is important to allow change to be driven in the context of everything else.
Detail and Techniques for EA Workspaces & Versioning
There are a number of techniques that are necessary to manage architecture over time. It’s important to understand the enterprise baseline, workspaces, baselines, merge and extract, workspace compare, concept versioning, concept compare, communities. The following sections detail each of these topics and why they are important and how they work together.
Dealing with Change
When we look at change within the context of innovation management and/or enterprise architecture, we can see that change is continuous, slower (than change in software development) and often has a medium-high approval cycle (governance).
There is also a need to manage access to information through community groups so that some aspects of the detail cannot be changed or viewed without permission. Proposals for change can take the form of multiple plans, option and programs that are proposed.
One of the main deliverables for an architecture blueprint is a set of recommendations and constraints and some idea of how to transition and decide between blueprints and different alternatives. The outputs of these alternatives maybe Time lines/Roadmaps, costs and resource.
An organization may move through different lifecycles at different phases of their enterprise architecture practice.
For example, within the TOGAF ADM, different iterations and approval lifecycles may be carried out.
Architecture context is setting the context of the architecture initiative. Architecture definition is about defining and iterating through the domains of architecture. Transition planning is focusing on moving from one state of the architecture to another. And, governance is about applying management and sign-off activities to architecture initiatives.
Enterprise Baseline
As an organization matures its architecture over time, a published version of the architecture should be made available. This will normally be done as a major release.
An enterprise baseline is a continuous moving target. In TOGAF terms, the continuum. That is, we would never roll back to a baseline without losing all of the descendants of the baseline. It is best practice to create a copy of a workspace of the baseline and increment that with a major version number.
In a simple ‘as is’ and ‘to be’ scenario (Figure 2), we may decide to outsource some of our data and systems management. Two alternative architectures may be examined and one chosen as the outcome.
Whilst alternative X and Y may be compared for value, the current architecture is baselined. When Y is chosen, it becomes the new baseline. This is an extremely simple way of managing architecture. At this point, we can publish the new baseline to the organization.
However, in most instances, management of the baseline and alternatives are far more complex. Figure 3 shows some example implementation and migration patterns for innovation management and enterprise architecture.
Workspaces
Workspaces can equate to the Plateau concept in ArchiMate. However, we’ve used the term workspace as it has a wider meaning. A workspace is defined as a relatively stable state of the architecture that exists at a moment in time. A workspace can represent either current, future or transition architecture. By nature, workspaces are hierarchical.
Transition workspaces represent the enterprise at incremental states reflecting the periods of transition between a current and future architecture (sometimes called baseline and target architecture). A current and future architecture may have many transition workspaces between them showing alternative ways that a future architecture may be achieved.
Transition workspaces are used to allow for work packages and projects to be grouped into managed portfolios and programs, demonstrating the business value of each transition. Workspaces should be created from other workspaces to create hierarchies and lineage. In this manner, workspaces can be used for decision making about alternatives.
Baselines
When a workspace exists for a limited time and is unlikely to be changed, we can baseline the architecture. Once architecture has been baselined, it should not be modified again, instead, it should flow to new target architecture. All changes should be made in the target architecture.
You should be able to view any baseline for historical purposes and to compare to the any other workspace.
Merge and Extract
In order to copy concepts between workspaces, its important to be able to merge into your current workspace or to extract out of your current workspace. Each concept you define should have a unique identifier. The identifier shouldn’t be the name.
When a concept is copied to another workspace (or made available to a workspace), it should retain its lineage. Workspaces that are baselined cannot have concepts copied into them.
Lineage, Workspace Compare and Gaps
When a concept exists within multiple workspaces, and the lineage has been created from workspace to workspace, then a compare can take place between two or more workspaces. Lineage is an extremely important concept. Much like human ancestors have lineage (grand parents, children, siblings etc.), concepts can have lineage.
The lineage is maintained through a concepts identifier. This means that even if a concept changes name between workspaces, we can still compare the concept by tracing its lineage up and down the workspace hierarchy.
A gap is the difference between two workspaces or plateaus. A gap usually shows what was created, updated or deleted between two workspaces. A gap is closely tied to a work package as it may instantiate a set of work to be done.
A comparison between two workspaces can automatically produce the contents of the gap and the created, updated or deleted status of the gap. Again this helps with project and portfolio management when assessing initiatives and work.
Concept Versioning
Concepts within their own right may be versioned. When a new version of a concept is produced, the current version of the concept is baselined. The concept baseline stores all of the associations that the concept currently has in that version, including the destination concepts at the end of an association. Version numbers are incremental and usually system generated.
A user may work on the current version and can see the previous versions for reference purposes.
A model is a network of concepts and other concepts will have their own associations. The current version of a concept only includes its immediate relatives. This is very similar to a configuration set in version control systems. In a team environment, concepts that are related via other concepts may well have been changed at a different time, in a different workspace or completely removed.
In Figure 5, we can see that the account management business capability has its own set of associations but these are not part of the CRM system version. If a concept version is rolled back to a previous version then all of its immediate relatives are rolled back to but not their associations.
If a concept has been removed, it is put back in place. If an association was removed it is added back. The implication of this is that rolling back a version of a concept may change the semantic meaning of the overall model as in Figure 6.
In Figure 7, Account Management had Account Manager associated with it.
If CRM system is rolled back to version 1 from version 2, then the new model looks like this example. There is a balance between base lining workspaces (entire configuration sets) and individual concepts.
Concept Compare
It is useful just to compare the lineage of a single concept anywhere.
Where used
In its simplest form, a ‘where used’ report is useful to show which concepts are in which workspaces and what their version numbers are. This report also makes use of lineage. This provides a view of all possible initiatives a particular concept is involved in and therefore an understanding of cross project or program dependencies.
Version Compare
Versions of concepts can be compared. The comparison will show the associations and concepts that have been created, updated or deleted for each version. A concept can be compared for two or more versions of the concept including the current version.
Concept compare is very different to a workspace compare. Workspace compare is about finding differences and gaps with a view to planning out work. Concept compare is about understanding what has changed and why.
Communities
Community access to workspaces and concepts needs to be managed. Access control is critical. some workspaces may be created purely for protecting access privileges. For example, an organization may have an initiative to reduce head count for a particular part of the business in order to streamline it. However, this alternative should not be visible to all stakeholders. A community can be set up and assigned as a private community to work with this alternative workspace.
In Summary
The use of workspaces, baselines, and comparisons is essential for bridging the gap between the architecture of the enterprise and the architecture of a particular solution or initiative. As part of the architectural planning process we need to be able to manage parallel solutions whilst retaining the relationship with the enterprise continuum.