Assets and Resources

More on translating Business Model Canvas to Archimate etc. (Yes, it’s another of those long, interminable technical posts – my apologies, though they are necessary…)

This one picks up on a couple of sort-of-mistakes that I’ve made in the previous post, ‘Questions on business-model to enterprise-architecture‘, and which need a bit more clarity in explanation. In particular, it’s about specific points in relation to two of Stuart Boardman’s questions:

  • an Asset as a type of a Resource – specifically as a Resource for which “the respective service is responsible”;
  • a Capability also as a type of Resource.

A key part of this relates to what goes into the Key Resources section in Business Model Canvas, and how we translate and model the respective items in Archimate.

This will no doubt be another long one – sorry… – hence more after the ‘Read more…’ break.

Resources in Business Model Canvas

Business Model Canvas is about business, and in essence is in the language of business. Perhaps that seems obvious at first – but it has some implications that aren’t obvious at all, that are very important indeed to anyone working with detailed design.

Implementation folks need precision, exactness, certainty – because very often that’s the difference between what works, and what doesn’t. But the whole point of the kind of strategic language used in Business Model Canvas is that it’s blurry, uncertain, cluttered with clunky not-quite-categories and ‘you-know-what-I-mean’ mixups of service versus function versus capability versus process and so on. At that level, allowing that kind of clumsy clunkiness to exist is often what makes the difference between what works, and what doesn’t. But the clash between those two very different mindsets can life very, uh, interesting, for enterprise-architects and others who have to bridge the gap…

Business Model Canvas starts with a Value Proposition. No problem there. Yet the first questions any implementer will ask are:

  • What do we do to create value?
  • What do we use to create value?

In Business Model Canvas, that’s what we would list under Key Activities, and Key Resources.

Key Activities are what we do. In Archimate terms, that’s Behaviour, as a service, function, process, interaction. (We won’t explore these any further in this post.)

Key Resources are what we use. Anything that we would use in doing something is a ‘resource’. This includes what we use to do things to, and what we use to do things with. Archimate splits these into two parts: the ‘things’ that we use which Archimate calls Passive Structure, such as an object, a contract, a product and so on; and what we use to act on those things, which Archimate calls Active Structure, as roles, interfaces, actors and suchlike.

Capability as Resource

A capability is ‘the ability to do something’ – an active part of what we would use to do something. In Business Model Canvas, we would describe this as a Resource, because it’s something that is available to use, but not the activity itself.

A capability is part of the structure of work, rather than the doing of work. Hence it’s what Archimate would call Active Structure – except that it doesn’t use the term ‘capability’ at all. Instead, if we accept that capability is ‘the ability to do something’, then it’s sort-of-implied in Business Role (Business layer), Application Component (Application layer) and Device (Technology layer).

Note that those entities in the respective layers could also be described as capabilities embedded in a real-person, in IT-software, and in a machine. Those distinctions become important when we look at Assets later.

A capability is a Resource that, with some provisos, we translate into Archimate as an aspect of the ‘things’ of Active Structure. Or, to put it the other way round, each of the ‘things’ of Active Structure has capabilities. That capability is exposed through an Interface, to say how it will do something; and linked to a Function (or Process, or Interaction), to say what it will do to something; then both Function and Interface are linked together to provide a Service.

Anything that Business Model Canvas terms as ‘Key Resources’ is something that is available to be used within the business-model. Anything that Archimate terms as ‘structure’ – whether ‘passive’ or ‘active’ – is a resource. Capability is active structure that is a resource because it is something that available to use.

Asset and Resource

Over on the other side of Archimate is its Passive Structure, are the ‘things’ to which or with which something is done. This forms the bulk of the remainder of the Business Model Canvas’ ‘Key Resources’.

There are a few other Zachman-like items that don’t really fit into either Key Activities or Key Resources, though they are needed for modelling of implementation. These include key events for the business-model, key decisions (but not decision-making itself, which is a capability and/or an activity), and some types of locations. Archimate places Event as a class of Behaviour (somewhat oddly, because it’s a trigger for behaviour rather than a behaviour as such); the current version of Archimate doesn’t cover anything else, but the upcoming version is expected to include an entity for Location, and may cover some aspects of decisions in the proposed Motivation extension. (We won’t explore these any further in this post either.)

For most of these other Resources, I’ve found it useful to map them in terms of two specific dimensional sets of attributes:

  • entity in focus is tangible versus non-tangible
  • focus is on the entity itself, versus emotive relationship between a real-person and this entity

I’ve suggested in the other post that a Resource becomes an Asset when someone has an explicit responsibility for the appropriate maintenance and/or use of that resource. A clear illustration of this responsibility is implicit in the ‘assets and liabilities’ column of a balance-sheet – where a ‘liability’ is in relation to an asset for which the organisation accepts responsibility without actually the ownership of it.

This gives us four key categories of asset-‘primitives’: physical (tangible entity), virtual (non-tangible entity), relational (person to/with tangible entity), and aspirational (person to non-tangible entity).

A physical-asset is tangible, hence also ‘alienable’: it is transferred from one owner to another by physical exchange of the entity. Responsibility for the asset rests with the person who holds it. It’s relatively simple to build a property-model based on ‘rights of exclusion’ around physical-assets. (We’ll ignore for the moment the ethics or sustainability of doing – the point is that the alienable nature of physical-assets makes it possible to do so.)

