By ‘completeness’ I mean that we check that the service has all the connections and support and flows that it needs to play its full part in the respective layer of the enterprise value-network.

And ‘viability’ here is in the sense described in the Viable System Model, that the interdependencies that the service needs both to operate in the ‘now’ and to change appropriately over time are all in place and in action.

In a service-oriented architecture and and a service-oriented view of enterprise, everything is or delivers or represents a service. Which means that everything in the enterprise will rely on those interlinks and interdependencies. Which is why a model-type such as Enterprise Canvas, which explicitly sets out to model those interdependencies, could be very useful indeed.

So here’s an as-brief-as-I-can-make-it how-to introduction on using Enterprise Canvas for this purpose, creating models with the simplified version of the Enterprise Canvas notation.

For this we’ll need the (rather large) overview-model of service-relationships, in the simplified notation:

We’ll also need the extended-Zachman map of layers of abstraction:

And the ‘single-row extended-Zachman’ checklist for service-content – the ‘service-content map’:

And to model the flows (Exchange-entities) between services, we’ll also need to check against the market-cycle model, with an emphasis on completions for the different parts of the exchange:

If we want to start from a business-model developed on Business Model Canvas, we’ll need the cross-map from Business Model Canvas to Enterprise:

It’d probably be useful to print out those diagrams – or at least keep them close to hand – for reference as we work our way through this how-to.

So, to get started, pick a service – any service, anywhere in the overall enterprise – that happens to be of interest at present. (If none comes immediately to mind, start with the organisation as a whole, as a ‘service’ in context of its market and the broader shared-enterprise.)

Ideally, this should be modelled using a proper EA toolset. But if a metamodel for the simplified Enterprise Canvas isn’t yet available in the toolset, use an office-diagramming tool such as Visio or Dia – or perhaps just draw the model by hand, on paper or on a whiteboard.

Place a Service-entity in the middle of the model, to represent the chosen ‘service of interest’ – and then see what insights arise as the modelling proceeds…

As-is, to-be and gap-analysis

We can do the modelling in any way we need, for any practical purpose. However, there should always be an explicit business-need or business-question behind every modelling-effort.

We might model the service in an as-is context, describing its current configuration and interdependencies. There often isn’t much point in doing an as-is assessment on its own, though: we’d usually do it to establish a baseline for a roadmap towards some intended future, as the base for a gap-analysis, or perhaps to support a training-programme.

We’ll often do a to-be assessment to support scenarios for change, including business-model innovation via Business Model Canvas and the like. This type of assessment also provides an important endpoint-baseline for gap-analysis.

Often the greatest value of this type of modelling is in gap-analysis: either identifying interdependencies that are misaligned or missing, or – via mismatches between Service-entities and Exchange-entities – identifying misaligned supplier or customer-relationships, opportunities for new supplier- or customer-groups, or risks or opportunities all the way out through the market to the broader shared-enterprise.

The how-to descriptions that follow can be applied to any of these needs.

A note on layers

If you’ve used other IT-oriented architecture-frameworks such as TOGAF or Archimate, you’ll be used to splitting a model into layers in terms of technology versus applications versus business and suchlike. In reality those ‘layers’ are entirely arbitrary, but it’s a practice that can work quite well for domain-specific architectures.

At a true enterprise scope, however, that type of pseudo-layering can be misleading and even dangerous. Hence a reminder here that the only layers explicitly acknowledged in Enterprise Canvas are layers of abstraction, as in the extended-Zachman layering – from most-abstract to most-concrete, from infinite-future to immediate-past. Unlike in IT-architectures, no explicit distinction is drawn between modes of implementation – such as IT versus machine or manual process – because in principle they are all interchangeable. Likewise there’s no mandatory distinction between layers of granularity: the granularity can be shown via composition-relations between Services, but the respective flow-relations and Exchange-entities could legitimately connect to a Service-entity at either level, because it’s literally a matter of detail. The only explicit distinction here is between layers of abstraction.

You can use pseudo-layering if you must, but you’ll have to do so manually, via colour-coding or groups or whatever. Just note that there are very good reasons why it’s not built into the notation.

That point is particularly important here because our aim is to explore direct interdependencies between services. Every relation implies an exchange of some kind, even if the exchange consists only of an acknowledgement that the relationship exists (which we could document in the model as a ‘relational-asset’ within an Exchange-entity). The nature and implied content of the exchange may vary between levels of abstraction, but the exchanges themselves only take place between services at the same level of abstraction. And to understand interdependence, we need to identify the content of those exchanges.

Hence this type of modelling demands a discipline about layering that may take some getting used to, but is extremely valuable in practice:

• in general, flow-relations and Exchange-entities should only connect between Service-entities at the same layer
• changes in layer should be indicated by realisation-relations between Service-entities, which cannot incorporate any Exchange
• where a flow-relation must connect between Service-entities at different layers – such as where the actual service at that layer is unknown – the ‘different-layer’ Service must be indicated explicitly by a dotted-line border

Most modelling for this ‘viability-checklist’ purpose would or should be at a single layer of abstraction. For the supply-chain part of the model, this should be straightforward: any changes in layering should usually be self-evident there. Yet it’s all too easy to scramble the layering when exploring links with guidance-services or with investors and beneficiaries.

For example, if we’re using this checklist to focus on a detail-layer web-service, there’ll be a strong temptation to tick off the Direct::Change guidance-service as ‘IT Strategy’ or the like, and leave it at that. But if we do so, that’d be a real missed-opportunity. ‘IT Strategy’ is abstract, yet there’s real work there that’s done by real people, every bit as real as the web-service that’s our current focus of attention: hence what exactly is the chain of responsibilities and connections – and hence flow-relations and Exchanges between real-world Services – that links between that work and this web-service? There are some valuable insights to be gained there about how the enterprise actually works, and how it maintains its viability: it’s well worth the little bit of extra effort around layer-discipline in order to obtain them.

In short, the discipline that Enterprise Canvas demands around layers of abstraction, can perhaps seem tedious at times: yet in architecture-practice it can be one of the most valuable allies that we have. Don’t skip it!

The service itself

Back to modelling, and to the service in focus.

What is this service? Start by assigning it a name. (If you’re doing this within an EA toolset, provide a brief description as well.)

What layer of abstraction will we use as the base for modelling this service? (Usually this will be either row-2 ‘Business-model’, to describe the overall context, without much if any description of actual content; row-3 ‘System-model’, the implementation-independent ‘logical’ layer, where we start to fill in the details of the content of services and the inter-service exchanges; or row-4 ‘Design-model’, the implementation-specific ‘physical’ layer. Remember that if any specific technology or implementation is mentioned, by definition it’s at row-4 or below.)

Apply a RACI assessment to the service:

• Who is ultimately responsible or accountable for this service?
• Who assists in delivering or running or supporting this service?
• Who needs to be consulted about this service, or any changes to this service?
• Who needs to be informed about the performance of or changes to this service?

What other responsibilities and accountabilities apply in this context?

Nature of service

As a first step in the functional decomposition of the service – what it does, and how, and why – focus attention on the three innermost ‘cells’ of the Enterprise Canvas view of the service.

What value does this service provide – its Value-Proposition, in terms of the aims and needs and values of the broader extended-enterprise? (If cross-mapping from Business Model Canvas, this is a more enterprise-oriented version of that model’s Value-Proposition.) If appropriate, build a trail of linkage up through the layers of abstraction, to connect with the vision and values of the shared-enterprise. To model this, link this service to at at least one other Service-entity in each layer upward to row-1; then link to one or more Value-entities in row-0, and ultimately to the Vision-entity at that top of the abstraction-’tree’. (We’ll come back to some of this later when we explore this service’s links to other Validate services.)

What does this service do to create and deliver that value – its Value-Creation in terms of that Value-Proposition? (If cross-mapping from Business Model Canvas, this merges the latter’s Key Resources and Key Activities cells.) Use the service-content map (single-row extended-Zachman) to explore and identify the various assets, functions, locations, capabilities, events and decisions that apply within that value-creation. (We’ll come back to some of this later when we explore this service’s links to other Coordinate services.)

What does this service need to govern its service-delivery – its Value-Governance to keep the Value-Creation on-track to the Value-Proposition? (This isn’t really described at all in Business Model Canvas.) How does it do this? Under what business-rules? (We’ll come back to some of this later when we explore this service’s links to other Direct and Validate services.)

Apply a RACI assessment to each of these subsidiary ‘cells’ within the service: who is responsible or accountable, for what, and why?

Service-provision

For the next step we explore what this service provides to others – and who those ‘others’ might be.

We have several different ways to do this. One would be to focus mainly on the service itself, and infer the resultant exchanges with others; another would be to focus on the exchanges; and yet another would be to identify the ‘others’ (often described as ‘clients’ or ‘customers’ or ‘service-consumers’). For this how-to, we’ll start with the exchanges – but note that the other options are just as valid.

In a conventional transaction-oriented supply-chain model, this would explore only the goods or services delivered to others – and those ‘customer-side’ others are always considered to be distinct from anyone on ‘supplier-side’. We can model this in Enterprise Canvas, of course. Here, though, it’s usually wiser to use a more-complete value-network approach, in which the mapping of what happens before and after the main-transactions is every bit as important as the transactions themselves – and in which the supposed distinctions between ‘supplier’ and ‘customer’ will often tend to blur. For our purposes here, we’ll describe ‘customer’ and ‘supplier’ as if separate: but note that in many contexts in the real world, ‘supplier’ and ‘customer’ may well be the same.

