The concept of merging standards and tools isn’t new, in fact my first professional role was to map the supplier’s tool (Oracle Designer) and method to the corporate methodology (Fujitsu Macroscope).

All traffic merges

So I’m approaching this, not with any apprehension of difficulty, but instead from a perspective of being concerned about the level of compromise necessary to integrate the tools, standards and methods.

I set out in the previous article why I was doing this.

I’d come across several articles mapping out the Business Motivation Model and Archimate, with varying degrees of success. The main issue is the granularity of goals and how that doesn’t really help with the difference between board-level goals and local, more project level goals. In a way, that may be an advantage. The best was this article at bizzdesign.com

The other issue I’m finding is that it’s not clear what’s before the fact and what’s after the fact, plus whether they relate directly or support each other. To explain, let’s consider a Benefit. I’d expect that Benefit to be defined early on in the life of a programme.

Then I’d expect to see an Outcome that relates to that Benefit. At least one Outcome, possibly more.

Firstly, the Outcome is something that happens as a result of the programme’s activities. The Expected Benefit is what’s defined early on and is realised through the Outcome(s). For me, the Outcome is the Realised Benefit.

That may seem a little awkward, but the implications become clear when you look at the Business Motivation Model and the inherent differences between Means and End. Both Benefits and Outcomes would be modelled under End. Both of them are statements about the end result. Benefits are stated before change occurs, outcomes are stated once change has occurred.

OMG Business motivation model

Bearing that in mind, MSP Benefits are mapped to:

• Goals in Archimate and
• Objectives in BMM

MSP Outcomes are mapped to:

• Outcomes in Archimate and
• Potential Impact (not shown) in BMM

The result

I’ve inserted part of the Archi model below. You’ll notice the 2 grey boxes for Goals and the green box for Outcomes. These are purely visual from Archi’s perspective; providing no information in the repository about relations to elements. I’ve included them to give an indication of how the mapping could work. We see the Archimate Goals as BMM Vision and MSP Vision. That vision will incorporate content, e.g. Benefits and plans which I’ll cover more in a later article.

Business Motivation – Goals – alancward.co.uk

The Starting Line

The starting line?

Starting with benefits and goals got me so far with the integration I wanted to achieve, but did highlight some of the issues:

• Different terminology between the standards (that’s to be expected)
• Different places in the organisation context (MSP’s place compared to BMM’s place)
• Some of the relationships don’t seem that clear in Archimate (without every relationship resolving to the default “associated to”, but I’ll cover this in a later article)

That second issue of different places is fundamental. While MSP, BMM and Archimate cover similar ideas of drivers, goals, benefits and outcomes, the roles that those artefacts play in the organisation in each standard or method are different.

The clue is in the title, MSP is design to manage programmes, whereas BMM and Archimate cover organisation-wide and even enterprise-wide concepts. So MSP is necessarily starting part-way down the corporate structure. True, it’s near the top of structure, but there will be drivers, goals and decisions made above MSP, sometimes in MoP (Management of Portfolios).

Conclusion

While drivers and goals can be mapped, the main issue has been that the Business Motivation Model is an organisation-wide concept, very top down (at least initially), whereas programmes usually start one or two levels down from the executive board.

I’ll address this, with more Archi examples in the next article in this series.