Using Archimate to model OKRs for Business Motivation

A Fabricated Example of Using OKRs with Archimate

Following the theme of moulding different modelling languages, methodologies and toolsets together, I want to take a look at how to model OKRs in Archimate.

Once again, I’m using Archi (or ArchimateTool) with the Archimate modelling language.

OKRs do not cascade

Just because the diagram depicts a hierarchy, doesn’t mean that the objectives cascade down the organisational hierarchy. Following the logic in OKRs don’t cascade, I’ve taken the approach of the depicting the hierarchy, rather than how that hierarchy is achieved. In the article, Felipe mentions that objectives should not be cascaded down the organisation. Instead, objectives and key results should be discussed and agreed at each level. The resulting picture is the same either way, but the content of the objectives and key results may be different depending on the route.

Contributing Goals

Depending on the level of the organisation, many of the components that achieve an Objective will not be Key Results, but instead will be lower level Objectives (e.g. of the next team down in the corporate hierarchy or downstream in case of a flatter hierarchy). The diagram allows both Key Results and Objectives to form part of an Objective.

Modelling Goals and Objectives

Key Results have been modelled as Outcomes. Objectives and Contributing Goals (lower-level Objectives) have been modelled as Goals. In doing so, I’ve allowed for a hierarchy of Objectives to fulfil the concept of Contributing Goals. Had I gone with a model of Objective = Outcome, we would have seen a model of hierarchical outcomes which would not have made as much sense, especially to those having to achieve those outcomes.

Alignment

From the perspective of Business Architecture, I’m interested in the alignment of actions to the overall vision. I like to see a clean line connecting actions of the workforce to corporate objectives to vision. Many organisations suffer because the objectives are cascaded down rather than agreed at each level. Combining OKRs with a culture of joint-goal setting has a good chance of resolving that core issue.

Notes about the diagram

The content is fabricated; completely artificial. I haven’t populated every single branch, but enough to indicate what could be captured. For those areas that I did populate, I kept to the concept of 3 key results per Objective, of which any of the Key Results can be replaced with Contributing Goals. You can flex that as you wish.

I’ve created a tiny environment in which the OKRs operate, featuring an internal driver for change, an external driver, the assessments for both and the corporate vision and missions.

Implementation

The interesting concept for me regarding business motivation is that the diagram is agnostic of the organisation structure in that it doesn’t indicate which team or who is responsible for achieving which objectives or key results. I’ve done that on purpose.

If we imagine a typical organisation of 400 people. Each of those named 400 individuals could have Key Results to deliver. Some of those Key Results would contribute to team Objectives. Some of those team Objectives would coalesce to fulfil higher level Objectives and so on. That’s the bottom-up picture.

The top-down picture is that the strategy needs to pervade the organisation and steer the choice of actions and the delivery of those actions. At the top level, the objectives may be independent of who is going to deliver them, but shortly thereafter the key results or contributing goals would have to be assigned. And it’s likely that they’ll be assigned to relevant directors (in the case of stretch targets and keeping the operation running) or delivery teams (in the case of changes). However each of the delivery teams should have a sponsor. It’s that sponsor that’s actually accountable in this case for the delivery of the key result, whereas in many organisations it would be the delivery team.

Overall, OKRs force a concept of personal responsibility or rather, a concept of personal accountability if we follow a RACI model. For the majority of a workforce, the individual is likely to be both accountable and responsible for their key results.

What I haven’t address is the non-aligned use of OKRs, e.g. allowing or encouraging the setting of key results that do not fit with corporate objectives.

A Fabricated Example of Using OKRs with Archimate
A Fabricated Example of Using OKRs with Archimate

The Whole Chicken

Chick

KFC has a radio commercial playing over the last few weeks, but I’m struggling to understand what it means. I understand the words but they’re contradictory, even within the commercial spot itself. I’m left wondering what the business motivation is behind commissioning that ad slot. What was the intention?

The Content

Here are some of the main points of the commercial:

“The whole chicken, just the chicken and nothing but the chicken.”

“For £12.99”

“Prices may vary”

Analysis

Let’s take each of those in turn:

“The whole chicken, just the chicken and nothing but the chicken.”

