Full title: The Enterprise As Story: the role of narrative in enterprise-architecture

ISBN: 978-1-906681-34-0

Description:

Most current approaches to enterprise-architecture describe everything in terms of structure. Yet people work better with story than with structure – and people are the enterprise. As we expand the architecture towards a true whole-of-enterprise scope, we need to describe the enterprise as story. Story is everywhere in the architecture – even the enterprise itself is a story.

This ground-breaking book places story at centre-stage for the architecture, itself using a narrative structure to explore the role of narrative in enterprise-architecture. Via business story-structures such as the Market-Cycle, and genres such as We Sell Certainty, it shows how stories underpin every aspect of the enterprise – and how we can use story within the architecture to enhance overall enterprise effectiveness.

Topics covered include:

• how to use story and narrative to assist in sensemaking for architecture
• how to create engagement in the architecture through story
• how to balance structure and story for better business results
• how to identify and use business-story genres to guide overall architecture
• how to change the organisation’s relationships with its ‘anti-clients’ from business-risk to business-opportunity
• how to use story-patterns to identify and resolve strategic business-issues
• how to leverage your own experience to create stronger architecture stories

If you want to create real engagement in the architecture and the enterprise, this is one book you’ll definitely need.

—

You can already order the printed book from Amazon.co.uk or Amazon.com, and presumably most other book-retailers as well.

(Ignore the comment on Amazon about ‘Temporarily out of stock’: Amazon say that for any print-on-demand book that they themselves don’t produce… It’s at most a couple extra days’ delivery-time, that’s all.)

I’ll also be adding it to the book-set deals on Kevin Smith’s Pragmatic EA bookshop: should be set up within the next few days, anyway.

And new - you can now buy the e-book from Leanpub, as a complete set of PDF (portrait-format), EPUB (for iPad, Sony-Reader etc) and MOBI (for Kindle).

I’ll be doing a lot more publishing via Leanpub from now on: not just e-books of the existing books, but also smaller more focussed e-books on topics such as SCAN sensemaking and modelling with Enterprise Canvas. More details on that in an upcoming post, anyway.

The slidedeck is just under 80 slides, split into five sequences:

• “What’s the story?” – introducing the idea of story as a way of working within enterprise-architectures, using the example of Carnaval, in Rio de Janeiro
• “A cast of thousands!” - describing the ‘sharedness’ of enterprises and the enterprise-story, again using Carnaval as its example
• “The plot thickens…” - linking story to process and the practical details of the enterprise
• “To be continued…” - exploring the structure of story, and strategic-structures that cause failure of the organisation’s story
• “Every picture tells a story” - a plea for stronger support of story in our enterprise-architecture toolsets

For once, I did a slidedeck that’s more about visuals than words – and it certainly seemed to go down well with the audience, which is always good fun.

The conference is, for me, one of the highlights of the year, because they cover architectures with such an enormously varied scope: most of the attendees are from defence / security contexts or high-reliability areas such as rail-transport or air-traffic control. I put in a a few sort-of visual jokes that I put in specifically for them – which seemed to go down well, too.

I also did a audio-recording, but it’s a bit crackly. I’ll try to clean it up and, if so, attach it to the slidedeck to make a bit more of a standalone presentation.

Share and enjoy, anyway?

The first has a working-title of The enterprise as story: the role of narrative in enterprise-architecture. This has been a major theme on this blog for the past couple of years or so: more than 40 posts here on various aspects since ‘The enterprise is the story‘. And as in the post ‘The no-plan Plan: architecture as story‘, it’s one of the five key-themes in my ‘no-plan plan‘ for my current and future work-direction. So it’s something I need to get down on paper, in more direct, usable form.

There’s a definite deadline of end of February for this one, because I’ll need it available in time for my presentation ‘The enterprise is a story: a narrative approach to enterprise-architecture‘ at the Integrated EA conference in London on 6-7 March 2012.

The second has a working-title of The business-anarchist: enterprise-architectures for the edge of chaos. This has perhaps been a less prominent theme on the blog, but it’s turned up quite a few times, such as in the post ‘Analyst, anarchist, architect‘. In essence, it’s about being deliberate and responsible about working with disruption in the business-context, preferably before that disruption is thrust upon us – a concern which is rapidly becoming more and more important almost by the day.

