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

Strategy, Architecture & Problem-Solving

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

Print Friendly, PDF & Email