Did someone fall in love with that phrase and refuse to see the reality when presented with it. The deal includes fries and drink. Neither of them count as chicken. It’s not just chicken or nothing but the chicken. There are sides. Maybe those are alternative facts.

The deal includes pieces of chicken. I’m assuming chicken feet, beak and eyes aren’t included in the pieces of chicken so neither is it the whole chicken. In fact, 100% of the phrases in that sentence are false.

“For £12.99”

Great. We now know how much some of the chicken pieces with sides and drink costs. However, the following phrase removes that knowledge. “Prices may vary”. It’s more complicated than that since the price depends on where you buy from, so it’s not £12.99 as advertised.

Remove the “whole chicken” line and the price and there’s not much content left of that advert. Now we’re left knowing that they sell chicken, drink and sides but we’re unsure of the price.

Half of that advert could be paraphrased as something similar to “we sell chicken with sides and drink and the price varies”.

I think most of us already knew that.

Motivation

So what’s the point of an advert? Is it to raise awareness, inform of new releases/changes, inform of offers, etc? I’m interested in the business motivation behind actions by companies. Whether using Business Motivation Model, VMOST or similar models, many of the principles are the same. Identify the top-level vision, separate into big themes and then align every action to those themes.

I’d struggle with this one to understand what theme was that advert aligned to?

I’d guess it’s increase awareness of offer, in order to increase a positive change in purchases (converting people who are already familiar with KFC products to purchase more than they would have done). I’d also guess it’s aimed at lapsed customers, e.g. those who used to buy but have stopped/paused.

Maybe the sole purpose was to lodge the phrase “The whole chicken, just the chicken and nothing but the chicken.” into our minds; associating take-away fried chicken with KFC first and foremost.

I also wonder if the business motivation had been clear, with a connection between vision, theme and action, would the commercial have sounded different or had different content?

GDPR: The White Knight or The Elephant in The Room

Business Motivation Model for GDPR

I’m going to use GDPR as an example of how prioritised goals can make a big difference in how an organisation responds to change. I’ve no wish to jump on the consultancy bandwagon that is GDPR; I’m definitely no expert on the subject. However, GDPR will serve as a good example in this content as it’s a topical subject that many organisations are addressing and so should be at the forefront of many strategic and tactical discussions.

A brief perspective on GDPR

I have a simple view of GDPR in that it’s requiring organisations to be better citizens, i.e. to behave better with the data that they obtain and manage. While there are a those complaining about the effects of GDPR, I would first want to question the motives of the companies they work for. I would be looking to see whether the motives are customer-centric or profit-centric. For most customer-centric organisations, most of GDPR is doing what they do already, but with some more rigour to their processes. Unfortunately GDPR is a bit of sledgehammer and a few other nuts will get cracked.

Who wants it?

I’ve written before about how companies can slow down checkout queues for the purpose of collecting customer contact data, e.g. emails, etc. That’s based on what the company wants, not what the customer wants.

GDPR has stronger implications for what can be done with customer data, potentially rendering data useless collected in such a way. Actually, it goes further in terms of legality of handling and processing data, but we’ll stick to usefulness to the company for now. The important point is that for many companies, there will have to be some changes to how they collect data in that manner and potentially if they continue to collect it at all.

Business Motivation Model

So let’s apply business motivation model and see what GDPR looks like in this case.

Business Motivation Model for GDPR
Business Motivation Model for GDPR

 

The above diagram depicts two companies. One on the left and one of the right; there’s a gap between the top. It is a simplified business motivation model showing the difference between the two organisations, based on one single goal at the top.

For the left-hand company, the main goal is to Provide the best customer service possible. They are achieving this through a sub-goal (maybe a mission in many organisations) of Build relationships with customers. This goal is achieved by the outcome of Capture Customer Contact Details. I’m simplifying to allow outcomes as measurable effects that will happen.

The outcome is realised by a process group of Ask for details of customer which is part of the Pre-GDPR state or plateau. That process group fulfils the outcome for the situation before GDPR. We’re interested in what happens in reaction to GDPR.

In the same company, we can see GDPR as a external driver. The company conducts an assessment and we have a goal of Be GDPR compliant.

That goal influences Capture Customer Contact Details.

We have a work package designed to achieve that goal of Become GDPR Compliant.