What does this service provide to others – the services (or products, as proto-services or proxy for services) consumed by others? Using the ‘Assets’-column of the service-content map as a guide, what forms does this service-provision take? Using a VPEC-T assessment, what values, policies, events, content and trust apply in each service-provision by this service? Model the results of this assessment as one or more Exchange entities, linked via flow-relations to the right-hand (‘outgoing’) side of the Service-entity.

Who or what are the ‘customers’ or ‘consumers’ of these services? (If cross-mapping from Business Model Canvas, these are the various customer-groups in the Customer Segments cell.) For each distinct customer-group, there should usually be a distinct Exchange; if necessary, split the overall exchange-content into further Exchange-entities, each linked to a Service-entity for each respective customer-group.

Review each Exchange in terms of what aspects of the overall exchange and its content take place before, during and after each main-transaction. Use the market-cycle model to map these as follows:

• What reputation, trust, relations and attention need to be in place before each main-transaction? What Customer-Relations subsidiary-services exist within the service to support the interactions that would enable these to be created and maintained? (In Business Model Canvas, this is the content in the ‘Customer Relations’ cell.) In market-cycle terms, what completions are needed to ensure that these are maintained as required, especially over the longer-term?
• What are the core transactions in the service-delivery, and what happens during those transactions? Via what Customer-Channels or other means are the services delivered? (In Business Model Canvas, this is the content in the ‘Channels’ cell.) What protocols are needed to set up each transaction itself? In market-cycle terms, what completions are needed to mark the end of the transaction, and ensure that the transaction itself is closed-off and complete?
• What follow-up interactions need to occur after the main-transaction – such as payment and the like? What Value-Return subsidiary-services exist within the service to support these interactions? (Some parts of this are implied by the content of the ‘Revenue Streams’ cell in Business Model Canvas.) In market-cycle terms, what completions are needed to ensure that everything is complete and all parties are satisfied?

Define subsidiary Exchange-entities for each of these before, during and after flows, and link these via flow-relations to the respective subsidiary-cells of the service.

Optionally, use the service-content map to summarise the assets, activities and other content for each of the subsidiary-services.

Apply a RACI-assessment to each of these ‘customer-side’ subsidiary-services within the service, to identify responsibilities and accountabilities for each aspect of the Exchange-transactions and relations with the respective ‘customer’-service.

Given that the before, during and after interactions may all occur at different times, through different channels and on different time-scales, what mechanisms exist within the service to keep them all in balance, and appropriately linked to the core Value-Proposition, Value-Creation and Value-Governance of the service? Who or what is responsible for enacting and governing each of these internal activities and interactions?

Consuming other services

Next, we explore the ‘incoming’ side of the service – the services provided by and ‘consumed’ from others – and identify who those ‘others’ might be.

This is the symmetric-opposite of service-provision, and hence we should assess and model it in exactly the same way. The ‘others’ in this case are usually described as ‘suppliers’ or ‘partners’.

What does this service consume from others – the services or products provided by others? What forms does this service-provision take? What values, policies, events, content and trust apply in each service-provision to this service? Model the results of this assessment as one or more Exchange entities, linked to the left-hand (‘incoming’) side of the Service-entity.

Who or what are the ‘suppliers’ or ‘partners’ for each of these services? (If cross-mapping from Business Model Canvas, these are the content of the Key Partners cell.) For each distinct supplier-group, there should usually be a distinct Exchange; if necessary, split the overall exchange-content into further Exchange-entities, each linked to a Service-entity for each respective supplier-group.

Review each Exchange in terms of what aspects of the overall exchange and its content take place before, during and after each main-transaction. Use the market-cycle model to map these as follows:

• What reputation, trust, relations and attention need to be in place before each main-transaction? What Supplier-Relations subsidiary-services exist within the service to support these? (This is implied in part in Business Model Canvas by the Key Partners cell cell.) What completions are needed to ensure that these are maintained as required?
• What are the core transactions in the service-delivery, and what happens during those transactions? Via what Supplier-Channels or other means are the services delivered? (Again, this is implied in the Key Partners cell in Business Model Canvas) What protocols are needed to set up each transaction itself? What completions are needed to mark the end of the transaction, and ensure that the transaction itself is closed-off and complete?
• What follow-up interactions need to occur after the main-transaction – such as payment and the like? What Value-Outlay subsidiary-services exist within the service to support these interactions? (Some parts of this are implied by the content of the ‘Cost Structure’ cell in Business Model Canvas.) What completions are needed to ensure that everything is complete and all parties are satisfied?

Define subsidiary Exchange-entities for each of these before, during and after flows, and link these to the respective subsidiary-cells of the service.

