The model I’ve been using in the previous articles has grown to become relative complex (complex for a online article, not for a typical business architecture model) while trying to describe a common situation in most organisations. I’m going to show it all in one diagram in this article and show different perspectives on the diagram.

Recap

In the first article, I introduced the standards and the tools that are in scope of this series of articles. To recap, the chosen tools/standards/methods are:

• Archimate – The open source enterprise architecture modelling standard
• Archi – a tool for working with Archimate
• Managing Successful Programmes (MSP)
• Business Motivation Model (BMM)

In the second article, I introduced how I’m handling benefits and goals.

In the third article, I introduced the corporate element of the BMM.

In the fourth article, I introduced the Blueprint element of MSP.

In this article, I’ll show the whole diagram so far and the achieving different perspectives on that model

What we’ll cover:

• The model covering all elements that have been discussed so far
• The use of viewpoints

What we won’t cover

• Plateaus (Plateaux)
• The current to future organisation model

Warning

Do not consider this article to contain the definitive method for documenting the combination of MSP, Business Motivation with Archimate.

I’m more confident about the parts of the model described in articles 1, 2 and 3, than I am in this. Mainly the right-hand side of the model doesn’t feel fully integrated. That’s instinct at the moment, but I’ll look to evaluate further.

The Whole Model

The model for this series of articles in one image

The model starts with the external drivers, influencing corporate ambition. There’s an example of an assessment. Archimate implies that a influencer does nothing to an organisation without an assessment. I’m not keen on that thought. Events will happen to your organisation whether or not you assess them. I can see where they’re coming from, i.e. the internal organisation will not respond to the external influence without an assessment, but it feels odd at the moment.

We then descend the left-hand side of the model through the goals being set, then into corporate governance (probably including portfolios in larger organisations), the MSP Mandate and Brief.

Further down we see the goals related to the MSP Vision, the MSP Outcomes and the Requirements.

On the right-hand side, there’s the assessment mentioned earlier. Below that there’s a gap while we’re in corporate governance on the left-hand side. Then we see the MSP Blueprint. And it starts to become more convoluted at that stage, especially if we include the descriptions of the future state, as you may expect in a Blueprint.

In the previous article regarding blueprints and missions, I highlighted that many programmes cannot have a Blueprint with a future state defined at the start. These are the programmes that are created with the specific purpose of designing the future. Having been involved with many of these, it that’s type of programme that I chose to portray, plus it takes us out of the comfort zone of works-in-theory to a zone of how-does-this-work-in-reality?

The final part is a collection of the 3 work packages. There would usually be more, but their inclusion is more to show how they’d relate to the rest of the model.

Missing Artifacts

I set out to see how Business Motivation Model and MSP could be modelled using Archimate. It’s common to see the use enterprise architecture tools focus on the current state or a future state, but without easily assisting with the navigation from one state to the other, especially regarding what needs to be involved in change programmes.

There is another part of the model, on a different diagram, that I’m going to discuss in a following article. It concerns that change, from documenting the current state to showing the delivery of the business capabilities in the future state.

In hindsight, I’d like to include the plateau artifact in the main model. That would be a better solution and would replace the To-Be organisation units currently included.

Connections

Part of what I wanted to achieve was to be able to see track the response to an influence all the way from the work package and it’s change on organisational units, policies, etc up through the programme governance to the executive. And also track the reverse.

Looking at the model, we can see that you can navigate from the top to the bottom. Nothing is isolated or standing on its own. However, not all of the relationships are that useful or required to be able to connect the top to the bottom.

Corporate Archimate

For instance, look at the Corporate Archimate diagram above. You’ll notice the dotted lines with arrowheads, e.g. between Changes in Legislation and Assess Impact of Legislation. That’s because that relationship is “influences”. It hasn’t defaulted to the standard of “associates with”. Archimate allows a default “associated with” for any artifacts, but it’s not always that useful and implies that you’re deviating from the purposes of the model. The straight line relationship between Forthcoming Demographic Change and Increase Market share is a good example of that “associated with” relationship. Fine if you know what you’re doing.

In our case, I’d already mentioned I’d take a bit of short-cut and only included one assessment. The point here, is that to use Archimate properly, we have to go from Influencer through Assessment to Goal. Even if an assessment is just the CEO or MD thinking it through for a few minutes, it’s still an Assessment.

Looking further down the model, we see that the goal defined in the corporate vision do not relate directly to those defined in the programme vision. They should. In fact, that’s the alignment that I’m most interested in. Instead, during the development of this model, I connected them through the MSP Mandate and Brief. Since Archi is a repository-based system, it’d be easy enough to connect them. Unfortunately for us in the model, the mandate and the brief are only connected with a the default “associated with” relationship.

Business Motivation goals

Perspectives

So my next step is to ensure that all relationships are worth documenting by trying to avoid the default “associated with” relationship where possible.

To assist with that, I’ve been looking at different perspectives within the same diagram. Archi implements these as Viewpoints. So far, we’ve been using the default “All” viewpoint.

Motivation Viewpoint

The first viewpoint we’re going to look at is Motivation. Using this viewpoint, we’d expect to see only the artifacts and relationships that relate to motivation, and we’d hope that this viewpoint aligns with Business Motivation Model.

Business Motivation Motivation

As we can see, all Deliverables are now greyed out (those relating the Mandate, Brief, Mission and Blueprint). Also greyed-out are the organisational units, business capabilities, capability changes and the work packages. From a BMM perspective, all that makes sense. It also highlights the need to connect the corporate goals with the programme goals directly, separate to the programme mandate and brief.

Goal Realization Viewpoint

I also used the Goal Realization viewpoint which overlaps with the Motivation viewpoint. In addition, it greys-out stakeholders and influencers. My intention here isn’t to find the perfect viewpoint. It can’t exist since it depends on the purpose and the audience. I was intending to see what the tool can do to assist in achieving a more logical model, consistent with the underlying Archimate language.

Business Motivation Goal Realization

Validation

That quest for the logical consistency and use of the model/tool segues nicely to the validation tool. I had wanted this to point towards missing relationships or where the default relationship is used. I wanted pointers to making it a better model and I’d accept better being defined in terms of adherence to the Archimate language. More ideal, would be the ability to receive pointers to a better model based on a selectable standard, e.g. Business Motivation Model, Enterprise Business Motivation Model, etc. I had in mind the way that code editors, e.g. Sublime, can provide syntax checking based on various languages.

However, the validation in Archi is simpler than that.

There is the useful highlight of duplicate artifacts and unused artifacts. Then there is the list of artifacts that do not belong in that particular viewpoint. That’s useful if you only ever want to depict a model that conforms to a single viewpoint. It’s not as useful when you’re attempting to depict a model that crosses viewpoints, such as the mix of MSP, BMM and Archimate we’ve seen in this model.

Next Steps

1. I’m going to discuss the partner model to this model. It highlights the organisational units, capabilities etc.
2. I’m going to add in the relationships between the corporate goals and the programme goals. The aim is to see a clear line from top to bottom when using the Motivation viewpoint. That’s a starting position.
3. I’m going to replace the future organisation units in this model with a plateau

At the moment, it would be wise to view the diagrams and model included in these articles as a draft. They are open to discussion and subject to change.

Comment

Any comments, get in touch @alanward