Upwards and sideways from business-model

Link: http://weblog.tomgraves.org/index.php/2011/07/29/upwards-sideways-from-bizmodel/

The past few posts in this series have focussed on moving ‘downward’ from the business-model, towards implementation, such as might be modelled in Archimate notation. That’s an aspect of the business-architecture / enterprise-architecture interface that makes immediate and practical sense to most people.

Yet to complete and verify the business-model and its proposed implementation, we also need to look upward into the extended-enterprise, and sideways into other aspects of the business-architecture space – otherwise the business-model could well fail in ‘unexpected’ ways. This post explores how to do that exploration, using the Enterprise Canvas frame as a checklist and guide.

(This is an adaptation of material that’s explained in more detail in my books The Service-Oriented Enterprise and Mapping the Enterprise, but there should be enough here to use straight away without needing to refer to either of those books.)

This’ll be another long one, so continue after the ‘Read more…’ break.

Let’s assume again that we’re starting from a business-model that’s been mapped out in Business Model Canvas. From there, we know how to cross-map the business-model into Enterprise Canvas, and adjust the model for the various asymmetries and incompletenesses in the original Business Model Canvas layout:

That core frame in Enterprise Canvas allows us to explore in more depth the various flows that take place (or need to take place) before, during and after the main transaction – sometimes with different people in different roles for different parts of the same nominal transaction and relationship:

Yet that central core of the Enterprise Canvas is only part of the frame and its implied checklist. There are also the service’s relationships, interactions and transactions with its various investors and beneficiaries:

And also its relationships and so on with other services that provide various forms of guidance – direction, coordination and validation:

Hence the total context that we need to address when assessing a business-model is not solely the central core that maps directly to Business Model Canvas, but a rather broader scope, as in this ‘kitchen sink’ summary:

To make sense of these additional relationships and support-services we need to look out into a broader space than that which we explore with the mainstream mapping into Archimate. In effect, we need not only to look ‘down’ into the Archimate space, but also look upward into the extended-enterprise, and sideways into how an enterprise is managed in real-world practice. In other words, a viable business-model, built on viable services.

Remember too that the Enterprise Canvas is recursive: everything is a service, and each of those services has the same structural interdependencies and flows. Hence what we’ll explore here applies not just to the overall business-model, but to every ‘child’-service and sub-service that we’ve previously identified and mapped in our Archimate models. This consistency in recursion is what will make the business-model efficient, effective, reliable and robust.

Investors and beneficiaries

An Investor is a party that puts various forms of value into the service – often as part of the ‘pump-priming’ to get the business-model started. It’s a similar role to that of a Supplier, except that the main flow goes the opposite direction, into the Value Outlay (‘Cost Structure’) cell, rather than removing value from that cell (such as payment for products provided or services rendered) via the back-channel.

A Beneficiary is a party that extracts various forms of value from the service, usually as the ‘excess value’ over and above that needed to operate the service (business-model) itself. It’s a similar role to that of a Customer, except that the main flow goes the opposite direction, from the Value Return (‘Revenue Stream’) cell, rather than providing value to that cell (such as payment for products provided or services rendered) via the back-channel.

Note that investors and beneficiaries are not necessarily the same people, and also that many different types of energy, resources and other forms of value may be invested and/or returned, again often in different forms.

For example, a bank-manager will not usually invest their own personal funds in a bank-loan – the money invested is that of the bank, and behind them the bank’s depositors and shareholders. But the bank-manager does place their own trust and reputation on the line in making that decision – and that trust is a form of investment that does need to be acknowledged as an investment. Note that repaying that investment in monetary form is usually called ‘bribery’, and is usually very illegal…

To give another example, a city-council may well invest actual funds, or proxies for funds such as a tax-rebate, to a company ’setting up shop’ in the district. The city-council itself does not get a direct monetary dividend, but receives the dividend in the form of local employment – hence reduced social stress etc – and also more money flowing around the community in general. The dividend can perhaps be sort-of translated into strict monetary terms, but often doing so leads to people kind of missing the point… the flows and transforms are usually more subtle and more complex than a simplistic ‘monetary account’.