Optionally, use the service-content map to summarise the assets, activities and other content for each of the subsidiary-services.

Apply a RACI-assessment to each of these ‘customer-side’ subsidiary-services within the service, to identify responsibilities and accountabilities for each aspect of the Exchange-transactions and relations with the respective ‘customer’-service.

What mechanisms exist within the service to keep all of the before, during and after interactions in balance, and appropriately linked to the core Value-Proposition, Value-Creation and Value-Governance of the service? Who or what is responsible for enacting and governing each of these internal activities and interactions?

Who or what is responsible for the overall balance across the whole of the service? (In principle this is a key part of the role of the Value-Governance subsidiary-services, but may in part be enacted by others: if so, who or what are they, and what mechanisms exist to ensure balance?)

Guidance service-relationships

The concept of ‘guidance-services’ is adapted from Viable System Model. (More accurately, a somewhat-extended version of Viable System Model – see my book The Service-Oriented Enterprise.) These represent the web of service-interdependencies that would ensure the viability of the service – the effectiveness of its operations at run-time, and its adaptability and resilience to change, especially over the longer-term. In line with Viable System Model, they’re described in Enterprise Canvas under three categories:

• direction – services that assist in planning and day-to-day management of this service and its clusters of related services
• coordination – services that assist in run-time coordination with other services, and with planning and coordination of change
• validation – services that help to keep the service on-track with and aligned to the vision and values of the shared-enterprise

These services or functions may be embedded somewhere within the service itself, though more usually enacted by separate business-functions. In a few cases – especially some aspects of validation-services – they may be required by law to be enacted by a completely separate organisation. Yet in whatever form they may be implemented in real-world practice, the point is that they must all exist somewhere, in some form, in an engaged relationship to this specific service. That’s the real concern here.

Note that these most of these guidance-services are implied or described only peripherally – if at all –  in conventional transaction-oriented architectures and business-models. Classic Taylorist ‘scientific management’ describes some aspects of the direction-services, but nothing else; Business Model Canvas and classic IT-centric ‘enterprise’-architectures do not describe any of them at all. There is a very significant architectural gap here that is rarely addressed – and needs to be.

For many enterprise-architects, much of this part of modelling with Enterprise Canvas may seem at first to be somewhat alien territory. The reason that it’s important is that unless these interdependencies are properly in place and in action, the service cannot be considered viable. Every ‘missing’, incomplete or inappropriately-supported interrelationship in this part of the Enterprise Canvas checklist represents a real and significant risk to the entire enterprise – risks that must be acknowledged and addressed so as to ensure the viability of the whole.

In short, don’t skip over this – there are very good reasons why these service-interrelationships are included in the Enterprise Canvas checklist!

Guidance – direction

The direction-services represent the usual ‘management’-type functions of the enterprise, seen here in relation to the service that is our current focus of attention.

Note that these ‘management-functions’ are viewed here solely as services in relation to other services, just like everything else. In many organisations, front-line services often seem to be regarded as ‘inferiors’, as ‘servants to the whims of management’, whereas from an architectural perspective it usually needs to be seen as more the other way round, that the real role of management is as a support-service to front-line service-delivery. In Enterprise Canvas, no special priority or importance is accorded to ‘the management’, for the simple reason that doing so doesn’t work: in a true enterprise-scope architecture, everywhere and nowhere is ‘the centre’, always, all at the same time. If you must treat management as ‘special and different’, do so outside of the architecture itself!

These services can be split into three distinct groups, often referred to as ‘Develop the Business’, ‘Change the Business’ and ‘Run the Business’. (In Viable System Model, these are referred to as system-5, system-4 and system-3 respectively.)

In a classic Taylorist view, ‘Develop’ and ‘Change’ are primarily staff-functions, whereas ‘Run’ is primarily a line-management function. There’s also a timescale-element here: ‘Develop’ tends to have a long time-view, ranging from years or decades, potentially all the way to infinity; ‘Change’ has a medium-term view, from the current quarter out to a few years ahead at most; whilst ‘Run’ is mostly focussed on the day-to-day. Strategy develops out of the intersection between ‘Develop’ and ‘Change’; tactics from the intersection of ‘Change’ and ‘Run’; and operations from the intersection between ‘Run’ and this service.

Most of these services must not and cannot be outsourced to another organisation.

Questions to ask here include:

• Direction::Develop – What support for long-term direction does this service need? What services would ensure that this service is aligned to the overall Vision for the enterprise? By what means are these ‘Develop’ direction-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Direction::Change – What support for medium-term strategic direction does this service need? What services would ensure that this service is aligned to the changing context of its market and business-ecosystem? By what means are these ‘Change’ direction-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Direction::Run – What support for day-to-day management does this service need? What services would ensure that this service has the resources that it needs to do its work in creating value? What performance-metrics does this service need to provide to those ‘Run’ direction-functions? How are those performance-metrics used in providing management-services to this service? By what means are these ‘Run’ direction-services delivered to this service? Who or what is responsible for these services, and how they apply to this service?