I’ve been nibbling at this one since mid-2009, and even wrote a fair chunk of it at various points last year, but didn’t finish it then, in part because it didn’t feel like the right time. Now, post-Occupy and suchlike, it does feel more like the right time, so I need to get it done. It’ll have to come after The enterprise as story, but with luck and lack-of-distraction it should be ready somewhen in April.

There’s also another enterprise-architecture book I’ve been working on for quite a while now with a colleague in Guatemala, Michael Smith. We don’t have a working-title for this one yet, and it’s rather further away in time – somewhen mid to late next year, probably – but it’s probably worth mentioning at this point. It’ll focus on the Five Elements theme that comes up in quite a few places in my work – for example, the structure of the effectiveness model used in SCORE strategy-assessment and the book Real Enterprise-Architecture, and the core of the market-cycle that’s used in conjunction with Enterprise Canvas.

Will let you know when any of the books become ready and available, but thought I’d keep you up to date with this part of work-in-progress, anyway.

One reason is implied this Tweet by Belgian consultant Patrick Van Renterghem:

itworks: Big discussion now about what happens when cloud vendors go bankrupt or out-of-service. Should [be] in the contract… #BAEA

“Should be in the contract…”: yes, indeed – but what should be in that contract? And why?

Without an enterprise-architecture that covers a broader scope than just the bare IT-transactions, we have no way to know what actually needs to be in that contract – and also in the parts that can’t be covered by contract, and that really do depend on relationships and trust. Which could be a serious problem from a business perspective. Hmm…

I’ve covered a fair bit of the detail of this in other posts here, such as ‘Enterprise-architecture and the Cloud‘. Some people seem to have misunderstood the questions there as somehow being ‘anti-Cloud’, or even ‘anti-IT’: it’s not. It’s about really looking at the whole context – about the whole ‘market-cycle’, about understanding the full implications of a customer-centric view, about maintaining consistency of service across all in-source and out-source relationships, and so on. And we do need to do that: because if we don’t, it can get really expensive.

Yet cloud-outsourcing is only one small example. As enterprise-architects, we also need to be able to extend out to a much broader business-picture, as Steve Denning describes in his Forbes post, ‘Clayton Christensen: How Pursuit of Profits Kills Innovation and the U.S. Economy‘

when a firm calculates the rate of return on a proposal to outsource manufacturing overseas, it typically does not include:

• The cost of the knowledge that is being lost, possibly forever.
• The cost of being unable to innovate in future, because critical knowledge has been lost.
• The consequent cost of its current business being destroyed by competitors emerging who can make a better product at lower cost.
• The missed opportunity of profits that could be made from innovations based on that knowledge that is being lost.

Failure to apply a proper enterprise-scope architecture-assessment of such themes can be more serious than merely expensive: mistakes at that level can easily kill a corporation. In short, it matters.

That kind of in-depth EA assessment might at first seem pernickety and pedantic, especially to those who just want to get moving. But as John Seddon warns, most of the ‘conventional’ methods to save money and effort usually end up costing far, far more: if we do need to cut costs, for example, we need to take more systemic, whole-of-context view in order to find the real places where those costs can be cut back. And the reality is that often they’re not where we’d expect them to be: hence, again, the need for a true enterprise-scope architecture.

Cloud-IT and other forms of outsourcing often look like the quickest, easiest and most practical way to cut costs. But Steve Denning quotes John Maynard Keynes to warn:

Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.

Most often, those ‘defunct economists’ have failed to account for the hidden costs of a context – particularly the real human costs, which can be ignored only at our peril, especially in the longer term. There are good reasons why those ideas became ‘defunct’: but unfortunately, it seems each new generation has to re-learn those reasons time and time again…

In our domains, those forgotten lessons are reflected in IT-centrism and the like, and the over-simplification of otherwise-valuable ideas such as ‘scientific management’ and ‘business process reengineering’, and, now, cloud-based IT-services. A key role of a whole-of-enterprise architecture, here in the context of outsourcing, is to remind us of why those lessons about the real complexities of outsourcing and the like are so important, and what they mean in real-world practice to Keynes’ ‘practical men’.

In short, use enterprise-architecture to help identify the real hidden-costs of outsourcing – so that your business doesn’t get hit by the bill when those hidden-costs come back to bite…

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?

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Some related questions on service-metrics and quality:

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

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

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

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

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

Some questions about responsibilities and stakeholders:

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

Some questions about composition, decomposition and implementation:

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

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

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

Some questions around requirements, conflicts and dependencies:

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

