In Enterprise Canvas, we assert that everything is or represents a service. Ultimately, each service serves the overall vision or purpose of the shared-enterprise, which often extends far beyond the boundary-of-control of the organisation itself.

The values of the shared-enterprise derive from and express that vision or purpose. Hence these are values that the organisation must respect if it is be and remain in business within that shared-enterprise. For example, the TED vision of “ideas worth spreading” is expressed in practice through values such as responsibility, respect, clarity, connection, engagement, passion for ideas and production-quality – values that can be seen in practice in just about everything for which TED has either direct responsibility or oversight (such as the independent TEDx conferences).

In the sketch-notation for Enterprise Canvas, we typically model these as the ‘vertical axis’ through the service, connecting intent to real-world results:

In detailed practice and implementation, the values are expressed in more actionable form as principles. (See Chapter 23 ‘Principles’ in the TOGAF 9 specification for a good summary of how to define and structure actionable principles.) Principles are used to guide decision-making in the face of uncertainty at every level of abstraction, from strategy to tactics to real-time operations.

Value is what is passed around the enterprise, as exchanges between services, in order to achieve the overall aims of the shared-enterprise. In effect, exchanges of value within the enterprise align with and contribute to the values of the enterprise.

In the sketch-notation for Enterprise Canvas, we typically model most of these exchanges of value as the ‘horizontal-axis’ through the service, connecting with other services before, during and after each main-transaction. We would sketch a simple supplier-self-customer supply-chain model – such as is typical in Business Model Canvas – in a format somewhat like this:

To make better sense of that ‘horizontal’ flow of value, we often partition the service into a three-by-three matrix of ‘child-services’ – the matrix being formed from a time-dimension (before, during and after) and an orientation-dimension (inbound [service-consumption], self [value-creation] and outbound [service-provision]):

Often in modelling with Enterprise Canvas we’ll use generic labels for each of these clusters f ‘child’-services. For our purposes here, the cluster we need most to focus on is value-governance, which acts mostly (though by no means exclusively) on the back-channel, the ‘after transactiuon’ flows:

The service also needs to connect to other guidance-services, to help keep the flow of value on track to the enterprise-values. The guidance-services include:

• direction-services - the strategic, tactical and operational forms of classic ‘management services’
• coordination-services - guiding end-to-end connection of processes that intersect with multiple services, often across or between organisational silos
• validation-services - services that assist in building awareness, capability and action, and verifying and auditing that action, on ‘pervasive’ value-themes such as knowledge-management, health, safety and environment, efficiency, reliability, security and financial probity

In Enterprise Canvas sketch-notation we’d typically show the guidance-services like this, tagged with the respective symbol:

Of the guidance-services, probably ‘direction-services’ connect must strongly with the ‘Value Governance’ cluster of child-services, though by definition all of the guidance-services must connect with every part of the service.

So far so good: value connects to values.

Yet there’s another set of service-relationships that we must not overlook: the relationships with investors and beneficiaries. In Enterprise Canvas sketch-notation we’d usually show them like this:

Investors provide forms of value that are different from the forms of value that flow ‘horizontally’ around the shared-enterprise, but may be needed in order to start up, operate and maintain the service. The obvious example is financial investors, where the value of the investment is usually described in monetary terms. Yet there are many other forms of value that may be involved: for example, a community invests trust and, often, hope in an organisation doing business in its locality; families of employees may invest very real energy to keep them working there, and so on.

Beneficiaries receive some of the returned-value from the service, typically diverted from the flow in the backchannel, as a ‘dividend’ or suchlike. Again, the obvious example is value in monetary form, but again there are many other possible forms of value: civic pride, for example, or the shared pride of employees’ families.

Yet there are two fundamentally important traps to note here.

One is that the Investors and Beneficiaries may be different people. For example, an ‘externality’ occurs whenever one or more groups invest their own forms of value, but another group extracts all or most of the available value in one preferred form only, damaging or destroying most or all other forms of value. Again, the obvious example is financial: the community and employees invest their energy and their time, but the shareholders – as nominal ‘owners’ – claim the ‘rights’ to possess all of the returned-value, which somehow must also be converted to monetary form. A key role of value-governance is to identify such mismatches, and to bring them back into some form of balance that is acceptable to all parties – otherwise the service will fail over the longer-term.

(Somewhen I’ll have to write a post about anti-clients, anti-value, anti-Investors and, especially, anti-Beneficiaries. But that, as they say, is another story for another time!)

The other trap is that whilst the Investors’ and Beneficiaries’ forms of value may be needed by or deliverable by the service, the values of the Investors and/or Beneficiaries may not align with those of the service’s shared-enterprise. In enterprise-architecture we do need to respect the drivers and needs of Investors and Beneficiaries, but it may be essential to keep the value-systems separate. If we don’t, we risk ending up with the kind of lethal mess where, for example, attempts are made to measure everything in monetary terms, blocking the actual forms of value that traverse ‘horizontally’ across the enterprise-space.

