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?

For many people, it’s ‘the ‘Holiday Season’, or Christmas, or New Year, or something like that. A calendrical marker-point, anyway. Something to celebrate, perhaps.

The culture I come from is nominally Christian, hence ‘Christmas’ and suchlike, so that’s the label others around me tend to use. (Though it doesn’t quite have the same sense for me, I’ll admit: in religious terms, my family-background is in the Quaker tradition, which historically regards Christmas as ‘just another day’.)

[These days 'Christmas' in this country seems barely Christian anyway: it's much more about families - which sadly doesn't have much relevance for me - and, even more, about the real 'state-religion', the Church of Conspicuous Consumption, which I try to avoid as much as possible...]

As a perennial Outsider, my real colleagues are scattered around the globe: I have stronger connections with people in the Netherlands, Australia,Guatemala, Brazil or the US, for example, than with just about anyone in this town. Those friends and families and colleagues all follow different faiths, different traditions, different worldviews: even the Christians amongst them will celebrate their Christmas on different dates, from 1st December right through to 6th January (‘Twelfth Night’, also known in England as ‘Old Christmas’). And even a nominally-secular marker such as ‘New Year’ can be almost as problematic: there seem to be dozens of different definitions of ‘New Year’, few of which make much sense to anyone else.

So it’s kinda tricky knowing what to ‘celebrate’, or know which date-marker to use. For purely pragmatic reasons, I tend to focus on astronomical markers such as solstices and equinoxes, because they’re probably the ‘safest’ in social terms. Hence today, being the solstice closest to the most-acknowledged festival in these parts, and also closest to the New-Year point for this culture.

Even so, which solstice? It’s winter-solstice here, but summer-solstice for my friends down south; and solstices don’t mean much anyway to my friends in the tropical-regions, whose ‘summer’ and ‘winter’ and the like align with other real-world markers. Hmm… see what I mean by ‘kinda tricky’?

So what can a not-particularly-social not-particularly-anchored-anywhere soft-of-digital-native do or say these days, in terms of others’ societal celebrations?

I guess the best I can offer is that however, whatever and whenever you choose your celebrations to be, have fun, and Have A Happy Whatever!

Enjoy! – and thanks again for sharing this journey with me over the passing year.

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.

Am I giving up? No, not at all.

Am I actually leaving the entire enterprise-architecture domain? Nope. (Sorry to disappoint a few folks there, but you’ll just have to put up with that. )

So what exactly am I doing, then?

All I’m doing here, metaphorically speaking, is that I’m moving along the road a bit: a few metaphoric houses up the road, if you like. Similar sort of work to what I’ve always done, in many ways, but a much bigger picture this time. A much bigger picture. I’m not going to be looking (much) at the ‘enterprise’-architecture of some small bits of detail-level IT any more: I’ll be looking at the ‘enterprise-architecture’ of the whole darn planet…

Arrogant sucker, ain’t I?

In a way, yeah, of course it is, to say something like that. But if you look around on this blog and elsewhere, in effect that’s what I’ve already been doing, for years. All that’s really different now is that I’m making it a bit more explicit.

And to be blunt, looking around a bit, it really does feel as if I’m one of the few people anywhere who has a freakin’ clue about what’s really going on out there (answer: an MQ-9 mythquake [kind of like a worldwide Richter-9 earthquake, only worse]), what chance we have to stop it (answer: none at all), what won’t work (answer: just about everything we might think of as ‘normal’ or ‘business-as-usual’), and what might work (very-tentative-suggested-answer: something on the lines of a responsibility-based service-oriented enterprise model for a global economics, with systematic eradication of any concept of possession – including all concept of ‘rights’ – and total restructure of every possible aspect of politics at every level. In other words, just a few minor changes here and there… ). Seems like there might be a real need, then, for someone with my kind of background in futures, social-dynamics, skills-development, creativity, complexity, innovation, sensemaking and strategy, across a whole swathe of different companies, climates, cultures and continents. Oh, and there’s also enterprise-architectures, of course: reckon that might possibly be useful, too.

Yes: a real big need for that.

Kind of a big anti-want for it, though.

A very big anti-want.

Oh well.

But no problem, really. Do I think I can make a living out of it? Nope, of course not: I’m not that crazy. But I’m not making any kind of viable living out of enterprise-architecture, either, so what’s the difference? As long as I can pay my way somehow in this increasingly-insane ‘economic system’, that’s all I’ll need. And given that I’ve survived somehow for all these years, without ever having suffered the indignity of being a so-called ‘permanent’ employee, I reckon I’ll manage to keep going for a while yet. Somehow. Doesn’t really matter that I don’t know how: the way things are going, pretty soon no concept of a ‘plan’ is going to make sense any more, so perhaps I’m just getting in early to beat the rush?

Yeah, sure it’s lonely at times: I don’t have any real support at all, no family, no partner since literally decades ago, and at my age pretty unlikely ever again. Good: it means that there’s no-one else to get hurt on my behalf if I screw things up.

Sure it’s scary, desperately insecure: I don’t even have a home of my own any more. Good: nothing particularly to lose, then; nothing of that kind that can be used as leverage against me. And I can just up-sticks and go anywhere that I’m needed. Easy. (In principle, anyway… )

I’m useless at organising anything, events, stuff like that. Good: instead of desperately pretending that I can do everything myself, let other people do that stuff instead – they’re much better at it than I’ve ever been or ever will be. Just do my part of the work, and let others get on with theirs. Simple. (Interesting challenges on trust, of course… )

Turn every obstacle into an opportunity. Live this stuff that I’ve been talking about: rather than ‘making a living’, much better to go for ‘making a life’.

Crazy? Sure. Of course it is: never said it wasn’t. But then I come out of a family-background with a long anarchist-style tradition (of the more constructive if occasionally-quixotic Quaker variety, rather than the brainless bomb-throwing kind), and it’s about time I put those principles into real-world practice. Time to give something back – especially as, at age 60, I probably don’t have that many years left in which to do so. That fact matters, a lot. It also brings its own rather interesting sense of urgency…

So what does all this mean, in plain, ordinary, everyday terms?

Various things I won’t be doing:

1. I won’t do any more work here on detail-layer analysis of IT-oriented ‘enterprise’-architecture such as TOGAF or Archimate (unless anyone specifically asks me for an opinion or whatever).
2. I won’t be presenting myself for any more contract-work as an ‘enterprise-architect’. (I’ll still be available to do spot-work commercial consultancy or training for most types of EA, in just about any industry that isn’t finance, banking or insurance – but I will expect to get paid for that, every time.)
3. I won’t offer any more ‘free’ advice on enterprise-architecture or whatever to people who can darn well afford to pay for it. (I’ll still be more than happy to help anyone in any other way – especially any of the upcoming ‘new generation’ of enterprise-architects.)
4. I probably won’t be going to any more ‘enterprise’-architecture conferences, not least because I won’t be able to afford it (unless someone pays at least my expenses, of course).
5. I won’t pander any more to people who to me seem arrogant, bullying, unwilling to think, and otherwise acting in an asinine or irresponsible manner (and yes, there’s been a lot of them I’ve put up with way too often over the past few years…)

Various things I will be doing:

1. I will be doing a lot more research and exploration on ‘big-picture’ themes, developing new types of tools and techniques to tackle those issues in a much more constructive way than as at present; and working with others to develop new toolsets and training-materials for these needs. (It’d be nice if someone else paid for some of that work, but being realistic I wouldn’t expect it, unless anyone else that I’m working with is getting paid for it too.)
2. I will be doing various types of consultancy-work with non-profits, citizen-groups and other organisations that are reaching towards a more constructive world. (Again, it’d be nice if I got paid to do some of that, but I’d only expect it from commercial organisations or government bodies, who should be able to afford to subsidise some of that other work at least.)
3. I will show the EA community and others how to apply those ideas, tools and techniques, within the conventional business context, such as with Enterprise Canvas and the like. (It would likewise be nice if sometimes people would at least offer to pay some of my expenses for doing this, but I do acknowledge that there are too many of us already in this same boat that I am with regard to ‘real-EA’.)
4. I probably will be going to a wide variety of conferences and other gatherings on broader-scope societal-change topics. (As ever, the real limit here will be my probable near-nonexistent income: so if you really want me at your gathering, please do find some way to subsidise my travel-expenses at least.)
5. Much of my work and writing will be a lot more ‘political’ and challenging for a lot more folks: in which case, sorry, but that’s just too bad, because none of us can afford to tolerate outright irresponsibility and abuse any more. (I am very clear about what is and is not abuse in the social context, by the way: see the ‘manifesto‘ on that, from my book Power and Response-ability.)

So that’s it: getting down to work in a different garden – a garden that’s a rather better fit, than that of current mainstream ‘enterprise’-architecture, for this admittedly somewhat-strange kind of toad.

Comments / suggestions / requests, anyone?

My mother tells the story of the first house she and my father lived in, some small place way up in the north of England somewhere, back when my elder brother was still a babe-in-arms. The garden they’d inherited there was an overgrown tangle, and they didn’t have much of a clue about gardening, but it seemed a friendly sort of place. It even had its own toad, hiding in the humid dankness underneath a sprawl of strawberry-creepers that had crept in from under the fence from next-door.

It didn’t take long to see why the toad was there. Next-door’s garden was regimented, ordered, everything under control, just so. And all a bit sad, because nothing was thriving there. Beneath all that would-be perfection, the strawberry-patch was a mess of slugs and snails, stunting all the growth; what few fruit were left were all tiny. Yet over on my parents’ side of the fence, those same plants were producing a lush spread of abundant greenery, enough strawberries to keep a grocery going all on its own – and one very happy toad, who’d made very sure that there was not a single slug to be seen.

My mother realised what was happening in the next-door garden, and even offered to send ‘their’ toad over there. But the neighbour was adamant that she wasn’t having “that disgusting creature” in her perfect space: no way! And continued to fret over the fact that her once-imagined idyll was indeed dying…

Hence interesting that I’ve been writing about ‘the toad in the road‘, because I guess that’s what I am myself right now, in this garden we call ‘enterprise architecture’. A toad in the road: right idea, wrong place. Right idea for somewhere, I’d hope. But wrong place for here-and-now. Oh well.

Yeah, enterprise-architecture. You know, this could be a really nice garden? Especially if you got rid of most of this mess of concrete, and let those tired plants in their cracked concrete tubs get their roots down into the dirt at last. Plenty of potential and all that: to get the water flowing again, you might have to take a stick of dynamite to that ugly-looking paddling-pool that the last lot of kids built for themselves, over in the corner called ‘IT-centrism‘, but hey, it’s all here. Why not do it?

You’d wondered where all the wildlife went, but can’t you see there’s not much that can thrive in this kind of desert? A few bugs and wood-lice and a lizard or two, perhaps, but that’s about it. If you want it to work, perhaps plant a few things that can actually grow here: get a bit of shade going an’ all that. There’s a few plants of my own that might grow well here too, if given a halfway-decent chance: the Enterprise Canvas, perhaps, or that notation-agnostic metamodel; or maybe even a bunch of ideas about value-trees, about the service-oriented enterprise and the structure of management – kinda strange-looking at first, I know, but they really do work in this kind of climate. Only a suggestion, of course: it’s your garden, after all.

I’ll have to admit, though, that this isn’t really my kind of place that you’ve got here. Partly my fault, perhaps: I do know I’m kind of an Outsider – always have been, I guess – though I really have tried, I promise you. It’s just I really can’t cope with all the broken-down bits of machinery parked all over the place, and the possessiveness that still pervades everything: they do kinda get in the way all the time. And a bit too grey, too cold, too lifeless: too corporate, I suppose you could say? I’m gettin’ old, I s’pose: I need somewhere that’s a bit more comfortable with having real people around the place, a bit more aware of the anarchic nature of, well, nature itself? I guess I could do with a bit more of the bigger picture, too: and I don’t mind all those mythquakes that we can see coming down the road a ways, though I know they do worry some other folks a lot.

I’ll still be around, of course: if you need me, you know where to find me. And I’m always happy to drop by in your garden – especially if you find a way to bring it more back to life again.

But yeah, I gotta face the facts: this kind of ‘enterprise’-architecture garden ain’t no place for the likes o’ me – and out here at present I’m just another toad in the road.

So it’s “goodbye and thanks for all the slugs”, I guess? – because it seems like it’s time for this old toad to be a-movin’ on.

By ‘completeness’ I mean that we check that the service has all the connections and support and flows that it needs to play its full part in the respective layer of the enterprise value-network.

And ‘viability’ here is in the sense described in the Viable System Model, that the interdependencies that the service needs both to operate in the ‘now’ and to change appropriately over time are all in place and in action.

In a service-oriented architecture and and a service-oriented view of enterprise, everything is or delivers or represents a service. Which means that everything in the enterprise will rely on those interlinks and interdependencies. Which is why a model-type such as Enterprise Canvas, which explicitly sets out to model those interdependencies, could be very useful indeed.

So here’s an as-brief-as-I-can-make-it how-to introduction on using Enterprise Canvas for this purpose, creating models with the simplified version of the Enterprise Canvas notation.

For this we’ll need the (rather large) overview-model of service-relationships, in the simplified notation:

We’ll also need the extended-Zachman map of layers of abstraction:

And the ‘single-row extended-Zachman’ checklist for service-content – the ‘service-content map’:

