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

What we’ll cover

• Corporate vision as opposed to MSP vision
• Drivers and influencers

What we won’t cover

• Programme plans
• Risk governance, etc
• IT artefacts
• Anything that isn’t related to business motivation. Archimate and Archi are capable of modelling more than just business motivation, but my scope is purely the intersection of Business Motivation, Archimate and MSP.

Background

In the previous article, I mentioned that starting with the Programme creates some issues when integrating the chosen standards, methods and models. However it’s proven useful by highlighting the differences in levels of the models and their relative contexts within organisations.

For this article, I want to take a simplified (indeed, a very simplified view) of corporate decision making. It’s stripped-down so that we focus on how it affects Business Motivation and the use of MSP.

The external start

Our starting point is the set of Drivers that are influencing our change.

I’ve used the Archimate Driver to depict:

• MSP Influencer
• BMM Driver

These can be external or internal, but the initial set that propel an organisation to change have always appeared to be external to me. These could be forthcoming legislation, changing demographics, changing technology, market dominance by a competitor, etc.

In addition, how the organisation reacts to these drivers can also be drivers, but start with the external ones first. Even in the startup domain, that external driver could be market-driven based on the market’s need for saving time and/or effort with a particular task.

I’ve only chosen to model the one set of external drivers. It would be a simple task to add in internal drivers and their relationship to the external drivers.

Corporate Archimate

Assessment

All of those drivers need analysing, but not all are formally analysed. In some cases, the executive will simply decide on a route forwards. In other cases, more care is required or the driver is complex and so, an assessment of that driver will be required. Typically these are performed to prepare for the advent of new legislation, e.g. The Care Act, GDPR or Brexit.

The fabricated example I’ve chosen is based on an organisation responding to changing market conditions, choosing its place in the market, and facing a potentially different market under Brexit-type changes. I’ve assumed that the executive have decided how they’ll handle the market competitor changes, but will require an assessment of the Brexit-type change. It’s rarely that simple and in fact, a goal of increasing market would appear to be naive on its own. However I’m not intending to model every facet of the organisation.

Assessments could take some time, could take a significant amount of planning and be programmes or projects in their own right. I’ve chosen not to model that part of the concept here. Programmes to execute assessments would follow the same concepts as the programmes that we’re detailing here anyway.

MSP Programme Mandate

Once the corporate goals have been set, we’d see the initiation of implementation activities. This is the early stage with the rough outlining of programmes to deliver those goals. Larger sets of goals and cross-directorate changes could indicate a higher level such as portfolios. I’m sticking with programmes for this example since Portfolios would predominantly be more of the same modelling but with a few more levels between corporate and programme.

We’ll start with the mandate which can range in detail from a rough email to a more thought-out document. This is the command to start preparing the programme.

Programme Archimate

In the diagram above, I’ve used a grey frame for the MSP Programme Mandate. This is purely visual as an aid to understand how the artefacts relate to MSP.

Inside that frame, I’ve used two Archimate Deliverables for the Programme Mandate. In doing so, I’ve assumed that the mandate is actually a document, even if it’s an email. I’d expect the Programme Sponsor or SRO to have written that mandate. However, in reality, often the SRO is assigned after the programme has been further defined, so add in a stakeholder artefact for the CFO or whoever wrote the mandate as appropriate. The mandate allows a programme manager to prepare the programme.

Programme Brief

The first deliverable following the mandate is the Programme Brief which should flesh out the ideas in the mandate. Again, I’ve used a visual frame for the Briefs and use the Archimate Deliverable for the MSP Brief documents.

I’ve assumed a simplistic approach of one programme per corporate goal, again, not terribly realistic but doing it this way allows us to concentrate on what artefacts are required. We’re concentrating on the chain from corporate vision through to

The brief normally includes benefits, costs, timescales and risks. I usually think of this as the Business Case, so it has to include all the information necessary for a board to approve funding and permission to proceed. Depending on how you follow MSP, it may or may not include a vision. Although it’s difficult to see how it’s possible to progress beyond the brief if it doesn’t include a vision. The confusion sometimes arises since visions, especially complex, can be developed in parallel to the brief and delivered to the same board.

For the purposes here, the Brief and the Vision are separate documents, but there’s nothing to say that the Vision can’t be part of the Brief. There is no flow in this particular Archimate view, just a representation of what artefacts relate to other artefacts. The way that I’ve documented the relationships, the Vision would have to be part of the Brief in order to reference the Benefits. A potential confusion is that I haven’t placed the grey frame for the Brief around the Vision as well. Bear in mind that frame is purely a visual aid and doesn’t record hierarchy or boundary, but instead may indicate it visually.

Goals

I’ve used the Archimate Goal to represent

• BMM Objectives
• MSP Benefits

This was first covered in the previous article and is included here to set the context. Now we can see where we originally started (i.e. with the Programme), then started again at the top of the organisation and worked our way down to meet the Programme.

Similar to the concept of whether the vision is part of the brief or not, the placement below MSP Programme Brief does not include that they are defined later. Rather that they are separate artefacts that can be discussed separate to the Brief.

Another artefact within the Brief is the definition of how the programme will be delivered, e.g. timescales and resources required. That will show in the next article.

Also in the next article in the series, I’ll cover the Blueprint and the other elements that have been cut from the right-hand side of the diagrams so far.