Michael Porter described one form of this trap as“the obsession with shareholder-value is the Bermuda Triangle of strategy, in which companies sink without trace”. There are many forms of this trap, though: look around at much of mainstream politics and politically-motivated regulation these days, or the sad disaster-area that is the ‘rights’-discourse… It’s definitely a real challenge for any enterprise-architect.

In short:

• values guide decision-making and appropriacy of choices within the shared-enterprise
• value is what flows around, through, to and from each service in the shared-enterprise

So in each architectural context, be clear what values and forms of value you’re dealing with, and how and where and why – and don’t mix them up!

Why Archimate?

Archimate aims to be the standard notation for all enterprise-architecture work, bridging an important gap between free-form whiteboard-style sketches and detail-layer executable models.

The catch is that it all depends on what’s meant by the term ‘enterprise-architecture’… which is not a trivial point, as Len Fehskens explained on the Open Group blog early last year, in his seminal post ‘Enterprise Architecture’s Quest for its Identity‘.

The short answer is that version 1.0 of Archimate was a very good fit for what Fehskens describes as ‘EITA’ – enterprise IT-architecture. It was not a good fit for whole-enterprise architecture – a literal ‘architecture of the enterprise’ – because in essence everything in Archimate 1.0 centred around IT, and it had no real means to describe anything that did not in some way directly impact upon IT.