And to model the flows (Exchange-entities) between services, we’ll also need to check against the market-cycle model, with an emphasis on completions for the different parts of the exchange:

If we want to start from a business-model developed on Business Model Canvas, we’ll need the cross-map from Business Model Canvas to Enterprise:

It’d probably be useful to print out those diagrams – or at least keep them close to hand – for reference as we work our way through this how-to.

So, to get started, pick a service – any service, anywhere in the overall enterprise – that happens to be of interest at present. (If none comes immediately to mind, start with the organisation as a whole, as a ‘service’ in context of its market and the broader shared-enterprise.)

Ideally, this should be modelled using a proper EA toolset. But if a metamodel for the simplified Enterprise Canvas isn’t yet available in the toolset, use an office-diagramming tool such as Visio or Dia – or perhaps just draw the model by hand, on paper or on a whiteboard.

Place a Service-entity in the middle of the model, to represent the chosen ‘service of interest’ – and then see what insights arise as the modelling proceeds…

As-is, to-be and gap-analysis

We can do the modelling in any way we need, for any practical purpose. However, there should always be an explicit business-need or business-question behind every modelling-effort.

We might model the service in an as-is context, describing its current configuration and interdependencies. There often isn’t much point in doing an as-is assessment on its own, though: we’d usually do it to establish a baseline for a roadmap towards some intended future, as the base for a gap-analysis, or perhaps to support a training-programme.

We’ll often do a to-be assessment to support scenarios for change, including business-model innovation via Business Model Canvas and the like. This type of assessment also provides an important endpoint-baseline for gap-analysis.

Often the greatest value of this type of modelling is in gap-analysis: either identifying interdependencies that are misaligned or missing, or – via mismatches between Service-entities and Exchange-entities – identifying misaligned supplier or customer-relationships, opportunities for new supplier- or customer-groups, or risks or opportunities all the way out through the market to the broader shared-enterprise.

The how-to descriptions that follow can be applied to any of these needs.

A note on layers

If you’ve used other IT-oriented architecture-frameworks such as TOGAF or Archimate, you’ll be used to splitting a model into layers in terms of technology versus applications versus business and suchlike. In reality those ‘layers’ are entirely arbitrary, but it’s a practice that can work quite well for domain-specific architectures.

At a true enterprise scope, however, that type of pseudo-layering can be misleading and even dangerous. Hence a reminder here that the only layers explicitly acknowledged in Enterprise Canvas are layers of abstraction, as in the extended-Zachman layering – from most-abstract to most-concrete, from infinite-future to immediate-past. Unlike in IT-architectures, no explicit distinction is drawn between modes of implementation – such as IT versus machine or manual process – because in principle they are all interchangeable. Likewise there’s no mandatory distinction between layers of granularity: the granularity can be shown via composition-relations between Services, but the respective flow-relations and Exchange-entities could legitimately connect to a Service-entity at either level, because it’s literally a matter of detail. The only explicit distinction here is between layers of abstraction.

You can use pseudo-layering if you must, but you’ll have to do so manually, via colour-coding or groups or whatever. Just note that there are very good reasons why it’s not built into the notation.

That point is particularly important here because our aim is to explore direct interdependencies between services. Every relation implies an exchange of some kind, even if the exchange consists only of an acknowledgement that the relationship exists (which we could document in the model as a ‘relational-asset’ within an Exchange-entity). The nature and implied content of the exchange may vary between levels of abstraction, but the exchanges themselves only take place between services at the same level of abstraction. And to understand interdependence, we need to identify the content of those exchanges.

Hence this type of modelling demands a discipline about layering that may take some getting used to, but is extremely valuable in practice:

• in general, flow-relations and Exchange-entities should only connect between Service-entities at the same layer
• changes in layer should be indicated by realisation-relations between Service-entities, which cannot incorporate any Exchange
• where a flow-relation must connect between Service-entities at different layers – such as where the actual service at that layer is unknown – the ‘different-layer’ Service must be indicated explicitly by a dotted-line border

Most modelling for this ‘viability-checklist’ purpose would or should be at a single layer of abstraction. For the supply-chain part of the model, this should be straightforward: any changes in layering should usually be self-evident there. Yet it’s all too easy to scramble the layering when exploring links with guidance-services or with investors and beneficiaries.

For example, if we’re using this checklist to focus on a detail-layer web-service, there’ll be a strong temptation to tick off the Direct::Change guidance-service as ‘IT Strategy’ or the like, and leave it at that. But if we do so, that’d be a real missed-opportunity. ‘IT Strategy’ is abstract, yet there’s real work there that’s done by real people, every bit as real as the web-service that’s our current focus of attention: hence what exactly is the chain of responsibilities and connections – and hence flow-relations and Exchanges between real-world Services – that links between that work and this web-service? There are some valuable insights to be gained there about how the enterprise actually works, and how it maintains its viability: it’s well worth the little bit of extra effort around layer-discipline in order to obtain them.

In short, the discipline that Enterprise Canvas demands around layers of abstraction, can perhaps seem tedious at times: yet in architecture-practice it can be one of the most valuable allies that we have. Don’t skip it!

The service itself

Back to modelling, and to the service in focus.

What is this service? Start by assigning it a name. (If you’re doing this within an EA toolset, provide a brief description as well.)

What layer of abstraction will we use as the base for modelling this service? (Usually this will be either row-2 ‘Business-model’, to describe the overall context, without much if any description of actual content; row-3 ‘System-model’, the implementation-independent ‘logical’ layer, where we start to fill in the details of the content of services and the inter-service exchanges; or row-4 ‘Design-model’, the implementation-specific ‘physical’ layer. Remember that if any specific technology or implementation is mentioned, by definition it’s at row-4 or below.)

Apply a RACI assessment to the service:

• Who is ultimately responsible or accountable for this service?
• Who assists in delivering or running or supporting this service?
• Who needs to be consulted about this service, or any changes to this service?
• Who needs to be informed about the performance of or changes to this service?

What other responsibilities and accountabilities apply in this context?

Nature of service

As a first step in the functional decomposition of the service – what it does, and how, and why – focus attention on the three innermost ‘cells’ of the Enterprise Canvas view of the service.

What value does this service provide – its Value-Proposition, in terms of the aims and needs and values of the broader extended-enterprise? (If cross-mapping from Business Model Canvas, this is a more enterprise-oriented version of that model’s Value-Proposition.) If appropriate, build a trail of linkage up through the layers of abstraction, to connect with the vision and values of the shared-enterprise. To model this, link this service to at at least one other Service-entity in each layer upward to row-1; then link to one or more Value-entities in row-0, and ultimately to the Vision-entity at that top of the abstraction-’tree’. (We’ll come back to some of this later when we explore this service’s links to other Validate services.)

What does this service do to create and deliver that value – its Value-Creation in terms of that Value-Proposition? (If cross-mapping from Business Model Canvas, this merges the latter’s Key Resources and Key Activities cells.) Use the service-content map (single-row extended-Zachman) to explore and identify the various assets, functions, locations, capabilities, events and decisions that apply within that value-creation. (We’ll come back to some of this later when we explore this service’s links to other Coordinate services.)

What does this service need to govern its service-delivery – its Value-Governance to keep the Value-Creation on-track to the Value-Proposition? (This isn’t really described at all in Business Model Canvas.) How does it do this? Under what business-rules? (We’ll come back to some of this later when we explore this service’s links to other Direct and Validate services.)

Apply a RACI assessment to each of these subsidiary ‘cells’ within the service: who is responsible or accountable, for what, and why?

Service-provision

For the next step we explore what this service provides to others – and who those ‘others’ might be.

We have several different ways to do this. One would be to focus mainly on the service itself, and infer the resultant exchanges with others; another would be to focus on the exchanges; and yet another would be to identify the ‘others’ (often described as ‘clients’ or ‘customers’ or ‘service-consumers’). For this how-to, we’ll start with the exchanges – but note that the other options are just as valid.

In a conventional transaction-oriented supply-chain model, this would explore only the goods or services delivered to others – and those ‘customer-side’ others are always considered to be distinct from anyone on ‘supplier-side’. We can model this in Enterprise Canvas, of course. Here, though, it’s usually wiser to use a more-complete value-network approach, in which the mapping of what happens before and after the main-transactions is every bit as important as the transactions themselves – and in which the supposed distinctions between ‘supplier’ and ‘customer’ will often tend to blur. For our purposes here, we’ll describe ‘customer’ and ‘supplier’ as if separate: but note that in many contexts in the real world, ‘supplier’ and ‘customer’ may well be the same.

What does this service provide to others – the services (or products, as proto-services or proxy for services) consumed by others? Using the ‘Assets’-column of the service-content map as a guide, what forms does this service-provision take? Using a VPEC-T assessment, what values, policies, events, content and trust apply in each service-provision by this service? Model the results of this assessment as one or more Exchange entities, linked via flow-relations to the right-hand (‘outgoing’) side of the Service-entity.

Who or what are the ‘customers’ or ‘consumers’ of these services? (If cross-mapping from Business Model Canvas, these are the various customer-groups in the Customer Segments cell.) For each distinct customer-group, there should usually be a distinct Exchange; if necessary, split the overall exchange-content into further Exchange-entities, each linked to a Service-entity for each respective customer-group.

Review each Exchange in terms of what aspects of the overall exchange and its content take place before, during and after each main-transaction. Use the market-cycle model to map these as follows:

• What reputation, trust, relations and attention need to be in place before each main-transaction? What Customer-Relations subsidiary-services exist within the service to support the interactions that would enable these to be created and maintained? (In Business Model Canvas, this is the content in the ‘Customer Relations’ cell.) In market-cycle terms, what completions are needed to ensure that these are maintained as required, especially over the longer-term?
• What are the core transactions in the service-delivery, and what happens during those transactions? Via what Customer-Channels or other means are the services delivered? (In Business Model Canvas, this is the content in the ‘Channels’ cell.) What protocols are needed to set up each transaction itself? In market-cycle terms, what completions are needed to mark the end of the transaction, and ensure that the transaction itself is closed-off and complete?
• What follow-up interactions need to occur after the main-transaction – such as payment and the like? What Value-Return subsidiary-services exist within the service to support these interactions? (Some parts of this are implied by the content of the ‘Revenue Streams’ cell in Business Model Canvas.) In market-cycle terms, what completions are needed to ensure that everything is complete and all parties are satisfied?

Define subsidiary Exchange-entities for each of these before, during and after flows, and link these via flow-relations to the respective subsidiary-cells of the service.

Optionally, use the service-content map to summarise the assets, activities and other content for each of the subsidiary-services.

Apply a RACI-assessment to each of these ‘customer-side’ subsidiary-services within the service, to identify responsibilities and accountabilities for each aspect of the Exchange-transactions and relations with the respective ‘customer’-service.

Given that the before, during and after interactions may all occur at different times, through different channels and on different time-scales, what mechanisms exist within the service to keep them all in balance, and appropriately linked to the core Value-Proposition, Value-Creation and Value-Governance of the service? Who or what is responsible for enacting and governing each of these internal activities and interactions?

Consuming other services

Next, we explore the ‘incoming’ side of the service – the services provided by and ‘consumed’ from others – and identify who those ‘others’ might be.

This is the symmetric-opposite of service-provision, and hence we should assess and model it in exactly the same way. The ‘others’ in this case are usually described as ‘suppliers’ or ‘partners’.

What does this service consume from others – the services or products provided by others? What forms does this service-provision take? What values, policies, events, content and trust apply in each service-provision to this service? Model the results of this assessment as one or more Exchange entities, linked to the left-hand (‘incoming’) side of the Service-entity.

Who or what are the ‘suppliers’ or ‘partners’ for each of these services? (If cross-mapping from Business Model Canvas, these are the content of the Key Partners cell.) For each distinct supplier-group, there should usually be a distinct Exchange; if necessary, split the overall exchange-content into further Exchange-entities, each linked to a Service-entity for each respective supplier-group.

Review each Exchange in terms of what aspects of the overall exchange and its content take place before, during and after each main-transaction. Use the market-cycle model to map these as follows:

• What reputation, trust, relations and attention need to be in place before each main-transaction? What Supplier-Relations subsidiary-services exist within the service to support these? (This is implied in part in Business Model Canvas by the Key Partners cell cell.) What completions are needed to ensure that these are maintained as required?
• What are the core transactions in the service-delivery, and what happens during those transactions? Via what Supplier-Channels or other means are the services delivered? (Again, this is implied in the Key Partners cell in Business Model Canvas) What protocols are needed to set up each transaction itself? What completions are needed to mark the end of the transaction, and ensure that the transaction itself is closed-off and complete?
• What follow-up interactions need to occur after the main-transaction – such as payment and the like? What Value-Outlay subsidiary-services exist within the service to support these interactions? (Some parts of this are implied by the content of the ‘Cost Structure’ cell in Business Model Canvas.) What completions are needed to ensure that everything is complete and all parties are satisfied?

Define subsidiary Exchange-entities for each of these before, during and after flows, and link these to the respective subsidiary-cells of the service.

Optionally, use the service-content map to summarise the assets, activities and other content for each of the subsidiary-services.

Apply a RACI-assessment to each of these ‘customer-side’ subsidiary-services within the service, to identify responsibilities and accountabilities for each aspect of the Exchange-transactions and relations with the respective ‘customer’-service.

What mechanisms exist within the service to keep all of the before, during and after interactions in balance, and appropriately linked to the core Value-Proposition, Value-Creation and Value-Governance of the service? Who or what is responsible for enacting and governing each of these internal activities and interactions?

