Tom Graves / Tetradian

This is another follow-on to the earlier post ‘Helping others make sense of my work’ – this time about how to bring all of this to a wider audience and market, and help bring ‘whole-enterprise architecture’ ideas into more general use.

If you’ve been around this weblog for a while, you’ve probably noticed I tend to churn out ideas for tools for whole-enterprise-architecture. That’s what I am, really – a toolmaker, a maker of conceptual tools.

Some of those ideas for tools, I’ll have to admit, have pretty much gone nowhere. Others, though, have gained a fair bit of attention and interest. A few have so far made it out into book-form, and look like going a lot further.

But what I really want to do is re-work all of the best ideas into apps – tools that can be used online or offline, on any part of the EA toolset-ecosystem, from smartphones to tablets to laptops to desktops to ‘proper’ repository-based EA-toolsets.

The practical catch is that I’m long out of date as a software-developer, and at present I don’t have access to investment funds to pay someone else to do it.

So I’m looking for partners to work with me in developing these apps.

I firmly believe that if we get it right, there’s a huge potential market for several of these app-ideas, and at present there’s little or nothing out there to serve that need. And the first developer who fully ‘gets’ what I’ve been struggling to explain here on this weblog over the past few years is going to gain a market-position that should establish them for many years to come. So, your choice, folks: anyone interested?

I’ll quickly outline below the five ideas that I think are the most ready to be implemented as apps:

• SCAN sensemaking-framework
• Context-space mapping sensemaking-method
• ‘This’ exploratory game for service-oriented enterprise-architectures
• Enterprise Canvas for modelling service-oriented enterprise-architectures
• SEMPER diagnostic and intervention-design for organisational ‘ability to do work’

For each app-idea, I’ll summarise:

• why and how this app will help
• what the app would do
• what it would look like
• existing apps which include some aspects of this
• how this links with broader EA-tools context
• probable market (and hence potential revenue)
• probable complexity / difficulty for development (and hence potential cost)
• current development-status
• posts and other sources for further information on this prospect
• other notes (if any)

For the right person, or the right team, there really is a huge opportunity here that’s too good to miss…

Read on, anyway: and if you’re interested in any of this, or know someone else who might be, please get in touch with me as soon as possible. Thanks!

Read more…

In enterprise-architecture, how do we disentangle business-function, business-capability and business-service?

This one’s for Adam Johnson, particularly as a follow-on to his comment to the previous post ‘More on EA and asset-types [Part 4]‘:

I perceived your usage of function to be business function at a certain level of abstraction that could be perceived as a capability. Sorry..and now based on your reply I think I understand, but lets try an example…

Capability – Marketing Resource Management – What we are capable of
Function – Marketing
Service – Create Marketing Resource

Capability – Disaster Management:Alert / Notification Management
Capability:Actor – Disaster Recovery Lead
Function – Disaster Recovery:Disaster Recovery Triage
Service – Alert / Notify Disaster Recovery Team

Perhaps my take on actor is a bit off, but I’m trying not to think too much…

I’d say that both of those sets are pretty close to what I meant – thanks. The actor of ‘Disaster Recovery Lead’ makes sense as the person (in this implementation) who is able to deliver the work of Alert/Notification for Disaster Management.

It still seems worth going over all of this once more, to hammer home both why clarity is needed, and what we can do about it.

The biggest single problem here is that people tend to use ‘business-function’, ‘business-capability’, ‘business-service’ and sometimes even ‘business-process’ as either direct synonyms or near-synonyms. Sometimes they’re at the same level of abstraction, sometimes not; either way, there’s very little clarity as to which is which, the same term is used by different people to mean different things, and different terms to mean the same things. The result, unsurprisingly, is a lot of confusion – and that confusion certainly does matter when we’re trying to describe or implement an architecture.

To cut through all of this, and to try to introduce some certainty and precision, I’m using a fairly flat set of definitions for the levels of abstraction, and for certain key terms that are used within all layers of abstraction. (Okay, almost all layers – some terms aren’t needed in ‘higher’ levels of abstraction, as we’ll see later.) I’m well aware that others may define these items differently: these are just the definitions that I use with Enterprise Canvas, to manage consistency across the entire architecture space.

First, we have a set of definitions for levels of abstraction, from row-0 – the vision/values layer, ‘the unchanging future’ – to row-6, ‘the unchangeable past’. Each of the rows between those two layers – the Zachman rows 1-5 – represents a changeable future, each row coming closer to the moment of ‘the travelling-Now’; and every one of those rows adds something more to the architecture:

Note, though, that the inverse also applies: each ‘higher’ layer is less definite about the content of the architecture. So, for example, the moment we specify a particular technology, a particular type of implementation, we can’t be above row-4; the moment we specify any kind of content, we can’t be above row-3; row-2 describes relationships, between ‘relevant items’, but no content; and row-1 is just lists of ‘relevant items’.

The reason for the pedantry is that we model things in different ways at different levels of abstraction; and there are different dependencies, which don’t link well – or don’t make sense, rather – across different levels of abstraction. (Hence in Enterprise Canvas we model relationship within a layer by flow- and composition-relations, but between layers with realisation-relations.)

The catch is that what is nominally the same entity may recur in different forms at different levels of abstraction – the same name, the same overall ‘thing’, yet not actually the same entity or same type of ‘thing’ from an architectural perspective. To complicate this even further, it’s common to use an abstract ‘container’-entity at one level as an aggregation of a whole lot of other entities for the next level down – hence a business department is an aggregation of a cluster of facilities and activities, in both a metaphoric (abstract) and administrative (literal) sense.

Given all of that, when we talk about a ‘business function’, what exactly is it?

Uh… werll, ‘s a business-function, innit, know what I mean?

We can just about get away with that inclarity in a general business conversation; we definitely can’t get away with it in architecture. Hence the necessity for Mr Pedant…

In row-2 and above, Zachman’s distinction between What, How, Where, Who, When and Why work well enough. In lower rows, though, they can get seriously misleading – especially around ‘Who’, which gives us a very muddled confusion between the agent for a capability versus the person responsible for that capability. In row-3 and below, once we start to describe service-content in proper detail, we need a lot more precision – hence that service-content checklist in Enterprise Canvas:

The relationships between the asset-types and everything else – the orange section of the checklist – is what we covered in those asset-types posts; the relationships with skill-type and decision-type are essentially the territory covered by SCAN.

For this purpose, the key distinction is between function and capability.

A function is just a place-holder for “where something happens*. Think of it in the same way as for a mathematical function: what_i_get = do_something_with(this_thing,that_value). An alternate term might be ‘interface’: it’s a declaration of a protocol, with some indication of what might happen at that point.

Yet on its own, that function doesn’t do anything: it’s just a declaration of intent, a black-box marked ‘Magic Happens Here’. If we drill down into it, we’ll usually find similar declaration of sub-functions, perhaps chained into defined sub-processes, each with their own sub-sub-functions, and so on – but in effect it’s still just ‘Magic Happens Here’. So a ‘business-function’ is just the same thing at a higher level of abstraction or aggregation: a bigger box labelled ‘Magic Will Happen Here, Honest’.

