From business-model to enterprise-architecture

Link: http://weblog.tomgraves.org/index.php/2011/07/26/from-biz-model-to-ea/

Okay, I think I’m finally getting somewhere, on looking for a way to connect a business-model to enterprise-architecture, to provide a full link between top-down intent and bottom-up real-world constraints.

This specific part goes from the business-model downwards, from Business Model Canvas to Archimate, and thence to BPMN, UML and other detail-layer models. (There’s another part needed to link upward, connecting that work back up through Business Motivation Model and the like to the core shared-enterprise, but I’ll have to deal with that in another post.)

As you’ll see, I’ve had to twist Archimate somewhat in a few places, to provide workarounds for its current IT-centrism, but otherwise everything exactly follows the existing standards. The keys that enable and to some extent validate those adaptations are two assertions:

everything is a service (an assertion supported explicitly by the design of Archimate itself)
everything is recursive (a principle that enables pattern-based modelling, such as the concept of ‘layers‘ used in Archimate, TOGAF etc)

The ‘how-to’ that follows after the break is the current outcome of a lot of exploration over the past weeks, months and years, a lots of posts and conversations on this blog and elsewhere, and a lot of in-person discussion with a lot of people, many of whom have explicitly asked to remain anonymous. I do believe it’s in a usable state right now, but it should still be regarded as ‘in beta’ at best: use with some caution, and please send me any feedback and suggestions.

In parallel with both Business Model Canvas and Archimate, this may be considered to be under a Creative Commons licence. It’s probably not yet stable enough to attach to a CC license-type in a formal manner, but for now please assume non-commercial, share-alike and attribution-requested for the parts described here.

More after the ‘Read more…’ break, anyway.

Step 1: Develop a business-model

The term ‘business-model‘ here means a semi-detailed overview of what the organisation does in its business with others, and the offers and value-types that are exchanged. A strong recommendation that the model should be developed in the Business Model Canvas format, using the associated methods described and/or summarised in the book Business Model Generation. (The book is currently available in at least 18 languages.)

Here’s an example Canvas from an earlier post:

Identify the flows that take place between the various entities in the model. This example (from the same earlier post) shows only the connections, but also identify and record what would traverse these flows in order to enact the intent of the model:

All of this would typically be developed in a workshop context, or in a cafe-type setting with a notepad or a software toolset such as the BMTBox app.

Step 2: Re-map the overall business-model as related services

Split the Canvas into a core for the organisation that executes the business-model, and separate entities for each of the Customer Segments and Key Partners:

In Enterprise Canvas, each of these would be mapped as nodes (services) in a value-network, all in relation to each other and the the overall vision for the shared-enterprise:

The Business Model Canvas typically shows only the immediate links in the supply-chain or value-network, but in Enterprise Canvas we could also extend the node-relationships as required:

In Archimate, at the highest level, the organisation and its combined business-model can be represented as a single Business Service; the [BMC] Customer Segments and Key Partners can be represented as Business Actor entities, each of whom takes on one or more Business Role positions, and connect to the service presented by the organisation via Business Interface relationships:

Step 3: Expand the detail of the overall business-model

From previous work, we can cross-map the Business Model Canvas onto Enterprise Canvas:

The Archimate specification indicates that a unit exposes functionality externally as a Business Service, but represents internal functionality as a Business Function. In essence, this is a simple recursion: structurally, they are the same – the difference is in in where and how the interface is exposed, for example whether or not the related Business Interface requires an explicit Contract.

The simplest summary is that the overall functionality and relationships represented via a single Enterprise Canvas entity would be depicted in Archimate as a Business Service; but the constituent ‘cells’ within that Enterprise Canvas would be depicted as Archimate Business Function entities:

The Archimate Business Process entity literally does not come into the picture at this level. A business-process is best understood as a pattern of activities that make use of services in some form of choreographed sequence: it is somewhat misleading to describe it as a structure in the same sense as other Archimate entities such as Business Service or Business Interaction, because in essence it’s a structure in time only. The term ‘business process’ tends to be misused as a kind of variant of ’service’ or ‘function’ or ‘capability’, and all of these terms seem to be used in an arbitrarily interchangeable manner, leading to much confusion in modelling and even in business practice: instead, precise taxonomic distinctions are essential here. In that taxonomy, a service is a combination of function and capability, but for these purposes we can allow ’service’ and ‘function’ to in effect be synonymous, as summarised above.

Given this, we can re-map the Business Model Canvas / Enterprise Canvas [EC:] cross-map into Archimate (italics) entities as follows:

The Value Proposition (EC: value-proposition) is represented by one or more Product entities, with related Value entities.
We have already mapped the Key Partner and Customer Segment entities as Business Actor / Business Role / Business Interface entities.
All of the Enterprise Canvas cells are mapped to Business Function entities with appropriate names (default: same names as in Enterprise Canvas); these also represent in part the Key Activities cell of the Business Model Canvas.
All of the Enterprise Canvas interface cells (customer-relations, customer-channels, value-return; supplier-relations, supplier-channels, value-outlay) also include Business Interaction entities (which may optionally replace the respective Business Function entity), each linked to a Business Interface entity, representing the channels and other interfaces to the overall service.
Each of the six channels (Business Interface entities) links to one or more Business Object entities, which in turn link to the Business Interface of a Customer Segment or Key Partner; each Business Object may optionally be linked to a Meaning entity.
Each Business Object entity attached to a customer-channel Business Interface should also be linked to one or more Product entities; the same may optionally apply to Business Object entities attached to the supplier-channel Business Interface.
The Business Object entities associated with a supplier-channel and value-outlay, or customer-channel and value-return, should be linked by a Contract entity, representing the required relationship between the respective Enterprise Canvas main-channel and back-channel (e.g. Business Model Canvas linkage between Value Proposition, Customer Channel. Customer Segment and Revenue Stream).

In essence, using the suggested sort-of layers described in the previous post ‘Rethinking the layers in enterprise-architecture‘, this represents the content for the ‘Why’ layer, which Archimate describes as the ‘Business’ layer. To a significant extent, the ‘Key Activities’ cell of Business Model belong in the ‘How’ layer (which Archimate at present describes only as the largely IT-centric ‘Applications’ layer), whilst much if not most of the ‘Key Resources’ cell belong in the ‘With-What’ layer (which Archimate at present describes only as the exclusively IT-centric ‘Infrastructure’ layer).

More on that in the next steps. In the meantime, we can summarise the mappings as follows – from the Business Model Canvas for one class of offer (Value Proposition, or Product):

Then to the equivalent Enterprise Canvas for that segment of the overall business-model; and thence to a high-level (‘Business’ layer) Archimate model. [Apologies – I started work on these diagrams, but realised they would probably take an entire day each, and need a blog-post each of their own as well: leave this until later, perhaps?]

Note that this is for one category of offer only, from six categories shown in this overall business-model. The complete business-model for all of the offers in context would be a much larger and more complex Archimate model, even at the ‘Business’ layer only.

Step 4: Expand the Key Activities to Archimate ‘Application’ detail

In Archimate, each Business Function or the like in the Business (‘Why’) layer is supported by (realised via) one or more Application Service entities within the Application (‘How’) layer. We also have the same symmetry on the ‘active structure’ side, with an Application Interface entity underpinning or implementing each Business Role; and, on the ‘passive structure’ side a Data Object representing a more real-world form of a Business Object.

(cc) Open Group

The first point that this tells us is that each of the Enterprise Canvas cells and interfaces and flows will be represented by one or more Application-layer entities in Archimate. That part is straightforward enough.

But here we hit a problem with Archimate, because it assumes that activities at this level will only be enacted by IT. In the current structural assumptions in Archimate, activities that are enacted by real people are pushed upward into the Business layer, whilst activities enacted by non-IT technology (i.e. physical machines) are apparently deemed not to exist at all, or else shoved down into the Infrastructure (‘With-What’) layer.