Identify the services and exchanges in each case, typically using the service-content map to assess the content of activities of each service, and VPEC-T analysis or the like to identify the values, policies, events, content and trust-concerns implied in each exchange. Add the results of this assessment to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. Use either containment (as in the diagram above) or composition-relations to link each of these Service-entities to the overall Direction Service. Annotate each flow-relation here with a ‘direct’ label, to indicate that the flow delivers direction-services to the service-in-focus.

A reminder here to be careful about layering: see ‘A note on layers’ above.

In essence, ‘Develop the Business’ is an architectural function for the organisation in relation to its shared-enterprise: in a very literal sense, the CEO is the organisation’s ‘Chief Enterprise Architect’. (Enterprise-architects provide decision-support for that role, but not the decision-making: that distinction is extremely important in practice!) The catch is that the CEO needs to do that work – but often doesn’t, and instead hides out in a comfort-zone of ‘Change’ or even ‘Run’, subsuming all the other management-functions into that role. This is a common cause of dysfunctional management and architecturally-inadequate support to the organisation’s overall services: classic examples include contexts where purported ‘shareholder-value’ is assigned absolute priority over everything else,or where “last year plus 10%” is considered to be a real strategy. This type of problem will almost invariably lead to organisational failure over the medium- to longer-term: it is an extremely important architectural risk to the organisation, and to the enterprise as a whole.

In short, if adequate and appropriate direction-support is not available, the service will not be viable.

Guidance – coordination

The coordination-services represent the business-functions that coordinate this service with other services.

These services can be split into three distinct groups, often referred to as ‘Develop the Business’, ‘Change the Business’ and ‘Run the Business’, in parallel with the matching functions in the Direction-services. (In Viable System Model, some aspects of ‘Coordinate::Run‘ are referred to as system-2. That model does not deal with coordination of change as such, hence has no explicit component for Coordinate::Develop or Coordinate::Change.)

In Taylorism these services are usually regarded as part of the ‘management’-functions, but in practice they often need to separate and distinct, not least because in many cases they must somehow bridge between management-hierarchy silos. Significant organisational problems can arise from that one fact…

In practice, Coordinate::Develop relates to coordination of strategy and strategic change, and hence links to both Direct::Develop and Direct::Change; it’s also often associated with portfolio-management and the like. The Coordinate::Change services focus more at the tactical level, and hence link to Direct::Change and Direct::Run; one classic aspect of these service is project-management and the Programme Management Office. In principle, the Coordinate::Run services would bridge between Direct::Run and the actual delivery-services (between system-3 and system-1 respectively, in Viable System Model terms), but in practice this is sometimes regarded – especially by questionably-competent managers – as ‘insubordination’, and hence at the human-coordination level may disappear into a kind of covert ‘shadow network’ via which work is actually coordinated and done. Architects can sometimes run head-on into unexpected political-problems when doing this part of the modelling work: a certain amount of caution may be advisable here!

It’s quite common for some aspects of these services to be outsourced to other organisations: if so, there would be additional coordination-services required to manage and coordinate the outsourcing process itself.

Questions to ask here include:

• Coordinate::Develop – What support for long-term strategic change does this service need? What services would ensure that this service is aligned to the overall enterprise strategy? By what means are these ‘Develop’ coordination-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Coordinate::Change – What support for medium-term tactical change does this service need? What services would ensure that this service is aligned to and fully supports the changing context of its market and business-ecosystem? By what means - such as programme- or project-management – are these ‘Change’ coordination-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Coordinate::Run – What support does this service need for run-time coordination with other services? What services would ensure that this service has the coordination with others that it needs so as to do its work in creating value? What information-flows, signalling or protocols are needed in this coordination-support? By what means are these ‘Run’ coordination-services delivered to this service? Who or what is responsible for these services, and how they apply to this service?

As before, identify the services and exchanges in each case. Add these to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. Use either containment or composition-relations to link each of these Service-entities to the overall Coordination Service. Annotate each flow-relation here with a ‘coordinate’ label, to indicate that the flow delivers coordination-services to the service-in-focus.

Identifying coordination-relationships between services is usually fairly straightforward, although it’s all to easy to fall into layering-mistakes in the modelling process here. (Hence another reminder to be careful here about layering: see ‘A note on layers’ above.) A lot of useful insights can be gained here about the interconnectedness of the enterprise, and its dynamics over time. Note, though, that there are also some important architectural risks (and opportunities) to be identified here: in short, if adequate and appropriate coordination-support is not available, the service will not be viable.

Guidance – validation