For the Post-GDPR state, notice that there is a revised process group of Revised Customer Engagement. This process group focusses on building the relationship. It’s implemented by the Become GDPR Compliant work package. You can trace the line up to the goal of Provide the best customer service possible and the driver of GDPR

Meanwhile, on the right-hand side, we see a similar motivation model, but with some differences. The GDPR elements remain the same. What has changed is the overall goal of Increase Revenue which includes the sub-goal of Increase Revenue from Individual Customers. To achieve those two goals, we end up with a different process group for the post-GDPR state. The result is the same as the original process, but prefaced with an explanation of what we’ll use the data for, etc.

 

Further Analyses

The Business Motivation Model was simplified in this case. I’d expect to see design principles/constraints, more detailed goals and objectives on the company-side and more detailed goals and objectives on the GDPR assessment side. All of those would constrain the future design.

For instance, the revised process groups I’ve displayed are not the only options that meet the listed goals. However with more goals and outcomes included, I’d expect there to be fewer options to choose between.

Conclusion

The examination of the GDPR scenario through a Business Motivation Model indicates at least two responses to a common data collection issue.

The end result is that it:

  1. may speed up queues since companies realise they can’t just ask for contact data and they decide to not ask,
  2. may speed up queues since companies realise that the interaction doesn’t allow for valuable data to be collected since they won’t have an agreement to use it and, again they decide not to ask, or
  3. may elongate queues so that the companies can ask for permission

Back to the title, I see options (1) and (2) being the white knights for the customers of many companies. We’re hoping that companies follow common sense and implement changes that both respect the customer experience and adhere to GDPR. However in addressing the elephant in the room of how processes can be changed to suit GDPR (rather than improved for the customer), we may end up with (3) and a worse customer experience.

Finding a balance between the needs of the organisation and the needs of the customer

Checkout Till
Some companies are immature in their approach to customer relationship management (CRM), but at the heart is a desire to get something for free. And that’s wrong.

The scenario

You look around a shop, you pick something up, take it to the checkout, wait in a queue. You notice that the queue is moving slowly, despite most customer only having a handful of items and then paying with credit card. Maybe the link to the credit card authoriser is a bit flakey today? It’s your turn at the checkout. Once the greeting and the small talk is out of the way, the dreaded question is delivered by the sales assistant “Can I have your email address please?” or some variant on that request for your email. This may be followed with “can I take your postcode?” or “do you already receive our newsletter?”.

The analysis

What’s happened is that the company’s desire for collecting valuable customer data got in the way of its prime purpose and I’m guessing the prime purpose is to make money by selling goods that customers want to the customers that want those goods.
There are other methods for collecting customer data. Some methods cost more than others, some are more accurate than others, some are more comprehensive than others. More importantly, some are less demanding to the customer and even less demanding to the customers in the queue behind them.
Often the desire is created due to a new multi-channel campaign that wants to treat all customer channels equally, not recognising that there’s a different social contract in place when you’re in a store to the one that’s in place when you’re buying on line. Companies that slow down the queue in order to collect information have broken that social contract.

Exceptions

While I’m against slowing queues down, I can concede that short analyses are valuable. This would mean performing the data collection during the natural queue created by your checkout processes. Even then, I’d be concerned that you have a queue and, while it may be acceptable to have queues, I would question an organisation if it counts queues as excellent customer service. If the answer to that is no, then we can prompt other questions such as relative priorities, but that’s for a different article. The take-away here is that companies usually choose acceptable customer service over exemplary customer service.
There are potentially other methods that they could use in store. One that never seems to be used apart from by car salespersons is the option of walking up to a customer, engaging in a conversation and then asking for their contact details. Can you imagine this working in your supermarket, the next time you buy a phone or the next clothing shop you go into? While I don’t believe we should all move to the used-car sales model, I do believe there is room to find a better balance.

The Real Issue

There is no need to wait until the checkout to ask for this information. In fact, asking at the checkout is contrary to the purpose of the checkout.
What’s missing is that the company is trying to build a relationship with the customer. But rather than trying to do that in an underhanded manner at the checkout till (sometimes in the guise of asking to email a receipt), why not engage with that customer while they’re perusing? This highlights the actual issue. It’s not what the company wants, but what the customer wants. What value is the company going to deliver to the customer in exchange for a longer-term relationship?
So rather than trying to obtain an email address for free, consider what you’re going to provide so that the customer would actually want to provide their email address. When viewed in that light, a 10% voucher may not be sufficient.