It’s also essential that an appropriate balance is established between investors and beneficiaries, that is understood by all parties to be acceptably ‘fair’ – otherwise the entire business-model will be placed at risk, especially in the longer term. The common ’shareholder-only’ model, which ignores almost all non-monetary investment and assign absolute priority to the so-called ‘owners’, may all too often in practice turn out to be a parasitic structure that can quickly kill the host – the business and its business-model. In the process, it can also poison the ecosystem against itself, creating a type of ‘immune-reaction’ rejection of any equivalent-seeming business-model in the future, even if benign.

Note that these issues can only be identified by use of an enterprise-architecture that applies an ‘outside-in’ whole-enterprise view, rather than solely an ‘inside-out’ business-centric view.

Quick summary of suggested questions to use in this kind of assessment:

What energies, resources or other items are or need to be invested in this service (business-model)? From what or whom (the investors) will these be provided, or made available? Via what relationships and transactions? Using a VPEC-T assessment, what values, policies, events, content and trust would apply to each of those relationships and transactions?
What energies, resources or other items are or need to be returned or extracted from this service (business-model)? To what or whom (the beneficiaries) will these be provided, or made available? Via what relationships and transactions? Using a VPEC-T assessment, what values, policies, events, content and trust would apply to each of those relationships and transactions?
In what ways are the invested energies and resources used and/or transformed within the service? In what forms is ‘excess value’ extracted and returned from the service as dividends to its beneficiaries?
What forms of assessment and governance are used to ensure that the balance of investment and dividend is acceptably ‘fair’ to all parties?

It’s important to note that this is fully recursive: this type of analysis applies not only to the core service (the business-model) but to all of its ‘child’-services, facilities and resources used within its real-world implementation.

Guidance – an overview

All services that deliver anything to any other part of the overall shared-enterprise will rely on other services to keep them ‘on track’ in relation to the overall enterprise. These relationships and interdependencies need to be identified as part of the assessment for viability of the business-model.

Obviously, there are many different methods and techniques to do this. The framework I most prefer for this purpose is based on the long-proven Viable System Model [VSM], with specific adaptations and extensions to address certain change-management and quality-management themes that apply in the non-hierarchical value-systems in a whole-enterprise business context. (This extended model is described in more detail in my book The Service-Oriented Enterprise.)

The VSM describes these inter-service relationships as ’systems’, in a recursive or ‘fractal’ structure in which each service interacts with other ’systems’ yet also contains aspects of those ’systems’ within itself. All of the ’systems’ and inter-system relationships need to be in place and functioning well in order to ensure viability of the overall service – hence ‘viable system model’.

This may take some explaining… especially why it’s relevant and important to implementing a business-model…

Probably easiest to start from the old Taylorist model of work, as an explicit split between ‘brain’ and ‘brawn’. There’s a complete separation between the roles: brain thinks, and doesn’t do, whilst brawn does things, and doesn’t think. Or not allowed to think, anyway.

We can see this illustrated in a standard BPMN diagram. We start off only describing the work:

But we soon discover that we can’t make it work in practice unless we also think about how it’s managed:

In most real organisations, this is structured in a hierarchical fashion, with managers who manage collections of ‘reports’ – middle-managers or line-managers – who manage their own clusters of subsidiary functions and services:

So far, so Taylorist. Managers think, workers do, and there’s a complete separation between them – especially if the ‘workers’ are IT and the managers are real people, as so often will seem to occur in a typical BPM (Business Process Management) context.

Yet there’s another hidden layer in Taylorism: the basic model tells us the How and the With-What of an organisation, but never really the Why. This is because Taylorism is built on a ‘machine’-metaphor – ‘the organisation as machine’. And a machine doesn’t have a Why: it just is. Its purpose – if it has one – comes from outside of itself: and in the machine-metaphor for business, that purpose comes from the ‘owners’. Who, again, are deemed to be entirely separate. Owners own, managers think, workers do. The work is done by the workers on the orders of the managers for the profit of the owners. Simple, really.