Who or what is responsible for the overall balance across the whole of the service? (In principle this is a key part of the role of the Value-Governance subsidiary-services, but may in part be enacted by others: if so, who or what are they, and what mechanisms exist to ensure balance?)

Guidance service-relationships

The concept of ‘guidance-services’ is adapted from Viable System Model. (More accurately, a somewhat-extended version of Viable System Model – see my book The Service-Oriented Enterprise.) These represent the web of service-interdependencies that would ensure the viability of the service – the effectiveness of its operations at run-time, and its adaptability and resilience to change, especially over the longer-term. In line with Viable System Model, they’re described in Enterprise Canvas under three categories:

• direction – services that assist in planning and day-to-day management of this service and its clusters of related services
• coordination – services that assist in run-time coordination with other services, and with planning and coordination of change
• validation – services that help to keep the service on-track with and aligned to the vision and values of the shared-enterprise

These services or functions may be embedded somewhere within the service itself, though more usually enacted by separate business-functions. In a few cases – especially some aspects of validation-services – they may be required by law to be enacted by a completely separate organisation. Yet in whatever form they may be implemented in real-world practice, the point is that they must all exist somewhere, in some form, in an engaged relationship to this specific service. That’s the real concern here.

Note that these most of these guidance-services are implied or described only peripherally – if at all –  in conventional transaction-oriented architectures and business-models. Classic Taylorist ‘scientific management’ describes some aspects of the direction-services, but nothing else; Business Model Canvas and classic IT-centric ‘enterprise’-architectures do not describe any of them at all. There is a very significant architectural gap here that is rarely addressed – and needs to be.

For many enterprise-architects, much of this part of modelling with Enterprise Canvas may seem at first to be somewhat alien territory. The reason that it’s important is that unless these interdependencies are properly in place and in action, the service cannot be considered viable. Every ‘missing’, incomplete or inappropriately-supported interrelationship in this part of the Enterprise Canvas checklist represents a real and significant risk to the entire enterprise – risks that must be acknowledged and addressed so as to ensure the viability of the whole.

In short, don’t skip over this – there are very good reasons why these service-interrelationships are included in the Enterprise Canvas checklist!

Guidance – direction

The direction-services represent the usual ‘management’-type functions of the enterprise, seen here in relation to the service that is our current focus of attention.

Note that these ‘management-functions’ are viewed here solely as services in relation to other services, just like everything else. In many organisations, front-line services often seem to be regarded as ‘inferiors’, as ‘servants to the whims of management’, whereas from an architectural perspective it usually needs to be seen as more the other way round, that the real role of management is as a support-service to front-line service-delivery. In Enterprise Canvas, no special priority or importance is accorded to ‘the management’, for the simple reason that doing so doesn’t work: in a true enterprise-scope architecture, everywhere and nowhere is ‘the centre’, always, all at the same time. If you must treat management as ‘special and different’, do so outside of the architecture itself!

These services can be split into three distinct groups, often referred to as ‘Develop the Business’, ‘Change the Business’ and ‘Run the Business’. (In Viable System Model, these are referred to as system-5, system-4 and system-3 respectively.)

In a classic Taylorist view, ‘Develop’ and ‘Change’ are primarily staff-functions, whereas ‘Run’ is primarily a line-management function. There’s also a timescale-element here: ‘Develop’ tends to have a long time-view, ranging from years or decades, potentially all the way to infinity; ‘Change’ has a medium-term view, from the current quarter out to a few years ahead at most; whilst ‘Run’ is mostly focussed on the day-to-day. Strategy develops out of the intersection between ‘Develop’ and ‘Change’; tactics from the intersection of ‘Change’ and ‘Run’; and operations from the intersection between ‘Run’ and this service.

Most of these services must not and cannot be outsourced to another organisation.

Questions to ask here include:

• Direction::Develop – What support for long-term direction does this service need? What services would ensure that this service is aligned to the overall Vision for the enterprise? By what means are these ‘Develop’ direction-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Direction::Change – What support for medium-term strategic direction does this service need? What services would ensure that this service is aligned to the changing context of its market and business-ecosystem? By what means are these ‘Change’ direction-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Direction::Run – What support for day-to-day management does this service need? What services would ensure that this service has the resources that it needs to do its work in creating value? What performance-metrics does this service need to provide to those ‘Run’ direction-functions? How are those performance-metrics used in providing management-services to this service? By what means are these ‘Run’ direction-services delivered to this service? Who or what is responsible for these services, and how they apply to this service?

Identify the services and exchanges in each case, typically using the service-content map to assess the content of activities of each service, and VPEC-T analysis or the like to identify the values, policies, events, content and trust-concerns implied in each exchange. Add the results of this assessment to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. Use either containment (as in the diagram above) or composition-relations to link each of these Service-entities to the overall Direction Service. Annotate each flow-relation here with a ‘direct’ label, to indicate that the flow delivers direction-services to the service-in-focus.

A reminder here to be careful about layering: see ‘A note on layers’ above.

In essence, ‘Develop the Business’ is an architectural function for the organisation in relation to its shared-enterprise: in a very literal sense, the CEO is the organisation’s ‘Chief Enterprise Architect’. (Enterprise-architects provide decision-support for that role, but not the decision-making: that distinction is extremely important in practice!) The catch is that the CEO needs to do that work – but often doesn’t, and instead hides out in a comfort-zone of ‘Change’ or even ‘Run’, subsuming all the other management-functions into that role. This is a common cause of dysfunctional management and architecturally-inadequate support to the organisation’s overall services: classic examples include contexts where purported ‘shareholder-value’ is assigned absolute priority over everything else,or where “last year plus 10%” is considered to be a real strategy. This type of problem will almost invariably lead to organisational failure over the medium- to longer-term: it is an extremely important architectural risk to the organisation, and to the enterprise as a whole.

In short, if adequate and appropriate direction-support is not available, the service will not be viable.

Guidance – coordination

The coordination-services represent the business-functions that coordinate this service with other services.

These services can be split into three distinct groups, often referred to as ‘Develop the Business’, ‘Change the Business’ and ‘Run the Business’, in parallel with the matching functions in the Direction-services. (In Viable System Model, some aspects of ‘Coordinate::Run‘ are referred to as system-2. That model does not deal with coordination of change as such, hence has no explicit component for Coordinate::Develop or Coordinate::Change.)

In Taylorism these services are usually regarded as part of the ‘management’-functions, but in practice they often need to separate and distinct, not least because in many cases they must somehow bridge between management-hierarchy silos. Significant organisational problems can arise from that one fact…

In practice, Coordinate::Develop relates to coordination of strategy and strategic change, and hence links to both Direct::Develop and Direct::Change; it’s also often associated with portfolio-management and the like. The Coordinate::Change services focus more at the tactical level, and hence link to Direct::Change and Direct::Run; one classic aspect of these service is project-management and the Programme Management Office. In principle, the Coordinate::Run services would bridge between Direct::Run and the actual delivery-services (between system-3 and system-1 respectively, in Viable System Model terms), but in practice this is sometimes regarded – especially by questionably-competent managers – as ‘insubordination’, and hence at the human-coordination level may disappear into a kind of covert ‘shadow network’ via which work is actually coordinated and done. Architects can sometimes run head-on into unexpected political-problems when doing this part of the modelling work: a certain amount of caution may be advisable here!

It’s quite common for some aspects of these services to be outsourced to other organisations: if so, there would be additional coordination-services required to manage and coordinate the outsourcing process itself.

Questions to ask here include:

• Coordinate::Develop – What support for long-term strategic change does this service need? What services would ensure that this service is aligned to the overall enterprise strategy? By what means are these ‘Develop’ coordination-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Coordinate::Change – What support for medium-term tactical change does this service need? What services would ensure that this service is aligned to and fully supports the changing context of its market and business-ecosystem? By what means - such as programme- or project-management – are these ‘Change’ coordination-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Coordinate::Run – What support does this service need for run-time coordination with other services? What services would ensure that this service has the coordination with others that it needs so as to do its work in creating value? What information-flows, signalling or protocols are needed in this coordination-support? By what means are these ‘Run’ coordination-services delivered to this service? Who or what is responsible for these services, and how they apply to this service?

As before, identify the services and exchanges in each case. Add these to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. Use either containment or composition-relations to link each of these Service-entities to the overall Coordination Service. Annotate each flow-relation here with a ‘coordinate’ label, to indicate that the flow delivers coordination-services to the service-in-focus.

Identifying coordination-relationships between services is usually fairly straightforward, although it’s all to easy to fall into layering-mistakes in the modelling process here. (Hence another reminder to be careful here about layering: see ‘A note on layers’ above.) A lot of useful insights can be gained here about the interconnectedness of the enterprise, and its dynamics over time. Note, though, that there are also some important architectural risks (and opportunities) to be identified here: in short, if adequate and appropriate coordination-support is not available, the service will not be viable.

Guidance – validation

The validation-services help to keep everything aligned to the enterprise values – whatever those values may be. Note that there are usually distinct sets of validation-services for each key value of concern in the enterprise. Typical examples of values in this context include quality, probity, security, ethics, health and safety, knowledge-sharing, sustainability, waste-management, efficiency, effectiveness, and also architecture itself.

A crucial point here is that, unlike strategy, management, coordination or change, maintaining these values is a personal responsibility for everyone in the enterprise. There’s often a small core-group tasked with ‘holding the flag’ for the respective value within the organisation, and it’s those people – the knowledge-management, the quality-team, the security-team and so on – who we would often regard as the people who deliver such services. In reality, though, it’s only the support-services around each value that most would deliver: the actual implementation and expression of that value in practice must somehow be embedded and enacted, as activities and checks and the like, within every service in the enterprise.

These support-services for value-alignment be split into three groups: ‘Develop Awareness’ of the value; ‘Develop Capability’ to enact run-time support for the value; and ‘Verify and Audit’, to confirm alignment and compliance to the requirements of the value. (The system-3* component Viable System Model, which represents the closest match to this part of Enterprise Canvas, covers just one aspect of ‘Verify and Audit’, namely random audit of compliance.)

In Taylorism these services are often subsumed into the ‘management’-functions, which can often lead to misunderstandings because the managers themselves must be as subject to the values as is everyone else. It is true, though, that in many cases the core support-group for each value will be regarded as a ‘staff’-function, often reporting indirectly or even directly to the CEO or overall executive; it’s certainly essential for each of these values to have the full backing of the executive, otherwise in practice they end up going nowhere.

Although these validation-services do provide guidance across the enterprise, they are in effect almost orthogonal to the direction-services (‘management’ etc) and to the coordination-services (‘change-management’ etc). Some aspects of these services are often outsourced to other organisations – such as training, to develop capability – and in many contexts the Verify and Audit’ functions must be enacted by an outside organisation, either to support certification or mandated by law. Overall, though, the final responsibility for alignment to each of the enterprise-values must reside within the organisation itself: that aspect of these services cannot be outsourced.

In effect, these services should represent the nodes of a PDCA (Plan / Do / Check / Act) continuous-improvement loop for the respective value, starting at the ‘Act’ node.

• Plan – ‘Develop Capability’ is crucial to embedding the ability to enact support for the value.
• Do – The awareness and capability are applied in practice within each service and service-delivery.
• Check – ‘Verify and Audit’ confirms compliance, or any deviation from required or intended performance.
• Act – ‘Develop Awareness’ is central to taking action towards improving support for the value.

Before any of this modelling-work can make sense, there are some obvious questions that need to be asked:

• What are the enterprise-values? Why do these values apply in this enterprise, and in this organisation?
• Which of these values are explicitly espoused as matter of personal choice, by the executive and/or by others – such as in this organisation’s equivalent of the ‘HP Way‘? Which of these values are imposed on the organisation from outside, as part of a metaphoric ‘license to operate’ within the industry or broader social milieu?
• What differences – if any – exist between the espoused values and the values actually enacted and upheld within the organisation and/or the broader shared-enterprise?

These values should typically be modelled as Value-entities in a row-0 segment of an Enterprise Canvas, attached to the Vision-entity in the model. Within the model, Service-entities for all validation-services should ultimately link back via flow-, composition and realization-relations to one or more row-0 Value-entities.

Given that list of enterprise-values, questions to ask here for each enterprise-value include:

• Validate::Awareness – What support does this service need to develop and establish awareness of the value and its importance to the organisation and enterprise? What services would ensure that this service is aligned to the respective value? By what means are these ‘Develop Awareness’ validation-services for this value delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Validate::Capability – What support does this service need to develop and improve its capability to enact the requirements of the value within the service and its service-delivery? What services would ensure that this capability is appropriately developed, and the capability verified prior to action? By what means - such as training-programmes – are these ‘Develop Capability’ validation-services delivered to this service? Who or what is responsible for providing these services to the organisation in general, and to this service in particular?
• Run-time support within this service – What functionality and other support exists within this service to enact the value within all of its activities and processes? In what ways are the awareness of the value and capabilities to support the value expressed in practice? Since this represents a personal responsibility incumbent on everyone involved, what support exists at run-time to ensure that those responsibilities are upheld?
• Validate::Verify – What support does this service need so as to verify and audit its actual performance in relation to the respective value? What services would ensure that this service has indeed delivered that performance? What records and other sources are needed in this validation-support? By what means are these ‘Verify and Audit’ validation-services delivered to this service? By what means are these ‘Verify and Audit’ services themselves verified and audited for alignment to the value? Who or what is responsible for these services, and how they apply to this service?

