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.
In the adaptation from Business Model Canvas to Archimate, if we start with one Business Service entity, that entity would then represent either the business-model as a whole, or else one of the subsidiary models in a multi-part business-model. If the latter, we would come back later and build equivalent cross-maps for the other subsidiary models. We ‘define’ the service only in the sense that we choose that as the place to start modelling: the content for that ‘service’ is defined already from what we’ve developed on the Business Model Canvas.
The reason for starting just with one Business Service entity is that, when we first start doing this kind of cross-map, it’s often complicated enough already just with the one. As we gain more experience with the cross-map process, we can go straight to a model that looks more like a real-world structure right from the beginning, but that level of detail can often seem overwhelming at first – especially to others when they see the model for the first time. We’ll almost certainly need to decompose it into multiple Business Service entities later, but it’s best to keep it simple at the start! 🙂
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.
To use the famous phrase, “it seemed like a good idea at the time”… to me there’s nothing special about that choice of ‘Activity’ versus any other equivalent term. The main point was that I wanted a term that could describe the same something-being-done, as done by any combination of real-people, machine and/or IT – not just the strongly IT-oriented term ‘Application’.
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” an Asset.
This relates to part of the rework I did some time back on making the Zachman columns fit more closely to what happens in the real-world, and specifically relates to what Zachman describes as the ‘Who’ column. To me Zachman’s column-structure has never made sense, because it kind of randomly conflates different things into the same spaces, and the ‘Who’ column is particularly problematic. Business-folks also tend to use terms such as ‘process’, ‘service’, ‘function’, ‘capability’ and even ‘unit’ as almost random sort-of-synonyms for each other but at different levels of abstraction or decomposition – a further muddying of the waters that really doesn’t help when trying to disentangle the resultant mess!
There are several fundamentally different things going on in that context:
- What is being changed or used or referenced or otherwise worked on or worked with;
- The rules that govern what changes are to take place, and how those changes should take place;
- The ability to work on (create changes to) whatever-it-is;
- The ability to make appropriate decisions about how those changes are taking place (the skill-level or decision-level).
Item 1 is what I term an Asset – more about that in a moment, when we look at Stuart’s next question.
Item 2 is what I term a Function, because it’s essentially as in a mathematical function – a=resultofdosomethingwith(x,y). It defines the parameters that will be used (i.e. providing labels for Asset-types), but in essence everything else is encapsulated inside the function (i.e. black-box).
The specific combination of item 3 and 4 is what I term a Capability, because it’s the ability to do something at a specific level of skill and decision-making. (This is similar to the way that Stuart defines it below – “the ability to perform some activity/task/service” – but with a bit more specificity and taxonomic precision.) In the human context, capabilities are often clustered or bundled into Roles and/or Responsibilities – the latter of which are, literally, ‘response-abilities’. That’s the human side of skill and ability, which is why it fits as more consistent meaning at the detail-layer than Zachman’s ‘Who’.
We bring a Function and a Capability together to form a Service. On its own, a Function is always abstract: it needs a Capability to make it actually do something. And on its own, a Capability literally has no function: the Function provides a context in which the Capability can be put to work. A Service may present the same Function interface but with different underlying Capabilities – hence, for example, a Service that can handle any level of insurance-claim, with low-value claims processed entirely by IT-based Capability but higher-value claims requiring human intervention with a different Capability implementing a higher skill-level and decision-making authority.
A Process is just a sequence of changes provided by Services, that are regarded as related in some way (hence ‘choreographed’ etc). It may be a predefined sequence (as in most IT-driven processes); or it may be almost entirely freeform, requiring high skill-levels; or anywhere between those two extremes, using any appropriate combination of human, machine and/or IT capabilities.
This is yet another example where IT-centrism has scrambled people’s understanding of what’s actually going on here. The problem arises because Function and Capability and, often, Process, are all blurred together within a software-application, whereas in a human or even a machine context the distinctions are much more necessary and explicit. We need to be able to distinguish between them for key architectural concerns such as trade-off analysis for implementations or load-balancing, and business-continuity/disaster-recovery.
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?
A Resource is simply something that can be used in some way: anything that exists in some form or other is a potential Resource for some kind of business-model. A resource becomes an Asset within some type of ownership-model: in the crudest possible sense, it’s an Asset if we own it. Some things – air, for example, or time – can be resources but can’t be Assets because we can’t own them as such.
We then hit up against the complexities of contrasting different ownership-models, particularly possession-based (i.e. what we’d usually think of as ‘property-rights’) versus responsibility-based. I won’t go into those distinctions in detail, but in essence all of this actually revolves around roles and responsibilities. The whole point of the business-model is we say that we will deliver the Value Proposition via the Channels to the Customer Segments. If we expand that statement into more precise taxonomic detail, what it means is that we declare responsibility (‘response-ability’) to deliver value to the shared-enterprise, by doing something (Key Activities) with Assets (i.e. resources for which we also have responsibility), and then, via some defined mechanism (i.e. Channels), passing the responsibility for those value-added Assets to the enterprise-stakeholders referred to as ‘Customer Segments’. That second definition probably seems horribly long-winded and pompous, but that’s the level of detail that we actually need when we’re going to design a real-world implementation.
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.
Perhaps the best way to explain this is that well-meant phrase “Our people are our greatest asset”. (In reality, it’s the relationship with the person that is the asset, but that’s another story.) The point here is that the skills and abilities of the person, the machine, the IT-application or whatever – the set of available “ability to perform some activity/task/service” – is definitely “something that gets used” in the organisation, and hence ‘resources’ from the organisation’s perspective. So it’s not a gap in the Business Model Canvas – it’s what we would include under the Key Resources banner.
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.
There’s a real danger of being unfair here, so I ought to reiterate that Business Model Canvas works very well indeed for the task that it was designed to do. That task is about getting people to think and innovate about how their business-model operates, in a kind of integrated, big-picture way, all with the simplicity needed for rapid brainstorming and pre-prototyping and the like in a free-form workshop or cafe context. To me it’s a business-architecture tool, with a very specific purpose: we really have no right to complain that it isn’t a good fit for whole-scope enterprise-architecture, or for detail-layer implementation, because it was never designed for those kinds of uses.
If we need to link it into methods and tools and the like for those other uses, it’s our responsibility to get those cross-mappings to work – not Alex’s. That’s what this bunch of posts has been about: going downward to Archimate and suchlike, and upward to Business Motivation Model and beyond.
The same applies to using Business Model Canvas for business-models for government or non-profits. The fundamental structure of the Canvas is geared towards commercial organisations, and there’s nothing wrong with that. If we want to use the Canvas outside of a commercial context, it’s our responsibility – not Alex’s – to make the appropriate amendments. (Alex did set up a website a couple of years back to explore ‘business-models beyond profit‘ – and although it doesn’t seem to have gone any further in the last eighteen months or so, I know he does have a deep personal interest in that space.) So again, we do need to be fair here.
The only ‘weakness’ in the Business Model Canvas as such is its implicit asymmetry on the Key Partners side of the model: in my opinion those relationships need to be understood as exactly symmetrical with the Customer Segments side, not least because we can make or break a business on supply-side as easily as on customer-side. That asymmetry also makes it more difficult to visualise a full supply-chain, or the role of the business-model within an overall value-network. Much the same applies to its orientation towards resources rather than services, and (especially in the Canvas’ implementation in the BMTBox iPad app) the low priority given to modelling of flows and transactions.
But I do acknowledge both of those as trade-offs to preserve simplicity: that kind of structure does make it easier to focus on this organisation’s business-model, without getting too distracted by anyone else. For the Enterprise Canvas, I made different trade-offs: it’s explicitly symmetrical, and it’s explicitly designed around services, but it is also more complex – especially once we use it to go into recursive service-decomposition or inter/intra-service coordination or flows-modelling or role-mapping or values-dependencies and the like. It’s designed for those uses, and Business Model Canvas isn’t – but that doesn’t make Business Model Canvas ‘wrong’ as such. Using Enterprise Canvas for multi-layered enterprise-modelling also requires a different mindset and skillset, than those needed for roughing out business-models on Business Model Canvas – the difference between whole-enterprise architecture and domain-specific business-architecture, in fact. Sure, we can use Enterprise Canvas to develop business-models, and it actually fits that need very well: but it’s not specifically designed for that purpose – whereas Business Model Canvas is. ‘Horses for courses’, really.
I hope that makes some degree of sense, anyway, and that it answers those questions well enough for now?