A capability is the ability to make something happen. A ‘business-unit’ is a cluster of capabilities. Note, though, that on its own, a capability literally has no function: it’s able to do something, but on its own it doesn’t know what that ‘something’ might be. In other words, unrealised potential – a description that certainly applies to all too many real-world business-units…

In itself, a function is kind of like ‘vapour-ware’: we’ve described it, but that doesn’t necessarily mean that we know to do it, or even that we can do it even if we knew how. And on its own, a capability has no function: it needs some practical, useful means and direction to realise all that potential. So it’s only when we put the two together that we get something that could actually be useful: and that coupling of function and capability is what I term a service.

So a ‘business-service’ combines a ‘business-function’ and a ‘business-capability’ (more usually, a business-unit). Note that we can ‘unbundle’ this: that’s what allows us to restructure an organisation and yet still deliver the same business-services. That unbundling and rebundling is what makes outsourcing possible; and it’s the linkage between the functions, the capabilities and the broader more-abstract aims of the enterprise as a whole that determine whether or not that outsourcing is viable in practice. And that’s also why a solid understanding of architecture is so essential to any outsourcing arrangement – including cloud, of course.

There’s one very important complication here. When we’re dealing with machines, and even with IT, there’s a tendency to assume an inherent bundling of function and capability: hence there’s often no perceived difference between function, capability and service, because they’re so tightly bundled together that there’s no way to tell them apart. (For software, the ‘capability’ is actually delivered by the programming-language: from there on up, everything is bundled together.) But this isn’t what happens with real-people: capability and function are definitely separate – or, to put it the other way round, people are highly versatile, whereas machines and IT generally aren’t. This has huge implications for process-redesign, process-automation, disaster-recovery, load-balancing and much, much more in enterprise-architecture and the like.

The same assumed-bundling is echoed in modelling-languages such as BPMN and Archimate. It may be different now, but last time I worked with BPMN, it didn’t even have a realisation-relationship, so there was no way to distinguish between logical-model (row-3) and physical-model (row-4/5). Archimate does have realisation-relationships, but treats different aspects of the same process-implementation as different ‘layers’, which makes it all but impossible to show alternate implementations of the same process – especially for a disaster-recovery context where IT roles have to be taken over by real-people.

Once we disentangle that non-trivial problem, though, Archimate does sort-of distinguish between function and capability, in its distinction between ‘Behaviour’ versus ‘Active Structure’. Unfortunately, it’s the opposite way round to what we might expect: function in this sense here translates to the Archimate ‘Behaviour’ category, whilst capability sort-of translates to ‘Active Structure’, with Archimate’s ‘interface’-entities as the interface to capability, not service or function.

It doesn’t help that in Archimate, service and function (and business-unit, and even business-event) are all bundled together as sort-of-synonyms; but ‘business-actor’ and its virtual and physical equivalents of ‘application-component’ and ‘device’ do at least make some degree of sense. To be somewhat unkind, the structure of Archimate in general is a mess, with many of the entities in plainly the wrong places, in part because of that scrambled pseudo-layering of ‘Business’, ‘Application’ and ‘Technology’: but at least those key distinctions are there.

Anyway, hope that makes more sense, and that it gives you something that you can use in real-world enterprise-architecture practice?

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the first post in this series, we identified four distinct asset-dimensions:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas, first with an emphasis on Assets and Functions:

In the third post we looked at how those asset-dimensions also apply to Locations and Events.

In this final part of the series, we’ll look at how the asset-dimensions impact on Capabilities, and then how all of those concerns come together within services.

