Tom Graves / Tetradian

Also launched at the Integrated EA 2012 conference was my new book ‘The enterprise as story‘:

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 enterprise is the story‘ – my presentation from the recent Integrated-EA enterprise-architecture conference in London – is now online on Slideshare:

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?

Another follow-on to the earlier post ‘Helping others make sense of my work‘, just a quick note to let you know about two current book-projects.

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.

Why do we need enterprise-architecture in a business? And why does that EA need to be broader than just IT, often all the way out to a true enterprise-wide scope?

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…

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

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

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

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

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

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

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

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

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

For each app-idea, I’ll summarise:

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

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

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

Read more…

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

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

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

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

To put into context, consider a few scenarios:

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

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

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

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

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

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

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

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

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

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

So there we are.

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

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

Uh, no…

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

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

Ouch…

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

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

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

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

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

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

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

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

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

Comments/suggestions, anyone?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Some related questions on service-metrics and quality:

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

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

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

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

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

Some questions about responsibilities and stakeholders:

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

Some questions about composition, decomposition and implementation:

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

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

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

Some questions around requirements, conflicts and dependencies:

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

Some questions around the lifecycle of the item itself:

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

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

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

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

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

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

Time to get back to the themes from the post ‘More on that enterprise-architecture ‘help wanted’‘, with a focus on toolsets and metamodels.

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?

Given the responses to my previous post ‘Guess I could do with some help here…‘, seems it’d be useful if I clarify a bit more what kind of help I most need. (Or we need, rather, as an industry and discipline: probably the only ‘I’-part here is that I seem to be one of the few at present who’s asking these questions?)

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?