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

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

 

The Washroom Principle – The Easiest Way to Evaluate a Company

The Washroom Principle - Revised

There are plenty of methods for conducting due diligence, whether for partners, customers, suppliers or mergers. They’re lengthy and they’re expensive. There are times for adopting principles of formal Business Architecture, such as capability matching in M&A situations. But no matter what the deliverables indicate, there’s a useful and quick check to perform as a balance.

I’d like to introduce the quickest method for evaluating a company.

  1. Check the state of the washrooms nearest the directors
  2. Check the state of the washrooms in the middle of the office, e.g. where developers work, where finance work, etc
  3. Compare the two and evaluate according to the 4 box model below

The Simplified View

The Washroom Principle - Simple
The Washroom Principle – Simple

The simple view consists of a 4-box model with two axis; vertical for the quality of the director/board/exec washrooms and horizontal for the quality of the employee washrooms. That leaves us with 4 quadrants to review:

High quality for director washrooms, high quality for employee washrooms. This the ideal situation. Comfortable for all to work in, with employees respecting their organisation space.

High quality for director washrooms, low quality for employee washrooms. This is a poor situation. It implies one of a few cultural attributes. Either:

  • the directors think that they are worth more and merit more than the workforce,
  • the directors do not work closely enough with the workforce (and so do not see the disparity) and/or
  • the employees don’t care about the quality of the environment (probably resulting from not feeling respected)

Those fall into 2 different categories. The first two fall into whether there is a disparity in provision. The third falls into maintenance and behaviour in an environment.

Low quality for director washrooms, high quality for employee washrooms. I’ve never seen this exist. In all the organisations I’ve work for or consulted for, directors have washrooms of at least equal quality to that of the workforce.

Low quality for director washrooms, low quality for employee washrooms. At least their is parity in these organisations; everyone shares the same facilities. Typically I find these in public sector organisations where money is more importantly spent on providing the services to public rather than on office accommodation.

The More Complex View

The 4-box model gets us to the point of a very quick analysis. But thinking about it further, the relationships are slightly more complex. Hence the revised version:

The Washroom Principle - Revised
The Washroom Principle – Revised

The revision version uses the same axes as in the 4 box model, but hasn’t been restricted to just the 4 boxes. Instead we’ll take a closer look at the relationships between directors and employee washrooms.

Firstly, the box that related to low quality of director washrooms and high quality of employee washrooms has been extended to a triangle to cover half of the chart. This section, highlighted “Do not exist” relates to any point of the chart where directors have worse quality washrooms than employees.

On the left, we have a basic minimum standard. It’s not an absolute minimum, but one that covers a point at which employees are not being respected.

The top left is similar to that in the 4 box model, again highlighting where directors do not walk in the shoes of the employees.

That then leaves us with a blue area covering an acceptable region. This is the region in which behaviour of the directors matches that of the workforce, with no undue disparity and more a shared “we’re all in this together”. Even with the typical stretched finances of public sector organisations, we should be careful not to stray too far to the left that the lack of care in maintaining washrooms starts to be reflected in the quality of services provided by the workforce.

P.S.

Despite being British (or perhaps because of being British and very British problems), I couldn’t bring myself to call this the “toilet principle”. It was too disparaging and cast the wrong tone for what I intended. Similarly, the lavatory principle didn’t work. The Bathroom Principle sounded good apart from the ambiguity of bathroom=lavatory or bathroom=room with a bath in. I settled on the Washroom Principle as it should be obvious to all (even those in the United Kingdom) which room I mean.

Pardon, which sector? – Xtech and Why I’m Fed Up with Tech part 3

Capability Components

I’ve written previously about the issues with xtech that arise from applying -tech to the end of a sector such as healthtech, fintech, etc. And I introduced (and revoked) the idea of a -value suffix. Earlier this week, a conversation earlier made me think more about this and I want to explore the concepts of Business Capability and Capability Components further.

The entrepreneur mentioned that he was in the finance sector. On questioning further, the offer was a financial app for any sector. There’s a big difference and we can explore that difference in a matrix between capabilities and sectors.

Sector Capability Matrix
Figure 1: Sector Capability Matrix

At first glance, that looks like a contender for the world’s least useful matrix. On second glance, I’d also probably agree with my first impression. Not only does every cell in the matrix have a tick in it (so there’s no differentiation), it doesn’t include a full list of Business Capabilities. Instead, there’s sufficient to explore the concept for our purposes.

Let’s take it a bit further and use it to explore an issue I see with companies, mostly those in a supply position. If you’re selling software into healthcare, then are you a tech company or a healthcare company? It helps to phrase the position in terms of the capability you provide or improve in your target sector. So in that case, you’d be providing technology into healthcare. As we can see from the possibly-useless matrix above, we’d expect all sectors to require all business capabilities.

But I find more companies are confused if they’re providing software into finance. Suddenly they’re in the financial sector. True, the selling into the financial sector, by providing services into it, but they’re still a tech company.

This becomes more obvious when the software company that originally sold to Finance sector then also repackages the product to sell into Healthcare.