A virtual-asset is non-tangible, hence also ‘non-alienable’. (IT systems work almost entirely with virtual-assets.) Non-alienability means that the way we create a sort-of transfer is by making a copy of the entity at the destination for the ‘exchange’, and optionally deleting the original copy at the ‘source’: there is no actual transfer of ‘the entity’ as such. Again, responsibility for the asset rests with each person who holds each independent copy of the asset. It is extremely hard (perhaps impossible) to build a viable property-model based on ‘rights of exclusion’ to virtual-assets (i.e. ‘intellectual-property’), because the nature of virtual-assets requires that a new copy be created at every transfer. Attempts at exclusion require ever-more-cumbersome structures that are, by definition, ultimately self-defeating; business-models that rely on such exclusion are inherently fragile and may well be delusory, “held together by nothing more than smoke-and-mirrors and lawyers’ bluff”.

A relational-asset exists between a real-person and another tangible entity. (The other entity is often another real-person, but not necessarily so: it’s useful here to consider the emotional attachment people have to physical objects or places or animals as other variants on the same theme. We could also be pedantic and say that the source-entity does not always have to be a real-person: a dog, for example, is certainly capable of forming emotional attachment to people, to places, to other animals and also to tangible objects – and each of those connections would technically be a potential relational-asset.) The asset is undeniably ‘real’, yet cannot actually be transferred to any other person, because it exists between the source and destination. (Conditions can be provided under which an equivalent relational-asset can be created, but the asset itself cannot be transferred as such.) Responsibility for the maintenance of the asset rests with both parties to the asset: if either party abandons that responsibility, the asset will cease to exist. Because of all these factors, it is extremely unwise to attempt to build a property-model based on ‘rights of exclusion’ around these assets, because it literally makes no sense: it can only be made to seem to make sense by treating ‘the Other’ as a ‘possessable’ physical object or as a subordinate subject of self – as unfortunately does occur in much employment-law, for example, or contract-law. (The well-meant phrase “our people are our greatest asset!” only makes sense when those people are slaves… it is essential to understand that it’s not the person that is the asset here, but the relationship with that person.)

An aspirational-asset exists sort-of ‘between’ but actually from a real-person to or towards a non-tangible or abstract entity. As with a relational-asset, both entities must exist in some sense in order for the asset to exist, even though the ‘far-end’ of the asset-relationship is technically ‘imaginary’. This latter point is crucial for brands and similar types of aspirational-assets, where the non-tangible entity is maintained by a third-party: if the ‘owner’ abandons the entity, or even changes the entity in some way, any aspirational-assets linked to that entity may well be lost. As with relational-assets, an aspirational-asset cannot be transferred as such to another person, but conditions may be created in which an equivalent relationship may emerge. Likewise the nature of aspirational-assets is often very poorly understood in business-models, and are often mis-framed as if one or both ends of the relationship are physical ‘possessions’: attempts to build a property-model based on aspirational-assets – such as ‘goodwill’ in relation to a business – are often delusory at best.

Many real-world assets (perhaps most?) are composites of these categories; each composite takes on the attributes of all of its component categories. A printed book, for example, is both a physical-asset (the book-object itself) and a virtual-asset (the information contained in the book): it is therefore subject to all the constraints that apply to physical objects (inventory, deterioration, alienable location etc) and information-objects (transfer-by-copy, if only into the reader’s personal memory). A customer of a shop has both a relational-asset link with the employees of the shop and an aspirational-asset link to the shop itself (the abstract-entity or idea of ‘the shop’): the business will in effect leverage the relational-asset to strengthen the aspirational-asset.

Note that all of these asset-primitives or composites could be represented on an Archimate ‘Business’-layer diagram as a Business Object. Unfortunately, the effective IT-centrism of Archimate at present means that it can only portray an IT-specific sub-class of virtual-assets in the ‘Application’ and ‘Technology’ layers (as Data Object and Artifact respectively). This makes it impossible to describe a complete business-model in Archimate without resorting to unsupported ‘kludges’ to create non-standard Archimate entities to represent those other asset-types in the detail-layers of the model. We need a better solution than this in Archimate or any future equivalent.

In evaluating business-models or enterprise-models, note carefully the points above about the viability (or rather, the non-viability) of business-models that go against the inherent asset-type natures of the assets in scope for the business-model.

Also beware that many existing business-models rely extensively or entirely on a notion of ‘anti-possession’, of use of but non-responsibility for specific types of resources: a perceived ‘right’ to pollute, for example, or to extract personal benefit by socialising other business costs. (In Enterprise Canvas terms, this is an expropriation arising via a mismatch between the full set of between stakeholder-Investors versus a much smaller subset as Beneficiaries.) Increasing transparency, increasing awareness of environmental and other costs, and increasing availability of alternate information-sources beyond organisations’ own control, all tend increasingly to expose any covert ‘cost-export’ process; the resultant social and legal pressure from that exposure is likely to render non-viable any business-model that depends on such dysfunctional processes, and needs to be understood as a very high kurtosis-risk to that business-model.

Okay, better stop there: more than enough already. Very technical, I know, but I hope it’s useful to someone?

Tagged with: , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*