Alignment

I take issue with any company that slows down the purchasing process for the purpose of collecting customer information. Whether it works financially or not, it’s a bad customer experience and not one I want to see implemented in any shops. I believe in a managed flow from a lean perspective (that’s Lean, not Lean Startup) and so, simplistically, anything that gets in the way of that flow is waste and should be avoided. Instead I’d provide options for collecting emails while people are queueing, while they’re on their way out (e.g. a pedestal table, pen, cards and a ballot/post box on the way out) or have it built into the product itself (like the cupcake liner mentioned in an earlier article).
In short, engage with customers at a more appropriate time (or stage of their purchase) and collect data that’s appropriate to collect for your future interactions but don’t make the purchase process worse just so that you can collect that data.
Any comments, you can find me @alanward.

How Might We Apply Service Design to the Enterprise?

Business Architecture and Service Design

I simplistically take the view that Service Design is the concepts and methods of Design Thinking applied to making services work better for their customers. It’s a definition that works in the circles I most commonly move in, i.e. directors, programme directors, etc. It allows me to set the stage in which service design and design thinking both play.

However on the same stage, we commonly find KPIs, OKRs, Business Architecture, etc. And the stage starts to look crowded very quickly. We also start to see people pulling in different directions, like someone has let a mouse loose in the chorus of an Italian opera.

Operas and plays have directors, often many directors each responsible for their own domain, but with one artistic director responsible for the overall vision.

Envisioning

Now imagine what would the stage look like if the director asked the question “How might we…..?”.

It’s the opening line of many a design thinking ideation round. And it serves many purposes, explained better by others elsewhere.

Taking the stage analogy further, I hear questions such as “How might we produce more colourful costumes?”, “How might we light the back of the stage better?”, “How might we fill this part of the stage?”.

All of them are good questions and relate to the specific problem that has been uncovered during the discovery phase.

What they’re not doing is thinking of the entirety of the show. They just resolve the problem that was uncovered for their part of the show.

How might we approach this differently?

What they’re not doing is asking “How might we aim to deliver a better show?

Business Architecture and Service Design
Business Architecture and Service Design

Let’s look at that question more thoroughly.

It’s got the typical format of “How might we…?” introducing the concepts of inclusion, a shared problem, and an indication of possibilities and potential.

I didn’t stop at the simpler question of “How might we deliver a better show?”. That’s where service design typically fits.

If we step back from the stage and consider an organisation, even applying service design in this way would be a stretch. At this scale, we’d be trying to apply service design to the whole organisation, e.g. how might we deliver better services? Where typically each service would have its own change activity, often in the form of design sprints, etc. Instead, the simpler question of “how might we deliver a better show?” could be translated into a top-down design question for an organisation of “how might we deliver better products and services?”, “how might we become a better organisation?” or similar organisation-wide design questions.

However, the question I introduced earlier focusses on the aim, not necessarily the end result. It asks about how might we aim to deliver. In focussing on the aim, it allows us to explore the goals and how goals are set. It leads us to question what goals would be required in order to deliver a better show. In understanding the goals, we have to understand what good looks like, what counts as successful and not just in the eyes of the board, but in the eyes of customers. If we set the concept of goals smart enough, this could easily set the scene for continual improvement.

Alignment with Business Architecture

Back to the organisation, now that we’re asking about the aims, and we’ve looked at the goals, we can start to see how the goals for the enterprise could be set. This brings Service Design up to the area where it aligns with Business Architecture. While this may seem at odds with a top-down approach of setting KPIs, we have to ask the question of why wouldn’t we want to develop an organisation that is driven by achieving its goals that deliver value to customers?

Alternative Business Motivation

By combining Business Architecture with Service Design, there is the possibility of redefining the concept of Business Model Modelling. Typically that’s a top-down approach, modelling external influencers, assessments, goals, objectives/outcomes, etc. Taking the combined service design/business architecture approach would result in metrics that matter to customers as the metrics percolate up through the organisation, not cascade down as is more common.