For a logistics context, for example, we could model how information about a package would move through the system, but not the physical package itself: so there was no real way describe any of the scenarios by which the parcel and the record of that parcel might become misaligned – or, perhaps more importantly, become realigned. (In the real world, that kind of misalignment still happens way too often for anyone to be comfortable or complacent about it – as can be seen in so many Twitter-complaints with the ‘#fail’ hashtag. It’s a very real business-problem – and usually a problem that is rooted somewhere deep within the architecture of the enterprise. Which is why it is our problem.)

There were also several key items that were missing from the Archimate metamodel that were going to be needed by anyone aiming to bridge the infamous business/IT-divide – particularly about motivation. (There’d been some coverage of that in the earlier versions of Archimate, but were dropped in the 1.0 release, perhaps to improve its alignment with the TOGAF 9 metamodel.)

The underlying anatomy of Archimate is also somewhat problematic. As I explained somewhen mid last year in a long post, ‘Unravelling the anatomy of Archimate‘, to me there are what seem to be several fundamental flaws in the structure of its metametamodel that actively constrain its use to an IT-oriented view of enterprise-architecture. And there seems to be no easy way to resolve those flaws without going a long way down into the internals and starting again. The surface-layer can look much the same – and certainly remain backwards-compatible – but the internals would need to be very different to make Archimate usable for the kind of business-oriented enterprise-architecture that so many more EAs are moving towards now.

So when I first found out about the revision for this new version, my attitude was ‘high hopes but not high expectations’. And that’s pretty much what’s happened – except that there’ve been some been very useful additions, some of them in places that I didn’t expect.

So for those of us working in whole-enterprise architectures, there’s good-news, and there’s bad-news. And there’s quite a lot of good-news, and nothing in the bad-news that we wouldn’t have expected, so let’s get the latter out of the way first.

Bad-news: there’s no fundamental move away from IT-centrism

The bad-news it that we’re still stuck with the same inane IT-centrism as before – right from the very first sentence of the specification:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization. … Architecture descriptions are formal descriptions of an information system, organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.

There’s a lot more to any enterprise than just its IT-based information-systems, but in essence that’s all that this new version of Archimate would allow us to handle. And that annoyingly-arbitrary constraint is carried through into the same old pseudo-layering of Business, Application and [IT] Technology, in which ‘Business Layer’ is a similarly arbitrary and annoyingly-incomplete placeholder for ‘anything not-IT that might affect IT’. Not only absurd, but now seriously out-of-date for current EA practice – as even Open Group would freely admit, given the nominal focus of many of the presentations at the San Francisco conference and elsewhere

Sigh.

And they’ve used the same ‘plug-in’ concept for all the new add-ons as in the TOGAF 9 metamodel – which is a nice idea, but there’s nothing to support it in the existing Archimate metametamodel. So the result is that the underlying architecture has become yet more fragmented – which is going to make it even harder to do the fundamental rework of the architecture that must be done it’s to be usable forward into the future.

Oh well.

But that’s about the sum-total of the bad-news, and none of it was unexpected, so let’s move on to what is good in the new release.

Good-news: the Motivation extension

This wasn’t unexpected, but it’s still very good news: we can now link any architectural-entity explicitly to the reasons why it exists, and in a manner that allows for formal rigour between all of those interrelationships, roughly in line with the Business Motivation Model (BMM). The new entities are a subset of the BMM, but still eminently usable:

• Stakeholder
• Driver
• Assessment
• Goal
• Requirement
• Constraint
• Principle

In the Business layer we can link these to the existing entities for Value and Meaning, to create a (mostly)-complete trail of derivation for business-purpose. No equivalents in the other two layers, but it probably doesn’t matter as long as entities there are linked up into the Business layer, either direct or via the new Motivation entities.

The only thing that’s bizarre about this is the whole idea of treating motivation as an ‘extension’, rather than core. To use Simon Sinek’s term, surely we should always ’start with why‘?

Good-news: the Implementation & Migration extension

This one’s likewise very good news, and I wasn’t expecting it at all. This gives us a means to model the dynamics of an architecture – the way in which the architecture itself undergoes change. Again the new entities here are only a subset of what we really need for this, but they’re certainly enough with which to get started:

• Work-Package
• Deliverable
• Plateau (for example, an ‘intermediate state’ at some predefined time-horizon)
• Gap

It does make sense to describe this as an ‘extension’, because we don’t need it to describe a particular configuration or ‘state’ of an architecture – though we do need it whenever the architecture is to change.

The really good-news about this is that it provides a nice graphic workaround for the fact that almost none of the existing toolsets handle architecture-dynamics in any useful way. And if the toolset-vendor implements the appropriate ‘hooks’, this would also provide a solid anchor-point for cross-links into project-management tools and the like. Nice.

Good-news: the Location entity, and other minor amendments

A Location entity had been included in the earliest iterations of Archimate, but for some unfathomable reason it was dropped long before the Version 1.0 release; it now makes a very welcome and very necessary return.

A glance at Zachman should give the reason why it’s so important: without it, we have no means to describe the ‘where‘ of the architecture, whether in virtual, physical or any other form.

The Location entity is arbitrarily placed in the Business layer – which makes no sense, of course, because location should apply to everything, but it’s probably the only way that it can be handled within that absurd IT-oriented ‘layering’. Despite that placement, it is allowed to connect with every other entity, mostly via ‘assignment’ or ‘association’ relationships.

The other oddity is that there’s no explicit distinctions between types of location – particularly virtual versus physical, which is extremely important even in IT-architecture. No doubt this can be handled within toolsets via attributes, but it is a distinction that needs to be addressed.

There are a few other clean-ups down in the Technology layer, mostly new types of IT-specific relationships for newer technologies. To me the most significant item is Infrastructure Function – significant mainly because its stated purpose is to reinstate some much-needed structural symmetry in the underlying metametamodel for Archimate.

What next?

The specification ends with a ‘Future Directions’ chapter, which summarises some ideas about what could be added in future. Which is all fine: except they still don’t include anything that would make it more usable for the non-IT aspects of enterprise-architecture.

At the very least, if Archimate is to be usable for what it purports to do, we need it to be able to cover the symmetric equivalents of Application and Technology in the non-IT space – and not try to dump it all into ‘Business’, where most of it does not belong. The core partitionings that we need in an architecture are:

• role-type – passive-structure, behaviour and active-structure
• asset-type – physical-object, virtual-information, human-relation
• agent-type – physical-machine, IT-system and/or human-process

Role-type is the nominal core of current Archimate. But asset-types are in effect conflated into and scrambled within Technology, Application and Business layers respectively; and the only agent-type fully acknowledged is IT-system, with the others either ignored (physical-machine) and/or arbitrarily shunted into the Business ‘layer’ (human-process). This makes it all but impossible, for example, to use Archimate to describe business-process redesign or process-fallback where the existing or alternate implementation-methods would use machines or manual-processes; it makes it impossible to describe a business-continuity plan for a context where the IT is out of action; it still leaves it impossible to describe that logistics paralleling-problem between physical parcel versus information about the parcel. This are real needs in any viable enterprise-architecture, and we need a notation that can cover them. Hence, if Archimate is to be the notation of choice for EA, it needs to address these concerns: there is simply no other option.

From assorted snippets of conversation with various colleagues I know that such concerns are being explored in the discussions for the next version of TOGAF, currently code-named ‘TOGAF Next’. So if Archimate is to keep aligned with TOGAF, any putative ‘Archimate Next’ would have to follow suit. So I do still have high hopes for something useful and usable happening there; is it too unreasonable this time to have high expectations as well?

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!

App idea 1: SCAN sensemaking framework

Why and how this app would help: This app would support people in practical sensemaking at work, much like SWOT (Strengths, Weaknesses, Opportunities, Threats) does for basic strategy and tactics. The focus is always on helping the user to make meaningful decisions in uncertain circumstances at ‘business-speed’.

What this app would do: The app would present the SCAN core-graphic, and allow people to build a quick ‘story’ of their current context, using the core-graphic as a guideline and checklist. The ‘story’ would point to different approaches, and clarify trade-offs and the risks and opportunities of particular approaches.

Using the app, the user will, for example, be able to:

• start a session – “let’s do a quick SCAN on this” – by typing or recording a brief intro to describe the context
• record text, voice, photo and video (dependent on device-capabilities), such as via attaching ‘post-it’ tags, audio-recordings and suchlike
• ‘drill-down’ into each of the segments (‘domains’) of the core-graphic, and apply the same method recursively to each ‘domain’
• ‘replay’ all or any part of the current session or previous sessions
• synchronise and/or store a SCAN from a small device (smartphone, tablet) onto a larger device (laptop, desktop)
• export reports of SCANs

What this app would look like: The app would be centred around the SCAN core-graphic:

The user would be able to attach ‘post-its’ and other tags to ‘domains’ (defined regions on the core-graphic), to act as reminders or to carry notes and memos of the sensemaking exploration.

The reverse of this main page (and of individual ‘domains’) would include explanatory text of what each ‘domain’ means in practice, how it’s used, and where the various choices lead.

Other pages would include session-details, and lists of previous sessions.

Existing apps: I envisaged this as a cross between a note-taker app [for text-notes], an audio-memo app (see AudioNote for iPhone/iPad) [for audio-notes, text-notes and 'replay] and a fixed-frame sensemaking structure (see BMTBox for iPad, the ‘official’ app for Business Model Canvas) [for 'post-its', tagging and session-based descriptions].

Broader context: This app should feed into the general EA-toolset ecosystem, such that SCAN sessions can be attached to models, or have models derived from SCAN sessions.

Probable market: The potential market for a smartphone version of this app could be enormous, across every possible industry or context – especially if SCAN becomes as ubiquitous as SWOT, for which it does have the potential to be. The market for a web-based app would probably be rather smaller, but still significant. It would need to be low-priced, and very quick to use and re-access. Establishing the market may take some time, but could take off virally if used / recommended by key figures in an industry.

Probable development issues: This should be straightforward, though very high quality user-experience and workflow will be absolutely critical to success. For iPhone/iPad, the main part of the app is only about five ‘pages’, with perhaps 10 ‘pages’ more of ancillary information, selection-lists, text-entry and so on. The audio-record/playback functions are built-in for most smartphones and tablets.

Current status: Preliminary storyboards, workflows and wireframes are under development at present. The basic concepts, workflows and usage-scenarios have been and are still being documented in various blog-posts (see ‘Further information’ below).

Further information:

• “Let’s do a quick SCAN on this”
• Using SCAN: some quick examples
• On SCAN, PDCA, OODA and the acronym-soup
• Domains and dimensions in SCAN
• Comparing SCAN and Cynefin

Other notes: (See ‘Other notes’ for ‘Context-space mapping’ app.)

App idea 2: Context-space mapping sensemaking-method

Why and how this app would help: This is another app for sensemaking in an uncertain context, but aimed more at enterprise-architects, strategists, futurists and other conceptual-level consultants. It’s likely to be used in a shared environment (cafe-conversation, brainstorming-meeting etc) as well as in solo use.

Context-space mapping uses a selected ‘base-map’ to as a guide and checklist for sensemaking in a context, much as for SCAN. However, unlike SCAN, other ‘cross-maps’ can be overlaid on the base-map to trigger different perspectives: in some cases these cross-maps will intentionally cause mismatch, to force alternate and often-unexpected ways of thinking about a context.

(SCAN is actually a simplified form of context-space mapping, optimised for rapid use under real-time pressure; this is the full generic version, allowing more options but typically taking more time to do.)

What this app would do: The app would be an extended version of the SCAN app, and should be able to do everything that the SCAN app would do (e.g. session-creation and review, tagging, text- and audio-memos, reports etc). In addition, the user should also be able to:

• select a ‘base-map’ graphic from a list of base-map types (rather than the single fixed based-map used in SCAN), and apply tags, memos etc to ‘domains’ on that base-map
• given a base-map, select from a list of compatible ‘cross-map’ overlays, and apply tags, memos etc to ‘domains’ created by the cross-map

What this app would look like: This would look much the same as for the SCAN app. The main addition would be selectors for base-maps and cross-maps – both graphic-format (as ‘cards’) and list-format.

Existing apps: I envisaged this as a combination of text/audio etc note-taking (e.g. AudioNote for iPhone/iPad) and fixed-frame sensemaking (BMTBox for iPad, SWOT for iPad), plus something like Gamestorming for the iPhone (for its use of ‘cards’ to represent models or processes).

Broader context: As for the SCAN app, this should fit in with the broader EA toolset. Also, assuming that a library of base-maps is developed – possibly or even probably by the user-community – it can also fit in with and support all kinds of general business-sensemaking that uses a static base-map and optional overlays: e.g. Porter Value Chain, SWOT, Galbraith Star, Five Element, Kotter Eight Phases etc. (For other examples see e.g. van Assen, van den Berg & Pietersma, Key Management Models, FT/PrenticeHall.)

Probable market: The basic market is a subset of that for SCAN – i.e. EA specialists and consultants. However, if support for an extensible library is added, the market could be huge – essentially everyone who needs to do any kind of business-sensemaking.

Probable development issues: This is best understood as an extension of the SCAN app (or rather, that the SCAN app is a subset of this). The main additions are:

• graphic selectors (‘cards’) for base-maps and for cross-map overlays for the current base-map
• text-list selectors for same
• zoom and horizontal/vertical scroll (some base-maps will be too large to make sense in one go, especially on smaller devices)

To allow for zooming, graphics will probably be best stored in vector format (e.g. SVG) rather than as bitmaps. (This would also make it easier to maintain the exchangeable data-format in text-only form.)

Current status: As for the SCAN app, preliminary storyboards, workflows and wireframes are under development at present. The basic concepts, workflows and usage-scenarios have been and are still being documented in various blog-posts (see ‘Further information’ below).

Further information:

• Book ‘Everyday Enterprise Architecture: sensemaking, strategy, structures and solutions‘ (complete book in free-download e-book)
• Context-space mapping and enterprise-architecture
• Context-space mapping with the Enterprise Canvas
• Context-space mapping with Enterprise Canvas, Part 2: Business-context
• Context-space mapping with Enterprise Canvas, Part 3: Value-proposition
• Context-space mapping with Enterprise Canvas, Part 4: Rethinking vision bottom-up
• Context-space mapping with Enterprise Canvas, Part 5: Service content
• On business-rules (worked-example with business-rules)
• Standing up for the value of our work (worked example with Cynefin framework)
• Causal Layered Analysis, SCCC and Cynefin (worked-example with Causal Layered Analysis)

Other notes: One option that would greatly add to the market would be to present the SCAN app as the extensible base for this larger-scope app. Offer the SCAN app as a very low cost ($2-3) or even ‘free’ app, and add other models via in-app purchase or via subscription to a web-based library. (Proprietary models could be included into the library on a royalty basis.) The extended features for context-space mapping become available as soon as the first extension is downloaded; further models become visible as new ‘cards’ or text-items in the selector-lists.

App idea 3: ‘This’-game for context-exploration

Why and how this app would help: One of the practical problems in requirements-elicitation (and modelling in general) is knowing where to start. The ‘This’ game bypasses the problem by supporting a ‘start anywhere’ principle – everything connects with everything else, so it doesn’t matter where we start. The broader meaning and central themes within the context emerge from the exploration, rather than having to be predefined (possibly incorrectly) from the start.

A key point in requirements-elicitation, which this app would help to emphasise, is that often the most important information and ideas arise from the conversation around a topic, rather than from the specific questions themselves.

What this app would do: The app presents questions about the current focus within the context – i.e. ‘This’ – and records the answers to those questions as text, audio, video, photo (e.g. of a whiteboard) and perhaps also sketch-diagrams. The questions can be presented in structured sequences (checklists), by manual selection from a list, or at random.

Some of the questions allow us to change the current focus (the ‘This’) to a related item, enabling us to expand the overall scope of the game.

The context can also display a graphic model of the context, in simplified Enterprise Canvas notation (see app-idea #4). The model is generated from the information collected to date, and is non-editable, but can be used to select a different ‘This’ within the current scope.

The app maintains a list of ‘This’-game sessions, and allows us to create a new session, review or edit an existing session, or delete a session. We can also export a session to another compatible system, such as a toolset for modelling with Enterprise Canvas.

What this app would look like: The core of the ‘game’ is a set of questions and supporting information, typically each presented in a format much like a playing-card:

Options to add responses to the question would be arranged around the ‘card’, with existing responses accessed either via a scrolling list ‘below’ the card, or on the ‘reverse’ of the card. Other administrative options – view session-details, select another question, export, etc – would also be arranged around the ‘card’, together with any context-specific options such as to move to or create a new ‘This’ focus-point.

Lists in graphic or text-format would be displayed as per the usual format for the respective device and user-interface paradigm.

Existing apps: Much as for the SCAN and Context-space mapping apps. The ‘card’ concept can be seen in the Gamestorming app; the zoomable/scrollable display could be much as per the Prezi web-based presentation-app.

Broader context: This will definitely need to link in to the EA-toolset ecosystem, as it will be a primary information-source for EA-toolset content. It could also be used as a method for review of EA-toolset content.

Probable market: Anyone involved in the broader enterprise-architecture context, including conventional (IT-oriented) ‘enterprise’-architecture, process- and service-design, value-network review, business-model implementation, and general review and troubleshooting in a wide variety of business contexts.

Probable development issues: Structurally this would be similar to the Context-space mapping app (app-idea #2), and could probably be built on top of the same underlying ‘engine’.

Compared to the Context-space mapping app-idea, the main differences are the ‘card’-selection mechanisms, and that the display is not editable as such: because the ‘card’ can be re-used many times even within the same session, responses would be added to a list, rather than ‘dragged’ onto the card-graphic. See the Gamestorming app for idea for ‘card’-selection.

Current status: Again, preliminary storyboards, workflows and wireframes are under development at present. The basic concepts, workflows and usage-scenarios have been and are still being documented in various blog-posts (see ‘Further information’ below).

Further information:

• This: an exploratory game for service-oriented EA
• More on the ‘This’ game for enterprise-architecture
• The ‘This’ game and EA toolsets

Other notes: So far I’ve done very little work on ‘gamification’ as such: it’s described as a ‘game’ only in the sense that ‘cards’ could be selected at random, rather than always as predefined lists. Some people have come up with possible suggestions for ‘gamification’ – see the ‘More on the ‘This’ game’ post – but it’s an avenue that may need further exploration.

App idea 4: Enterprise Canvas architecture-modelling

Why and how this app would help: One of the major problems in current enterprise-architecture is the way in which the many different model-types fragment the overall space into narrow subsets, often with no means to link between them. (Archimate is one of the few model-types that attempts to bridge across domains, but at present only in relation to IT.)

Enterprise Canvas resolves this by using a completely consistent service-oriented approach that applies to every part of the enterprise context, at every level, using the same small set of entity-types across the whole space, which can later be ‘translated’ into the other context-specific model-types.

This app provides a means to model or review any aspect of the business, at any level, that can be described in service-oriented terms.

What this app would do: This app provides a space to develop and review context-models of an aspect of an enterprise-architecture, based on the simplified Enterprise Canvas notation. On small devices (e.g. smartphones, small tablets) the emphasis would be on review, because the ‘screen real-estate’ would be too small for practical modelling; however, full modelling should be possible from mid-size tablets (7-inch? 10-inch?) upwards.

An extended version of the app should also allow comparison, cross-link and merge of models, to build a larger-scope model. This would then feed into a full EA-toolset (see ‘Bonus app’ below).

What this app would look like: On a small device, the app would allow:

• select from a list of models
• create a new model (including description of model-context etc)
• download a model for review
• upload/sync models that have been created or reviewed
• review by adding ‘wiki-like’ comments to existing entries

The display would be much as per the app-idea for the ‘This’-game: a zoomable/scrollable graphic that can also be used to select entities for review, and a ‘scrolling card’ display for the contents and comments for the entity itself.

On a larger device, the app would also allow creation and editing of graphic models, using the small palette of entities in the simplified Enterprise Canvas notation (two main entities, two subsidiary entities, three relation-types – see the ‘Simplifying the Enterprise Canvas’ post).

The larger screen would also allow using a sketch or image (such as a photo of a Business Model Canvas on a whiteboard) as a backplane on top of which to develop a model. (See the post ‘Enterprise Canvas as service-viability checklist’ for a cross-map between Business Model Canvas and the standard-layout Enterprise Canvas shown in simplified-notation above.)

Existing apps: For smaller devices, see the ‘Existing apps’ summary for the ‘This’-game app-idea above. For larger devices, see any graphic-modelling tool for UML, BPMN or any other similar notation: example tools include Visio, Archi, BizzDesign, Sparx Enterprise Architect etc.

Broader context: This app should be able to import sessions from the ‘This’-game app, and potentially re-export to the ‘This’-game app. It should also be able to exchange with a full EA-toolset that can convert between Enterprise Canvas and other model-types such as Archimate, BPMN and UML.

Probable market: The initial market is enterprise-architects and others who need to be able to model any part of an enterprise. This initial market is quite small, and depends on awareness of a need for whole-enterprise scope (rather than an IT-centric scope, as in most current ‘enterprise’-architecture).

However, as Enterprise Canvas becomes better known as a means to link across disparate model-types, the market is likely to grow radically, especially if an app is available right down to the tablet or smartphone level, where it can be used for information-capture, review and problem-resolution on-site.

Probable development issues: For the smaller-device implementations or for web-implementation, development could be based on the ‘This’-game app, without the need for the ‘card’-questions, but with an active rather than passive graphic display. In other words, it will be necessary to be able to drag-and-drop entities onto the workspace; to draw flow-links and other relation-links between entities; and to open, edit and review property-sheets associated with entities and flows. This is supported by HTML5 ‘canvas’, for example, but is likely to require more development-effort than for a passive graphic-display.

A standalone app could be based directly on the open-source Archi toolset for Archimate. (The simplified Enterprise Canvas notation is, by design, a UML-compatible subset of the Archimate notation, with a somewhat different structure and content for its property-sheets.)

Development of an appropriate file-format will be crucial to the success of this app. It must be public domain, extensible, and (as far as practicable) compatible with other standards in the EA, process-architecture and software-architecture space: the XMI format is a probable good candidate for a starting-point for such development.

Current status: Once again, preliminary storyboards, workflows and wireframes are under development at present. The Enterprise Canvas notation is fully specified in various blog-posts (see ‘Further information’ below). Further ideas for workflow, structure and user-experience can be adapted directly from Archi and other existing toolsets in the EA-modelling space.

Further information:

• Simplifying the Enterprise Canvas
• More on simplified Enterprise Canvas
• Enterprise Canvas as service-viability checklist
• Book ‘Mapping the enterprise: modelling the enterprise as services with the Enterprise Canvas‘
• Reference-sheet for ‘Mapping the enterprise‘ (Enterprise Canvas)

Other notes: (n/a).

App idea 5: SEMPER diagnostic

Why and how this app would help: The physics definition of ‘power’ approximates to ‘the ability to do work’; in many social contexts, though, the effective definition is often closer to ‘the ability to avoid work’. Therein lie many problems for organisations, who definitely do want work to happen… This app provides a simple, unthreatening means to identify and measure the ‘ability to do work’ within a given context, and, via a cross-map, suggest appropriate techniques for intervention.

What this app would do: The diagnostic works somewhat like a more structured version of the ‘This’-game, presenting a set of questions for each section of each ‘domain’. (In the SEMPER-5 model, there are 5×5 questions; in the SEMPER-11 model, which is more for experienced consultants, there are 5×10 +1 questions.) In general, the app would use predefined sets of questions, which can be defined externally and uploaded to the app, but also potentially also edited within the app if required.

To start with, the user would define the context for a session. It should be possible to link sessions together into groups, so as to do statistical evaluations such as 360degree-view, vertical-slice view or comparison of executive versus front-line view.

To answer each question, the user picks an option from two pull-down lists (in effect, the ‘ability to do work’ score, and any trend upward or downward), and optionally enters a comment. In principle, the questions can be answered in any order, though it would be more usual to do them in sequence.

The results are shown in tabular or ‘dashboard’ format, with or without trends.

The results can be exported in appropriate form such as CSV for statistical-analysis on spreadsheet.

What this app would look like: Defining a new session, reviewing a previous session, running the diagnostic itself, and export/re-import, would all quite similar to that for the ‘This’ game.

A ‘dashboard’ display would be much as above, though probably simplified for a small-device.

Existing apps: A complete demonstrator, implemented in PHP/MySQL, already exists, as shown on the SEMPER Metrics website. This is also available as a ‘Portable App’, to run direct from a USB thumb-drive or SD card, complete with its own web-server. For smaller devices, see the descriptions for the ‘This’-game.

Broader context: This is largely a standalone app, but could be integrated into a larger EA toolset or equivalent as appropriate.

Probable market: This is likely to be a somewhat specialist tool, primarily for organisational consultants and enterprise-architects. Even so, it does have quite a broad potential market, as the need (if perhaps not always the want) for this will be evident within every medium- to large-sized organisation or enterprise.

Probable development issues: A demonstrator already exists, incorporating all of the functionality described above, although it’s likely that it will need a complete re-implementation even for a web-based app. Structurally it is quite simple, using only a handful of database tables and very straightforward business-logic. A portable version could be based on the ‘This’-game app.

Current status: A complete demonstrator already exists, together with full design-documentation. The formal theory and structure of the SEMPER diagnostic is described on the SEMPER Metrics website and, in more detail, in the book SEMPER & SCORE; the latter also includes paper-based versions of the diagnostics.

Further information:

• Book ‘SEMPER & SCORE: enhancing enterprise effectiveness’ (key chapters are in free-download e-book)
• SEMPER Metrics website (reference and demonstrator)

Other notes: (n/a).

Bonus rather-more-than-an-app idea: full EA toolset

This final item is a lot more than a simple app: it’s a complete commercial-grade toolset to cover the entire scope of enterprise-architecture. Without it, we’re stuck with the limitations of the existing ‘EA’-toolsets, many of which are so constrained in their scope, and often so IT-centric that – to be blunt - they’re almost worse than useless for doing any kind of real enterprise-architecture.

It’s a big challenge: but the first team who actually ‘gets’ this really will dominate the toolset-space for the upcoming enterprise-architecture market. And that’ll be huge, because it has to sort out everything that currently doesn’t work in the entire economic model typically described as ‘business as usual’ – which, to again be blunt, is just about everything in ‘business as usual’.

So yes, big challenge, huge opportunity, waiting there for the first person to ‘get’ it: I just wish someone would… Will it be you?

Anyway, quick summary follows.

Why and how this toolset would help: Most of the existing EA toolsets support only a small subset of the myriad of model-notations and model-types currently fragmenting across the EA space. Most of these toolsets are strictly IT-focussed, and are simply not usable for anything that does not centre around or at least focus on an IT-oriented implementation. It is almost impossible to use these toolsets to cover the full whole-enterprise space, and those few that do have no means to link across all the different notations.

The aim of this toolset is to provide a consistent means to link across the entire space, to develop and support a ‘holographic’ model of the enterprise that can be described from any required viewpoint using any appropriate notation.

This would be a professional-level tool, used primarily by enterprise-architects, process- and service-designers, organisational-change specialists and the like. It will probably be implemented only for mid-range systems and above, from laptops (single-user) to desktops (multi-user). Because of the necessity for significant amounts of ‘screen real-estate’ or equivalent, it is unlikely to be available on small devices.

What this toolset would do: The toolset is based on a ‘universal’ metametamodel, which allows entities, relations and model-types to be described in a consistent, notation-agnostic way. Notations themselves are described in terms of the metametamodel, allowing consistent re-use of the same nominal entities in different notations and model-types.

Models can then be developed in the usual way, much as with any other existing EA toolset, and with entities stored in a local or shared repository as required. The toolset must also support import and export in a standardised notation-agnostic file-format, enabling sharing of models between different toolsets, and also with other compatible apps such as the ‘This’-game and the notation-specific Enterprise Canvas app.

What this toolset would look like: On the surface, it is likely that this toolset would look much like any existing EA-toolset, with multiple panes to access palettes for different notations, filtered subsets of existing entities in the repository, and so on.

Existing toolsets: A huge range to choose from, such as Archi or Aris Express at the single-user level, Sparx Enterprise Architect or Bizzdesign at the basic-repository level, mid-level systems such as Mega or Casewise (or, more IT-oriented, planningIT or alfabet), and ‘big-systems’ such as Aris, Troux or IBM System Architect.

Broader context: The toolset needs to be able to import and share with most of the apps above, especially the ‘This’-game and the Enterprise Canvas app. It also needs to be able to share models with many other toolsets, though this may be constrained by limitations of those other toolsets.

Probable market: The market for EA toolsets is specialist, but large – estimated in the low hundreds of millions of dollars per year. Most of this income is for high-end toolsets such as Troux or IBM System Architect, for which some configurations can be priced well into the tens of thousands of dollars per seat; but even low-end toolsets such as Sparx Enterprise Architect, which is priced in the low hundreds of dollars, do still sell many thousands of user-licenses overall.

To me, it would seem best to provide a range of offerings, from a high-end enterprise-wide repository with support-services that would genuinely justify a high per-seat license-fee (which, bluntly, cannot be said for some of the current toolsets), all the way down to a simple single-user system – still fully file-compatible with the high-end system, but with a simple local repository and reduced functionality – at a much lower price, or even available free. A ‘freemium’ structure would also help to create and extend the overall market.

Probable development issues: This would not be a simple development; nor would it be cheap, in terms of time at least. A good approach might be to start from some of the existing open-source toolsets such as Archi or Essential, and rework the underlying mechanisms to align with the notation-agnostic metametamodel, whilst still keeping the surface functionality essentially unchanged.

Current status: A lot of work has been done on ideas for a notation-agnostic metametamodel, and how that could be used to underpin multi-notation enterprise-modelling and information-exchange – see the ‘Further information’ section below for more details. Many of the workflows and wireframes can be based on or adapted from existing EA-toolsets, though the opportunity also exists for a complete rethink, more in line with the ‘holographic’ nature of the overall enterprise-model maintained by the toolset.

Further information:

• Enabling enterprise-architecture conversations
• Scenarios in ‘The ‘This’-game and EA toolsets‘
• Next-generation toolsets for EA
• The toolset-ecosystem
• More on that enterprise-architecture ‘help needed’
• Enterprise-architecture? – it’s all about story
• Back to the roots for EA toolset metamodels
• EA metamodel: two questions
• EA metamodel – the big picture (and the small picture too)
• What’s the point of this EA metamodel?
• Dependency and resilience in enterprise-architecture models
• More detail on EA metamodel
• Meanderings on metamodels
• More metamodel stuff
• Wiki on metamodels and structure for Open Source EA Toolset

Other notes: (n/a).

Nothing more to add for now: over to you for comments, if you would?

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?

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?

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.

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.

[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.

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.

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?