This is a simplistic view of the concepts of horizontal-integration or vertical-distribution; you can provide:

  • more services into your industry vertical, e.g. provide tech and financial management into healthcare or
  • the same capability into many sectors, e.g. provide financial management into healthcare and education or expand in both directions with
  • a mix of capabilities across sectors

Another Perspective

However, it’s more complicated than that. Each of the capabilities listed in the only-slightly-useful Sector Capability Matrix features at Level 1 or Level 2 (depending on where you start counting from the top). From a standard business architecture practice, each of the capabilities can be decomposed further, for instance, within sales management, we’d expect to see sales analytics, sales commissions, sales execution (the actual doing the selling), sales performance management, etc. Different organisations have a different angle on how they decompose the lower level capabilities. The main concept to take away is that we can take a conceptual capability and split it into more granular capabilities.

Instead, we are going to decompose them in a different manner. Most of the capabilities can be viewed as mini-businesses in their own right, so we’d expect to see a microcosm of capabilities within them.

Business Components
Figure 2: Business Components

Whereas the traditional business architecture view is based on functional decomposition (in that the capabilities are decomposing into more specialist capabilities), we’re going to decompose into enabling components.

For each of those capabilities that support an organisation, there are several components that are required to turn those capabilities into reality. In the same way that the organisation requires capabilities to function, the capabilities themselves require the components to be able to deliver. These components are capabilities at the next level down, to some extent mirroring the capabilities of the organisation as whole. For instance, most capabilities require people who can do the job, people who can manage, technology, etc. Hence the concept of capabilities as mini-businesses in their own right and that’s what we see in Figure 2 above. Each capability is supported by components. Note that Figure 2 does not include all capabilities or components, just enough to give an indication of what we’re discussing here.

Capability Components
Figure 3: Capability Components

This becomes significant when we consider the role of the components in a B2B context. This article started with a founder’s confusion over the sector, we then took a route through exploring capabilities. Now I want us to focus on the components.

It’s that middle column, with the red border, that we should consider when creating a new business. For B2B, we provide Capability Components to a client business.

If your client is a car dealership, they’re in the automotive sector.

The car dealership will have many Capabilities, e.g. Sales Management, HR Management, Organisational Development, etc.

If you are a company selling sales training, then your selling into two capabilities. You’re improving their Sales Management capability, but providing services into their Organisational Development capability. And that’s why it’s confusing. We have to remember, not only the sector that the client is in, but the interplay of the Capability Components we offer with the client’s Capabilities.

A further angle is that if you have sufficient capability components, you can provide the whole Capability to your client business, e.g. fully outsourced HR services.

Conclusion

We need to be careful about how we define our sector. Depending on the context, your audience will interpret the sector differently. A lot of that will also depend on what you meaning you intend to convey when you say your company is in a given sector.

The key item to remember is that the client operates in a Sector and that we offer Capability Components that interact (e.g. support, improve, provide) with the client’s Capabilities.

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

The Taco of Business Architecture – What’s the Purpose of Business Architecture?

taco

As a profession, Business Architects are in danger of becoming defined by just one of the products that they create. Unfortunately, it reduces the value that the profession can provide to organisations and limits expectations of prospects and clients.

What went wrong?

Imagine a fine-dining chef who makes tacos once at the request of a favourite customer. The chef knows tacos will do the job, she knows they’re sustenance, she knows that there are better products and even advises the customer of what she can do instead. But the customer wants tacos, so she delivers.

Other people like tacos as well. So she becomes known as a taco chef and the world is left short one fine-dining chef. Or rather, she’s no longer unavailable to provide the fine-dining experience since she’s now cooking tacos at the request of many customers. She knows she can do more and tries to prompt customers through educating them of other ideas and concepts. But the tacos are pleasing the short-termism of the current customers. It keeps them fed for an hour until they start to feel hungry again. She’s diligent and adds as much nutrition in them as she can. She listens to each customer, understands their needs and can plan a superb meal that will keep them well-nourished for hours. But the customers want tacos and end up hungry again in a hour or so.

The tacos could be cooked by someone on a lower salary. But they may not have her knowledge of nutrition and attention to detail. So yes, they’d still be tacos but not tacos of the quality that she’s been producing.

That’s our taco

And that taco situation is what I see with Business Architects. We’re commonly requested to perform a documentation task, e.g. “document the current business”. It’s usually followed by “so that we can …..”. Look on any job boards for contract Business Architects and you’ll see the activities we’re requested to perform. It’s usually the pattern described above of “document the current business”. Roles for permanent Business Architects are usually wider since clients don’t want professional expertise for just 6 months; they’re thinking longer-term.

The contract clients request knowledge or even certification of TOGAF or Zachman, but you don’t need knowledge of those to be able to document the business.

They may want specific knowledge of their industry sector (e.g. SOX and MiFID II for finance) and they may want experience with specific tools. But if the role requires a Business Architect, then documentation will be the activity.

They may even want knowledge about Business Architecture offerings specific to their industry sector (e.g. MODAF or ETOM). That last element can assist with documentation, especially if there are reusable models in the sector-specific offering.

