Art requires rigour, science requires creativity

RigourAndCreativity

I heard this quote the other day, but I didn’t catch who originally said it.

Art requires rigour, science requires creativity

The first point is that it’s contrary to the standard view. The second point is that both perspectives are valid and that there shouldn’t be that much of a difference.

It then made me think of typical transformation programme roles and the relation between creativity and rigour. Most roles have a balance between the two, with that balance changing according to the standard role and, at times, according to the demands on that role.

RigourAndCreativity
Rigour And Creativity

For instance, process analysts should generally follow a set of standards. Business Analysts have to be more creative, but still have methodologies to follow. Service Designers have less rigour methods, usually a composition of tools and techniques rather than the standardised methodologies of previous decades. At the more rigorous side, project managers have their methodologies and frameworks to follow. Programme managers see a wider scope and have more creativity in organising the interdependencies. Which then fits nicely with my normal comment that a Business Architect has more in common with a Programme Manager than a Project Manager; there are more skills in common, even though the professional methods involved are different. Which leads me to the Business Architect who has to know when to be standardised and when to be creative. There has to be the flexibility to modify the approach to suit the needs of the client, depending on the stage of transformation.

 

 

 

 

Using Archimate for Business Motivation Model and MSP – Part 6: Capabilities and Org Units

Capability Vision 0_04

Taking the model defined so far and introducing the concept of capability changes and the effect on the organisation units.

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 the fifth article, I introduced the whole diagram so far and the achieving different perspectives on that model

In this article, I’m going to introduce a related model that includes how to model the effects on capabilities and organisation units.

What we’ll cover:

  • Current and future states regarding one of the changes
  • Reorganisation
  • Plateaus

What we won’t cover

  • The original model
  • All of the changes implied in the original model

Warning

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

It’s a work-in-progress and is developing in line as I understand more of the complexity of interaction between the different models, standards and tools.

Start with the Current Model

Current Organisation Model

I’ve taken the design principle of Deliver local where possible from the main model as the root of this view. It’s off the page in this crop but we will see it later when we discuss the future model as well. The basic concept here is that the current model has 3 offices; one provides marketing, one provides sales and one provides product support. Each office houses staff aligned to those capabilities. The plateau is used to describe the current state (and relates back to the main model which has been updated with plateaus).

So working up from the plateau of the Current State at the bottom, we see that it comprises the business org units of Marketing Associate, Sales Associate and Product Support Associate. I’m using the Plateau to capture all the artifacts related to the state of the organisation at that time. Later we’ll see a second Plateau for the future of the organisation. For this particular plateau:

  • The Marketing Associate fulfils the role of Marketing in the NorthWest office. The Marketing role realises the Marketing capability.
  • The Sales Associate fulfils the role of Sales in the East office. The Sales role realises the Sales capability.
  • The Product Support Associate fulfils the role of Product Support in the South office. The Product Support role realises the Product Support capability.

This is necessarily simplified compared to the majority of companies in existence. It’s rare to see such simplicity in coterminosity but suffices for our purposes.

The Future Model

Future Org Vision 0_04
Model of Future Organisation

This is the top half of the diagram. What I’ve shown here starts at the top right, with the design principle. A fuller description of the principle is that we’ll provide the service as close to the customer as reasonable. It could be combined with another principle that allows for tailoring of products according to the demographic needs within specific geographies.

I’ve then used a Plateau for the the Future State, which realises the design principle of Deliver Local Where Possible.

In the current organisation, with three offices in the area, a customer is only served if they require the services of the office that is currently near to them. So Sales from one office and Product Support from another. If customer is in the North and they require Product Support, then they’d have to travel (assuming face-to-face is required) to the South office.

I would envisage an assessment detailing options. For instance, we could achieve the same design principle through acquiring other premises, through partnering with other organisations to achieve a more local spread, through rationalisation of current premises or through a combination of these options. I’ve chosen to progress with the option of rationalisation here, highlighting what the organisation could look like if it were to have all 3 capabilities available in every office.

One way of achieving this would be to distribute the people in each office and share them across the 3 offices so each office had one even share of 1/3 marketing, 1/3 sales and 1/3 product support. Or we can implement a cross-skilled role where every person can cover marketing, sales and product support. I’ve gone with the cross-skilled role option. I’m not saying here that organisations should do this, I’m using it as an exercise to model current and future states.

The Design Principle of Deliver Local Where Possible is realised by Cross-Skilled Roles Course of Action which in turn is realised by a new organisational unit of Product Line Associate. That’s the key to making this change. The Product Line Associate realises the Combined Team Capability and we find ourselves having to make some documentation descisions at this point. Part of the issue is that we’re crossing themes, discussing elements from Motivation, Business and Strategy in the same model.

So I’ve included the word Capability in the title of Combined Team Capability, only so that we can quickly identify and differentiate it in this article. I wouldn’t normally include the artifact name in the title; it’s clumsy.

Combined Team Capability is realised by the org units of NW Team, East Team and South Team. At the top-left, we see that Combined Team Capability is composed of the Combined Team Capabilities of Marketing, Sales Management and Product Support.

The same offices as in the current model have been used. Rather the association relationships crossing current and future, I’ve chosen to include a copy of the office artifacts in the future part of the model. There are benefits and disadvantages to both ways of modelling. Using an artifact only once, such as an office, allows you to see the nexus of change and more importantly, in this case, what’s not changing. Copying the artifact allows for a neater diagram but requires more interpretation.

The other main difference between current and future is that:

  • in the current state, the Offices serve the Business Role
  • in the future state, the Offices serve the Business Actor (or the organisational unit)

Neither is wrong, but consistency would be preferred. In the current state, there is significantly more clarity regarding which roles and actors are using which offices, due to a single capability per office. In the future state, with the mixed capabilities per office, there would be numerous business roles.

The complete view of Capability Change

Capability Vision 0_04
Capability Vision 0_04

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
  4. Update with consistent view of Business Roles and Offices

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

Using Archimate for Business Motivation Model and MSP – Part 5: Perspectives

The whole model for this series of articles

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 whole model for this series of articles
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
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
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
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
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

Using Archimate for Business Motivation Model and MSP – Part 4: Mission

Business Motivation Blueprint

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
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:

“Directives govern Courses of Action”

Directives include Business Policies and Business Rules. Courses of Action include Strategies and Tactics. The concept of a Courses of Actions producing Directives doesn’t appear to exist within BMM.

The reality of the model may be different in that we’d likely see a Work Package acting as the initiation phase of the Programme and the main deliverable would be the Blueprint. That deliverable includes the broad strategies in how the objectives will be met and the business rules that will be used to constrain  the more detailed design later on.

The work package would be initiated based on the Mandate and Vision in order to create the Blueprint and the Mission. There would have been a package of work before this to cover the work necessary to produce the Brief following the Mandate, but as I mentioned in that article, I wasn’t covering work packages at that time. More importantly, in most organisations, it probably wouldn’t exist as a formal Work Package anyway.

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

Using Archimate for Business Motivation Model and MSP – Part 3: Corporate

Corporate Archimate

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
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
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.

Using Archimate for Business Motivation Model and MSP – Part 2: Goals and Benefits

Business Motivation - Goals - alancward.co.uk

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
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
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
Business Motivation – Goals – alancward.co.uk

 

The Starting Line
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.