Some questions around the lifecycle of the item itself:

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

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

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

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

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

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

The usual approach to toolsets – just about any kind of toolset, as far as I can tell – is to describe the overall context, knock up a metamodel, and then build a toolset that works with that metamodel.

That’s fine as long as we don’t need to use the content for anything else, in any other way, or (in all too many cases) in any other toolset. If we do need to do anything like that – and frankly, most of us do – well, then, we have a problem…

What we actually need is a toolset that can do any kind of modelling and simulation that we could possibly want. Given the nature of Reality Department, we’re not likely to get it… Oh well. But if we can’t have that One Toolset To Rule Them All, then perhaps a good second-best is a metamodel (or metametamodel, or whatever layer we need to go to) that underpins a file-format that can move anything that we need to share across all the disparate toolsets. And that, I believe, is doable. Hence this series of posts.

Let’s start right at the roots.

(And please watch for anything that I’ve missed, or that I seem to have got wrong – because that’s the way we’ll get this to work right, for everyone.)

Let’s start with the idea of a ‘thing’. This ‘thing’ could be or represent anything at all: an object, a piece of information, a perceived connection, an idea, a question, whatever. It’s just, well, something. Anything.

Given a collection of ‘things’, we then might want to describe perceived relationships between various of those ‘things’.

And we then might want to model those ‘things’ and relationships between ‘things’ in a structured or semi-structured way, to aid in sense-making and decision-making. (We then might also want to describe explicit viewpoints and views that determine the scope and role of models, as per IEEE1471 / ISO42010.)

This gives us the core of what we need to support here: entities (‘things’), relations, and model-types.

(I think that part is straightforward, but if not, please say so?)

Way back when, whilst we were designing an information-system for an aircraft tear-down, my colleague Graeme Burnett said that for anything of interest, anything in scope, we need to be able to ask of each ‘thing’:

• Tell me about yourself, and about what happens to you, with you, by you?
• Tell me what you’re associated with, and why?

Which in a sense leads us to the usual metamodel set, but with a few extra twists:

• entities and their attributes
• relationships and their attributes
• lifecycles and other types of change of entities
• flows and other types of change between entities
• questions about entities, relationships, attributes, flows, lifecycles and other changes

(What else needs to be added to this list? What have I missed so far?)

We need these items to be able to be portrayed in any representation (in both the visual sense and technical sense), including plain-text. This means that any representation needs to be separate from any entity or relationship or other item, yet needs to be associatable with it. In other words, we can’t link a metamodel rigidly with a notation, or vice versa, as with UML or BPMN or Archimate, for example – we must be able to re-use the same entities and relations and so on in multiple notations.

Some examples of how we might want to re-use the same entities might include:

• enterprise-architecture notation such as Archimate in Archi, or other notations such as UML, BPMN and so on
• enterprise-architecture metamodels such as in Troux Semantics
• systems models such as in Southbeach
• narrative questions such as in Southbeach MyCreativity
• context-maps such as in CMapTools
• social-networks for shared-concepts such as in Cohere
• personal sensemaking such as in Compendium
• support ‘barely repeatable processes’ such as in Thingamy
• partial-duplication for what-if experiments and for as-is versus to-be comparisons
• modelling of flows between entities

(Any other items that we ought to add to this list?)

As indicated in that list, we need to be able to support a wide variety of views and model-types. But the key point here is that there’s actually only one type of entity – or rather, every different entity is based on and resolves to the same core entity-type. The same applies to relationships: although there are many different apparent types, ultimately they all resolve back to the same core relationship-entity. That’s what would enable their portability between views, notations, model-types and applications.

This also implies that there’s no fundamental distinction between a ‘type’ and an ‘instance’. The only difference is that a type is instantiable, and an instance isn’t: we convert an instance to a type by making it instantiable, and we create an instance by making a non-instantiable copy of a type.

(Is there any part of the above that seems unworkable or doesn’t make sense?)

We need to be able to support several different levels of model-validation:

• free-form (no validation), as in Visio
• partial or variable validation, as in Archimate (or most forms of architecture-development)
• strict formal validation, as in BPMN to BPEL conversion

(Free-form and strict are relatively easy to implement; partial or variable validation can be a lot harder! Partial or variable-validation also means that we need to support null-entities or placeholders to indicate ‘dangling’ relations or items that have yet to be defined.)

We need to support to keep the information clean, including:

• explicit identifiers (distinct from editable names)
• standardised explicit change/lifecycle, as per CRUD or REST
• versioning
• deduplication, merge and split
• change of base-type for entity or entity-instance
• resolve of dangling links (i.e. links where the ‘far-end’ entity has been deleted)
• entity owner(s) – or preferably a complete RACI set for each entity

(What have I missed here?)

If I’ve got this right – and I’ll admit it’s a big ‘if’ – then conceptually we need only one core entity-type, and one core-relation-type, to cover all potential uses.

If so, then that would open an enormous range of possibilities for enterprise-architecture and for many other disciplines as well.

There are a number of tweaks and tricks to make this work in practice – particularly the concept of ‘tags’, which I’ll explain in the next post, and likewise a fundamental reorientation of the relationship between entity-types, relation-types and model-types – but in essence that seems to be enough to get started.

Comments, anyone, please?

To be honest, we don’t need much help in thinking about the nature of enterprise-architecture or the like: that’s already well covered, and it’s actually quite straightforward anyway.

Where we need help is in rethinking the toolsets that we use for enterprise-architecture and the like.

To me it’s clear that if we’re to make sense of the enterprise, and support viable decision-making about the true whole-enterprise-scope within which our organisations operate, we’re going to need some kind of holographic approach to modelling.

We already have plenty of frameworks for enterprise-architecture. We also have plenty of methodologies to work with those frameworks. Each of those is constrained to some variously narrow view into this holographic space, and usually constrained by placing some particular point as ‘the centre’ – hence IT-centrism, business-centrism, health-and-safety-centrism and so on. And those constraints are useful in practice: no doubts whatsoever about that. So to my mind there’s nothing whatsoever that’s inherently ‘wrong’ about any of those frameworks or methods, other than their own occasional internal inconsistencies and than that they too-often position their own very limited perspective on reality as ‘the only possible’ view on reality. That’s the only problem there, and it’s very easy to fix, by acknowledging the value of a single viewpoint as a viewpoint yet also insisting on cross-viewpoint generics. We can choose anywhere as ‘the centre’, for some given purpose, yet must also insist that everywhere and nowhere is ‘the centre’, all at the same time.

Hence, as such, we don’t need any new frameworks or methodologies for enterprise-architecture. We have more than enough of them already, to be honest.

What we do need are better ways to manage and make sense of the information we have about this ‘enterprise-hologram’.

Which is where toolsets come into the picture. And that‘s the part that I really need help on – or we need help on, rather, because it’s definitely too large a context for any one person, or even any one group, to tackle on their own.

What we need most is clarity on the question we’re aiming to address. I think it’s an Einstein quote that says “if I had an hour to solve a problem, I would spend the first fifty-nine of those minutes on the question, and only the last minute on the answer” – because the right answer tends to fall out all by itself when we have clarity on the question.

One thing we do know, though, is that there are many different players all trying to tackle different aspects of the same enterprise-holograph – for example:

• enterprise-architecture and all the other domain-architectures and solution-architectures – an emphasis on structure and purpose, and how they link together to deliver useful value
• knowledge-management – an emphasis on how knowledge-items link together (especially narrative-knowledge, stories and ‘subjective truth’)
• change-management – how everything changes and can be changed over time
• process-management – how activities link together, and entities flow between them, to add value across supply-chains, value-networks and so on
• service-management – the human and technical aspects of keeping everything going and ‘on purpose’
• futures and other business-intelligence – how to trawl through the enterprise-space for sensemaking and the like
• simulation, ‘gamification’ and other skills-development – how to apply ‘what-if’ to any part of the overall context
• skills-management – identifying the skills needed, and the training and/or recruiting needed to cover present or future gaps
• performance-management – identifying required metrics and their impacts (especially, to avoid ‘gaming the system’)
• governance – identifying requirements and responsibilities, assuring assignment and ability to comply, and verifying compliance

In principle, yes, they’re all views or viewpoints into the same overall context. Yet each of those views also carries information or requirements that are specific to that view alone – in other words, more like an orthogonal dimension. And there are a lot of those distinct dimensions in there – an n-dimensional space, where n could literally be any number. (Certainly a lot more than are accessible in the simple flat images so typical of so many current ‘EA’-toolsets, anyway.)

