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 this article, I’m going to introduce the Blueprint element of MSP.

What we’ll cover:

• The MSP Blueprint
• The MSP Mission
• Some of the capabilities that we’re affecting
• Design Principles
• The start of work packages

What we won’t cover

• The detail of the organisation design (e.g. current and future designs)
• The full capability map
• Multiple programmes

Warning

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

I have more confidence in the previous articles and the documentation contained within them than in what I’m covering in this article. See the Aside below for more detail.

The Blueprint

Similar to the previous diagrams, I’ve used a grey frame to indicate the MSP Blueprint. Unlike the one I used for the MSP Programme Brief, in this article, I’ve included the content I’d expect to see within the Blueprint within the same grey frame. Remember that the frame is visual only.

Again, following the previous articles, the Blueprint is a document and has been modelled as a Archimate Deliverable.

I expect a Blueprint to take the information from the Mandate and deliver a description of what the organisation/technology will look like when the change has been delivered. A key component of that is what large-scale changes we’re likely to see during the course of the programme. In this case, I’ve used:

Archimate Course of Action to denote the:

• BMM Mission
• MSP Mission

The red frame is visual again. I’m using it to highlight the different sections of the Blueprint.

Business Motivation Blueprint

Design Principles

I expect the designs within Blueprints to be draft or incomplete, especially in Programmes that are tasked with designing the future operation of an organisation. That may appear in conflict with the typical requirement for a Blueprint that states the design upfront (as part of the Brief and Blueprint) before the programme can be funded, but some Programmes are iterative or need to learn from Assessments before the design can be finalised. And it’s that type of programme that I find myself more commonly working on; those that have the mandate to define the future, without knowing what that future will look like at the start of the programme. So we develop the future design over time and produce iterations of the Blueprint.

Fortunately, we can start with Design Principles, e.g. what criteria can we set that constrain our designs later on? An example here is “Enterprise above Siloes”. I’d usually have a longer description about what this means and how it will affect design further downstream. In this case, we will design the best solution for the enterprise rather than for an individual department. That principle will most definitely come in useful later when considering organisational design.

These Design Principles are modelled as:

• BMM Directive (Business Policy/Business Rule)
• Archimate Principle

It’s worth noting that I’ve strayed from pure BMM here. From the definition of BMM 1.3:

Organisational Design

On the right of the grey frame, I’ve include a blue frame for High Level Organisational Design.

Within that, we have 3 teams of East Team, North-West Team and South Team. Behind the scenes in a separate diagram (but the same repository), I’ve documented a change from 3 teams which are based on sales, marketing and product support/after support and decided that following the Design Principle of “Deliver Local Where Possible” that each of the teams will be restructure with multi-skilled staff to deliver the same capabilities in the 3 locations. This is a fabricated example so we don’t have enough information to evaluate whether this would be a good thing for the organisation. But it is a typical change.

The teams are modelled with the:

• Archimate Business Actor

Since this is the Blueprint and focusing on the future, I’ve only included the representation for the future organisational design, not the current.

Capability

The teams mentioned earlier deliver Business Capability. I’ve included high-level capabilities (typically Level 1 or Level 2 depending on your starting point) in this diagram: Sales Management and Marketing. A common capability map would include lower levels of capability, e.g. sales reporting, etc. The Capability Map itself would be a separate, but related diagram. We would then have the option of including lower level capabilities in the Blueprint if appropriate. For the purposes of this article, I’ve chosen two higher level capabilities.

For the type of programme listed here, we would expect the programme to be active in developing the capabilities, perhaps even creating them if they don’t exist yet. However considering the main changes revolve around a re-alignment of roles and locations, then the Business Capabilities would still be the same, just delivered in all locations and probably delivered by a different skill set.

Business Capability does not fit in MSP or BMM and is an artifact from Business Architecture. Hence there are no MSP or BMM objects to reference as equivalent.

Capability Changes

To highlight this change, I’ve used a green frame for Capability Changes. This isn’t a concept specifically in MSP or BMM, instead it’s more about the changes being introduced by the programme, from a Business Architecture perspective.

Capability Change is an modelled as:

• Archimate Course of Action.

I’d suggest thinking about the Courses of Action used earlier in the Mission as defining how we are going to support the goals and the Course of Action in the Capability Change as how we are going to implement the Mission.

This Capability Change of “Cross-skilled roles” is essential to the implementation of the re-aligned teams to the right of the diagram.

Implementation

The final part of a Blueprint is how the programme will deliver its changes, e.g. how will it apportion work and govern the activities going forward?

I’ve used a turquoise frame to highlight the work packages resulting from the Programme Initiation. These are the work packages that will deliver the objectives.

These do not fit within the BMM, but do relate to it.

Archimate Work Packages were used to model:

• MSP/Prince2 Work packages/Work Streams
• BMM – no corresponding object

The Work Packages deliver the outcomes based on fulfilling the requirements.

An Aside

Admittedly, the integration of the methods, tool and standards started to become murkier here with little clarity in how changes are supported. Most noticeable of the issues were:

1. Finding an approach to model how Business Capabilities relate to other artefacts such as future teams. I’ll publish the diagram that contains the changes in a following article and you’ll see why the artefacts shown in today’s diagram were chosen.
2. Documenting the relationships between Directives and Courses of Action and their use in programmes that implement change in strategic direction.

Some of that confusion could be:

• my lack of familiarity with the Archimate language for these artifacts.
• the lack of detailed documentation and examples for these Archimate artifacts. There is some very good documentation available. However, in common, with most EA tools, they’re great at documenting how to use the tool within a static context, e.g. defining a current state. But you then have to find a way to use them to depict different states, e.g. as an organisation evolves over time. This can range from prefixing artefacts and diagrams, creating folders based on phases, using attributes to denote which phase an artefact should be in, etc. This “how to use the tool” information is usually held by the implementation consultants of each tool. They’ll know what has worked elsewhere, what pitfalls are involved if you deviate, etc.
• that the modelling language hasn’t been designed to do what I want to do
• that the tools doesn’t reflect the modelling language (I’ve no evidence to say it hasn’t implemented and all reason to believe it that Archi is an accurate representation of Archimate)
• that it is just a first draft, subject to change and that future versions will depict a better model

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.

Any comments, get in touch @alanward