The validation-services help to keep everything aligned to the enterprise values – whatever those values may be. Note that there are usually distinct sets of validation-services for each key value of concern in the enterprise. Typical examples of values in this context include quality, probity, security, ethics, health and safety, knowledge-sharing, sustainability, waste-management, efficiency, effectiveness, and also architecture itself.

A crucial point here is that, unlike strategy, management, coordination or change, maintaining these values is a personal responsibility for everyone in the enterprise. There’s often a small core-group tasked with ‘holding the flag’ for the respective value within the organisation, and it’s those people – the knowledge-management, the quality-team, the security-team and so on – who we would often regard as the people who deliver such services. In reality, though, it’s only the support-services around each value that most would deliver: the actual implementation and expression of that value in practice must somehow be embedded and enacted, as activities and checks and the like, within every service in the enterprise.

These support-services for value-alignment be split into three groups: ‘Develop Awareness’ of the value; ‘Develop Capability’ to enact run-time support for the value; and ‘Verify and Audit’, to confirm alignment and compliance to the requirements of the value. (The system-3* component Viable System Model, which represents the closest match to this part of Enterprise Canvas, covers just one aspect of ‘Verify and Audit’, namely random audit of compliance.)

In Taylorism these services are often subsumed into the ‘management’-functions, which can often lead to misunderstandings because the managers themselves must be as subject to the values as is everyone else. It is true, though, that in many cases the core support-group for each value will be regarded as a ‘staff’-function, often reporting indirectly or even directly to the CEO or overall executive; it’s certainly essential for each of these values to have the full backing of the executive, otherwise in practice they end up going nowhere.

Although these validation-services do provide guidance across the enterprise, they are in effect almost orthogonal to the direction-services (‘management’ etc) and to the coordination-services (‘change-management’ etc). Some aspects of these services are often outsourced to other organisations – such as training, to develop capability – and in many contexts the Verify and Audit’ functions must be enacted by an outside organisation, either to support certification or mandated by law. Overall, though, the final responsibility for alignment to each of the enterprise-values must reside within the organisation itself: that aspect of these services cannot be outsourced.

In effect, these services should represent the nodes of a PDCA (Plan / Do / Check / Act) continuous-improvement loop for the respective value, starting at the ‘Act’ node.

• Plan – ‘Develop Capability’ is crucial to embedding the ability to enact support for the value.
• Do – The awareness and capability are applied in practice within each service and service-delivery.
• Check – ‘Verify and Audit’ confirms compliance, or any deviation from required or intended performance.
• Act – ‘Develop Awareness’ is central to taking action towards improving support for the value.

Before any of this modelling-work can make sense, there are some obvious questions that need to be asked:

• What are the enterprise-values? Why do these values apply in this enterprise, and in this organisation?
• Which of these values are explicitly espoused as matter of personal choice, by the executive and/or by others – such as in this organisation’s equivalent of the ‘HP Way‘? Which of these values are imposed on the organisation from outside, as part of a metaphoric ‘license to operate’ within the industry or broader social milieu?
• What differences – if any – exist between the espoused values and the values actually enacted and upheld within the organisation and/or the broader shared-enterprise?

These values should typically be modelled as Value-entities in a row-0 segment of an Enterprise Canvas, attached to the Vision-entity in the model. Within the model, Service-entities for all validation-services should ultimately link back via flow-, composition and realization-relations to one or more row-0 Value-entities.

Given that list of enterprise-values, questions to ask here for each enterprise-value include:

• Validate::Awareness – What support does this service need to develop and establish awareness of the value and its importance to the organisation and enterprise? What services would ensure that this service is aligned to the respective value? By what means are these ‘Develop Awareness’ validation-services for this value delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Validate::Capability – What support does this service need to develop and improve its capability to enact the requirements of the value within the service and its service-delivery? What services would ensure that this capability is appropriately developed, and the capability verified prior to action? By what means - such as training-programmes – are these ‘Develop Capability’ validation-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Run-time support within this service – What functionality and other support exists within this service to enact the value within all of its activities and processes? In what ways are the awareness of the value and capabilities to support the value expressed in practice? Since this represents a personal responsibility incumbent on everyone involved, what support exists at run-time to ensure that those responsibilities are upheld?
• Validate::Verify – What support does this service need so as to verify and audit its actual performance in relation to the respective value? What services would ensure that this service has indeed delivered that performance? What records and other sources are needed in this validation-support? By what means are these ‘Verify and Audit’ validation-services delivered to this service? By what means are these ‘Verify and Audit’ services themselves verified and audited for alignment to the value? Who or what is responsible for these services, and how they apply to this service?

As before, identify the services and exchanges in each case. Add these to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. Use either containment or composition-relations to link each of these Service-entities to the overall Validation Service. Annotate each flow-relation here with a ‘validate’ label, to indicate that the flow delivers validation-services to the service-in-focus.