In principle, every activity could be implemented by any conceivable combination of ‘manual’-process, physical-machine and/or IT. Each of these categories of implementation – human, IT and machine – need to be assessed here as if at the same level, so as to identify the trade-offs between different implementations. We also need to be able to view as if ‘the same’ in development and in disaster-recovery, where – for example – we would switch back and forth between a paper-and-pencil versus an IT implementation of what is functionally the same business-process. But Archimate at present doesn’t allow us to do that trade-off assessment: instead, it assumes that everything can be implemented only by IT. In effect, each of the Archimate entities in this layer is an IT-specific specialisation of a generic entity that does not exist. This is a fundamental flaw in the design of Archimate – and one that we need to resolve before we can use Archimate for the kind of true enterprise-scope assessments needed in reviewing the architectural implications of business-models.

The simplest solution here is to go back and recreate the ‘missing’ generic entities of which the existing Archimate entities in this layer are the IT-oriented specialisations. Given that this layer is about the activities that enact business-functions and business-services, these generic entities could be labelled with an ‘Activity’ prefix:

Activity Object – generic of Data Object
Activity Service – generic of Application Service
Activity Function – generic of Application Function
Activity Interaction – generic of Application Interaction
Activity Interface – generic of Application Interface
Activity Module – generic of Application Component
Activity Collaboration – generic of Application Collaboration

An Activity Object could perhaps be more accurately described as an ‘Activity Subject’, since it’s the subject of all activities, the entity which will be created, accessed, updated and/or destroyed through the respective activity. Again, note that this is the generic: this entity would usually be specialised in the model, to describe a physical object being worked on, a business-relationship being developed, a data-item being accessed or amended, and so on.

An Activity Module is a somewhat arbitrarily-bounded ‘chunk’ of functionality, described in structural terms (‘active structure’) rather than the action itself. For IT, this would typically be described as a ‘component’ or (somewhat misleadingly) as a ’service’. For a manual process, a typical ‘chunk’ would be as described in a Work-Instruction (in ISO-9000 terms), or possibly a somewhat more abstract Procedure. For a machine-based process, a more typical ‘chunk’ would be the defined work within a given process at a single machine or workstation or cluster of workstations.

The types of relationships that Archimate permits between these more-generic entities (and hence between their derived specialisations) should remain essentially unchanged.

It may also be useful to include links and references to location – physical, virtual and/or relational. There is no Location entity in the current Archimate standard, but it is expected that one will be included in the upcoming Version 2, so there should be no problems with compatibility there.

A strong recommendation here to use the distinctions between Function and Capability as described in the extended-Zachman model used in conjunction with Enterprise Canvas. A function is a metaphoric ‘place’ where an Activity Object will be accessed or changed, and that summarises the changes that will take place; whereas a capability is the competence and skill-level brought to bear on Activity Objects in order to enact the required changes. In most IT applications, these two aspects are merged together into the one item of functionality, hence the distinctions between them may seem too subtle for some people to notice; but for machines and, especially, for human processes, the distinctions are much more explicit, and very important. The function aspect relates to activity, and hence belongs in this layer, whereas the capability is in effect a type of ‘resource’, and hence belongs more properly in the equivalent of the Archimate ‘Infrastructure’ layer. More on that when we look at the Key Resources section of the business-model, anyway.

I won’t go into more detail here of how to develop the model itself. Instead, refer to any of the Archimate reference-materials – such as the formal Archimate standard, the documentation from the Archimate Foundation, or the free Archi toolset for Archimate – and then adapt using the generics and re-specialisation of entities as summarised above.

Each of the activities summarised in the Key Activities cell in the Business Model Canvas should be represented somewhere in this layer of the adapted-Archimate, linked appropriately to the services in each of the cells in the matching Enterprise Canvas.

Step 5: Expand the Key Resources to Archimate ‘Infrastructure’ detail

We now go down one more level in the architectural recursion.

In Archimate, each Application Function or the like in the Application (‘How’) layer is supported by (realised via) one or more Infrastructure Service entities within the Infrastructure (With-What’) layer. We also have the same symmetry on the ‘active structure’ side, with an Infrastructure Interface entity underpinning or implementing each Application Component; and, on the ‘passive structure’ side an Artifact representing the full concrete form of a Data Object.

