Link: http://weblog.tomgraves.org/index.php/2011/07/26/bmcanvas-to-archimate-short/
The previous post, ‘From business model to enterprise-architecture‘, turned out to be another of my monster essays. Sorry… 
The detail’s there if you need it, but if you just want to do the translation from Business Model Canvas to Archimate, without worrying too much about the ‘Why’ behind it, here’s the short version.
Step 1: Start with a business-model on Business Model Canvas
That part’s straightforward enough for most folks here, I imagine?
Step 2: Separate out the players on the business-model
Start an Archimate diagram at the Business layer (the ‘Why’ layer).
Represent each Key Partner from the Business Model Canvas by a Business Actor entity on the Archimate diagram.
Likewise, represent each Customer Segment by a Business Actor entity.
(We will also need Business Role and Business Interface link-entities for each of these business-actors, but we’ll come back to that in a moment.)
The remaining cells of the Business Model Canvas – this organisation – can for now be represented by a single Business Service entity.
Step 3: Expand the detail for the interfaces of the business-model
Represent each Value-Proposition offer by a Product entity, optionally with an associated Value entity to describe why this offer would be of value to a customer-segment. Link these Product entities to the organisation’s Business Service.
Represent each Customer Relations item and Channel with the following:
- Business Interface entity, linked on one side to the organisation’s Business Service, and on the other side to a Business Role assigned to the respective customer-segment Actor
- Business Interaction entity, also linked to the Business Service and to a customer-segment’s Business Role
- Business Object entity – indicating the content of the flow between the organisation and the customer-segment, optionally associated with a Meaning entity and/or Contract entity – linked to the respective Business Interaction
Represent each Revenue Stream in a similar way, as a ‘back-channel’ through which value is returned to the organisation. Each back-channel will include its own Business Interface, Business Interaction, and Business Object, with the latter probably linked to the same Contract as for the respective Business Object in the main transaction channel.
Repeat the same process on the supplier-side, with matching Business Interface and Business Role entities for each Key Partner, and Business Interface, Business Interaction, Business Object and Contract entities for each external Cost Structure item. The respective channels and supplier-relations services are only implicit in Business Model Canvas, but you’ll need to add the respective Business Interaction and Business Object entities on that side, together with any needed Contract entities.
Step 4: Expand the Key Activities
Extend the Archimate diagram down to the Applications layer (the ‘How’ layer). In particular, we’ll use this layer to model the Key Activities in the Business Model Canvas.
We have a problem at this point: Archimate’s ‘Applications’ layer only knows about IT, and we need it to cover a much broader range of types of ‘How’. This is because an activity in a business-model could be done by any combination of people, IT and ordinary machines, and to understand the trade-offs between different ways of doing things – different types of ‘How’ – we need to model them in much the same way in each case.
To do this, we need to change the Archimate entities for this layer from the IT-specific ones in the standard, to more generic ones that will work with any type of implementation. In most cases, all we need to do is change the prefix of the name from ‘Application’ to the generic ‘Activity’. This gives us the following entities to model our Key Activities:
- Activity Object (generic of Data Object): represents an object (or subject) to be created, accessed, changed, deleted or otherwise worked on in a business-activity – may be physical, virtual, relational or any combination of those as required
- Activity Service (generic of Application Service): the ‘exposed’ part of an activity that connects with a Business Function in the Business layer
- Activity Function (generic of Application Function): a ‘chunk’ of activity that is visible only within this layer
- Activity Interaction (generic of Application Interaction): a unit of behaviour where two or more components or modules come together to act on an Activity Object
- Activity Interface (generic of Application Interface): a point where an activity can connect with its environment – particular to access or exchange Activity Objects
- Activity Module (generic of Application Component): a defined unit of activity in a structural sense, such as specified in an ISO9000-style Work Instruction
- Activity Collaboration (generic of Application Collaboration): a temporary configuration of two or more modules to perform collaborations
Link these entities as appropriate, using the respective standard Archimate relationship-links.
Step 5: Expand the Key Resources
Extend the Archimate diagram down to the Infrastructure layer (the ‘With-What’ layer). In particular, we’ll use this layer to model the Key Resources in the Business Model Canvas.
One of the frames we use extensively in our own enterprise-architecture is an extended and adapted version of Zachman, which uses the categories Asset, Function, Location, Capability, Event and Decision. In general, the Key Resources section in Business Model Canvas relates to Assets, Locations (physical, virtual, relational, and various combinations), and Capabilities (the abilities or facilities used to the work or within which or through the work takes place).
Again, the Archimate standard only knows about Assets, Locations and Capabilities that relate to IT: we need to extend this to include any other types we may need in the business-model – including buildings, machines, and individual people’s skills.
An Asset can be defined simply as a resource for which the respective service is responsible and can put to use as required.
A Capability is the ability to work on specific types of Asset using a specific level of competence and skill.
A Location is a node within some type of location-schema. Locations may be of any asset-type or resource-type, or any combination of these.
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.
An infrastructure is thus a clustering of Assets, Capabilities and Locations, often in network-relationships.
Given these, we would represent the Key Resources via the following Archimate entities, adapted as appropriate:
- The Artifact entity may represent any type of real-world Asset.
- The Infrastructure Service entity may 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 Infrastructure Interface entity can represent the exposed interface for an Infrastructure Service, as linked to any Activity Interface in the Application layer.
- The System Software entity is merely one very specific example of a generic Capability entity, and can be used (preferably retitled) to represent any Capability.
- The 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 a Device in this sense.
- The 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 (Artifact entity) 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.
Step 6: Apply enterprise-architecture disciplines as required
Use standard enterprise-architecture techniques – such as the methods and tactics outlined in TOGAF Phases B-D – to review the resultant architecture portrayed in the Archimate model(s), and make any recommendations for changes to the business-model itself.
Use standard project/architecture techniques – such as the methods and governance outlined in TOGAF Phases E-G – to define and monitor change-projects to implement the agreed business-model.