Also as before, be careful to avoid falling into layering-mistakes in the modelling process here (again, see ‘A note on layers’ above.) Overall, there are lot of useful insights to be gained here, about the nature of the enterprise, and about architectural risks and opportunities. The key concern to note, as with the other guidance-services, is that the service-in-focus will not be viable – especially over the longer-term – unless adequate and appropriate validation-support is available for each value in context.

Investors and beneficiaries

The Investor and Beneficiary services respectively represent those who contribute value to the service, or to whom value is returned from the service, beyond and outside of the usual transactions of the service’s supply-chain.

These services (or service-relationships) are not covered as such in the Viable System Model. They barely rate any mention in classic Taylorism: the only investors acknowledged there, and also the only beneficiaries acknowledged, are the purported ‘owners’ of the business, who invest money in the business and receive money from it in return.

In practice, even at the whole-organisation level, we need a much broader understanding of the roles of investors and beneficiaries, and the nature and myriad forms of value which they invest or receive. We also often need to explore how the forms of value are themselves transformed within a service. For example, in a business-startup context, people may invest time and skill and effort, and hope to receive monetary return; whereas in a non-profit context, people might invest money in the hope of seeing broader social benefit. The same overall principles apply right down to the level of an individual web-service or the like, though sometimes these value-relationships there can be difficult to identify and even harder to describe!

Note that ‘value’ here has a somewhat different meaning to ‘values’ in the enterprise-values sense: the two terms are often related, but they’re not necessarily the same.

When modelling these aspects of service-viability, we need to be aware that these relationships are often highly politicised, and often bound up with some very muddled notions about ‘rights’ or ‘control’. There are also often very strong pressures – especially in commercial organisations – to either ignore all non-monetary forms of value, or to try to force all forms of value into monetary terms, even when it makes little or no sense to do so. Although others may need to work solely with monetary valuations, for our purposes here we need to model the actual forms of value in each context, in their own terms, prior to any conversion to any other form. Failing to do so will invariably lead to architectural problems that can have serious impacts on overall viability – particularly via anti-clients and other kurtosis-risks.

Questions to ask here include:

• Investor – Who or what invests value in this service, in order to get it started, or to keep it running? What forms of value are delivered as investment in this service? Via what services, relationships and exchanges are these investments delivered to this service?
• Beneficiary – Who or what receives value as a return from this service? What forms of value delivered by this service as returns to its beneficiaries? Via what services, relationships and exchanges are these returns delivered by this service?
• Transformation – What are the differences – if any – between the forms of value that are invested, and the forms of value that are returned? By what means do these value-transforms take place within this service?
• Balance – In what ways and to what extent are the invest and benefit relationships in balance, both before and after transformations of value within this service? What relationships with other services are needed to monitor that balance, and/or to take action to correct any perceived imbalance? If the two flows do not balance overall, what impact would this have on overall viability, both of this service and of other related services?

As usual, identify the services and exchanges in each case. Add these to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. If necessary, use either containment or composition-relations to link each of these Service-entities to the overall Investor or Beneficiary Service.

Annotate each flow-relation here with a ‘invest’ or ‘benefit’ label, to indicate that the flow delivers investment of some form to the service-in-focus, or that the service delivers benefits to a beneficiary. An ‘invest’-flow will typically connect either to the Service as a whole, or to the Value-Outlay cell, since the latter represents an abstraction of the activities that manage costs and outgoing payments and the like. For much the same reasons, a ‘benefit’-flow would typically connect either to the Service as a whole, or to its Value-Return cell.

Once again, be careful to avoid falling into layering-mistakes (see ‘A note on layers’). There are some very important and often enlightening insights to be gained here, again about the nature of the overall enterprise, and about architectural risks and opportunities. The key concern to note is that the service-in-focus will not be or remain viable unless it does have adequate and appropriate investor-support, and that – in architectural terms, at least – the balance between investors and beneficiaries is appropriately managed.

Iteration and recursion

At this point we’ve now completed the viability-checklist for that single service-in-focus – the Service-entity with which we started. We could now apply the same checklist-assessment, recursively or iteratively, to any of the Service-entities that we’ve added to the model during this process – everything is a service, so the same viability-principles apply everywhere and at every level.

For obvious reasons, don’t attempt to apply this to everything: by definition, it would take an infinite amount of time to complete the model! Instead, it’s wise to hold to the guideline that we only create a model in response to an explicit business-question, and only to the level of detail needed to answer or respond to that question.

In the same way, it can often be useful to do a drill-down into the details of a specific service, and apply the same viability-assessment at the next level down; or to the next level upward, to a more abstract layer at which redesign and restructure becomes possible. (Or levels – again, iteration and recursion would apply in both directions all the way up and down the layers of abstraction.)