(cc) Open Group

The implication here is that each of the Key Resources in the Business Model Canvas should be represented in some way within this layer. But here again we hit up against the current limitations of Archimate, because it assumes that the only relevant resources are those that can be described in terms of IT: devices, networks, system-software and so on. In the current structural assumptions in Archimate, the competencies and skills of real people are somehow pushed upward into the Business layer, whilst any other non-IT technology or physical resources, capabilities and infrastructures are apparently deemed not to exist at all. To be blunt, this is IT-centrism running wild, and presents serious problems for modelling at this layer.

In principle, every activity could be implemented by any conceivable combination of ‘manual’-process, physical-machine and/or IT- which means that we need the respective resources and infrastructures to match and underpin each implementation. As in the ‘How’ layer, each of these categories of implementation – human, IT and machine – need to be assessed here as if at the same level, so as to identify the requirements and trade-offs between different implementations, including those needed for special-cases such as development and disaster-recovery.

But again, Archimate at present doesn’t allow us to do that trade-off assessment: instead, it assumes that everything can be implemented only by IT. Some of the entities in this layer are sort-of generic – Infrastructure Service, Infrastructure Interface, Network, Node, Artifact – but they’re kind of incomplete relative to the full infrastructure/resource set, and it’s clear that, as in the Application layer, they’re intended more to represent IT-specific specialisations of generic entities that aren’t available in the Archimate specification. This is another fundamental flaw in the design of Archimate – and one that, once again, we need to resolve before we can use Archimate for its purported purpose as an enterprise-architecture notation.

Because the IT-centrism here is more implied than overt, resolving this is not quite as straightforward as in the Application layer. Probably our best option here is to re-assess the whole structure from the perspectives of the expanded-Zachman used in Enterprise Canvas: Asset, Function, Location, Capability, Event and Decision. These are mostly self-explanatory, though note that each of these itself expands to cover the full ontological scope:

These categories apply everywhere, yet there are also distinct emphases in each of the Archimate-style layers: Decisions, Events and, to a lesser extent, Functions in the Business layer; Functions and, to a lesser extent, Events, in the Applications layer; and Assets, Locations and Capabilities in this layer.

An Asset can be defined simply as a resource for which the respective service is responsible and can put to use as required. (In this context, there’s no real difference between assets and liabilities, other than in terms of availability, because in essence they’re variations on a theme of resource and responsibility.)

A Capability is the ability to work on specific types of Asset using a specific level of competence and skill. Note that in general, physical-machines can only work at a rule-based skill-level, IT typically at an algorithmic level, but in most cases only humans can act at guideline or principle-based skill-level. Also that almost by definition, physical-machines and IT are unlikely to be much use for working on relational or aspirational assets – a point that is often forgotten in the design and operation of many IT-based CRM systems…

A Location is a node within some type of location-schema. These may be of any asset-type or resource-type, or any combination of these: for example, a room in a building will have both a physical location and a virtual location-identifier; an IT network-node will typically have an IP-address or equivalent, but also at a physical location; an organisational hierarchy is also a relational network; and so on. And whilst time is often referred to as an ‘asset’ or a ‘resource’, it can’t be changed or transformed in the same way as for other assets, and hence is best understood as a type of Location rather than a resource. (An Event may be considered to occur in time, but is not in itself of time: the distinction may seem subtle, but can be very important in practice.)

A network is a schema that describes a set of Location nodes, specific relationships between those nodes, and, often, the types of Assets than can be transferred on pathways of connection between those nodes.

What we could term an infrastructure is thus a clustering of Assets, Capabilities and Locations, often in network-relationships.

This schema enables us to identify how the existing Archimate entities in the Infrastructure layer are somewhat-arbitrary IT-specific specialisations of the underlying generics:

The Archimate Artifact entity is specified as a virtual-Asset, but can be repurposed to represent any type of real-world Asset.
The Archimate Infrastructure Service entity can be repurposed to represent the exposed available behaviour (Capability) of any cluster of related Assets, Capabilities and Locations, linked to any Activity Function in the Application Layer.
The Archimate Infrastructure Interface entity can be repurposed to represent the exposed interface for an Infrastructure Service, as linked to any Activity Interface in the Application Layer.
The Archimate System Software entity is merely one very specific example of a generic Capability entity.
The Archimate Device entity represents a type of Asset that can be used in and for specific activities, as ‘active structure’: a hammer, a power-drill, a fork-lift truck and an ordinary ‘dumb’ telephone are each likewise a Device in this sense.
The Archimate Network, Node and Communication Path entities respectively represent a schema for connections between Location nodes, a node within that schema, and a connection-path through which specific types of Asset may be transferred between nodes.

As in the Application layer, the types of relationships that Archimate permits between these more generic entities and their derived specialisations should remain essentially unchanged.

Again, I won’t go into more detail here of how to develop the model at this layer: instead, refer to the Archimate reference-materials, and adapt that to the generics and re-specialisations of entities as summarised above.

Each of the items summarised in the Key Resources cell in the Business Model Canvas should be represented somewhere in this layer of the adapted-Archimate, linked appropriately to the services in the Application layer, and thence the services and interfaces and the like in each of the cells in the matching Enterprise Canvas.

Step 6: Apply enterprise-architecture disciplines to review the business-model

What we have, as the outcome of this modelling exercise, is a full ‘to-be’ description of the implemented architecture for the business-model. Which means that we can now turn to all the usual enterprise-architecture tools and techniques – TOGAF ADM, VPEC-T, requirements-modelling and the rest – to evaluate and rethink what works and what doesn’t, and what’s needed to make it all work together well.

The question at the initial Business Model Canvas stage was whether the ideas made sense at the business level. The questions here are more about whether it would work in real-world practice, such as:

What structures, capabilities, skills, equipment does this business-model need?
What exactly passes between each party in each flow – what are the Business Objects that are transferred and/or changed or exchanged? At what points in each process do these transfers take place? What mechanisms and functions are needed to ensure complete balance across the whole ‘Before’ / ‘During’ / ‘After’ cycle of the whole transaction?
What structures and so on do we have already for this? What equipment and configurations and the like would need to be repurposed? What impacts would that have on existing operations and existing business-models?
What kinds of changes do each of the requirements demand – incremental, step-change or breakthrough? Has adequate allowance been made in the risk-assessments for the feasibility or achievability of any required breakthroughs?
Has sufficient attention been paid to the human aspects of the required business-model, including skills-development, retraining, redeployment and cultural change?
What intermediate stages would be required, in the transition from ‘as-is’ to ‘to-be’? Has sufficient attention been paid to the probabilities that ‘there’ may not in reality be the same as we expected when we aimed to get there?
Over what timescales could these changes be implemented? What timescales must apply if the business-model is to be viable?

And so on: the usual stuff, really.

(There are some planned extensions to Archimate to deal with versioning and projects and the like, but I’ll cover that in the next part, that deals more with looking ‘upward’ in the enterprise from the business-oriented view in Business Model Canvas.)

The point here is that this kind of modelling process enables us to do an iterative assessment and reassessment of the idea of the business-model and its real-world feasibility, implications and its implementation, bouncing back-and-forth between top-down (the ‘Why’ of the Business Model Canvas) and bottom-up (the ‘How’ and ‘With-What’ of Archimate’s Application and Infrastructure layers). This is also where enterprise-architects would be directly engaged in the development of business-strategy and its real-world implementation – the ’seat at the table’ at the CxO level of the organisation that so many EAs seem to desire!

—-

So: that’s a suggested pattern and process for direct ‘translation’ between Business Model Canvas and a more whole-enterprise adaptation of Archimate, using Enterprise Canvas as an intermediate layer. There’s another ‘how-to’ to come, going in the other direction, to link Business Model Canvas ‘upward’ to the shared-enterprise, but that’s it for now.

Many thanks for sticking with it this far, anyway. And over to you, if you would?

-1