As before, identify the services and exchanges in each case. Add these to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. Use either containment or composition-relations to link each of these Service-entities to the overall Validation Service. Annotate each flow-relation here with a ‘validate’ label, to indicate that the flow delivers validation-services to the service-in-focus.

Also as before, be careful to avoid falling into layering-mistakes in the modelling process here (again, see ‘A note on layers’ above.) Overall, there are lot of useful insights to be gained here, about the nature of the enterprise, and about architectural risks and opportunities. The key concern to note, as with the other guidance-services, is that the service-in-focus will not be viable – especially over the longer-term – unless adequate and appropriate validation-support is available for each value in context.

Investors and beneficiaries

The Investor and Beneficiary services respectively represent those who contribute value to the service, or to whom value is returned from the service, beyond and outside of the usual transactions of the service’s supply-chain.

These services (or service-relationships) are not covered as such in the Viable System Model. They barely rate any mention in classic Taylorism: the only investors acknowledged there, and also the only beneficiaries acknowledged, are the purported ‘owners’ of the business, who invest money in the business and receive money from it in return.

In practice, even at the whole-organisation level, we need a much broader understanding of the roles of investors and beneficiaries, and the nature and myriad forms of value which they invest or receive. We also often need to explore how the forms of value are themselves transformed within a service. For example, in a business-startup context, people may invest time and skill and effort, and hope to receive monetary return; whereas in a non-profit context, people might invest money in the hope of seeing broader social benefit. The same overall principles apply right down to the level of an individual web-service or the like, though sometimes these value-relationships there can be difficult to identify and even harder to describe!

Note that ‘value’ here has a somewhat different meaning to ‘values’ in the enterprise-values sense: the two terms are often related, but they’re not necessarily the same.

When modelling these aspects of service-viability, we need to be aware that these relationships are often highly politicised, and often bound up with some very muddled notions about ‘rights’ or ‘control’. There are also often very strong pressures – especially in commercial organisations – to either ignore all non-monetary forms of value, or to try to force all forms of value into monetary terms, even when it makes little or no sense to do so. Although others may need to work solely with monetary valuations, for our purposes here we need to model the actual forms of value in each context, in their own terms, prior to any conversion to any other form. Failing to do so will invariably lead to architectural problems that can have serious impacts on overall viability – particularly via anti-clients and other kurtosis-risks.

Questions to ask here include:

• Investor – Who or what invests value in this service, in order to get it started, or to keep it running? What forms of value are delivered as investment in this service? Via what services, relationships and exchanges are these investments delivered to this service?
• Beneficiary – Who or what receives value as a return from this service? What forms of value delivered by this service as returns to its beneficiaries? Via what services, relationships and exchanges are these returns delivered by this service?
• Transformation – What are the differences – if any – between the forms of value that are invested, and the forms of value that are returned? By what means do these value-transforms take place within this service?
• Balance – In what ways and to what extent are the invest and benefit relationships in balance, both before and after transformations of value within this service? What relationships with other services are needed to monitor that balance, and/or to take action to correct any perceived imbalance? If the two flows do not balance overall, what impact would this have on overall viability, both of this service and of other related services?

As usual, identify the services and exchanges in each case. Add these to the model as Service-entities and Exchange-entities, linked to the service-in-focus via flow-relations. If necessary, use either containment or composition-relations to link each of these Service-entities to the overall Investor or Beneficiary Service.

Annotate each flow-relation here with a ‘invest’ or ‘benefit’ label, to indicate that the flow delivers investment of some form to the service-in-focus, or that the service delivers benefits to a beneficiary. An ‘invest’-flow will typically connect either to the Service as a whole, or to the Value-Outlay cell, since the latter represents an abstraction of the activities that manage costs and outgoing payments and the like. For much the same reasons, a ‘benefit’-flow would typically connect either to the Service as a whole, or to its Value-Return cell.

Once again, be careful to avoid falling into layering-mistakes (see ‘A note on layers’). There are some very important and often enlightening insights to be gained here, again about the nature of the overall enterprise, and about architectural risks and opportunities. The key concern to note is that the service-in-focus will not be or remain viable unless it does have adequate and appropriate investor-support, and that – in architectural terms, at least – the balance between investors and beneficiaries is appropriately managed.

Iteration and recursion

At this point we’ve now completed the viability-checklist for that single service-in-focus – the Service-entity with which we started. We could now apply the same checklist-assessment, recursively or iteratively, to any of the Service-entities that we’ve added to the model during this process – everything is a service, so the same viability-principles apply everywhere and at every level.

For obvious reasons, don’t attempt to apply this to everything: by definition, it would take an infinite amount of time to complete the model! Instead, it’s wise to hold to the guideline that we only create a model in response to an explicit business-question, and only to the level of detail needed to answer or respond to that question.

In the same way, it can often be useful to do a drill-down into the details of a specific service, and apply the same viability-assessment at the next level down; or to the next level upward, to a more abstract layer at which redesign and restructure becomes possible. (Or levels – again, iteration and recursion would apply in both directions all the way up and down the layers of abstraction.)

In drill-down or drill-up, though, we need to be especially careful about the distinctions between layers of granularity and layers of abstraction (see ‘A note on layers’ again), because it’s very easy to get them confused here. Going up or down in granularity – composition-relations – is just a change in detail: each ‘child’- or ‘parent’-service will handle a subset or superset of the service-content and Exchange-content of the initial service-in-focus. However, going up or down in abstraction – realization-relations - involves a change in the type of detail that can be described: for example, by definition, row-3 cannot contain descriptions of any specific technology or implementation-method, whereas row-4 can.

Beyond that, though, there are no real restrictions on what we can model in Enterprise Canvas, or why: we’re welcome to iterate or recurse to our hearts’ content, up and down the layers, and anywhere across the enterprise context.

It’s all about story

One last point to finish this Enterprise Canvas how-to.

So far everything we’ve done has probably seemed to be in terms of structure, and relationships between structures: services, exchanges, flows, composition and realization.

Yet there’s another equally-valid way to look at architecture: and that’s in terms of story.

One of the first things we say with Enterprise Canvas is that everything is a service. Yet it’s equally true to say that everything is a story.

Every service is a story, represents a story, has its own story to tell.

Every exchange is a story. Every flow or composition or realization is a story. Every change is a story. The enterprise itself is a story, too. Everything is a story.

When we look at an architecture, yes, it’s all about structure, and dynamics of structure; and it’s also all about stories.

And stories engage; stories draw people in; stories give people a reason to be involved in whatever it is that the service does and delivers, and how and why and where and with what it does so. It’s often in the stories that people tell us that we find the most important clues about what’s working or not-working in the enterprise, and what to do to make it work better. In that sense, the stories matter.

So whenever we look at an architecture, whenever we look at structure, we need also to look at, and look for, the stories that underly and underpin and interweave with that structure. And likewise, whenever we look at the stories, we need to look for the underlying structures that they each imply. Architecture is both structure, and story – and more, of course.

So it’s useful to see Enterprise Canvas not just as a framework for models of structure, but also as an anchor for stories, about the enterprise, about how everything fits together (or not) within the unified whole that is the organisation and its broader enterprise.

Something to work with, play with, even dance with, perhaps, as we further develop our organisation’s enterprise-architecture?

Perhaps not quite as technical as some of the other recent posts, but I’ll admit that if enterprise-architectures and the like are not of much interest to you, you might want to skip this one. If that is of interest, though, please do read on!

Information in the Service entity

I said in the previous post that the Service entity needed a name-parameter and not much else. Which was just plain wrong: my apologies…

If we follow the principles of ‘The Metamodel To Rule Them All’, the Service-entity is going to need to carry a lot of descriptive information, about what the service does, what it is, who or what does it, what it uses, where it fits within the overall scheme of things, and so on. (Part of that was implied when I mentioned the use of the ‘single-row extended-Zachman’ to map out service-content – but all that information has to be stored somewhere.)

All of that implies that the Service-entity will need at least one more parameter, and probably several of them. The minimum requirement would be a free-form text field, probably to be used in wiki-style format. A separate and distinct description-field would be useful, too, to help build a service-glossary and service-catalogue.

It’s simple enough to add this in the toolset-metamodel: it just needs to be done from the start, that’s all.

Layers and realization-relations in Enterprise Canvas

A reminder that the layers or ‘rows’ in Enterprise Canvas parallel those in Zachman: they are layers of abstraction – not arbitrary pseudo-’layers’ of implementation, as in classic IT-centric ‘enterprise’-architecture.

The set of layers in Enterprise Canvas are a slightly-extended variant of the Zachman set:

The ‘row-0′ above the Zachman set provides compatibility with ISO-9000 and the like, and represents an unchanging permanent-anchor – specifically, the shared-enterprise Vision and its concomitant Values.

The ‘row-6′ below the Zachman set represents the past, what has actually happened within our architecture; all of the other layers represent future intent, progressively moving closer towards the real-world detail of ‘the Now’ as we move down through the rows. This gives us the support we need for architectural review following a continuous-improvement process such as PDCA or After Action Review:

• What was supposed to happen?
• What actually happened?
• What was the source of the difference?
• What can we learn from this, to do differently next time?

In Enterprise Canvas, we use realization-relations to link between rows – and only between rows. We don’t use realization-relations to connect between the pseudo-’layers’ (‘Business’, ‘Applications’, ‘Technology’ etc) in TOGAF and Archimate and the like.

In most architectural work we’ll focus on row-2 to row-4, shown here as Business-model, System-model and Design-model – otherwise known as ‘business-context’, ‘logical’ and ‘physical’. A ‘logical’ (implementation-independent) design realises – i.e. makes more concrete – the support for a business-need or business-service described in the ‘business-context’; a ‘physical’ (implementation-specific) design realises an implementation for a ‘logical’ service; and so on. (Going the other way, the ‘logical-service’ is the reason for the existence of the ‘physical-service’, the ‘business-service’ is the reason for the existence of the ‘logical-service’, and so on all the way upward to the shared-enterprise Vision.)

If we’re working only within one row, we don’t need (or use) any realization-relations in our model. We only use realization-relations to describe linkages between different layers of abstraction, such as how a specific implementation realises a business-need.

Beware of pseudo-’layers’

I know I’ve said this several times in various posts, but it needs to be hammered home: the ‘layers’ used in IT-centric frameworks such as TOGAF and Archimate are not layers of abstraction, and hence should not be used as layers in enterprise-architecture models. Those pseudo-’layers’ are highly misleading, as they blur the fundamental distinctions between abstraction and implementation-type: for example, the so-called ‘Business’-layer is often used as a random grab-bag containing a jumbled-up mess of any non-implementation-specific abstraction and anything that might be classed as ‘not-IT’. The resultant scrambling of inter-entity relationships is illustrated well in this diagram from the Archimate specification:

Archimate v1.0, Figure 39: (c) Open Group 2009

The relationship between ‘Business Object’ and ‘Data Object’ is correctly shown here as a realization: it crosses a boundary between layers of abstraction. However, all of the other links would be shown in Enterprise Canvas as variations on a theme of composition – i.e. relationships that do not cross layer-boundaries.

Be wary of implicit inter-layer transitions in ‘containment’ views

‘Containment’ is a popular space-saving technique supported by many toolsets, such as Phil Beauvoir’s excellent free Archi cross-platform toolset for Archimate (funded by UK JISC). Within the model, an entity can ‘contain’ other entities, which usually implies that the ‘child’ entities have composition-relations with the ‘parent’.

In Enterprise Canvas, this is implied in the matrix-subdivision of the core Service entity into nine subsidiary cells:

And also implied in the ‘before / during / after’ split of the inter-service flow, as represented in this metamodel by the Exchange-entity:

There’s no doubt that this is ‘cleaner’ and (usually) easier to read than doing the same thing with composition-links:

However, do beware that in some cases, the ‘containment’ may actually be a realization-link, not a composition-link. A very common example is where we would want to show an implementation-independent (row-3) service ‘containing’ the implementation-specific (row-4) services that bring that higher-level abstraction into reality. The catch is that that’s a realization relationship – a transition between rows, or layers of abstraction – rather than a simple matter of granularity within the same layer. Hence if we use ‘containment’, we need some means to distinguish between composition-relations and realization-relations for the implied links between the ‘parent’ and its ‘children’.

One way to do this is that, in keeping with the dotted-line of the realization-relation, we could use a dotted-line rather than solid-line for the boundary of a Service-entity or Exchange-entity. What’s not immediately clear, though, is to which entity we should apply the dotted-line, because the realization could be considered to go either way. One convention we could use is that if only some of the ‘children’ have realization-relations with the parent, then the dotted-line would apply to each of those children; whereas if all of the children have realization-relations with the parent, the dotted-line should apply to the parent:

It would be good if the toolset could manage this automatically for us, but in almost all cases we should be able to do this manually if need be.

Alternate modelling for Exchange entities

The Exchange-entities represent whatever passes between Service-entities in a flow-relation between each other.

In the standard modelling-usage that I described in the previous post, the Exchange is literally placed between Service entities, and the flow-relation links directly to the Exchange on both the ‘incoming’ and ‘outgoing’ side:

This is probably the best way to model Exchange-entities if there’s a strong emphasis on flow-content – as there is in VPEC-T analysis, for example, where we focus on what a service would need or provide before looking for other services that would provide or consume that inter-service content.