Whereas the concept of One Metric That Matters may suit startups as they redefine/focus on a different metric per stage of development and growth, it would not be expected to change as often in a more mature organisation. Instead, we may see a single metric that is of most interest for a cycle of improvement. But here’s the clincher – that metric would be an aggregate of the metrics defined by exploring the problem space with customers, not one that’s defined by an executive board.

However we may see a situation where an executive board decides to steer the organisation away from its current model towards a different business model. In that case, we would consider a more top-down approach.

The Maturing of Business Architecture

Enterprise Architecture and Business Architecture as Peers

In Black Sheep or Shepherd, I introduced the idea that Business Architecture isn’t aligned with Enterprise Architecture as well as we may expect from looking at traditional structures for Enterprise Architecture.

I’ve had several conversations about that topic since, all raised by the person I was talking with, rather than me asking them. And we’re all coming to similar set of conclusions:

  1. Business Architecture doesn’t fit well within Enterprise Architecture (more on this below)
  2. Business Architecture as a profession is maturing
  3. Organisations who are using Business Architects are using them differently
  4. Business Architecture may be better defined as a peer capability to Enterprise Architecture, rather than within EA.

Let’s take each in turn.

1. Business Architecture doesn’t fit well within Enterprise Architecture

I covered a lot of this in Black Sheep or Shepherd. The traditional implementation of EA originates from an IT perspective. Enterprise Architecture is typically initiated from with the IT function. While EA is meant to include Business Architecture in parallel to Technical Architecture, etc, Business Architecture is typically the last to be included and takes a position following Technical Architecture.

Enterprise Architecture structure
Enterprise Architecture structure

A typical Enterprise Architecture structure would include Application Architecture, Infrastructure Architecture, Data/Information Architecture and Business Architecture. Usually implemented in that order when originating from an IT perspective. In fact, I’ve often seen the sub-architecture of Process Architecture being implemented before Business Architecture.

EA implementation
EA implementation

This is opposite to what we would expect if we were able to plan it logically. In that case, we’d apply Business Architecture first in order to understand the aims and vision of the organisation, then organise everything around that vision. That’s where the other architecture domains come in. That’s the method as described (but often not followed) within TOGAF ADM. Start with the agreements, architectural principles, then business architecture to define the requirements for the other architecture domains.

2. Business Architecture as a profession is maturing

While we could say this of almost any profession, the rate of progress and thought-leadership in Business Architecture has progressed noticeably over the last few years. Prospects and clients are more aware of what it can do for them, internally within organisations there are more allies for the need for Business Architecture. It’s not all rosy, but it is improving.

Not only are the consultancies improving in their offer and the clients are improving in their knowledge and their requests, but short-term resource agencies are also improving in their placement of business architecture. More people involved in the wider enterprise are now talking about the value of business architecture. It’s still not prevalent and there’s often sales activity involved in influencing clients and prospects in the value, but it is increasing.

3. Organisations who are using Business Architects are using them differently.

Many of my requests for work come from portfolios or programmes rather than central, corporate enterprise functions. It is the change function of the business that is seeing a need to create order within the organisation and hence wanting the services of a Business Architect to assist with that. Typically, these assignments also stretch into guidance on business analysis although that can be considered separate. The indication though is that’s how the clients are seeing the tasks at hand. They see that the technology is taken care of through technical design authorities, etc and want a similar structure for business decisions.

This can be extended to a point where a change programme uses business architecture which then informs a corporate function. That corporate function realises the value and initiates their own business architecture initiative. When done well, these two different business architecture functions concentrate on their own objectives while ensuring alignment between corporate and change function. When done badly, they compete.

4. Business Architecture may be a peer capability to Enterprise Architecture

I find myself discussing future designs with Enterprise Architects, not because the designs have to go through them in terms of governance, but as a peer review. It does raise the question of whether they’re should be a consolidated governance route and review boards, not just technical design authorities. I have created design authorities that focus on business design (including the use of technology) rather than the technology solutions as would often appear before a technical design authority.

In addition, if we take the EA implementation diagram mentioned earlier, we can see that there are several transition states; one after each phase where only a subset of the Enterprise Architecture has been implemented. The typical transition state follows phase 2, where we see EA comprising Infrastructure and Application Architectures, all governed through an EA route. But with Business Architecture and Data/Information Architecture governed through other routes.