In drill-down or drill-up, though, we need to be especially careful about the distinctions between layers of granularity and layers of abstraction (see ‘A note on layers’ again), because it’s very easy to get them confused here. Going up or down in granularity – composition-relations – is just a change in detail: each ‘child’- or ‘parent’-service will handle a subset or superset of the service-content and Exchange-content of the initial service-in-focus. However, going up or down in abstraction – realization-relations - involves a change in the type of detail that can be described: for example, by definition, row-3 cannot contain descriptions of any specific technology or implementation-method, whereas row-4 can.

Beyond that, though, there are no real restrictions on what we can model in Enterprise Canvas, or why: we’re welcome to iterate or recurse to our hearts’ content, up and down the layers, and anywhere across the enterprise context.

It’s all about story

One last point to finish this Enterprise Canvas how-to.

So far everything we’ve done has probably seemed to be in terms of structure, and relationships between structures: services, exchanges, flows, composition and realization.

Yet there’s another equally-valid way to look at architecture: and that’s in terms of story.

One of the first things we say with Enterprise Canvas is that everything is a service. Yet it’s equally true to say that everything is a story.

Every service is a story, represents a story, has its own story to tell.

Every exchange is a story. Every flow or composition or realization is a story. Every change is a story. The enterprise itself is a story, too. Everything is a story.

When we look at an architecture, yes, it’s all about structure, and dynamics of structure; and it’s also all about stories.

And stories engage; stories draw people in; stories give people a reason to be involved in whatever it is that the service does and delivers, and how and why and where and with what it does so. It’s often in the stories that people tell us that we find the most important clues about what’s working or not-working in the enterprise, and what to do to make it work better. In that sense, the stories matter.

So whenever we look at an architecture, whenever we look at structure, we need also to look at, and look for, the stories that underly and underpin and interweave with that structure. And likewise, whenever we look at the stories, we need to look for the underlying structures that they each imply. Architecture is both structure, and story – and more, of course.

So it’s useful to see Enterprise Canvas not just as a framework for models of structure, but also as an anchor for stories, about the enterprise, about how everything fits together (or not) within the unified whole that is the organisation and its broader enterprise.

Something to work with, play with, even dance with, perhaps, as we further develop our organisation’s enterprise-architecture?

As all-too-usual, the previous ‘how-to’ post ‘Upwards sideways from business-model‘ – to complement the earlier post on transforming from Business Model Canvas to Archimate, to plan and verify the implementation – has turned out to be huge, because it included all of the explanation and context. Here’s a stripped-down version without any of the explanation – just the checklist-questions for the exploration and modelling.

This takes us from the core frame in Enterprise Canvas:

To the complete Enterprise Canvas frame, by including questions on investors and beneficiaries (below the core) and guidance-services for direction, coordination and validation (above the core):

Because the Enterprise Canvas is recursive, the questions here will apply 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.

Investors and beneficiaries

Quick summary of suggested questions to use in this 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?

Guidance – direction-services

Quick summary of suggested questions to use in this assessment:

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

Guidance – coordination-services

Quick summary of suggested questions to use in this assessment:

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

Guidance – validation-services

Quick summary of suggested questions to use in this assessment:

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

—

Over to you: hope it’s useful, anyway.

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?

I base much of my architecture-work on a rethink of Tuckman’s Group Dynamics project-lifecycle as an overview-model of the overall workings of an enterprise:

• forming: purpose, identity, strategy; also far-future
• storming: people-issues; kind-of orthogonal to time – anywhere from far-future to far-past
• norming: plans and schedules; also near-future
• performing: production; also ‘now!‘
• adjourning (or mourning): completions; also near- to mid-past

But when we look at the management-section of Beer’s Viable System Model, only three of those five are covered:

• system-5 ‘policy’: aligns to ‘forming’
• system-4 ‘strategy’: aligns to later part of ‘forming’, plus ‘norming’
• system-3 ‘direction’: aligns to later part of ‘norming’, plus ‘performing’

(For those who don’t know the VSM, ‘system-2′ is about inter-process coordination, and ‘system-1′ about service-delivery, the detail-level of the ‘performing’ phase: they don’t really apply here.)

There’s no VSM coverage at all of the ‘storming’ phase, the people-issues – which seems odd, considering Beer’s very strong personal bent towards left-wing participatory politics. And although VSM ‘system-3*’, random-audit, does sort-of touch the ‘adjourning’ phase, it’s only on a very occasional basis – not the continuous process needed for completions and lessons-learned and the like.

This may stem from the VSM’s history as a model of the information flows for management and the like; but it still seems a huge hole in the coverage of what’s actually needed for systemic design of management processes. Is there any way that the VSM does actually cover that hole? And if not, what would we need to do to fill it?