[As before, we'll skip the Decisions and Capabilities:skill columns for now: the asset-dimensions do apply there, but only kind-of in parallel - as implied in the service-content checklist above - rather than directly as in the other columns. A topic for another post, really.]

The asset-dimensions apply to Capabilities in a somewhat more complicated way than for those columns described earlier. What we definitely need to avoid here are those endless arguments about capability versus function versus service versus process and the like, which can get very tangled indeed. So to keep everything as simple as possible, I use a very flat definition here: a capability is the ability to do something.

[If you want to extend it a bit for the business-context, a capability is the ability to do something that would be of value to the enterprise. We'll see why such a bald definition is so useful later when we look at services.]

In practice, though, this capability ends up with three distinct components:

• action: what kind of capability, what the capability can do, to what, and with what
• actor: who or what does the work implied by the capability
• skill-level: in effect, the ability to deal with real-world variation within the context of that work [which we won't explore here]

The simplest part of this is Capabilities:action. The actions of a capability act on assets, or create changes in assets, so it’s essentially the same as for assets.

We have physical-actions, which act on, use or change physical-assets, or the physical-dimension components of composite-assets.

We have virtual-actions, which act on, use or change virtual-assets, or the virtual-dimension components of composite-assets.

We have relational-actions, which act on, reference or change relational-assets, or the relational-asset components of composite-assets.

And we have aspirational-actions, which act on, reference or change aspirational-assets, or the aspirational-asset components of composite-assets.

Sadly, the real world is rarely quite that simple…

True, if everything lines up straight away – for example, we have the right type of physical-action to work on the right type of physical-asset – it actually is that simple: metal-working capability to work on metal, and so on. Remember, though, that these are dimensions, which in the real world usually occur in fairly complicated and sometimes dynamically-changing composites – both for asset-types, and for the capabilities that would act on them. Getting everything to line up properly is often a lot harder than it looks, with plenty of scope of for inefficiency, ineffectiveness and error – especially if we don’t even know about the relational-asset and aspirational-asset aspects of some task that needs to be done. Hence why we need to use the dimensions-set as a checklist – along with other checklists, of course – to make sure that nothing has been missed.

[I won't give a detailed example here: it'd take too long, and would probably only make sense in that specific context anyway. But if you do need a full example, please let me know? - preferably with some background and description from which to build the example.]

Which brings us to Capabilities:actor – that which actually enacts the required action with the required level(s) of skill and suchlike.

In a business sense, the capability is often thought of as an ‘asset’, a kind of active asset. Yet the capability doesn’t just appear from nowhere: something – or someone – will do that work, will enact the capability. That ‘something or someone’ is the actor of the capability – which in principle implies that it’s the actor, rather than the capability itself, that is the respective ‘asset’.

Which leads us once again to the asset-dimensions, because there are crucial distinctions here about the relationship between actor and asset:

• physical-dimension: actor is embedded in physical-asset (e.g. machine)
• virtual-dimension: actor is embedded in virtual-asset (e.g. as software)
• relational-dimension: actor is linked with via relational-asset (e.g. person-to-person relationship with worker)
• aspirational-dimension: actor is linked to via aspirational-asset (e.g. person-to-purpose relationship with worker)

The key point here is that whilst machines or software are real business-assets, real-people should never be described as ‘assets’. Although the person might be the actor for the capability in terms of doing the required work, it’s the relational- and aspirational-links between the organisation and that person that are the actual assets here: and if those links are lost, the effective access to the capabilities of that actor are lost as well.

This distinction becomes critical when we need to switch back-and-forth between machine, IT and manual implementations of the same nominal capability – such as is a common requirement in prototyping and process-development, in load-balancing, and in business-continuity and disaster-recovery. It’s easy enough to see that if we don’t have the right machines or the right software on the right IT-servers, it’s going to be difficult to get a job done that needs that capability. It’s also obvious that if we don’t have the machines or the IT, then we’re going to need a real person to do the work.

But it’s not as simple as swapping out one machine and plugging in another (even though classic Taylorism assumes that that is the case) – because even if we find someone with the right capability, we’re not going to be able to access that capability without providing enough reason for that person to engage in the work. That’s why the relational (person-to-person) and aspirational (person-to-purpose) links are so important: they in effect provide that person with the reason to be there, the reason to engage their capability. That’s why we need to understand that, from the organisation’s perspective, it’s the relationship that is the key asset here – and never the person as such.

[There are some other interactions we also need to take into account here, around the Capabilities:skill component. For example, skills for high-variability (Complex and Chaotic) contexts are in most cases available only in real-people, not machines or IT: at certain levels of complexity, we're going to need a real person, whether we like it not. Yet if the relationship isn't there, the person may be present, but probably not with the required skill-level: which means that if there isn't adequate attention to relational- and aspirational-assets, the capability will be unavailable, and the service or process won't work. Which makes this very important for a service- or process-architecture. Another topic for another post, though.]

Finally, Services are what bring this all together.

To me, services are the core to the architecture: everything in the enterprise is or represents a service, and every service in an enterprise exists to serve in some way the vision of that enterprise.

[Note that the meaning of 'the enterprise' here is much larger than the organisation: see 'What is an enterprise?'. In enterprise-architecture we develop an architecture for an organisation, but about the extended-enterprise in which that organisation plays its part. Don't fall for the trap of thinking that the organisation 'is' the enterprise: they're fundamentally different.]

Which leads us to another deliberately-flat definition: a service is something that serves a need within the respective context.

So how does the service serve that need? This is where we bring together all of the above work on asset-types:

– The organisation as a whole, and each of its services at every level of decomposition from ‘business-services’ right down to individual actions and web-services and the like, serve the enterprise by making appropriate changes (CRUD etc) to assets on behalf of other services.

– Assets may be of many different forms or types (such as indicated by the asset-dimensions described here), and, within a service, may be changed from one form or type to another as required.

– Assets are located at, and may be be moved between, specific locations.

– Assets are acted on in response to events.

– Assets are acted on (CRUD etc) as specified by functions and their protocols, service-level agreements, contracts etc.

– The ability to act on assets is embodied by capabilities.

– A service brings together the structure of the function and the capabilities to enact that function, to act on specific assets at specific locations in response to specific events. [Also in accordance with specific decision-types at specific skill-levels, but that's that other topic again.]

– A process is a kind of pathway – predefined, free-form, or any combination – that links services together in a sequence that delivers required overall changes to assets or to asset-status or ownership or whatever.

And the asset-dimensions weave across all of this, applying to the assets themselves, and to locations, events, functions, capabilities, services and processes, in all of the ways that we’ve explored above.

That’s it, really.

Comments, anyone?

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the first post in this series, we looked at the concept of four distinct asset-dimensions:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas:

And we looked at how those asset-dimensions apply in practice to for the first two columns of that checklist: Assets, and Functions.

Moving on, we now apply the same logic to locations: every location, of any type, exists within a schema that incorporates any combination of the asset-type dimensions.

[As in shown the service-content checklist above, there's a fifth dimension - time - that applies primarily to locations, though potentially to specific types of events as well. The key point is that although we do treat it as a dimension here, time is not an asset in the same sense as for the other dimensions: we know this because we can't 'own' time, in any sense, and we can't create it, update it or delete it. (We can waste our own time, of course, and sometimes for or with others as well - but that's not the same as deleting time itself! )]

Obviously, we have physical-locations – locations with physical-dimension schemas – with which we would typically associate physical-assets.

We have virtual-locations, with which we would typically associate virtual and/or physical-assets. An IP-address or URL is a classic-example of a virtual-location. A street-address or room-number is actually a composite, a virtual-asset from an imaginary-schema of street-names or floor-numbers or the like, that also references a parallel schema for physical-locations. Much the same for the pairing of a network-address and rack-location for a data-server, for example.

We have relational-locations, within relational-schemas, within which we find relational-assets: the dreaded org-chart is perhaps the archetypal example of this. (Note, by the way, that it’s the relationship between people that is the asset in this context - never the person!)

[I'll admit I'm not quite sure how best to describe, within this taxonomy, the implicit relationship indicated by an 'owner'-responsibility such as process-owner, project-owner, data-owner etc. There's no person-to-person connection there, so it's probably not a relational-asset; in fact it seems to point strongly towards it being an aspirational-asset, because it's clearly person-to-abstract, even where it's a physical object that's 'owned'. The fact that such 'owner'-responsibilities only work well when there's a personal commitment involved again points to a variant on aspirational-asset. But I'd appreciate any comments you might have on this, anyway.]

Then we have aspirational-locations, within aspirational-schemas, within which we find aspirational-assets. This one’s perhaps a bit of a mindstretch too, but the most obvious example is brand-mapping, where brands are mapped in relation to each other, and demographics mapped to brands.

And, of course, we have temporal-locations, within various forms of timescales – some of which may be time-itself, others as proxies for time, such as video-framenumbers and the like. Time isn’t itself an asset, so we can’t place ‘time-assets’ within time: but we can place other assets, and other locations in other schemas, and so on, in relation to time.

As with functions and assets themselves, locations often exist within composite multiple-dimension schemas, which may intersect with other multiple- or variable-dimension schemas: it gets complicated… But again, this taxonomy does help to disentangle all the threads, which can become highly relevant as we move assets or functions or whatever between or even within different location-schemas.

By contrast, events are relatively straightforward.

We have physical-events: mechanical triggers, events in the real-world, and so on.

We have virtual-events: a signal, a numerical-value, a clock-event.

We have relational-events: something that marks the start of a beautiful relationship, we might say, or an unfortunate divorce – in a business sense, in this case, but the metaphor still holds for events that impact or are triggered by changes in relational-assets.

We have aspirational-events: anything that affects a brand, for example.

And we have composite-events, of course. “A man walks into a bar” might be the beginning of a joke, but in business terms it’s a composite of a physical event, probably a virtual-event ‘door open’ signal, possibly a relational-event, and quite likely a select-a-beer-brand aspirational-event too.

We can also see how the various asset-dimension threads weave through sequences of events, such as in what might happen after “a man walks into a bar”:

• there’s the change-of-status physical-event of no more beer in the vending-machine, which is…
• indicated by the ‘dispenser-empty’ virtual-event signal from the vending-machine, which may lead to…
• a physical-event of an angry kick at the machine from the would-be customer; thence to…
• an end-relation event with the bar-keeper, and…
• the aspirational-event of the signal of a potential beginning of an anti-client aspirational-link ‘anti-asset’ between the now-ex-customer and the bar

Disentangling all of those threads is an interesting exercise for a service-designer or solution-architect, one that really is made a lot easier through this type of taxonomy – though probably not very interesting at all to our ex-customer, who still just wants his drink!

Again, stop there for now: in the final part of this series we’ll explore how the same principle applies to capabilities, and thence to services – to me, the core of the architecture.

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the previous post in this series, we looked at the concept of four distinct asset-dimensions: Physical, Virtual, Relational and Aspirational.

The same dimensions carry right the way through the entire architecture. We can see this if we map it as per the ‘service-content checklist’ from Enterprise Canvas, which can also be understood as a much-extended adaptation of a single row from the Zachman taxonomy:

The asset-dimensions are kind of orthogonal to the dimensions represented by the Zachman-style ‘columns’. For this we’ll keep the emphasis on the columns to which these dimensions map directly: Assets, Functions, Locations, ‘action’ and implicit ‘actor’ component of Capabilities, and Events.

[The mapping comes out in a related but somewhat different way in the Decisions/Reasons column and the 'skill-level' component of the Capability column, which I won't go into here.]

On assets themselves, we’ve already covered the fundamentals in that bullet-list from the previous post:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

We need to handle and manage assets in accordance with the respective dimensions: management in terms of storage, security, access, natural-lifecycle, refresh, migration and so on.

It’s all fairly straightforward territory for enterprise-architects; the only real complication is that many entities are or represent composites of dimensions, which means that they need to be handled and managed in accordance with the rules for all of the respective dimensions. A printed book is one simple example:

• book as physical-asset (object): physical storage, ownership-title, inventory-control, access-control, instance-identification, maintenance, repair, physical disposal etc
• book as virtual-asset (information): data-storage, copyright, copy-control, access-control, version-control, validity, review, renewal, metadata, indexing, withdrawal, secure-deletion etc

Just to make it even more fun, the combinations of those composites can change, too, in response to events, the CRUD actions in functions, sometimes in different locations, and even through natural deterioration or depreciation within the lifecycle.

[There's a lot more to explore about the detail of this, but I'll do that in another post: for here I want to concentrate on the way the same principles go across the whole architecture.]

Hence, yes, can be a bit mind-bending at times: but taking a dimensions-approach – using the dimensions as ‘lenses’, if you like – really does help.

In the broadest sense, functions act on assets: they describe the activities that apply CRUD-type changes and the like to assets. Hence, again, we have different dimensions of functions – actually the same dimensions – that act on those respective dimensions of the assets.

We have functions that create, use, change and destroy physical objects, or physical attributes of objects.

We have functions that create, read, update and delete information and other virtual-assets or virtual attributes of entities.

We have functions that help people create relational-links with each other; remember existing relational-links; refresh those links, or provide conditions under which a link can sort-of be transferred to another person, such as in a shop, or an escalation at a call-centre; and although relational-links in effect delete themselves as soon as either party drops it, we have functions which can either assist that to happen, or to dissuade it from happening,

And we have functions that help people create aspirational-links – for example, to connect with a brand. We have many, many functions – most advertising, for example – that help people refresh and renew and reconnect with their aspirations in context of a brand or some other aspirational-link ‘target’: in other words, ‘read’ an aspirational-asset, the aspirational-link itself. We have a suite of functions to get people to ‘update’ the aspirational-asset link – for example, to get someone to change loyalty from a competitor’s brand, or to support ‘upsell’ to a more upmarket brand of our own. And for a few special cases, we have functions that aim intentionally to destroy an aspirational-asset – such as when a brand comes to the end of its life, yet we have no replacement, and we don’t want to upset existing customers of that brand.

And, as before, there will be functions that interweave any or all of these dimensions at the same time. But it’s useful to be able to tease all of the threads apart where necessary – not least because a re-implementation of a function in a different form could lose or gain key aspects of dimensions that we might otherwise not realise were there in the previous form.

Thinking of relational-links and aspirational-links as assets, in exactly the same sense as for physical- and virtual-assets, can sometimes be a bit of a mindstretch: but because it allows us to address all asset-types – and what we do to and with all types of assets – in exactly the same overall way, it really does simplify the architecture-frame a lot. And as we’ll see in a moment, it also brings a new clarity and new simplicity to service-oriented architectures, right up to a whole-enterprise scope.

Stop there for now: in the next post we’ll look at how this applies to locations and events.

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

[I know I usually write too long, so as a kind of trial-run, I'm splitting up this original long-post into four smaller ones: please let me know if this works better for you? Thanks!]

This one is a sort-of follow-up to the earlier post ‘Charisma, connection and brand‘, which looked at two lesser-understood asset-types, relational and aspirational. It’s also a pick-up on the article pointed to by the following Tweet, with my explanatory comment attached:

• SAlhir: Brand vs. product: what really drives reputation? http://bit.ly/sLf4hs >actually, she says, it’s neither: it’s delivery on promise that matters most – agree.

I usually define an asset as “anything that the organisation uses and/or is of value to the organisation, and for which it is responsible”. In essence, if we can do some form of a CRUD (Create, Read, Update, Delete) to it, and the organisation ‘owns’ it in a stewardship sense at least, then it’s an organisational asset – and hence relevant to the architecture. So this is deliberately broader than the usual definitions of ‘asset’, to enable the architecture to cover the full range of assets, both tangible and intangible.

Overall, there are four different types, or more precisely, four distinct dimensions of assets:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

So any asset may be or represent not just one of these dimensions – i.e. as an ‘asset-type’ in the same sense – but also a composite of any combination of these dimensions, a combination which may well change over time for the same nominal entity. Hence I often map this in tetradian form, the inner axes of a tetrahedron:

Most business looks only at the physical and/or virtual dimensions, because, being transferrable, that also represents something that can be sold. But it’s the interactions of all of those dimensions that makes it all happen. Consider this in terms of the market-cycle:

Almost by definition, if we’re dealing with business-type Operations, the focus is mainly on saleable, exchangeable physical and/or virtual. Yet even there, whenever real-people are involved, it’s going to imply some aspects of relational and/or aspirational.

In the Tactics space – the start and end of the core sales-process, for example – it’s definitely going to involve relational-links with real-people, and aspirational-links around desires.

Further out, into Strategy, most of the core concerns will revolve around the aspirational-links that underpin reputation and trust.

And if we don’t manage all of those less-tangible dimensions properly, and manage all of the completions properly, the cycle is going to break – yet we probably won’t be able to see or understand why it’s broken. Which means, very quickly, a dead business. Hence this isn’t some trivial ‘academic exercise’: this is absolutely fundamental to all forms of business-architecture and the like. Yet many of the nominal enterprise-architects or business-architects I meet don’t seem to know about any of this: they just point at the financials, for example, and think that that’s the answer to everything. Which I must admit I do find worrying, to say the least…

[Notice that, unlike many conventional models, there isn't a distinct category here for financial-assets. This is not an error, because in this schema we don't treat money any differently from any other asset. A financial-asset is, in effect, a composite of virtual-asset (the information carried by a monetary value, which in itself is usually stable) plus aspirational-asset (the belief in the value of that asset, which can be highly variable), plus also physical-asset if the monetary-value is expressed in the form of cash or some other physical entity.]

The point is that each of these dimensions indicates different requirements for handling: physical cash needs to be handled as a physical-asset, whereas a data-record of the same monetary-value generally doesn’t (other than in terms of its storage or transport within a disk-drive or network, which is a different physical-asset). They’re also worked on in different ways in different functions and by different capabilities, have different event-types, have their own distinct location-schemas and so on – and yet they all interweave with each other in practice in ways that can be mind-bogglingly complex.

Yet architecturally speaking, if we allow ourselves to become confused about what type of asset we’re dealing with, or which dimensions we’re dealing with in each context, we’re going to get into serious trouble. This is especially true if we build a business-model on incorrect assumptions about asset-types – as the media-industries discovered to their cost in the shift, for delivery of music and film and text, from physical/virtual-bundling (a music-manuscript or disk, a cinema-seat, a physical book) to virtual-only (digital data).

So as I understand it, it’s part of the architect’s job to sort it all out, and prevent it from twisting itself into an unmanageable tangle. Hence this post, and others like it.

In the next post, we’ll explore how this same principle of ‘asset-dimensions’ echoes across the entire scope of the architecture.

How do we make sense of brands and the like? How do brands actually work? And how does that connect with charisma, with ‘self-as-brand’?

The starting point for this one was a re-tweet from narrative-knowledge guru Shawn Callahan:

• unorder: RT @thaler: Yesterday, in a program for Brazilian professional communicators, a participant defined charisma as the ability to connect with others.

“Connect with“? – not quite… And that ‘not-quite’ also helps to clarify the distinction between relational-assets and aspirational-assets in an enterprise-architecture, and thence to the role of brands – so it’s worth doing a brief exploration to explain that point.

From an enterprise-architecture perspective we would think of this in terms of assets: something that is valued, and for which we are responsible. The moment we mention ‘ability to do something’ – such as “ability to connect with others” – we’re also talking about capabilities, but we can come back to that later: we’ll focus on the ‘assets’ aspect for now.

Recall that there are not so much four different types of asset, as four distinct dimensions of assets:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract – between, non-tangible, non-transferrable

We might talk about a ‘physical asset’, but in practice most real-world assets embody some combination of these dimensions. A printed book, for example is both a physical-asset (the book itself) and a virtual-asset (the information in the book) and possibly also represents an aspirational-asset (the feeling of connection with the author, perhaps, or the characters in the story).

The more we have of one dimension, the less we can have of of the others – hence why I usually depict this in a tetradian layout, the internal axes of a tetrahedron:

The point is that each dimension has to be managed in different ways: for example, physical-assets need inventory and storage, virtual-assets don’t (much). But it’s also extremely important not to mix them up: for example, the chaos around so-called ‘intellectual property’ exists because people are trying to control virtual-assets as if they’re physical-assets, even though they’re fundamentally different.

Which brings us back to the key distinction between relational-assets and aspirational-assets:

• relational: sense of (two-way) connection with another (real) person
• an aspirational: sense of (one-way) connection to an (imagined) person or ideal

(Note the parallel with the distinction between physical versus virtual: one is real, the other is abstract.)

So to bring this back to that initial tweet, a more realistic definition for charisma is not so much ‘the ability to connect with others”, as “charisma is the ability to enable others to connect to self“. That distinction between ‘to‘ rather than ‘with‘ may seem subtle, but is extremely important in practice.

Yes, charisma can create relational-assets – a person-to-person connection – but it’s somewhat secondary, and, in a mass-market context, relatively rare. First and foremost, charisma creates aspirational-assets – a sense of trust and of desire (in a wide variety of types of ‘desire’…).

Another key distinction here:

• a relational-asset is held by both parties in the relationship – both parties are aware that the link exists
• an aspirational-asset is held by one party, the ‘source’ – the ‘target’ may not even know that the link exists

Both types of link are a ‘between’ asset: if either party drops the link, the asset ceases to exist.

[CRM [Customer Relationship Management] systems often fail to take this fact into account. If the laws on stalking were applied to the business-context, many companies would be in deep trouble indeed… and as it is, misused-CRM is a great way to turn former clients into infuriated anti-clients…]

For relational-assets, where both parties know that the link exists, both parties (should) also know when the link fades to nothing. But for aspirational-assets, where the ‘target’ may not even know about the link, things can get very messy if we’re not careful…

Aspirational-assets are about trust, and desire. Often it is, in an all too literal sense, a fantasy: “selling the sizzle”, to use the old advertising-slogan. So when that trust or desire is broken from the ‘target’-end of the asset-link, watch out – because it’s literally betraying someone’s fantasy.

Unsurprisingly, that fact is extremely important in a commercial context, not least because relational-assets – direct person-to-person links – don’t scale. For example, I can have strong personal links with the staff in my local grocery-store; but because relational-links aren’t transferrable as such, it’s hard to carry that sense of connection through to another branch of the same store in a different town. So one key role of a brand is to bridge the gap, and to create and maintain overall desire, overall trust, that then links back into the person-to-person connections that drive all personal business.

[Each company-representative then needs to embody what the brand represents, which is why vision and values are so important. Yet they also need to do this without clients or anyone else getting too much confused between fantasy - aspiration - and reality - relation. This can at times be a delicate juggling-act...]

Charisma sits in an uncomfortable and potentially-dangerous middle ground, halfway between relational-link and aspirational-link. The ‘target’ is a real person, hence also gives the impression that a relational-link is available – or rather, a fantasy-based relational-link, driven by trust and desire. (Again, remember that ‘desire’ has a very wide range of meanings here…) To use Brown, Hagel and Davison’s term, it projects ‘the power of pull‘: but we need to be careful as to exactly what we’re ‘pulling’, because of that risk of perceived ‘betrayal’ of the fantasy.

There’s no doubt that charisma is extremely important in business. Aspirational-links are actually much easier to transfer than relational-links, because the driver for the link is not so much the person as the implied-trust or implied-values behind the the desire: so as long as the trust and values are maintained, the link can be transferred to another aspirational-asset. In that sense, the charismatic salesman intentionally assigns his perceived authority to the brand as a whole – which then means that the trust can be carried through to any other location of the brand. In a business-context, that’s what we want to happen.

But it can go spectacularly wrong if anyone starts playing irresponsible, or isn’t aware of the risks of charisma. Changing a brand-image might seem trivial to the brand-owner, for example – but it’s not trivial at all to those whose sense of trust is attached to that brand, and who will literally feel betrayed by any inappropriate change. Actors and public figures have even worse problems: they will often be attacked for ‘betraying’ that which they are believed to represent (the aspirational-link), without much if any acknowledgement of who they actually are (the relational-link, which probably doesn’t exist anyway). In a business-context, this is a common root-cause of many harassment-lawsuits, where the whole thing is grounded in a ‘betrayed’ fantasy – mistaken beliefs and misunderstandings arising from careless charisma.

So the crucial points from all of the above are these:

• a relational link – a relational-asset – is a two-way connection with others, grounded in reality
• an aspirational link – an aspirational-asset – is a one-way connection to an often-abstract ideal, grounded in fantasy
• charisma creates aspirational links that can easily be mistaken by the ‘source’ for relational links, or an offer of a precursor to a relational-link, yet with a high emotional (fantasy-driven) charge
• charisma can be dangerous in business (and elsewhere) because it creates implied responsibilities on the ‘target’, of which the target (or, for a brand, the owners of that brand) may not even be aware

I hope that makes sense, anyway?

Comments / suggestions etc requested, of course.

Continuing on the theme of the ‘This’ game for engaging people in enterprise-architecture exploration and development, as described in the two previous posts ‘This: an exploratory game for service-oriented EA‘ and ‘More on the ‘This’ game for enterprise-architecture‘.

The final note in that last post was about EA toolsets, and the need for appropriate support for the output of the game – and perhaps even the game itself – within the toolset. And that point actually brings together a whole stream of different threads that I’ve been tracking for some years here: enterprise as story, toolsets and their user-interfaces, metamodels and architecture-repositories, whole-enterprise scope, notation-agnostic modelling and a whole lot more.

There are (at least) two fundamentally-different viewpoints on enterprise-architecture: as structure, and as narrative. Most current EA toolsets focus only on the ‘structure’ side, and do so variously well; but there’s almost nothing to help us tackle the narrative side of the story, and even less to help us bring those two sides together. Which, in practice, is a serious problem, because story is actually what engages people in the architecture…

In short, we need our EA toolsets to help us bring a better balance between structure and story in the architecture.

To put into context, consider a few scenarios:

Scenario 1: The team reckon they’ve done well with their work on the new business-model, all laid out on the wall on a Business Model Canvas. But how are they going to implement it? Will it actually work in real-world practice? What are the pitfalls and hidden ‘gotchas’ that could cripple the new model’s viability?

To address these concerns, they set up for a game of ‘This’. One of the architecture-team leads, Maria, takes on the role of modeller, using an application on her iPad, the screen hooked up to a data-projector on the wall, but also coupled to the other team-members’ tablets and laptops. (The screen will also show the current manually-selected or randomly-selected ‘This’ question-card.) She also sets up a conference-microphone to capture an audio-channel.

Maria uses the camera on her iPad to take a snapshot of the current model on Business Model Canvas, and pulls the photo into the application. There, she marks up the graphic with zones and links, each of which – behind the scenes – is also noted as a Service or flow-relation in the underlying Enterprise Canvas.

The team choose an arbitrary starting-point, and build outward from there, as per the guidelines for the game. Instead of using the rather sparse Enterprise Canvas notation, Maria pulls up more-descriptive icons and images from a palette – trucks, parcels, people, machines, money, whatever – and places them on the screen as the current ‘This’; behind the scenes, though, the application stores the information in Enterprise Canvas notation. The audio-channel is attached both to the overall model, and to the entity for the current ‘This’; later, the audio-track can be played back, highlighting in matching sequence each of the items described in the model.

During the game, the discussion indicates that some changes will need to be made to the initial business-model. Maria uses the underlying Enterprise Canvas to recreate a new version of that model, in Business Model Canvas layout.

Scenario 2: Two days after the business-model meeting, Maria re-checks some of the people-connections captured in the Enterprise Canvas model during the ‘This’-session, for the purpose of building a list of stakeholders for one of the side-projects arising from the new business-model. She notices that she didn’t capture one person’s name, the process-owner for a related business-process – she remembers that his first-name was Steve, but not the surname. She clicks on the respective icon, and plays back the audio-channel that was captured at the time: Steve’s surname – Cartwright – is now clear, and she types the full name into the model. As she does so, a link to the company’s HRM-system brings up further contact-details for Steve, including several photographs. She selects one photograph, and sets it as the surface-view for that icon in Enterprise Canvas.

Later that day, Arjun reviews the business-model, using the zooming model-display. In the drill-down into the ‘Key Activities’ section of the Business Model Canvas, Steve’s photograph now appears in place of the previous abstract ‘person’-icon. Clicking on the photograph, Arjun sees all of the information on Steve’s role in the proposed business-model, and can also play back the captured audio both from that meeting, and another discussion that took place earlier in the day.

Scenario 3: Juan has been tasked with developing the IT-architecture for the e-commerce component of the new business-model. His business-unit has standardised on Archimate notation for all IT-architecture models. He opens the Enterprise Canvas model, and, using it as an active backplane, identifies Canvas entities that would map directly to Archimate equivalents: Canvas ‘Service’ to Archimate ‘Business Service’, ‘Application Service’ or ‘Infrastructure Service’, Canvas ‘Exchange’ to Archimate ‘Business Interface’, ‘Business Object’ and so on. He explores the additional detail recorded in the ‘This’ session to identify Archimate ‘Business Function’, ‘Business Event’, ‘Business Actor’ and the like. As he adds these entities to the Archimate model, they’re also attached to the Enterprise Canvas model in the backplane via composition-relation links into the respective Canvas ‘Service’, ‘Exchange’ entities and flow-relations.

Scenario 4: The following morning, one of the business-model team, Vasily, remembers that more detail was needed about warehouse configuration, for potential locations – both physical and logical – for new sensors that will be needed for logistics-tracking in the new business-model. He goes down to the warehouse, takes his smartphone out of his pocket, calls up the Enterprise Canvas model, selects the ‘New Sensors’ entity, and starts a new game of ‘This’ with that entity as its starting-point. He manually selects the question ‘What are the locations of This?’, and attaches to that card the photos that he takes, direct from the phone’s camera application.

In the Enterprise Canvas, Juan has already been identified as one of the people responsible for the ‘New Sensors’ component of the business-model. He receives a notification that new items have been added to the Enterprise Canvas; he opens that part of the model, reviews it, and adds new entities to his Archimate model, which are automatically linked back to the Enterprise Canvas.

So there we are.

Plenty of other scenarios we could add, too: about a meetup in a cafe, about people exchanging ideas in the elevator, about how this information might be used by a project-manager and her team, by a process-designer to gather feedback from the factory floor, by managers using a dashboard in high-level resource-planning, and so on. But that’s detail enough for now: four interlinked scenarios, all working on the same models in different ways, with different software-applications, on different hardware-platforms, for different purposes, all supporting each other.

So is that what actually happens in practice at present? Is that how we do our everyday architecture work?

Uh, no…

In which case, why not? Seriously: why not?

On the surface, it’s all straightforward enough: the work itself is essentially what architects and others do already. The only trouble is that it’s well-nigh impossible to do most of this in any existing EA toolset: most tools now should be able to cope with the Archimate-specific part of the modelling, but that’s about it – and they probably wouldn’t be able to link any of that model to anything else. As for the rest? – well, forget it, guys, you’re outta luck…

Ouch…

It should all be seamless, pretty much exactly as described in those scenarios above. In practice, it isn’t. In fact, the way we have to do it at present is a frustration-filled, kludge-ridden, error-prone mess of manual translations, bits of paper, scribbled notes, anguished phone-calls and worse. Hence no surprise that it often doesn’t work very well – if at all.

Yet there really is no need for it be that way, and no reason for it to be that way either.

To which the only remaining question is: Why? Why is it this way?

To me at least, it seems that the only real reason is that the current EA-toolset market is crippled by its own lack of imagination – and that’s all that’s holding us back.

Okay, yes, sure, there’s a sizeable amount of development-work required. But seriously, none of it would be hard to an experienced developer, someone who’s familiar with the current generation of development tools. Everything I’ve described above is already available in various apps and elsewhere – there’s nothing new as such in any of it. The only reason I haven’t done it myself is that I’m way out of date on that whole area, and it would take me months or years to do what a current developer would know how to do in days.

Have a wander around this blog: I’ve already done most of the conceptual work that’s needed for this, on toolset-ecosystem, overall requirements, metamodels, user-interface, underlying notation-agnostic structures and so on. For example, take a look at these posts:

• The toolset-ecosystem
• More on that enterprise-architecture ‘help-needed’
• EA metamodel: two questions
• EA metamodel – the big picture (and the small picture too)
• Simplifying the Enterprise Canvas
• Using Enterprise Canvas as a service-viability checklist

So I’m serious about this: it’s all there – a huge market, just waiting for the first person with the nous to pick this up and run with it.

Is anyone up to this challenge? And if not, what do we enterprise-architects do about it?

Comments/suggestions, anyone?

A great session yesterday with Kevin Smith, brainstorming ideas for the ‘This’ game for service-oriented enterprise-architecture.

I’d originally envisaged ‘This‘ as a kind of card-game, with questions and supporting-information printed on playing-cards:

There would be that small set of mandatory ‘setting-the-scene’ questions – perhaps printed on cards with a different-colour back – but all of the others would be in a card-deck that could be shuffled into random order.

(Note, though, that playing-cards would be just one form of implementation: there are plenty of other ways to implement the same idea, some of which could make great use of current consumer-technology. More on that later.)

In an early stage of the game, we would ‘Start Anywhere’, picking any appropriate point (or item, rather) as our ‘This’ with which to start. Once we’d done the ‘What is This?’ questions, we would pick random cards for new questions, add any new items to the model as suggested, and then use any ‘move’-options from the questions to move to another item that we’ve just created, to use it as our new focus, our new ‘This’.

At some point we would have populated enough of the model to see the larger picture start to emerge. From there we can go back and start to populate the detail of the model in a more systematic way, using the question-cards in structured sequences rather than solely at random.

The current text of the questions – ‘What is This? – tends towards an ‘as-is’ model. It might be better to reframe the questions for a ‘to-be’ model, creating ideas about the future rather than the present or past; the catch is that in English it leads to an awkward structure - ’What would This be?’ - in which we lose that useful reinforcement-emphasis of ‘This’ at the end of each question. Probably simpler just to use an implied future-tense for the whole of the game – ‘In the future, What is This?’ – and keep the text as it is.

One theme that came out of that brainstorming-session was a literal gamification: if you’re going to call it a game, said Kevin, why not make it into an actual game? For example, award points for asking questions; award even more points for answers. Perhaps different numbers of points for different types of answers: some for an answer that adds detail about the current item, more points for answer that adds further items to the model.

We could use multiple sets of question-cards – each participant with their own set of cards, perhaps. That would introduce even more serendipitous randomness into the exploratory stage, and perhaps further opportunities for gamification.

The game can be a distributed game, with people in different locations, and also at different times. Imagine a bunch of executives, each with their iPads or whatever, all accessing a shared screen, showing the action, sharing the annotations, exploring multiple perspectives and multiple views, with a facilitator updating the shared screen (and the model beneath it) in real-time. The ‘card-game’ notion helps keep the focus on one item at a time, whilst allowing a lot of individual freedom and space for ‘positioning’ within the game. Each interaction also feeds towards the overall model.

We can also imagine this as a personal game, hosted on a smartphone or other handheld. The device screen shows just the current question-card, with space to enter responses – which, depending on device-capability, could include audio-, photo- or video-capture as well as text or simple sketch-graphics.

(Conceptually at least, this ‘personal game’ should be quite straightforward to implement as an app, because most of it is little more than access to hosted-backend, display a card with predefined text and graphics, and support appropriate information-capture – all of which is supported as standard in most app-APIs. Access to the backend-host doesn’t even need to be in real-time: it can be done by batch-download, local-store, and then batch-update with feedback to resolve any merge-issues. There are some complications in displaying the Enterprise Canvas model being created in the background, but even those should not be hard to resolve, as it doesn’t involve any actual real-time drawing of links between entities: they’re generated from the responses to questions, not by direct user-interaction.)

In modelling with This, (almost) every link implies a flow – because that’s one of the key modelling-constraints in Enterprise Canvas. If it isn’t a change in layer-of-abstraction – a realisation-relation – or a decomposition to another level of granularity – a composition-relation – then it must be a flow-relation: those are the only three choices we have. And a flow-relation always implies that there’s something exchanged: so what is that Exchange? What are its content, structure, protocols, driving events, values, trust-concerns, and so on? There’s a lot of information there that we need to capture, explore, discuss… Unlike the association-relation in so many other notations, we can’t get away with saying, “Well, they’re just sort-of-related, aren’t they?” – we need to explain what that relationship between those entities is, what it entails, what it brings to the overall enterprise. A useful challenge in itself.

The more I explore this idea, the more I see it’ll need a new kind of EA toolset – one that supports a much better balance between structure and narrative, a different way of engaging everyone in the overall architecture. More on that in another post, though.

Any comments so far? Any ideas of your own on This?

For a while now I’ve been brewing a kind of ‘exploratory game’ for enterprise-architecture, with the somewhat uninventive title of This.

It’s based on the same service-oriented view of the enterprise as Enterprise Canvas – in fact we would typically use the game as part of modelling some aspect of the enterprise with Enterprise Canvas, usually with the ‘simplified notation‘. We can also use it in conjunction with the Enterprise Canvas service-viability assessment described in an earlier post.

[To keep things short, I'll assume that you're already familiar with the models and mappings I've used in my work, particularly Enterprise Canvas and its layers of abstraction ('extended-Zachman layering'), service-content checklist ('single-row extended-Zachman') and mapping between Business Model Canvas and the Enterprise Canvas core; the market-model / market-cycle; and the Five Element model, particularly its variants that focus on service-flow content. If not, all but the last of these - and their graphics - are described in that post on the service-viability checklist; for the service-flow content-model, see the posts 'Not quite VPEC-T' and 'More on 'Not-quite VPEC-T''.]

The aim of the game is simply to elicit whatever information we need about the context, and model it as required as we go.

We elicit that information by asking questions about the current item in focus, which is always called ‘This‘. Some of the questions enquire for more about This; others ask us about how This relates to other items; and some questions invite us to move the focus to another item, a new This.

In most cases, the questions can be asked in almost any order: I envisaged them being printed on a deck of cards, each question accompanied by an explanatory diagram or other descriptive information. We could pick the cards at random – “choose a card, any card!” – or work in a more structured way: it’s up to us.

We use much the same ‘Start Anywhere’ principle to choose where to start. Since in Enterprise Canvas we assert that everything is or represents a service, and everything is connected in some way to everything else, it actually doesn’t matter where we start: we can pick any item that seems appropriate, anywhere within the enterprise, at any level of granularity or abstraction. It can be a Service, a Product (proto-Service) or a Flow (Service as movement) or whatever – it doesn’t matter.

So, pick an item; any item. Think of it for now as a service, or representing a service. In that basic Enterprise Canvas notation, place it on the table, scribble it on the back of the napkin, scrawl it on the wall, or draw it on the screen:

For now, this is our current focus, our current centre of attention – our ‘This‘. And until we explicitly move our attention elsewhere, all of our questions relate to this This.

For any question that points to a ‘Who’, optionally create a new entity to represent that person or group, again described as a service. Optionally, move the focus to this new entity, as the new ‘This’.

A few scene-setting questions we need to ask first:

• What is This? - give it a name (or just call it This)
• What type of description will we use for This? – applicable layer of abstraction (selected layer constrains some of the questions and the details within the questions)
• What categories apply to This? – if categorisable, those categories may point to other questions about This

All of the other questions can apply in almost any order, though as we’ll see, some of them tend to cluster into groups that make more sense together.

Any question that includes a [*], [^] or [v] marker allows us the option to change our current ‘This’ to an item pointed to by the question. (An [*] marker indicates that any new item would usually be at the same level of abstraction; an [^] marker for a new item one or more levels up; and a [v] marker for one or more levels down.) That other item now becomes our new current ‘This’; typically we would re-start with the initial scene-setting questions on this new ‘This’, and continue onward from there.

Some questions about value, and relation to enterprise vision and values:

• What is the purpose of This? [^] (what drives This?) – vision and values
• What is the larger picture for This? [^] - abstraction
• What is the business-meaning of This? - where it fits in the big-picture
• What is done by This? [*] - value-creation
• What is the value of This? [*] - value-proposition
• Who would value This? [*] - value-connection to customer-segments, also connection to suppliers, engaged non-customers

(From these we might place Vision and Value entities onto the workspace, or sketch out a model of the overall enterprise and market.)

Another set of questions help to link a business-model from Business Model Canvas into this part of the architecture, via the cross-map between Business Model Canvas and the core Enterprise Canvas partitioning:

• Who or what uses This? [*] - service-consumers
• What connects with This? [*] - preliminary view of relationships/flows - expand with Supplier, Customer, Partner, flows etc
• Who or what supplies to This? [*] - service-providers, suppliers
• What delivers This? [*] - customer-channels, also supplier-channels
• Who or what works with This? [*] - partners
• What is used in This? [*] - key-resources – include asset-types as per service-content checklist
• What happens in This? – key-activities
• What are the processes within This? - use BPMN etc (an alternate way of asking about activities)
• How do we talk with others about This? - customer/supplier relations
• What are the costs of This? - cost-structure (what kinds of cost)
• What are the returns from This? - revenue streams (what kinds of value-returned?)

A set of questions based on the service-content checklist:

• What items are used or referenced in This? - assets in service-content checklist
• What are the functions of This? - functions in service-content checklist - links to asset-types used or referenced
• What are the places of This? - locations in service-content checklist - includes asset-types for schemas (plus location in Time as abstract)
• What skills and capabilities are needed for This? - capabilities in service-content checklist - includes asset-type, skill-level; also note skill-level limits to machine, IT, human
• What events drive This? - events in service-content checklist – includes asset-type
• What decisions guide This? - decisions/reasons in service-content checklist - includes skill-/complexity-level
• What standards, laws and regulations apply to This? – externally-imposed rules
• What principles and business-rules apply to This? – internally-imposed rules

Some questions about flows between ‘This’ and other items:

• What’s the transaction-lifecycle for This? - apply Market Cycle sequence
• What are the flows for This? - apply (original) VPEC-T for flow

(In Enterprise Canvas, we might model these as flow-relationships between Services, optionally with Exchange entities along the flow-relation.)

Some related questions on service-metrics and quality:

• How do we measure This? - metrics, service-level agreements
• What information do we need about This? - qualitatives, often in parallel with performance-metrics; also coordination-info, event-info
• What is success for This? - linkage between metrics and values
• How is quality assured for This? [*] - linkage to validation-services (create awareness, enhance capability, apply in practice, verify)

Some questions that link to the ‘guidance services’ in Enterprise Canvas:

• How do we manage This? [*] - links to direction-services (mainly ‘Run the Business’)
• Who or what defines strategy for This? [*] - links to direction-services (mainly ’Change the Business’ or ‘Develop the Business’)
• How do we change This? [*] - links to direction- and coordination-services (mainly ‘Change the Business’ in each)
• What is the change-strategy for This? – links to coordination-services for change-strategy (mainly ‘Develop the Business’)
• Who or what coordinates This? [*] - links to run-time coordination-services (‘Run the Business’)

Two questions address the Investor and Beneficiary relationships modelled in Enterprise Canvas:

• Who invests in This? [*] - investors (what forms of value?) - always crosslink with Beneficiaries to check balance
• Who benefits from This? [*] - beneficiaries (what forms of value?) - always crosslink with Investors to check balance

Some questions about responsibilities and stakeholders:

• What leadership is needed for This? - leadership as per Five-Element (5+5+1)
• Who is responsible for This? [*] - apply RACI
• Who knows about This? [*] - designer, developer, archivist, documentation-keeper, subject-matter expert (SME), supernode etc
• Who are the stakeholders for This? [* ]- extend out into the organisation, and further outward to the market and extended-enterprise
• Who might be anti-clients for This? [*] - ‘inherent anti-clients’ (e.g. environmentalists vs oil-industry), ‘betrayal anti-clients’ (identify risks that might lead to sense of ‘betrayal’)

Some questions about composition, decomposition and implementation:

• What is another variant of This? [*] - info about siblings or alternate paths
• What are the components of This? [*] - decomposition into sub-services
• How do we implement This? [v] - implementation-detail, sub-services etc

Some questions that use the SCORE method for strategy/tactics review:

• What are the strengths of This? - SCORE assessment – crosslink to Challenges, also risks, opportunities, effectiveness
• What are the challenges for This? - SCORE assessment – always crosslink to Strengths, also risks / opportunities / effectiveness
• What are the risks for This? - include ‘normal’ risks plus kurtosis-risks; always crosslink to opportunities, plus strengths / challenges / effectiveness
• What are the opportunities for This? – include ‘normal’ opportunities plus ‘Black Swan’ / ‘Blue Ocean’ opportunities; always crosslink to risks, plus strengths / challenges / effectiveness
• How do we enhance the effectiveness of This? - sub-questions on Efficient, Reliable, Elegant, Appropriate, Integrated

Some questions around requirements, conflicts and dependencies:

• What is the pain around This? – describe the pain-points that underpin requirements for change
• What are the requirements for This? – describe the requirements (functional and qualitative), the authorities for those requirements, etc (e.g. as per Volere requirements-template)
• What conflicts with This? [*]- list other services or requirements, and the nature of the conflict
• What depends on This? [*] - list the dependent services or other items, and the nature of the dependency

Some questions around the lifecycle of the item itself:

• What is the history of This? – describe past versions, past uses (outline an as-was to as-is)
• What is the future for This? – outline intended future versions, uses etc (develop an as-is to to-be)
• What is the lifecycle for This? – what creates, reads or references, updates, deletes or disposes of this? (or, optionally, the lifecycle IN This – the lifecycle of whatever this service acts on, i.e. a CRUD usage-lifecycle)

And finally (for now), some questions that focus on narrative-knowledge and the narrative aspects of enterprise-architecture and service-design:

• Tell me a story about This?
• What is a use-case for This?
• What is a scenario for This?
• What is a customer-journey that uses This?

(Typically we would record those stories in freeform format, perhaps as an audio- or video-recording attached to the item-entity within the toolset.)

Obviously there are many, many other questions we could ask in the same way – though remember that part of the aim here is to support modelling with Enterprise Canvas. The key theme throughout is that it’s about creating engagement in the architecture – this isn’t done solely by people with an ‘architect’ job-title, but anyone at all, in a form and format that is usable by just by anyone, even in the midst of their everyday work.

More later on how we could apply this in practice – but any comments for now on the basic idea?