But in the end, the client is asking for someone to document their current business. There’s often little thought for what to do with the documentation once it’s been produced. Some clients think ahead to wanting a future model, but don’t give much thought as to what to do with the gaps between current and future or how to evaluate benefits of different future models.

That’s our taco. Documenting the current business is the Taco of Business Architecture.

How did we get here?

Let’s take a look at some of the definitions for Business Architecture and then do the same for Enterprise Architecture. We would expect them to be similar, with Business Architecture being more focussed on the business domain.

Business Architecture Definitions

  • wikipedia: “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
  • OMG: “defines the structure of the enterprise in terms of its governance structure, business processes, and business information.”
  • The BA Institute – “defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation.”

The common theme in these is that Business Architecture is referred to by the deliverable or product that it creates. It’s output is the definition of the enterprise business.

Whereas I’d see Business Architecture as an activity. I’d expect to see more relating to its purpose, what it does and why it does it.

Interestingly, TOGAF (also by OMG) describes the context of the first few steps of the ADM with:

  • “a knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).”

TOGAF, in the paragraph above, implies Business Architecture as an activity.

Enterprise Architecture Definitions

Let’s look at definitions for Enterprise Architecture and see if they exhibit the same characteristics.

  • Wikipedia defines EA as “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy”
  • MIT CISR defines EA as “the organizing logic for business process and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.” Jeanne W. Ross, Peter Weill, David C. Robertson
  • Gartner defines EA”is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes”
  • Enterprise Architect Body of Knowledges defines EA as “analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology”

Here we see words such as discipline, practice, logic, guide. There’s a mix of nouns and verbs in that list, but they all indicate activity, for instance, you’d only have a discipline if you were to produce something.

We seem to have lost that concept with the Business Architecture definitions, although the TOGAF ADM excerpt does imply that Business Architect involves activity.

The Tao of Business Architecture

I’m going to approach this from a different direction and simplify the concept.

1. Business Architecture assists strategy

tic-tac-toe
Strategy from the heart

Business Architecture only exists because of strategy. Without strategy, Business Architecture has no purpose, no reason for being. We would just be producing documents for the sake of producing documents. Either those documents have to be useful or the process of creating the documents has to be useful, otherwise Business Architecture is a waste in any organisation.

Business Architecture relates to how that strategy is developed and maintained, how that strategy is implemented, how different strategies are evaluated and indeed, even the documentation of current strategy.

Business Architecture assists strategy, and paraphrasing from Rumelt (Good Strategy, Bad Strategy):

A good strategy includes 3 parts:

  1. A description of the current landscape and challenges
  2. A description of the future target that can respond to those challenges
  3. A plan to get you to that future

For Business Architecture (and also Enterprise Architecture), those concepts make a lot of sense and can be interpreted as:

  • A description of the current architecture. In this case business architecture, specifically the BMM, organisation units, influencers, partners, governance, etc
  • A description of the future target. In this case, the goals, outcomes, changes to capabilities, future organisation units
  • A plan to get you to that future. In this case, the change programme and work packages (most likely later supported by programme and project plans).

Here is the crux. Business Architecture is not only those documents, but it is the activity involved in producing those documents. There is more value in a Business Architect assisting an organisation in defining their strategy, challenging, providing other options, providing analyses, etc than there is in the delivered documents. It is the analysis and the progression of the conversation and the development of knowledge within the enterprise that is of most value. For some clients, the future state doesn’t need to be written down at the end of the assignment because the organisation has developed to the point that all know the common direction. The direction has become subsumed into organisational knowledge and culture. That’s not common, but the fact that it can happen, indicates that we’ve assigned value to the wrong part of the contract.

2. Business Architecture assists the enterprise

Enterprise
Enterprise

When I read the EA definition earlier from the Enterprise Architecture Body of Knowledge, I found that it described Business Architecture with one element missing:

“analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and the use of technology”

The simple addition of “the use of” alters the definition to be suitable for Business Architecture. I also like the focus on “future states” rather than current.

3. Business Architecture assists goals

Directions
Directions

This is fundamental for me. When I’m explaining to people what I do, I avoid phrases such as “I architect businesses” in the same way that a programme manager may say that “I manage programmes”. Instead I simplify for the layperson and say that:

“I help organisations do what they want to achieve”

and often the first step of that is

“assisting the organisation’s executive define what it wants to achieve.”

From my perspective, the majority of large issues within organisations stem from a lack of alignment. I find that larger organisations evolve to a state of disparate, loosely connected governance models that are not aligned with a central set of themes (or goals in this case). I work to align an enterprise so that it can focus resources on what it want to achieve, briefly (or as briefly as is reasonable) documenting where it is now, developing the future vision and then assisting the executive in steering the company towards that vision.

In short, it boils down to: “What direction do you want to go in? Then let’s define what we need to do to get you there.”

Summary

Business Architects need to retake the definition of the profession, in order to move clients and prospects from the Taco of Business Architecture to the Tao of Business Architecture.

This should be done with a focus on Strategy, Enterprise and Alignment and a lesser focus on documentation for the sake of documentation.

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