Business Model Canvas to Archimate (the short version)
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.
Tom,
I think the whole process is still rather/very (depending on the readers knowledge of ArchiMate) complicated. My perception of models is that they should simplify and distort the world to make it comprehensible and “playable”. Wouldn’t it be more logical to take a step back (from ArchiMate) and focus first in more detail on the Business Model Canvas and Enterprise Canvas parts?
Personal I believe that the power of the Business Model Canvas is that it visualizes in a simple & clear way that every business (part) has to deal with three lines from and/or to the customer segments:
– the value line (through the channels)
– the feedback line (through the customer relationships)
– the balance (cost/revenue) line
This is somewhat in line with what John Hagel & Marc Singer wrote in 1999 in http://www.pardis.ir/articles/pdf/Hagel-UNBUNDING_THE_CORPORATION.pdf : “When you look beneath the surface of most companies, you find three kinds of businesses – a customer relationship business, a product innovation business, and an infrastructure business.”. Only difference is that I don’t think that the infrastructure business is or should be a different business but that is more logical to distinguish a financial business because that is a part of every business with special rules & requirements.
Tom
Lots of good food for thought here.
I’m going to start with mostly questions – some of which may betray my ignorance.
You advocate starting (“for now”) with one Business Service. How are we to determine what this business service represents? If the typical enterprise had one single, tightly defined core business, it would be easy but as that’s not usual, I’m unclear how one would define this.
Why did you pick Activity as the genericization of Application? I see an activity as a much more fine grained thing. (IT) Applications typically perform many activities (and I’m only talking about externally visible activities here). That’s actually one of the reasons I am uncomfortable about the IT focus on applications rather than services. But that’s another discussion. This point might just be semantics, in which case don’t worry.
You say a Capability is “the ability to work on specific types of asset”. Can you give an example? I’m not following what you mean by “working on” a Asset.
When you say an Asset is a Resource for which “the respective service is responsible”, how do we determine which service that is and what does responsible mean?
I’m uncomfortable with Capability as a Resource. A Capability seems like an abstract concept, the ability to perform some activity/task/service. A resource is something that gets used – whether consumable or not. I realize that, if I’m right, we may have a gap in the Business Model Canvas, which doesn’t seem to have a place for Capabilities.
In fact in general one of the things you’ve done (deliberately or otherwise) is to highlight a weakness in the Canvas, when it comes to dealing with extended enterprise. I mentioned this in another comment. Of course it’s possible but it requires one to think outside of the boxes (boundaries)in the Canvas. In particular the relationship with Partners seems to be unidirectional and rather more resource than service based. By doing the mapping this becomes clearer. So either we say that it’s OK just to work with the Canvas’s implicit support for extended enterprise or we need to address that (or rather ask Alex Osterwalder to do so). The first option means from my perspective that we then need to find a way to handle it explicit in the Archimate (or any similar) mapping. You were dealing with some of these issues in your post on non-profit enterprises and the Canvas.
cheers
Stuart
@Stuart Boardman
For me a capability offers the possibility to undergo an experience. I therefore would say that the value propositions on the business model canvas are the implicit capabilities offered to the customer segments.
@Peter Bakker – Thanks, Peter.
Yes, I do know that at present “the whole process is still rather/very complicated” – but please remember that I did say that most of this is ‘work-in-progress’, is ‘in beta’, and so on. Facing up to the complication is just the first stage: there’s a lot of further work needed to get back to simplicity again, and I’m all too aware that it isn’t there yet. Some tolerance of that fact, please? And maybe even some help? đ
I do also think you’re perhaps being a bit unfair by implying that all of this has to have exactly the same simplicity as Business Model Canvas, because the real world just isn’t that simple – and anyone who works in implementation will know that fact all too well. We first have to respect the sheer complexity of the real world – and then search for simplicity, through patterns and the like. Unless we respect the complexity, all we’ll have is something nice and simple and pretty that doesn’t actually work in the real world – which is what we’re finding all too often at present when we try to implement business-models developed on Business Model Canvas.
Remember Einstein’s dictum about “making everything as simple as possible, but not more simple”? That’s the conundrum I’m facing here. For example, you talk about ‘three lines’, where the ‘value-line’ goes “through the channels”: yes, they do, but it’s not solely the Channels set described in Business Model Canvas, nor even that plus the Customer Relations channels – it’s a lot more than that, as Enterprise Canvas does describe. That’s what I’ve been trying to explain here: how all of that actually works, in real-world practice rather than solely in the often over-simplified abstractions of business-models.
Enterprise Canvas does actually cover a lot more of this whole-context scope than does Business Model Canvas or, for that matter, Archimate. That’s what I designed Enterprise Canvas to do: to cover that whole scope. But the point is that Business Model Canvas is what people already know; Archimate is what people already know; UML and BPMN is what people already know. And Business Motivation Model, for example, going ‘upward’ in the other direction. Yet each of them only covers a small part of the overall picture; and few of them ‘play nicely’ with anything else. What I’m doing here is showing how to link them all together in a way that works, which means that I also have to show various workarounds to resolve the various kludges and structural flaws and mis-interfaces between all of those different models-contexts. Those flaws are not my fault: I’m just trying to show how to work around them, is all. Some respect of that fact might be nice? đ
Again, Enterprise Canvas does cover all of this space, from ‘really-big-picture’ down to ‘very-fine-detail’. But Enterprise Canvas itself is not the main focus here, because it’s still not very well known. Instead, the main focus here has been how to work with what people do already know, and create workarounds for all the kludges and limitations in those frameworks that they know. So yes, what’s being shown here is full of kludges and limitations – because that’s what’s in the originals, and I don’t have any choice in that. Ne tirez le pianiste, peut-etre, s’il vous plait?
@Stuart Boardman – Thanks, Stuart – great questions. I’ve replied to them in two later posts: ‘Questions on business-model to enterprise-architecture‘ and ‘Assets and Resources‘ – hope it makes more sense there?
@Tom G
Tom,
It was not my intention to shoot the piano player because I like listening to his music đ
I wrote my comment because, although I know something about ArchiMate and about the Business Model Canvas, I had a hard time to follow the articles (short and long version) because I felt they went to quick through the whole process, jumping back and forth between Business Model, Enterprise Model and ArchiMate concept . I thought that taking a step back would make it more comprehensible (for me anyway). And that was all that I was trying to say.
I admit that maybe I shouldn’t have added my personal view on the Business Model Canvas because it is not directly related to what you are trying to do with the Enterprise Canvas. And I certainly respect your views on simplicity versus complexity and I’m very aware of what Einstein said đ
You say in your comment: “Thatâs what Iâve been trying to explain here: how all of that actually works, in real-world practice rather than solely in the often over-simplified abstractions of business-models.” I see models as tools not to show how the world actually works but as tools that make the parts world you want to change “playable” and that models are used to generate & dismiss ideas in a very fast way (like some small scale fast-paced evolution). So I would like to help you where I can but maybe our views on modeling are too far apart at this moment đ
Another point of difference is probably that I am more interested in what the audience of Enterprise Architects know and not the Enterprise Architects themselves. The audience doesn’t know ArchiMate, UML or BPMN. The SysML people seems to be the only ones who are putting an effort in making there models comprehensible for a broader audience by putting together different diagrams as a kind of story. So I’m curious what you think of SysML.
And my last point is that I think that modeling should not be done by architects themselves. In most other areas (like aerospace) modeling is a separate specialization and I think that there is (or will be) a need for specialized modelers in the digital architecture world as well.
But despite our different views on certain aspects I do respect your views and certainly your work and ideas!
I hope that you have the patience to live with the fact that my comments can be sometimes a bit clumsy đ
Many thanks again, Peter (and thanks also for lowering the pistol… đ )
You’re right, I probably did go through the cross-mapping process far too fast. It’s really just a first-cut to get the ideas out there and in practical use, and I think (hope?) it sufficed for that. (I’ve had complaints from others that it was all far too long, of course… đ oh well…)
What these posts have really been about has been “How to take a business-model from Business Model Canvas and cross-map it elsewhere to make sure it’ll work in practice”. Hence we need to go both ‘downward’, ultimately down into the UML/SysML/BPMN kind of space, but using Archimate as an architecture-oriented intermediate; and also go ‘upward’ to connect with extended-enterprise, for which at present Enterprise Canvas is probably the best architecture-oriented option that we have.
A reminder too that I don’t regard models as somehow ‘defining’ “how the world works”, but more as anchors for story about what we can or intend to do to make something happen – literally ‘realise’ it – in the real world. The ‘finished’ model is really little more than a record of conversations and decisions – and literally useless, of course, unless we do actually use it to do something.
I took a look at SysML, and to be honest it seems to combine all of the disadvantages and tangled complications of UML without any of the architecture-oriented advantages of Archimate – a kind of ‘worst of both worlds’, really. I’ll admit I don’t greatly like Archimate – especially in its current overly IT-centric implementation – but I would really need some good reasons as to why SysML would be any better for architectural mapping. (For the next level down, as a precursor to UML, yes, possibly – but that’s detail-layer IT-architecture, and it isn’t a world I deal with at all.) Unless there is a solid community-of-practice around using SysML in a ‘storied’ way, I frankly would recommend that no enterprise-architect should come near it with a barge-pole, because on the surface at least it doesn’t seem any different from the usual UML disaster-area… So yeah, I would really like to know why you recommend, and how it could or should be used to model the entire enterprise-architecture space, from enterprise vision and values down to technical minutiae. Advice on that, please?
Very strongly agree with you that “modeling should not be done by architects themselves”: to my mind, the proper role of architects is that of facilitator and, in some cases, visual note-taker on behalf of the respective stakeholder group. Enterprise-architecture in particular should be a decision-support role for the organisation, not a decision-making one: whilst the EA does have distinct skills and responsibilities to bring to the table, the ultimate authority for architectural decisions should rest with the stakeholders – not with the EA.
On “the fact that my comments can be sometimes a bit clumsy”, the first point is that you’re writing in what is for you a foreign language! I’m painfully aware of how very little Dutch I know: I’m somewhat better in a few other languages – mainly French and Portuguese – but in none of them could I express complex ideas as you do here, so I have no reason whatsoever to complain! đ
@Tom G
Tom, I have used both ArchiMate and SysML in the past and I felt more attracted to SysML because:
1. it uses simple generic building blocks and relations to describe systems of systems (and I see an enterprise as a system of systems)
2. it has a simple way to model requirements
3. it helps you to think about context and define the system boundaries
4. it supports parametric modeling (you can model objectives and metrics)
The SysML language is supported by the system engineering community INCOSE http://www.incose.org/practice/fellowsconsensus.aspx
Examples (somewhat) relevant to EA:
– http://www.hfidtc.com/research/process/reports/phase-2/HFIDTC-2-2-8-9-1-sysml.pdf
– http://www.modaf.com/files/050203%20MODAF%20IEE%20v1a.ppt
– http://bit.ly/raPFKc
– http://www.incose.org/chesapek/Docs/2010/Presentations/2010_08_18_Osvalds_MBSE.pdf
Those are not examples of complete EA model but I hope they give an idea of the possibilities of SysML for EA’s.
And yes, I know that most of those things can be achieved with ArchiMate (although for some things you will probably need extensions on ArchiMate or tool-specific features) but at the same time my argument is that I can do anything with SysML that is possible with ArchiMate without tweaking/extending SysML itself or relying on tool-specific features.
Best thing would be if The Open Group would design an Enterprise Architecture modeling scenario which can be used to test the usefulness/effectiveness of different modeling languages so that people can see objectively what the impact is of choosing one notation language over another. But I’m afraid that the marketing power behind ArchiMate is not willing to allow that to happen đ
At this point in time I think both are sub-optimal modeling languages and I’m now completely focused on Petri nets. Hopefully I will post some sketches/ideas I have how Petri nets can be used in combination with business model canvasses and tube (subway) maps in the near future đ
And it is true that English is not my first language, but I must admit that I make even more clumsy comments in Dutch đ