Then there are all the different uses for all those distinct views: an architectural view shows us relationships between structure and purpose, for example, but do we need that view to decide on future strategy, to plan investment, to compare different implementation-options in trade-off analysis, to guide scenarios and substitutions in planning business-continuity and disaster-recovery? The views we’d use might at first seem similar, but the focus and emphasis and model-dynamics in each case might be very different.

At first glance this all might seem impossibly huge. Yet it’s not as hard as it seems. Most of the technology we’d need to deal with all of this complexity does already exist. Despite the huge spread of the overall toolset-ecosystem, most of the key software components we’d need are already easily available, at little or no direct cost, running on a wide-range of easily-available existing devices. Conceptually speaking, the underlying data-structures are straightforward enough: for example, it could be done with little more than freeform tagging in an object-database of some kind, with some kind of filters applied to the tagging. The same applies to search, and filtering: pretty much everything we need already exists somewhere, if we knew where to look. And even if display-technologies are not yet quite capable of showing a true n-dimensional holographic space, they’re certainly capable of simulating one. Given the right people and the right ideas, the technology side really isn’t all that hard these days.

But if the technology isn’t hard, the user-experience part is hard. And seems to me that that’s where we most need to focus our attention at the moment.

In many cases, we simply don’t have the right metaphors for model-relationships:

• some of it can be usefully described as a matrix – but it’s definitely more than a simple matrix as per Zachman
• there are some contexts in which a metaphor of hierarchical layers will sort-of make sense – but it’s definitely more than a simple ‘stack’ as per TOGAF or Archimate, or even a multi-axis matrix-stack as per CapGemini IAF
• there are flows of information and materials – yet it’s much more than a simple supply-chain
• there are identifiable relationships, including realisation, aggregation and so on – yet much of it tends to follow a modal logic of possibility rather than solely a simple true/false logic of presence or absence
• there are identifiable trails of derivation and decomposition – yet there’s more to it than a simple Zachman layering, or the classic ‘current state’ versus ‘future state’

And perhaps more important, we don’t yet have adequate user-interface metaphors:

• drag-and-drop for entities can be misleading – is it a class or an instance? how do we link back an instance back to a parent class? are we editing the instance only, or the whole class? are we affecting other instances elsewhere? or other versions of the same nominal instance? what happens if the parent disappears over time, but the instance continues as re-linked to something else?
• notations can be confusing – especially where the same nominal entity would appear in multiple views with different notations or visualisations or images
• aggregation (as in Zachman primitives versus composites, TOGAF ABBs versus SBBs [Architectural Building Blocks versus Solution Building Blocks]) can be very confusing – especially where entities can recombine in many different forms, and at different levels of abstraction or realisation
• zooming (as per Prezi) works well to describe a ‘containment’ or hierarchical concept of structural-decomposition – but it’s hard to make sense, if entities aren’t fully ‘contained’, or if there are more than two orthogonal axes
• timelines (as in Gantt-chart relationships, or Apple OS-X Time Machine backup/restore) provide a good means to step through time-related views – yet the views themselves may change over time
• multi-axis user-controls work well for up to three or four exactly-orthogonal dimensions – but become exponentially harder to use with increasing numbers of dimensions and other variables, and probably cannot cope when the dimensions themselves blur into each other

In short, we urgently need new user-interface metaphors to navigate through n-dimensional holographic space, where the nature of the space itself may change as we go.

(Oh, and it has to be easy to use, too, such that both the navigation and what’s visible in the view will make immediate sense to anyone. Of course.)

To use another Einstein quote, “Everything must be made as simple as possible, but not more simple”. Simple to use; yet actively dissuade overly-simplistic ‘solutions’ such as IT-centrism and the like.

That’s the challenge.

And that’s also where Agile and the like come into the picture – and, most of all, people who are experienced in Agile-style software-development for toolsets and the like. We seem to have quite a lot of methodologists and the like around here, who tend to be great on the theory. But what we need most are developers who know how to think seriously-sideways and put it into practice.

We can’t just talk it into existence: we need to get past the ‘talking about it’ stage now. Given the blunt fact that we’re very unlikely to get it right first time, we need something to play with, to test in real-world practice, to review and rethink our ideas, to help us clarify what the question really is that we’re facing here.

More thinking-about-thinking, about the theory and the like, well, yes, we’re always going to need it, it’s always going to be a ‘nice to have’, and so on. But right now, we’ve done more than enough thinking-about-thinking: it’s time to get down to the doing, of creating this new kind of toolset.

Anyone interested in helping with that? Please?