But if we’re more interested in relationships between services, with only secondary interest in the content of what passes between them, it may be better to attach the Exchange-entity to the respective flow-relation, rather than visibly interposing it in the flow:

The disadvantage of the ‘attached-Exchange‘ option is that it’s not well suited to showing a split into subsidiary-Exchange items linked to the attached ‘parent’ via composition-relations: visually it becomes too messy, and hard to ‘read’. If you need to show composition / decomposition, use the in-flow format instead.

Ideally, the toolset and its metamodel should be able to support both display-formats. If it can support only one variant, use the in-flow format, rather than the ‘attached’ format.

Keeping things simple

Remember that one of the key aims here is to keep things simple, without ever dropping down into the over-simplistic. If we ignore for the moment the row-0 special-case of the Vision and Value entities, there are only two entity-types in the entire notation: Service, which does something; and Exchange, which represents something that passes between services. That’s it.

Because of that principle that ‘everything is a service’, it should be straightforward to substitute a graphic or photograph for the Service-entity in a model – which should make it much easier to create variations of models that will make visual sense to executives, line-managers and other non-architects, whilst still retaining the formal rigour of the model beneath the visible surface.

And there are only three types of relationship possible between those entities, which in turn follow very simple rules:

• flow-relations (between services) or composition-relations (internal structure of services and exchanges) can only connect within a single ‘row’ or layer of abstraction
• realization-relations (from abstract to concrete) can only connect between layers of abstraction

Again, that’s it.

It would be helpful if the metamodel could also include common non-semantic items such as groups and junctions and annotations, but they’re not required as such for the notation: they’re just useful.

And because the notation is so simple, it allows the true complexity in the context to emerge and surface cleanly through the modelling process. We don’t get distracted by arbitrary pseudo-’layers’: it’s just the enterprise, as enterprise.

For many modelling-purposes, the only relation-type we’ll need is the flow-relation. For example, a simple supply-chain with switching between multiple suppliers:

Or a business-model with multiple client-segments, where we use Exchange-entities to record the different transactions and transaction-content for each client-group:

We use decomposition – modelled via composition-relations – to drill down into more details about structure. When we’re aiming to model trade-offs between implementation-options, or service-substitutions in disaster-recovery, we start to see the real value of a notation that doesn’t make arbitrary distinctions between IT-based, machine-based and manual service-implementations:

For most modelling, we won’t use realization-relations at all. The main occasions where we would use them are:

• mapping ‘logical-to-physical’ transforms, and other moves from abstract to concrete
• mapping dependencies of ‘why’ / ‘how’ between the layers – for example, showing how a specific service contributes to the overall aims of the shared-enterprise

But that’s about it, really. Very simple. And yes, best to keep it that way as much as we can.

Enterprise Canvas – the full set of service-relationships

Because the notation consists of just two main entity-types and three relation-types, it’s certainly simple when compared to other notations. And at first glance it also looks simple when compared with the original Enterprise Canvas summary of inter-service relationships:

Not quite so simple, though, when we map out in this notation the full set of relations shown in that visual-summary above, including the relative roles of each of the flow-relations and all of the implied composition-relations:

That should, I think, give some idea of the full power of the Enterprise Canvas and its underlying concepts: there’s a lot in there…

The original Enterprise Canvas is compact and concise, but it’s likely to be hard to implement in any of the existing EA toolsets. (That original notation is still probably the best for rough-sketches on paper or whiteboard, though.) This simplified version is somewhat less concise, but it would be much easier to implement in an EA toolset, and easier for us to increase its uptake and more general adoption across the EA disciplines. Ultimately, though, just choose whatever works best in the context!

Comments / suggestions as usual, if you would? Many thanks for reading this far, anyway.

The full specification for Enterprise Canvas is in my book Mapping the Enterprise, which at present you can still download for free from here; there’s also a free two-page summary-sheet in PDF format. It incorporates and unifies themes from a wide variety of other model-types in common use in EA, such as Zachman, Archimate, Business Model Canvas, VPEC-T, Viable System Model, Market Model and many others, at first glance it can often seem a fairly complex beast.

The image above summarises the core service-entity and its relationships, but in addition to that, services can be described at seven distinct levels of abstraction, services-flows take place over several distinct phases (the ‘Market Cycle’), and so on. It’s a powerful way to model what’s going on within an enterprise, but there’s a lot to it; and I’d have to admit it’ll seem a bit daunting at first…

And there’s a real problem that at present there’s no EA toolset that implements it. Hence the only way to use it at present in EA modelling is via pen and paper, and then manual transfer to other more constrained, context-specific model-types. Which kind of defeats the object of the exercise, about unifying across the whole enterprise space…

So there’s a real challenge there: compress it all down into a simplified form that can be implemented on an existing EA toolset.

And courtesy of a great meeting yesterday with Alex Yakovlev, it looks like we’ve cracked it:

• one main entity-type (Service)
• one subsidiary entity-type (Exchange)
• three relation-types (flow, composition and realization)

There are also two more subsidiary entity-types (Vision and Value) that are probably optional because they’re only used in one specific context and can be simulated anyway by other entity-types (Service and Exchange respectively).

That’s it.

And it’s all close enough to common model-types such as UML, Archimate or BPMN that it can be implemented via a few minor tweaks to entity-types and relation-types that already exist within those models. Which means that we should be able to translate automatically to and from those other model-types. That’s definitely good news. (For me, anyway. )

So, here goes: formal details for a simplified variant of Enterprise Canvas that can be implemented as a UML Profile or equivalent metamodel in any EA toolset that supports that kind of metamodelling. (Alex is aiming to get an initial UML Profile for Sparx Enterprise Architect done in the next few days – I’ll post here when it becomes available.)

Service entity-type

In Enterprise Canvas, everything is or delivers a service. One side-effect is that that means that, in a model, everything (and everyone) that does something – the service in focus, its suppliers and customers, its investors and beneficiaries, and the services that coordinate, direct and validate it – can all be represented as instances of a single entity-type, Service.

Parameters for the Service entity would depend somewhat on the abstraction-layer being represented.

At the top layer, row-0 ‘Enterprise’, a Service actually represents the shared-enterprise vision, which should be defined solely by its name. (If supported, a Vision entity should be used for this, rather than a Service.)

At the next layer, row-1 ‘Scope’, Service entities can be used (if somewhat incorrectly) as placeholders and carriers for the lists of overall enterprise-content.

At row-2 ‘Business Services’, Service entities should be used, but without much if any content, as the focus at this layer is on key relationships between enterprise-scope services.

At row-3 ‘Service-content’ and below, more detail should added, according to the needs of the respective layer (‘Logical’ implementation-independent, ‘Physical’ implementation-specific, deployment, and run-time record). Content and activity of the service should typically be described in terms of the ‘single-row extended-Zachman’ taxonomy used within Enterprise Canvas:

Toolset implementation: Start from an appropriate metamodel entity-type, such as UML or BPMN ‘Activity’, or Archimate ‘Business Service’. Rename this entity-type ‘Service’. Ensure that it has a ‘name’-parameter; other parameters are probably optional.

For conceptual compatibility with BPMN (‘Activity’), Archimate (‘Business Service’ etc) and UML Activity Diagram (‘Activity’), a Service entity should be displayed as a rounded-rectangle.

Exchange entity-type

The Exchange entity-type represents what is passed between services, or involved in relationships between those services:

Exchange entities should only be used in models representing row-3 ‘Service-content’ or below. The content of the exchange should be described in terms of the ‘Asset’-column in the single-row extended-Zachman taxonomy above.

Toolset implementation: Start from an appropriate metamodel entity-type, such as UML Activity ‘Object’ (‘Document’), BPMN ‘Data Object’, or Archimate ‘Business Object’. Rename this entity-type ‘Exchange’. Ensure that it has at least a ‘name’-parameter, and preferably a text-box and/or checklist to summarise the content of the exchange, as above.

The Exchange entity-type could be represented in several different ways, depending on the content of the exchange, and the notation used as the base for the metamodel. A suggested default would be the ‘data object’ type used in several notations, as above. Alternatively we might use different symbols to represent different asset-types used in the respective exchange: for example, a box for physical objects, a page for information, a stick-figure for relations, and a flash for brands and other aspirational-assets.

However, given that many exchanges may involve multiple asset-types or composites, it may be better to use only the default, or to allow annotation of the single entity-type, allowing one or more of the asset-type symbols as ‘decorations’, similar to the ‘decoration’ add-ons used in Archimate to distinguish between service-types.

Vision and Value entity-types

The Vision and its concomitant Values are the ultimate anchors for everything that happens in the shared-enterprise – or, to put it the other way round, every service and exchange must in some way help towards the realising of the shared-enterprise vision and its values:

The Vision and Value entities should appear only in row-0 ‘Enterprise’, and are the only content that should appear in that row. For most purposes, only one Vision should be used: multiple Vision entities should only be used for the special case of assessing clashes between multiple shared-enterprises impacting on an organisation. (If necessary, a suitably-labelled Service entity may be used as a substitute for a Vision entity.) Use of Value entities is always optional in modelling; any number of Value entities may be attached to a Vision via composition-relations.

Everything in row-1 ‘Scope’ should have a realise-relation to the Vision and, optionally, to one or more of the Value-entities (if any).