Too simple, because in reality it doesn’t work very well. Sure, at first glance it seems it’d be very efficient as ‘a machine for making money’, but in practice the rigid hierarchy and active prevention of feedback from the real-world means that it’s very slow and cumbersome as a decision-making model – and unreliable, too. We can sort-of get away with this when the business-context is static, or close to static; but as soon as the market or context requires any kind of agility or responsiveness, it will almost immediately grind to a halt in ‘analysis-paralysis’. Instead, as Deming and others demonstrated so well, almost all aspects of inquiry and decision-making need to be distributed throughout the structure. And connection to purpose likewise needs to pervade every part of the structure, so as to enable principle-based decision-making in real-time response to the real-world chaos on the shop floor.

To make it work, we need to shift metaphors, from ‘organisation-as-machine’ to ‘organisation-as-organism’. Hence viable systems, viable services, viable business-models: in a quite literal sense, we need to ensure that they can come alive, support themselves, adapt themselves, because ‘classic’ Taylorism is simply too slow to survive in a fast-changing world. Given this, we can see that every aspect of our business-model – every sub-unit in the enterprise – would need to do, or have access to some means to do, all of the following:

to do its task – in other words, deliver its services
to sense and report on its perception of its internal and external environment
to remember, using some kind of repository of knowledge about its past
to coordinate its activities with other systems and services
to plan its activities in some way, coordinating strategies and tactics with others
to adapt to and, where possible, improve its own environment and operation
to maintain a sense of purpose, to contrast its present condition with a desired future condition or direction

If we want to build an architecture that will truly support our business-model, this is the true scope of what we have to be able to describe. The basic business-model on the Business Model Canvas will describe the ‘do’ part: that’s straightforward enough. It’s linking it with everything else that gets tricky…

Stafford Beer’s Viable System Model provides us with a framework that can help us do this. The ‘official’ version is probably too ‘theoretical’ for most people’s taste:

Yet the ideas behind it are simple enough. Every service, or the business-model as a whole, contains or links to a set of functions or ’systems’, as follows:

system-5: maintain policy, purpose and identity
system-4: research and report on the external environment, and develop strategy
system-3: plan and manage the operations activities
system-3*: monitor and verify by sporadic audit of activities
system-2: regulate and coordinate activities with other systems and services at a tactical level
system-1: do the allotted task of the overall service, and sense and report on the internal environment

A glance back at that earlier list would show that the VSM ’systems’ explicitly cover most of those requirements: as we’ll see later, the items about knowledge and memory, and adaptation and improvement, are handled by an expansion of the roles of the VSM’s ’system-2′ and ’system-3*’.

This is recursive, or fractal: every ’system’ incorporates or encapsulates all of the other ’systems’ in some way, everything contains or links to everything else, to support everything else as an interdependent whole.

Admittedly, it’s a lot to try to grasp all in one go, in order to model how to ensure that a business-model would be viable. But we can in fact simplify it right down to something that does make immediate sense in practice:

In this variant of VSM, each service has its set of subsidiary services or ‘child-services’ with four possible categories of functions:

delivery-services: task-delivery or delivery-support
management-services: service-management and direction
coordination-services: ‘horizontal coordination with other services
validation-services: functions to keep the overall service on track and aligned with enterprise purpose

Delivery-services are the VSM’s ’system-1′. They’re what we’ve modelled already in the business-model, and downward into Archimate. In reality, everything is a ‘delivery-service’, of course; but what we need to explore here are the interdependencies and roles that services need in relationship to each other, which in effect is everything other than the ‘delivery services’.

Management-services (better described as direction-services, because it encapsulates more than just management alone) are what we would expect from Taylorism, plus quite a bit more. The VSM splits these into three distinct parts (’system-3′, ’system-4′ and ’system-5′), as we’ll see in a moment.