Enterprise Architecture and Business Architecture as Peers
Enterprise Architecture and Business Architecture as Peers

That combined, with the multiple design authorities, is indicative of an immature EA function, leaving us with two choices:

  1. Improve the maturity of the EA function and the role of Business Architecture within it.
  2. Engage Business Architects as peers to Enterprise Architecture

(1) only works if the initiatives are not IT focussed and that there’s more well-rounded support and engagement for that function.

(2) is what many clients are doing. They’re seeing EA as not performing what they require of the function, so they engage a Business Architect to provide and cover that gap.

Where to go from here?

That leads me to my premise. Even though EA is mature as a concept, it’s implementation is poor in a number of organisations, especially those that treat EA as a subset of IT.

Wherever EA is a subset of IT, then Business Architecture should short-term be driven by change portfolios. In parallel, the organisation should consider how to achieve wider adoption of the EA function within the organisation. Ironically, that task is most suited to Business Architects.

Whichever route, there has to be single point at which all designs come together for review. Not necessarily reviewing the designs themselves, but at least the design principles behind them. That review function is the start of a homogenous Enterprise Architecture function.

Moreover, we should concentrate on Business Architecture first where possible. Relying on existing architects is fraught with issues, most of all leading the organisation down a technology-driven path, rather than a business-vision/purpose path as would be more appropriate.

So consider a revised implementation timeline to reflect the earlier presence of Business Architecture, whether within or as a peer to EA.

EA implementation - revised
EA implementation – revised

 

Any comments? Get in touch @alanward

 

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

I spend a lot of time around programmes that are managed with Managing Successful Programmes. I’m either in a separate architecture function, advising on changes, or sometimes in the trenches of the programmes themselves.

system
integration

There’s often a disconnect between the tools and the techniques being used, especially when different team members are coming from different backgrounds with different experiences.

Business Motivation

I’m always concerned about the why. Why does a programme exist? Why is it doing what it’s doing in the way that it’s doing it? Often that boils down to asking what problems are we trying to solve, but sometimes it’s more complex than that.

I’ve been a fan of the Business Motivation Model (BMM) for a few years and have used it successfully with clients, especially to highlight the gaps between expected benefits and portfolio/programme activities.

So I’ve been looking at a more concrete intersection of MSP and BMM and I’ve chosen Archi (based on the Archimate language) to record and display that intersection.

The Business Motivation Model is managed by the Object Management Group (OMG). It’s designed to enable us to articulate the motivation behind business decisions and the impact that those motives have on the organisation.

In common with most of the standards managed by OMG, it’s evolving on a regular basis with the current version at 1.3.

Managing Successful Programmes (MSP)

MSP originated from UK central government under the OGC, the same group that brought you Prince2. It’s now managed by Axelos who also provide more management frameworks, such as MoV, MoP and MoR (Value, Portfolio and Risk respectively).

It’s a well-respected framework and well-adopted within many larger organisations in the UK. However, like a number of standards and frameworks, there can be some confusion as to what is required at each stage. For instance, try discussing with fellow programme managers the level of benefits definition required at the brief and vision stage, or whether the vision forms part of the brief, etc. I’m going to keep clear of those discussions as much as I can within this article, so that may mean that I simplify some of the cases.

MSP has a clear route of expected documents in the early stages of a programme:

  1. Programme Mandate
  2. Programme Brief
  3. Programme Vision
  4. Programme Blueprint

In parallel, I would expect to see benefits being managed accordingly. With those documents listed above, the task is about defining the benefits that are to be expected and a rough idea of how they will be achieved.

Archimate

Archimate is an open-source modelling standard with Archi being an open-source software for working with that standard. Archimate the standard is managed by the Open Group and is designed not to be a replacement but, instead to work with your existing standards.

The aim

treasure map
x marks the spot

I wanted to use Archi, Archimate, Business Motivation Model and MSP and see how they fitted together. I had a larger aim of wondering if a combined model would assist me in explaining to my clients why uncovering the business motivation matters and that it’s so easy to lose track when you’re in the midst of large organisation-wide programme changes.

Part 2 to follow soon