Service-entities that are used to represent (‘validation-services’ (i.e. services that deliver ‘validation’ support for other other services, via a flow-relation with a ‘validate’ role), should generally take part in realise-relation chains that ultimately link up to a respective Value entity (if present).

Toolset implementation: In both cases, start from an appropriate metamodel entity-type, such as the Archimate ‘Service’-lozenge or ‘Meaning’-cloud for Vision, and the Archimate ‘Value’-oval for Value. In both cases, the only parameter should be a name of descriptor for the respective vision or value.

For simplicity, the representation should draw on that used for the respective base-type – i.e. lozenge, cloud or oval:

Although usage of distinct Vision and Value entities would be preferred, for clearer modelling, a simpler metamodel-implementation could use a Service entity as a substitute for the Vision entity. In this case, to keep the metamodel as simple as possible, no Value entity should be defined, and hence no specific relation-type links need be defined; instead, the single Service should used as the anchor-point for realise-relations with all layers of abstraction and concretisation (‘rows’) from below.

flow relation-type

Service-entities are connected to each other by flow-relations, to which Exchange-entities may be attached or imposed to indicate what is exchanged between those services:

The flow-relations should only be used in row-2 (‘Business Services’) and below. In row-3 and below, each flow should also take on a distinct role, representing the Enterprise-Canvas inter-service relationships, as follows:

• provide: simple provision of products and services, used to link with other services in Supplier and Customer relationships to this service (a Supplier is a source for or ‘provides’ a flow; a Customer is a destination for or ‘consumes’ a flow)
• invest: a flow from a service in an Investor relationship to this service
• benefit: a flow to a service in a Beneficiary relationship to this service
• coordinate: a flow or exchange with a service in a Coordination guidance-relationship to this service
• direct: a flow or exchange with a service in a Direction guidance-relationship to this service
• validate: a flow or exchange with a service in a Validation guidance-relationship to this service

(An open or ‘unspecified’ role should generally be used in row-2 flow-relations, and in other rows for flows in which the role has not yet been determined.)

Connection-rules are as follows:

• a flow-relation may link a Service-entity to another Service-entity.
• a flow-relation may link a Service-entity to an Exchange-entity, or an Exchange-entity to a Service-entity.

Note that flows can only link ‘horizontally’ across a row (layer of abstraction). They cannot and must not be used to link between services and/or exchanges in different rows.

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘flow’. The parameters should include an optional name, an identifier for the role (e.g. via dropdown-list), and an optional text-area to describe the content (if no Exchange entity is attached), triggering-events and other relevant information.

For consistency with Archimate, BPMN and UML, the flow-relation should be represented by a dotted-line ending in a solid arrow-head, indicating the primary direction of the flow:

(For flow-relations in which there is no emphasised direction of flow, an arrow-head should be used at both ends.)

composition relation-type

In addition to layers of abstraction (‘rows’), we often also need to model layers of granularity (composition), in which we examine in finer detail of the structure and implementation of a Service or Exchange.

The nine subsidiary cells of a service within Enterprise Canvas (a matrix of inbound / self / outbound, and before / during / after the main-transaction) and the three subsidiary flows in an inter-service exchange (again, before / during / after the main-transaction) are somewhat-abstract examples of composition or decomposition. However, these are merely the standard partitionings used in Enterprise Canvas, and any appropriate alternate partitioning may be used instead.

One somewhat-confusing example of composition/decomposition is the purported ‘layering’ in TOGAF or Archimate. In that context, parts of a service may be composed of (actually, implemented by) software applications, which in turn are in part composed of (actually, hosted on) physical IT systems and networks.

All of these can be modelled by composition relations between Service-entities, and between Exchange-entities:

The composition-relations should only be used in row-2 (‘Business Services’) and below. In row-3 (‘Service Content’) and below, it may be necessary to annotate the composition to add further specifics about the nature or sub-type of the composition, for example:

• composition: the ‘child’ services or exchanges are of the same general type as the ‘parent’
• aggregation: the ‘child’ services or exchanges are a mix of structurally-different types relative to the ‘parent’
• assignment: the ‘child’ service or exchange is of a structurally-different type taking on the role of a ‘child’ to the ‘parent’
• used-by: the ‘child’ service or exchange is ‘realised by’ a structurally-different type to the ‘parent’ (e.g. business-service implemented by software-application, in turn hosted-by physical-IT) but at the same level of abstraction

(Note that in Archimate and UML these are all defined as different relation-types. For this context they are best understood as variants on a theme of composition/decomposition.)

The default meaning for a composition-relation is that the ‘child’-entity is of a structurally similar type to the ‘parent’ – i.e. a simple composition/decomposition relationship.

Connection-rules are as follows:

• a composition-relation may link a Service-entity to another Service-entity.
• a composition-relation may link an Exchange-entity to another Exchange-entity.
• a composition-relation may link a Value-entity to a Vision-entity.

Note that composition/decomposition relationships can only link within a row (layer of abstraction). They cannot and must not be used to link between services and/or exchanges in different rows. To link between rows (i.e. different layers of abstraction), always use a realization-relation – a composition-relation should never be used for this purpose.

Take especial care when emulating an Archimate ‘assigned-to’ or ‘uses/used-by’ relation: these are often used in Archimate in a very misleading way, as a kind of analogue of a realization-relation, but one that occurs at the same level of abstraction. Their main function in Archimate, TOGAF and many other IT-centric frameworks is to provide links between their purported ‘layers’ (Business, Application, Technology), which in reality are arbitrary subset-partitions of the conceptual-space. In effect, ‘Business’ is used for anything that involves purpose or human concerns; ‘Application’ is used for all information-related concerns (but for IT-maintained information only); and ‘Technology’ for anything to do with IT-hardware (with no allowance for any non-IT forms of technology). These pseudo-’layers’ have no intrinsic relationship to layers of abstraction, and again are often highly misleading in enterprise-architecture practice. “You Have Been Warned” etc…

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘composition’. The parameters should include an optional name, an identifier for the sub-type (e.g. via dropdown-list), and an optional text-area to describe the composition/decomposition context.

For consistency with Archimate, BPMN and UML, the composition-relation should be represented by a line ending in a solid diamond-arrowhead, with the arrow-head pointing to the ‘parent’:

For other Archimate variations such as aggregation, assignment and used-by, it is probably best to use the respective Archimate line-decoration (open-diamond, dot and line-arrow respectively).

realization relation-type

Links between layers of abstraction – for example, a transform between a ‘logical’ implementation-independent (‘row-3′) service and a ‘physical’ implementation-specific (‘row-4′) instantiation of that service – should be modelled via realization-relations between Service-entities and between Exchange-entities:

The realization-relations should be used between all rows, as appropriate, to create a full trail of dependencies between ‘Why’ (abstract, moving ‘upward’ between rows) and ‘How’ (concrete, moving ‘downward’ between rows).

There are no sub-types of realization-relation.

Connection-rules are as follows:

• a realization-relation may link a Service-entity to another Service-entity.
• a realization-relation may link an Exchange-entity to another Exchange-entity.
• a realization-relation may link a Service-entity ‘upward’ to a Vision-entity or Value-entity.

Note that realization relationships can only link between rows (layers of abstraction). They cannot and must not be used to link between services and/or exchanges in the same row. To link within rows (i.e. the same layer of abstraction), always use a flow-relation or composition-relation – a realization-relation should never be used for this purpose.

Take especial care when emulating an Archimate ‘realization’ relation. These are generally correct, in the sense that they usually link between different levels of abstraction (for example, Data Object realises Business Object); but note that in Archimate they can also be used to link between entities at the same level of abstraction. As usual, the problem here is the misleading pseudo-’layers’ (Business, Application, Technology) in Archimate, TOGAF and the like.

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘realization’. The parameters should include an optional name and an optional text-area to describe the realisation context.

For consistency with Archimate, BPMN and UML, the realization-relation should be represented by a dotted-line ending in a open-triangle arrowhead, with the arrow-head pointing to the more abstract ‘parent’:

No sub-types are required for the realization-relation.

Some comments on modelling

This simplified version of Enterprise Canvas does incorporate all of the original features, but in somewhat different form: a significant amount of the information – particularly around relative roles of services – is now carried within the entities and flows, rather than as per the original entity-notation. There are also some potential inconsistencies in the way relations are mapped in the ‘Scope’ layer (row-1). In some ways this version is simpler to use, but a side-effect is that more responsibility for correct modelling of underlying detail is passed to the modeller rather than explicit in the notation.

By default, colours for entities and flows are not semantically significant. Use colour in any way which suits the meaning best.

A quick summary of the full simplified notation is as follows:

One crucial area of concern is around inter-layer (inter-row) relationships – i.e. via realization-relations. In common with UML and BPMN, Enterprise Canvas demands a rigorous approach to proper modelling of links between versus within the respective layers of abstraction. However, anyone whose main architecture-modelling background is via Archimate, TOGAF or the like may not be fully aware either of that rigour, or of the need for it in practice. The problem is that because of the explicit IT-orientation and implicit IT-centrism of those frameworks, separation of layers of abstraction is blurred together with pseudo-’layers’ of implementation-category, as described above: ‘Business’ for purpose and human focus, ‘Application’ for (IT-specific) information, and ‘Technology’ for (IT-specific) physical hardware. In effect, the ‘Business’ pseudo-layer includes both purpose/human implementation (row-4 and below) and most items in implementation-independent layers of abstraction (row-3 or above). This cavalier approach to layers of abstraction is a major cause of problems when trying to use Archimate and the like in any non-IT-centric context.

In short: use flow and composition-relations only within layers of abstraction (rows); use realization-relations only between rows. Don’t mix them up!

That’s perhaps the shortest summary to a request by Anthony Draffin, in a comment to my previous post ‘Not quite bus-pass day‘:

On a selfish note… It’s apparent that the common thread to dowsing, printing and enterprise architecture is your ability to look at a field holistically and apply logical thought to extract inconsistencies and errors, as well as looking at new ways of doing something more efficiently to meet the original aims. That’s a rare skill. Have you given thought to documenting how you go about doing this? While I imagine it’s the application of a number of taught skills, the way you put these together must be far from ubiquitous. Have you considered teaching this? Personally, as a 27 year old, I want to soak up as much of your approach and thought process as you’re willing to offer.

(Warning, this is going to be another (very) long one, mainly because there’ll be several case-studies.)

Amused that Anthony says he’s 27, because that’s about the age that I really got going on this. (A little earlier, actually: the first dowsing book came out when I was still 24. I used to have to apologise for not being the age people expected me to be, namely at least 75! )

I wouldn’t say that any of what I do is a ‘rare skill’, although it’s true that it’s not often acknowledged or respected – perhaps because, by its nature, it necessarily tends to be disruptive to any comfortable status-quo. I’ve been doing it since a very early age – for as long as I can remember, anyway, certainly way back in primary school – but it’s actually the standard approach used in most forms of design-thinking and the like, as taught in art-college or architecture-school or good engineering courses or even in the US military. It’s also what really happens in scientific research – see, for example, WIB Beveridge’s classic The Art of Scientific Investigation.

My own particular twist on it arose because I’m not much good at doing things, or making things (I tend to describe myself as ‘ambi-sinistral’ – the opposite of ‘ambidextrous’… ). Hence I tend to focus instead on the thinking behind the doing or making or whatever, always searching for the simplest way to do things, the most effective way, and so on. Kind of recursive, if you like, but it works well. Except for that little problem that it tends to be so darn disruptive…

Methods, mechanics, approaches

One place to start would be around skill itself, and the key themes of my Masters thesis, way back in 1976. Back there, I described a skill – any skill – as being made up of three components:

• the methods used in the skill
• the mechanics and other real-world constraints of the ‘objective’ context of the skill – that which is common to everyone
• the approaches, assumptions, mindset, paradigms, physical dexterity and other ‘subjective’ context for the individual (the ‘operator’) – that which is specific to the individual

What I found, very quickly, was that most people seem to focus on the methods used in any skill. But that actually misses the point: the methods used by any skilled operator arise from their own personal resolution of the mechanics and the approaches – the ‘objective’ and ‘subjective’ components of the skill. This is why using someone else’s methods doesn’t always work, and why ‘best practice’ can be dangerously misleading: the mechanics of the issue remain the same, by definition, but the context is different, and hence may well need different methods.

Focussing on method also makes it much more difficult to tease apart the separate threads of mechanics and approaches. It should be obvious that blurring the objective and the subjective is not likely to be a good idea, and yet that’s exactly what happens whenever we focus only on method.

In all skills-work – in fact in just about every human context – we also come face to face with Gooch‘s Paradox: “things have not only to be seen to be believed, but also have to be believed to be seen”. In an all too literal sense, in skills-work, reality is what we say it is: we actually create it, from nothing, or rather from a combination of imagination and hard work. (In this kind of context, it doesn’t really make sense to ask the question “Is it real or imaginary?”, because the only possible answer is ‘Yes’ – both, therefore neither.) To resolve Gooch’s Paradox, we treat the approaches – our assumptions and beliefs – as if they are part of the mechanics of the context. The danger is that we may forget that point about ‘as if’, and – if we think about those assumptions at all – think that they are part of the fundamental mechanics of the context, rather than an arbitrary choice to achieve some particular purpose.

Once assumptions creep in – in other words, whenever the subjective is blurred into the objective without conscious intent to do so – what we have is a context to which arbitrary constraints have been applied. Which places arbitrary limits on possibility. Which is kinda pointless, really. But the only way that we’ll be able to see that the constraints are arbitrary is to step back a bit, and re-separate the subjective from the objective. Hence a kind of recursive methods-to-look-at-methods, analysis-to-unpack-analysis, and so on. Which is what I do.

As I mentioned in my reply-comment, much of the ‘how I do what I do’ is already documented in various ways throughout the books, such as in Everyday Enterprise Architecture (which focusses on method in a business context) and The Disciplines of Dowsing (which looks more at ‘thinking about thinking’). The core of the latter book is the ‘four disciplines’ section (see the summary on the separate two-page reference-sheet) and the ‘seven sins of dubious discipline’ (currently listed only in the book): it wouldn’t take much work to translate those into almost any other context.

What I’ll use here is the Five Element / effectiveness framework that I use in a lot of my client-work these days (though often in somewhat covert form). It’s nothing special, in fact it’s little more than a recursive use of a pair of matched checklists. The first of these, as summarised in the ‘Five Elements’ chapter in SEMPER & SCORE, is a set of perspectives on the overall context:

• Purpose – what are we aiming to do here? and why? (see also the slidedeck ‘Vision, Role, Mission, Goal‘)
• People – who would be needed for this purpose? what skills and relations do they need? what are their mutual responsibilities?
• Preparation – what planning and logistics would be needed for this purpose? what assumptions and mindsets apply here? what are the key events that trigger action?
• Process – what needs to be done to achieve the purpose? when, how and with what would this be done? when is each process complete?
• Performance – what constitutes ‘success’, and for whom? what information and metrics are needed to keep everything on track? what would be needed to support continuous improvement?

The other checklist is a set of keywords on effectiveness, which are sort-of orthogonal yet also sort-of linked to the Five Element set. Listing these in the same order as above:

• Appropriate – is this on track towards the purpose?
• Elegant – does this support the human-factors in the context? (e.g. simplicity, ergonomics etc)
• Efficient – does this make the best (e.g. least-wasteful) use of the available resources?
• Reliable – can this be relied upon to deliver the required results?
• Integrated – does this help to link everything to everything else in a consistent way?

To assess a context, we can start from anywhere at all. The point is that we use these checklists not as linear lists, but as a reminder to keep looking round, bouncing back and forth between each of the interconnected themes in the two lists, looking at the context from every possible angle, and at every level from really-big-picture to finest-detail, building up a kind of hologram of the overall context, using one form of sensemaking to bounce off others, and so on. The book Real Enterprise Architecture provides a complete worked-example of this kind of recursive process as applied to whole-enterprise architectures.

Questioning everything

Looking back at the various areas I’ve worked in or with, there’s a fairly consistent pattern about what I’ve done and the sequence in which I’ve done it.

The first stage is just getting involved at all: taking the ideas and practices at face-value, and putting them into practice as if they are entirely ‘true’. That usually works for a while (not least because that’s what everyone else is doing).

I then allow myself to start to notice the niggles, the things that don’t quite seem to work, where ‘what it says on the tin’ doesn’t actually deliver what it says on the tin. The problem, of course, is that we can’t assess the validity of a logic from within the logic itself. Yet we also can’t actually work on the context without being inside the logic (or some form of the logic). This is where we hit Gooch’s Paradox head-on: we have to see it to believe it, yet also have to believe it to see it. The only way out of that dilemma is to start to use beliefs as tools – which can be kinda challenging…

In my experience, there are two parts to this:

• identify the big-picture theme for the overall context (the ‘vision’ or, as architects would put it, the unifying ‘parti‘)
• apply design-thinking tactics to question everything, switching beliefs in order to experience the context in different ways, and test the apparent results

The tactics to identify the key-theme(s) are usually straightforward. A classic example is the ‘Five Whys’: just keep asking “why?” until eventually we hit a ‘Because.’ – or rather, a real ‘Because.’ that makes some degree of sense, rather than one that’s just used to get people to stop asking awkward questions! These days I tend to look for a brief overview-statement – usually only about three to five words – that has a distinct three-part structure: it identifies the ‘things’ or concerns that matter to everyone in the context, what’s being done with or to those items, and why it’s deemed to be important. This gives us a stable anchor to which we know we can return, and against which we can test anything in the context.

Then, following standard ‘design-thinking’ tactics, we use a suite of ‘disruptive’ questions about the context – for example:

• what’s another version of this?
• what does this look like at a smaller scale, or a larger scale?
• what happens if we substitute something else for this?
• what happens if we invert some or all of the rules?
• is there a ‘term-hijack’ here? – does a small subset purport to be the whole, blocking the view to any other aspect of the context?

This is where things often get to be, uh, fun… – because it’s very common to find aspects of the context that a) don’t and can’t make any sense, b) clearly don’t work ‘as advertised’, in fact usually work against the nominal aims of the overall enterprise, yet c) there are key players with a lot of vested interest in ensuring that the status quo remains unquestioned and unchallenged. Don’t be surprised at this: it happens every time.