Coordination-services manage the choreography between services, and also the choreography of change. Classic Taylorism tries to merge all of these services under the ‘management’ umbrella, but it doesn’t work, because the whole point is that they’re needed to bridge between the silos, and hence cannot actually exist solely within them. In real-world practice, this often surfaces as a combination of a shadow-network of ‘fixers’ who manage somehow bridge the silos, and IT-systems and the like that provide automated means to do the same. The VSM’s ’system-2′ addresses only one aspect of run-time coordination, whereas we will need to cover a broader scope.

Validation-services (sometimes called ‘pervasive services’, because they need to pervade through everything) are about quality – about ensuring that the business-model and each service within the business-model aligns with what is actually meant by ‘value’ in the Value Proposition. Classic Taylorism again bundles all of these under the ‘management’ umbrella, but they need to be at least partially outside, if only because many of them are subject to legal or regulatory mandates which must be beyond management ‘control’. The VSM’s ’system-3*’ addresses only one small aspect of this, to do with random-audit, whereas again we’ll need to cover a much broader scope.

Although the VSM itself focuses on management and the information-flows needed for management, the real tension of importance in the enterprise is between purpose of the overall shared-enterprise (the single top-level ’system-5′) and the expression of that purpose in real-world practice (the multitude of ’system-1′ entities at the outermost edges of the VSM hierarchy-tree). Everything else – including management, and including the business-model itself – is just a support-service towards that end.

Given all of that background, let’s look at what’s needed to ensure that the business-model will be viable in practice – and continue to be viable over the longer term.

Guidance – direction-services

The VSM splits the overall direction tasks into three distinct components, which we might summarise as ‘Run the Business’ (’system-3′, or ‘Inside/Now’), ‘Change the Business’ (’system-4′, or ‘Outside/Future’) and ‘Develop the Business’ (’system-5′). We need to ensure that our business-model either includes or has access to services that can support all of these needs.

Who or what will provide run-time management for the business-model – such as to plan and manage the operations, allocate resources, and collate and interpret performance-reports, and make run-time tactical decisions?
Who or what will guide changes to the business-model – such as to research and report on the external environment, and develop strategy?
Who or what will keep the business-model on track to the vision and values of the organisation and of the overall shared-enterprise – such as to maintain policy, purpose and identity?
Via what means – the ‘How’ and ‘With-What’ of business-services and business-processes – will all of these requirements be enacted in practice?
Who or what will provide coordination and choreography for all of this?
Who or what will provide governance for all of this?

Use these questions iteratively across all aspects of the business-model and its implementation, as previously modelled in Archimate or the like. Create any models as required: the Business Motivation Model (or Nick Malik’s Enterprise Business Motivation Model) may provide useful advice here. The present version of Archimate provides only rudimentary support for this – such as attaching Meaning or Value entities to a Business Service or Business Role via an is-associated link – but the upcoming Archimate v2 is expected to better support via a new Motivation extension.

Guidance – coordination-services

As standard, the VSM (via its ’system-2′) addresses only one aspect of inter-service coordination, namely run-time trade-offs between services at the same level within the same silo-hierarchy. To get a business-model to work well, especially over the longer term, we need much more coordination that that. We could summarise the overall requirements here under the same three headings as for the Direction-services: ‘Run the Business’, ‘Change the Business’ and ‘Develop the Business’. In effect:

‘Run the Business’ coordination connects run-time management (’system-3′), the balance between its delivery-services (’system-1′), and the ‘process-choreography’ with other delivery-services under the direction of other silos both within and beyond the organisation
‘Change the Business’ coordination connects external-oriented strategy (’system-4′) and internal-oriented tactics (’system-3′) to address the needs for and execution of change, both within this silo-tree and across the direction-services of other relevant silos both within and beyond the organisation
‘Develop the Business’ coordination links policy and purpose (’system-5′) with strategy (’system-4′) to address alignment of strategy, policy and standards across the broader scope, and to adapt to and, if possible, guide changes within the broader business-ecosystem

We again need to ensure that our business-model either includes or has access to services that can support all of these needs:

Who or what will provide run-time coordination for this business-model, within the various components and processes of itself, with its customers, and with its suppliers and other partners?
Who or what will guide the execution of change to the business-model – such as via project-management?
Who or what will define, guide and coordinate longer-term change, to develop and adapt to changes in the broader context for the business-model – such as via portfolio- or programme-management?
Via what means – the ‘How’ and ‘With-What’ of business-services and business-processes – will all of these requirements be enacted in practice?
Who or what will define or provide the standards, protocols and policies to guide all of this?
Who or what will provide governance for all of this?

Use these questions iteratively across all aspects of the business-model and its implementation, as previously modelled in Archimate or the like. Create any models as required: the present version of Archimate provides only rudimentary support for this, but the upcoming Archimate v2 is expected to better support via a new Projects extension.

Guidance – validation-services

As standard, the VSM (via its ’system-3*’) addresses only one very small part of keeping the organisation and organisation on-track to its values, namely random-audit to verify performance-reports and the like. To get the business model to work well, and to align and remain aligned to the desires and needs and expectations of its broader business-context, we will need a much broader value-management structure, with strong consistency across its management of all forms of value relevant to and within the enterprise. Some common business-examples of value-themes include:

quality – including exception-handling, issue-tracking, corrective-action and process-improvement
privacy, security and trust
health, safety and environment
ethics, social-responsibility and legal compliance
cost-effectiveness and waste minimisation
knowledge-sharing and innovation
whole-of-enterprise efficiency and effectiveness

We can summarise these requirements under four headings:

Create awareness – identify and describe each value-theme, why it’s important that that value-theme should be managed within the business-model, and how it could and should be done in practice
Develop capability – implement training and education around the value-theme, and also embed support for the value-theme within automated processes, with emphasis on what to do in real-world practice at run-time
Apply skills – execute at run-time the required actions to support the expression and protection of the value-theme, and record the results of each action (or inaction)
Monitor and verify – ensure that the value-theme has been supported in practice, and review to identify what needs to be further improved

Support for values always needs to be managed as a continuous-improvement cycle, as in the classic Deming/Shewhart PDCA (Plan / Do / Check/ Act), where the ‘Check’ phase emphasises both inspection (external) and introspection (individual/internal). Value-management is different from conventional Taylorist ‘control’ in that there is no single ‘right answer’, yet an almost infinite number of ways to ‘get it wrong’ or ‘get it not-quite-right’, and also an infinity of different ways to ‘do it better’. Since almost all of these themes revolve around personal responsibility and personal commitment, the focus here is not so much on ‘best practice’, but on individual capability and improvement as well as systemic change: Deming’s ‘14 Principles‘ and the related ‘Toyota Way‘ provide important guidance for design and review here.

Who or what will identify the full set of value-themes that would apply to this business-model?
For each value-theme in scope, who or what will assist in creating awareness of this value-theme throughout the design, implementation and execution of this business-model, both within the organisation and with its customers, suppliers and other partners?
Who or what will assist in developing and/or embedding the skills and capability to execute run-time support for each value-theme in scope?
Who or what is responsible for executing the required support for each value-theme at run-time? Are they fully aware of and capable of enacting those responsibilities at run-time to the standards required? Via what means – the ‘How’ and ‘With-What’ of business-services and business-processes – will all of these requirements be enacted in practice?
Who or what will monitor and verify compliance (and more) to the required standards of support for each value-theme in scope?
Who or what is responsible for ‘closing the loop’ to support continuous improvement on each value-theme in scope?
Who or what will define or provide the standards, protocols and policies to guide all of this?
Who or what will provide governance for all of this?

Use these questions iteratively across all aspects of the business-model and its implementation, as previously modelled in Archimate or the like, and create any additional models as required. The Business Motivation Model and Enterprise Business Motivation Model can provide some support in this: note, though, that both are structured on an ‘inside-out’ (organisation-centric) view, whereas many of the most important aspects of value-themes are only visible from an ‘outside-in’ (extended-enterprise) view. Again, the present version of Archimate provides only rudimentary support for this, but the upcoming Archimate v2 is expected to better support via a new Motivation extension.

—

That’s it for now. Comments/suggestions/improvements, if you would?