This is where a certain amount of dogged determination becomes essential… Also essential is a very clear, insistent emphasis on the big-picture, on holding to the overall vision for the shared-enterprise, because that’s often the only thing that will persuade people that there’s no ‘personal attack’ here, that instead the only purpose of the challenge and the enquiry is to make things work better, for everyone. (We have to be real about that, too: we need belief in ourselves in order to keep going, it’s true, but we need to keep questioning ourselves as well. It’s one reason why serious self-doubt is a chronic yet necessary occupational-hazard here.)

We need to keep hammering at this until we do start to get a clear separation between the mechanics of the context – which usually turn out to be surprisingly simple – and the approaches to the context – which are, by definition, individual and subjective. Then we can start to work towards new methods that work with the context under the current conditions.

The same seems to apply to just about any type of context: an individual’s personal challenges in developing their own skill, a business, a social context, a single conceptual tool, or an entire discipline.

Scattered throughout this weblog and the sister-weblog Sidewise, you’ll find examples of those techniques in use. Sometimes it’s reasonably straightforward, sometimes rather more controversial, but you’ll see in each case that’s it’s essentially the same principles, the same tactics.

I’ll also summarise here those same techniques in use in four different large-scale domains that I’ve been involved with over the decades: dowsing, desktop-publishing, domestic-violence resolution, and enterprise-architecture.

Example: Dowsing (1970s)

Big-picture theme: finding things, particularly where conventional (mechanical/physical) techniques either won’t work or are unavailable.

History: as a discipline, has been around ‘forever’, and often highly controversial – first from priests who regarded it as ‘the work of the devil’ etc, then later from would-be scientists who wanted to ‘explain’ it and couldn’t. When I first got involved, in the late 1960s, the field was pretty much moribund, with a random mixture of wild claims, erratic discipline, no formal methodology or theory-base as such, a long history of inconclusive scientific experiments, and the first flush of hype-laden New Age ‘thinking’ (if that’s the right term…). Most of the people involved were well into their sixties, seventies or more (which I, uh, wasn’t…). The key players consisted of a kind of closed ‘military club’ (water-finding being very important to an army on the move), a few variously-erratic practitioners (often with wild-eyed ideas about health and the like), a swathe of armchair-theorist camp-followers who talked a lot but did nothing, and a few people who really did know what they were doing and wisely kept themselves well away from the mess.

Conceptual mismatch: The most common assertion was that it was a special ‘innate’ skill that only certain ‘special people’ could do. Methods that often clashed or even flatly contradicted each other could lead to the same result; the same method used by different people would lead to wildly different results. Most of the theory in use – such as notions of ‘waves’ or vibrations’ or ‘radiations’ – was either meaningless or just plain wrong in terms of conventional physics. (Much of it did sort-of make sense as metaphor, but there seemed to be little understanding of the difference between active-metaphor and concrete fact.) Muddle-headed ‘New Age’ ideas merely added to the overall mess.

Vested interests: On the one side was the moribund ‘military club’, who liked the idea of being ‘special and different’, and/or the ‘right’ to tell the ‘lower ranks’ what to do, whether it made any sense or not. On the other side were the upcoming ‘New-Agers’, who were not going to let anything block their path to potential fame and fortune. (I’m being cynical, I know, but that’s exactly what happened.)

Assessment and action: Assess the purported theory, and scrap most of it: it’s meaningless. The only parts of the theory that do make sense and do have solid experimental backing revolve around perceptual psychology and physiology – particularly around weighted-sum merging of multiple channels (which is why there’s no single ‘the method’) and around edge-triggered reflex-response (which is why some experienced water-finders can’t find static water even when they’re standing on top of it). If some kind of tool is used, almost all of the tools act as some form of mechanical amplifier – if I move my hand a little, the tool moves a lot. (I’ve only ever found one case where that principle didn’t apply at all.) Materials, structures, theories and so on seemed to matter only because people believed that they did: in most cases, a simpler alternative would work just as well, if not better. Keep stripping it back to the bare essentials.

It is a true skill – but it’s not one that’s restricted to only ‘special people’. Instead, it’s a learnable skill: anyone can do it – though whether they may or will do so are entirely separate questions! (There was quite a lot of pushback from the ‘military club’ against the idea that ‘anyone can dowse’.) It’s also a skill that requires a lot of practice and a lot of discipline to get right. (Unsurprisingly, there was a lot of pushback from the ‘New-Agers’ on that point, and there still is – see the book Disciplines of Dowsing.) It’s also a skill which often requires a wide range of psychological ‘tricks’ to help people slide past Batcheldor’s ‘witness-inhibition’ and ‘ownership-resistance’ – in other words, “this isn’t happening, and if it is, it isn’t me”.

End-result: After a few months’ experimentation and subsequent practice over several years with a wide range of students, I’d stripped it down to the point where I could get most people started on the basics within less than two minutes, using two bits of fencing-wire from the garden as simple instruments. The notion that ‘anyone can dowse’ is now firmly established in the canon, and the teaching-methods that I developed (based on, self-responsibility, self-critique and continual-improvement) are still some of the most common currently in use.

Example: Desktop-publishing (1970s-80s)

Big-picture theme: getting ideas and information out into the public space.

History: I trained as a graphic-designer/typographer, and became professionally involved in typesetting in the late 1970s, with the early developments in smaller phototypesetting machines. (‘Smaller’ being a relative term here: the first system we bought required a room of its own and a separate darkroom, and cost more than my house.) The big bottleneck was keyboard input: the typesetting unit was capable of running much faster than a single operator. Although the internal technology was extremely complex, the input was not: some machines still relied on a very simple 6- or 7-channel punch-tape reader, using control-codes to extend the effective size of the character-set.

At the same time, simple but usable microcomputers were just starting to come onto the market. (My first microcomputer had only an 8-character LED display, hexadecimal keypad and 256 bytes of memory; the more usable Ohio Scientific systems that we first used for real had a proper keyboard but still only 8kbytes of memory, and the only storage was on audio-cassettes.) Almost all of these machines used a 7- or 8-channel character-set (ASCII or extended-ASCII); most also provided some form of direct data input/output for interfacing to other systems.

It seemed to me that there should at least be some way to use a basic micro as a much cheaper input-terminal, using simple code-translation and a standard hardware-interface. It also seemed probable that other people would want to do the same – taking control of their own publishing, driving a typesetter direct, or both. In the longer term, that could well be quite a large market.

Conceptual mismatch: This is best summarised by the phrase (exact quote, in fact) that “there is no interest in typesetting from microcomputers, and there never will be”. There were all manner of arbitrary demarcation-lines across the whole context, both on the pre-press side – such as between authors, publishers, unions and printers – and on the technical side – particularly between typesetter-manufacturers, computer-manufacturers and various hobbyists and hackers – most of which arose more from historical ‘turf-wars’, ‘positioning’, and mutual misunderstanding than from any concrete distinctions. On the union side especially, there were many arbitrary assumptions, based on the belief that technology could not and would not change, or if it did, it could not and would not be allowed to make any difference to existing processes or roles.

Vested interests: The entire context was riddled with vested interests, almost all of which were in conflict. A stream of intermediaries – agent, publisher, pre-press, press, retail – stood between author and audience. Typesetting-systems were expensive pieces of equipment, yet with not all that much to justify their cost: there was lot of money to made there, both from machinery-sales and from fonts and other consumables, and hence a lot of ‘need’ to protect those sources of income. Until IBM eventually stepped in, most of the microcomputer manufacturers were trying to establish themselves as ‘the manufacturer’, resulting in a plethora of mostly-proprietary, mostly-incompatible hardware and software non-’standards’ – at one point we had to buy two machines whose sole function was to read the two hundred or more different disk-formats used on the four distinct disk form-factors then in common use: 8″, 5.25″, 3.5″ and 3″. Weaving a path between all the different vested-interests and proprietary structures was, frankly, a time-wasting nightmare.

Assessment and action: On our first machine, we’d been told emphatically that it was physically impossible to connect a microcomputer; a weekend spent poring over technical specs and waving a soldering-iron around a bit on a prototype-board soon proved that ‘fact’ wrong, whilst the only software we needed at first was a straightforward lookup-table to translate between character-sets. It really was that simple. (We avoided warranty risks by using opto-isolators, so there was no electrical connection between the two machines.) For our later, larger systems – which were capable of typesetting a reasonable-sized book in less than an hour – the hardware-interfaces were already built in. This gave us ‘direct typesetting’ capability, but it still required operators to know – and use – the distinct formatting-codes for each type of machine.

The next step was to hide the complexity, using the format-code in common word-processors such as WordStar to trigger font-changes and the like. (I believe we were the first people to use style-codes, such that a single hideable code – *F1, for example – would change the entire style, including paragraphs, indents, font-family and so on.) At that point, people could use ordinary word-processors to typeset text: the first true precursor to desktop-publishing.

It worked, but there were still limitations. (Our main competitor, meanwhile, was using a mangled form of SGML which still required people to embed hard-codes in the text; in our system, all of the formatting could be invisible.) The main problem was that people couldn’t see beforehand exactly how much space any text would take up – a very important concern to two of our customers, who were producing page-spread books and partworks, Dorling-Kindersley style. Hence some serious code-hacking (all assembly-language, with multiple overlays to squeeze into no more than 40kb of memory) to create a post-processor that would copyfit line-by-line for the correct fonts and sizes, and output a symbolic result to a dot-matrix printer. This was probably the first viable attempt at a true desktop-publishing system – several years before Macintosh and, later, PageMaker.

End-result: I’m good at creating ideas and markets, and all the preliminary work that gets things going, but I’m not good at running businesses – that’s a different mindset entirely. Eventually we sold out to another pre-press company and (in an all too literal sense) I ran away, first to the US, and then onward to Australia. I believe it’s still running, and certainly made millions for the new owners. (I didn’t, of course.)

Example: Domestic-violence resolution (1980s-90s)

Big-picture theme: reducing and repairing the damage from social harm, particularly between individuals.

History: Fights and power-games between individuals in a domestic context have been part of the human story since forever, but had usually been largely covert and ignored as ‘a private matter’ for most of that time. It was brought into public notice in 1970s by women’s activists, most notably Erin Pizzey, founder of Chiswick Women’s Aid. Unlike Pizzey herself (who has always insisted that domestic-violence (DV) is a human problem, not a gendered one), most activists purport that DV is something that happens almost exclusively to women, and caused almost exclusively by men – so much so that some have called for the term ‘domestic-violence’ to be replaced always by the term ‘violence against women’. Most current law (e.g. US ‘Violence Against Women Act’), support-structures (domestic-violence help-lines) and formal theory (e.g. Duluth) reflect this assertion. I became involved in the field during the 1980s as a member of a pro-feminist men’s group who were taking up the feminist challenge that all violence was caused by men alone, and therefore men’s responsibility alone to resolve the (purportedly) ever-rising tide of men’s violence against women. The issues became more personal later when two of my lesbian friends asked me for advice after they had ended their relationship with a knife fight (without injuring each other, fortunately) but had been explicitly shut out from any help because no man could be blamed for the violence.

Conceptual mismatch: The theory was straightforward: men are the problem, women are the solution, and the only useful thing that men can do is blame themselves for everything that goes wrong in the world. Everything in my background supported that assertion, hence it seemed to make sense: self-blame had been a very deeply ingrained habit for me, going right back to earliest childhood. Yet the whole field seemed riddled with gendered special-cases: behaviours that were definitely violence if done by a man were, if done by a woman, either deemed ‘not violence’ or ‘indirectly caused by men, therefore men’s fault’. In the Duluth model, blame itself was classed as a form of violence only if done by a man, and only if the person being blamed was an adult woman: blaming of men (or in essence almost any other form of abuse of men), was explicitly not classed as violence. And the real catch was that, in terms of outcomes, it clearly wasn’t working: no matter how much we blamed ourselves, and blamed other men, the overall level of violence in the culture around us still seemed to continue to rise.

Vested interests: Looking around, it was very clear that there were a large number of players – mostly but not all women – whose identity and self-worth depended on putting men down, regardless of whether or not this actually helped women in general, or anyone in general. There were also very large sums of money, and large numbers of jobs, that depended on maintaining the assertions around women’s purported exclusive victimhood in this context.

Assessment and action: The first warning-signs appeared in one of our standard text-books, Paul Kivel’s Men’s Work: How To Stop The Violence That Tears Our Lives Apart, which is designed around a series of workshops for senior-school students. The book includes many oddly-unrealistic role-play scenarios in which an adolescent boy or young man is suddenly violent or abusive to a woman; yet the only real example of violence described in the whole book is an actual incident in which two girls had a full claws-out fight when one insulted the other in the classroom – and in which no boys were involved at all, other than to separate the warring parties.

After my lesbian friends had their knife-fight, we discovered that no violence-resolution material was available that acknowledged even the possibility that a woman could be a perpetrator of violence. The standard Duluth model defines violence as inherently ‘male’; on the Duluth Wheel, female pronouns are used exclusively throughout to indicate victim, and male pronouns exclusively for perpetrator, and mutuality (where both parties are both ‘perpetrator’ and ‘victim’ of each other and of themselves) – which clearly applied in my friends’ case – is explicitly denied. I decided to try a very simple thought-experiment: swap the gender-pronouns throughout, and see if it still makes sense in terms of real-world evidence and experience. It did: in fact for most of the Duluth categories of abuse it made more sense than the ‘official’ way round. Also – importantly – two key categories of abuse were absent from the original model: sexual abuse, and third-party-abuse. It became immediately clear that the Duluth model itself was structured as third-party abuse, primarily leveraged through other-blame – in other words, far from reducing violence and abuse, it was actually designed to increase it. (Whether that mis-design was intentional, or merely arose from incompetence and excess zeal, is a separate issue that I will not discuss here… – but the fact of its unfitness for purpose cannot be in any doubt.) A simple ‘de-gendered’ redesign resolved almost all of the structural problems, sufficient at least to satisfy my friends’ immediate needs.

That exposure of the extreme inadequacies of the original Duluth model forced our group to reassess all of our previous assumptions about gender and violence, and thence to look again at the research on whose purported facts we’d based those beliefs. I did two analyses of a much-published study on which Australian public policy was based – the first analysis on the public version of the paper and political assertions from it, and the second analysis on the original academic study, which took quite a bit of work to obtain, since it was not publicly available. Another colleague, as his MA thesis, undertook a meta-analysis of domestic-violence studies in Australia. The results were shocking. None of the original studies were based on defensible methodologies – in fact many were so riddled with basic methodological errors such as circular-reasoning that they were essentially meaningless. And in all cases, all of the methodological errors either inflated the female injury-rate or risk, diminished or denied the male injury-rate or risk, or both: there were no exceptions. In short, almost none of what we’d previously taken as ‘fact’ was fact at all. The only genuine facts we could establish was that domestic-violence was a systemic issue with some gendered overtones, and that although it that affected both sexes in different ways, overall it seemed to do so almost equally – though there were strong indications from hospital data and the like that the majority of victims were male, not female.

We then looked at public policy, and the provision of domestic-violence support-services. These too were based on the same fundamentally-flawed assumptions and the same unquestioned circular reasoning: women are the only victims, hence support-services are only available to women; and since only women use these services, this proves that women are the only victims. In some of our interviews we discovered that men who’d been abused – knifed, in one case – were referred to police for charges, simply because the models in use automatically deemed men to be the sole perpetrators, regardless of the actual context or evidence. In short, the entire domestic-violence resolution ‘industry’ it was, and still is, an unworkable and fundamentally dysfunctional mess whose structures and methods are all but guaranteed to cause far more harm than good: an archetypal example of the Shirky Principle that any institution will attempt to preserve the problem to which it purports to be the ‘solution’.

End-result: The domestic-violence ‘industry’ is the outcome of a classic example of a ‘term-hijack‘, in which a small subset of systemic issue is misframed as the whole, and strenuous efforts are made to deny or conceal any other aspect of that issue. In effect, the term-hijack converts a resolvable systemic context into a non-resolvable ‘wicked-problem‘, in which every attempt to resolve a problem is constrained by the structural myopia, inevitably making things worse with each iteration. Unfortunately, there are huge vested-interests in maintaining the term-hijack. Anyone who challenges it – as I and many others have learnt to our cost – is likely to come face to face with extreme violence from women who somehow purport that no woman is ever violent. It seems clear that resolving these structural problems would require a high level of honesty and humility from those players – an honesty that in most cases at present seems conspicuous only by its absence…

Some of the material I wrote is out there and in daily front-line use by others – with real success, according to the occasional emails I still receive on the subject. But to be blunt, after a decade of relentless ongoing abuse from almost all sides, I just gave up and literally threw away most of the work that I’d done… the structural dishonesties in this mess are so entrenched and so ‘political’ that I found it just too painful to be involved at all, and it still seems that resolving the mess would require fundamental shifts in societal attitudes and beliefs that would be unlikely to occur within my own lifetime. Oh well.

The issues are generic, though, and can be resolved at a more generic level. You’ll see how some of these exact same issues are addressed in the business-context in my book Power and Response-ability: the human side of systems and its accompanying ‘manifesto‘.

Example: Enterprise-architecture (2000s-to-present)

Big-picture theme: helping organisations and overall shared-enterprises become more efficient and effective (‘doing the right things right, on purpose’).

History: The main focus of enterprise-architecture is around the relationships between structure, purpose and business-execution.As a discipline, it’s been around for at least a century in various forms, such as Taylorism (‘scientific management’), operations-research and organisational cybernetics. I often describe it as based on a single, very simple idea: that things work better when they work together. Although my work often touched on it over the decades, I first became actively involved perhaps fifteen years ago, when trying to tackle issues around long-term knowledge-management in aircraft research. Over the past decade, most of my work has revolved around various aspects of enterprise-architectures.

Conceptual mismatch: The term ‘enterprise-architecture’ implies a very broad whole-enterprise scope. In recent decades, though, the term ‘enterprise-architecture’ has often been (mis)used to denote a very small subset of the real scope, relating to IT-infrastructure or IT-systems in general. This (mis)usage probably arose from a simple conflation of the term ‘enterprise- or organisation-wide IT-architecture’. The result, however, is a very serious term-hijack: the tiny subset of the overall enterprise represented by IT purports to be the whole, with all other aspects of the enterprise – including people, purpose, physical facilities and non-IT machines of any kind – either concealed or denied. In effect, it becomes all but impossible to discuss any aspect of enterprise-architecture without being forced to describe everything in terms of IT – even in contexts where IT-systems are either not relevant or not available.

Vested interests: There are huge vested interests in maintaining the story that ‘enterprise-architecture’ relates only to IT. Many, many billions of dollars are invested each year on IT-systems that purport to resolve inherently-complex enterprise-scale concerns such as customer-relationships, market-relationships, regulatory-compliance and the like. However, by definition, many if not most of these systems are incapable of resolving all aspects of the respective concerns, in effect converting them into non-resolvable wicked-problems; maintaining the ‘enterprise-architecture’ term-hijack makes it possible to conceal or deny the inherent dysfunctionality of the systems, instead maintaining the faith or fiction that the problems created can only be solved by yet another IT-centric system at yet further cost. There are also large vested-interests in training, certification and the like for IT-centric ‘enterprise’-architectures.

Assessment and action: The starting-point for assessment was a simple review of the term itself, deriving the natural-meaning via term-inversion. The ‘natural-meaning’ of a term is the meaning implied by the individual words of the term. The term-inversion here is ‘the architecture of the enterprise’: hence the natural-meaning is ‘anything to do with the structure and purpose [architecture] that underpin the emotional drivers and actions (the animal spirits of the entrepreneur”) in the shared context [enterprise]‘. The purported exclusive-association of enterprise-architecture with IT does not occur in the natural-meaning: in fact the role of IT in the enterprise-architecture is implied only peripherally, as a minor aspect of support for ‘the animal spirits of the entrepreneur’. In other words, what we’re dealing with here is definitely a term-hijack – and an extremely unhelpful one at that, because the constraint on the scope (i.e. ‘enterprise’-architecture constrained solely to IT aspects of the enterprise) has such a limited connection with the actual scope (which would naturally focus more around people than machines).

Most of my work in the past decade, and particularly the past five years, has been focussed on finding ways to highlight the term-hijack, to resolve the resultant problems and dysfunctionalities, and to create models, methods and frameworks to guide a true enterprise-scope architecture, in some cases all the way out to a global scale. The public outcomes of this work so far include several books, a couple of dozen conference-presentations and other slidedecks, and many, many weblog posts.

End-result: We are getting somewhere with this one. Most ‘enterprise’-architecture conferences these days do explicitly include some discussion of the enterprise-scope beyond IT, usually under a banner of ‘business-architecture’, and there’s much stronger linkage to true business-architecture models and techniques such as Business Model Canvas. The real danger now is there’s a tendency towards ‘business-centrism’ rather than ‘IT-centrism’ – in other words, where the architecture sub-domain of ‘the business of the business’ rather than the sub-domain of ‘the IT-systems’ becomes used as the base for yet another term-hijack. The crucial understanding that we’re still somewhat struggling to get across to most of the players in the field is that in a true enterprise-architecture, everywhere and nowhere is ‘the centre’.

But yes, we are getting somewhere with this one. Slowly…

Summary

So that’s what I do, and how I do it:

• explore a context that is of interest to me
• identify the conceptual mismatches that occur within that context, and that make it difficult to achieve effective results within that context
• identify the vested-interests that drive and maintain the current dysfunctionalities in the context, and, where possible, devise strategies and tactics to disarm and disengage those vested-interests
• assess the details of the dysfunctionalities in the context, and identify or design workarounds for those problems, and methods to work on the context when the dysfunctionalities are disengaged
• document the end-results in various forms, as appropriate

It’s a lot of work, and sometimes very painful work, but someone has do it?

A gentle warning on occupational-hazards

To anyone who might want to do this kind of work, I really ought to add some important caveats.

The work itself is actually not that hard. All it requires is a willingness to let go of assumptions, and tackle each of the issues with a rigorous attention to discipline, following the ever-changing rules of the different disciplines that apply at each moment whilst working in that context. Using beliefs as tools can be kind of challenging at times, but again it’s just another skill, and one that’s not that hard to build up over time.

It’s the social aspects of the work that are hard: sometimes very hard…

For starters, it’s often lonely. Very lonely. Part of that is because there aren’t many people who do this kind of work: at a guess, from what I’ve seen around the net and elsewhere, there may be as few as five or ten thousand people in the entire world who work in this space. Social-media does help to ease the loneliness a bit – the people I work most closely with are scattered literally across the entire globe – but it’s not the same as working in close proximity with close colleagues every working day.

Another part of the loneliness is that the feeling of loneliness – and likewise insistent sense of self-doubt – is actually inherent in the work. It’s almost an indicator of success: as Whitney Johnson put it in her HBR article ‘Disrupt Yourself‘, “If it feels scary and lonely, you’re probably on the right track”. To put it the other way round, the times when we feel most certain are probably the times when we’ve most likely missed the point. It’s hard, and it usually hurts, every single day: so if you can’t cope with a relentless, all-pervading feeling of failure, and yet somehow still create the required results, you really shouldn’t to do this work. There are plenty of other much easier ways to make a living, after all. (This isn’t a macho thing, “I’m tough” and that kind of garbage: in my own case, to be honest, I’m probably not suited to do most other kinds of work anyway. For me, though, there’s a real sense of ‘a calling’, an inner drive to do this work, whether I want to or not: and often that’s the only thing that keeps me going… )

Another crucial point is that whilst there’s a great need for this kind of work, there’s also a huge ‘anti-want’ for it. Every aspect of this work implies some kind of mythquake; and anyone who has a vested interest in the status-quo – which in effect that includes most of our would-be employers, amongst many, many others – will not want that mythquake to occur. It’s disruptive: it is, in a very literal sense, often anarchic. So for much if not most of the time, we’ll need to do the work ‘by stealth’, embedding it in other more conventional analysis-work or the like. Doing it ‘by stealth’ is often the only option if you’re an employee, and even then it can be risky: as one of my ProFuturist colleagues put it, “if you’re employed as a professional futurist, and you’re not being fired at least once every year or so, you’re probably not doing your job properly!”

In my own case, I’ve never been an employee: only ever a self-employed contractor, an independent consultant or running my own business. I’ve survived somehow, though often I don’t know quite know how – it’s certainly not an easy way to run one’s professional-life. But I’m well aware that’s not a viable option for many people, especially those with young families. If you are an employee, and you want or need to do this kind of work, you definitely need a Plan B – and work hard on building and maintaining your professional reputation, such that you can recover from being fired after that ‘one disruption too many’.

Another subtle problem that affects many of us arises from the fact that this work requires us to be very good generalists. The good part of being a generalist is that we’re able to learn fast and be interested in anything, at any level of the enterprise. The disadvantage is that, when people compare us to specialists, we almost always come off second-best – and the fact that we specialise in being generalists doesn’t seem to count, especially where the over-simplistic assessments of recruiters and the like so often come into play. In almost all of my contract- or consultancy-work in the past couple of decades, I’ve ended up doing a different (and much broader-scope) role than the one I was nominally employed for: the problem was that I somehow needed to employed for something in the first place, and that can be a real hurdle. So the catch for us is that we need to be at least as skilled as the typical specialist, whilst also being very skilled as a generalist. It’s not easy, and is one reason why the really good enterprise-architects tend to be older, often into their fifties or more – simply because it takes that long to build up the generalist portfolio and experience whilst embedded in what is (to be honest) often a complete waste of time and effort in a ‘required’ but irrelevant specialist role.

Overall, though, it’s probably the loneliness that hurts the most. But if you can cope with that, and with all of the other challenges of ‘the trade’, then yes, we definitely need you… come and join the club, perhaps?