Services and Enterprise Canvas review – Summary

What is a service-oriented architecture – particularly at a whole-of-enterprise scope? How best could we describe that architecture? How do we use that service-oriented approach to help enterprise-architecture break free of the IT-centrism that’s crippled it for the past couple of decades?

The past few posts here have been a review of a model-type I developed a few years back for service-oriented architecture, called ‘Enterprise Service Canvas’, or, more usually, just Enterprise Canvas. Yes, there’s an awful lot in those ten or so posts (almost 25000 words and just under a hundred graphics and other images – around half of a medium-sized book), and at first, yes, it does indeed look ‘complicated’ (as one person complained elsewhere). But why would anyone expect any less, considering that it is, quite literally, almost the equivalent of a primer on ‘how to architect an entire building’, but at an even larger scale?

As with building-architecture, the hard part of enterprise-architecture is not the fine-detail of any one part of it, but how everything works together as a unified whole – and that’s what Enterprise Canvas is really all about. As a consistent pattern that applies to every type of service, everywhere, it makes that making-sense-of-the-whole-as-whole a lot easier than it otherwise would be. Yes, it takes a bit of effort to get the head around all of Enterprise Canvas, and how all of those elements interweave with each other: but once we do do that, it suddenly becomes self-evident just how powerful it really is, and how much simpler it makes the overall task of enterprise-architecture. That’s my experience, at least: ‘Your Mileage May Vary’, as they say… 🙂

Anyway, after the brief introduction, what we covered was as follows:

— 1: Core: what a service-oriented architecture is and does – We looked at the nature of service itself via some deliberately everyday-examples of services – of which, also by intention, only one was much about IT in the usual sense.

— 2: Supplier and customer: modelling inbound and outbound service-relationships – Services serve: that’s why they’re called ‘services’. More specifically, they serve someone’s needs, via value added to and flowing around a shared-enterprise.

— 3: Guidance-services: keeping the service on-track to need and purpose – Most if not all services need other types of interrelations with other services, beyond just the basic value-flow around the shared-enterprise.

— 3A: Direction: identity, purpose, strategy and management – One of those support-connections is to services that provide guidance: what’s often loosely described as ‘management’, and more.

— 3B: Coordination: programmes, change and run-time – Another support-connection is to those less-visible services that help to link everything together, ‘bridging the silos’ and suchlike.

— 3C: Validation: keeping on-track to purpose – A third type of linkage is with the often even-less-visible services that help keep this service connected to (and, where appropriate, compliant with) the vision and values of the shared-enterprise.

— 3D: Investors and beneficiaries: support for and from the organisation – Yet another type of value-flow, this time from and to a wide range of other ‘external’ stakeholders.

— 4: Layers: how we partition service-descriptions – The way we describe our services needs to change as we move closer to real-world implementation, or further away from the real-world to enable redesign.

— 5: Service-content: looking inside the service ‘black-box’ – This section provided a visual-checklist to describe the structure and content of services, in the terms needed for those ‘layers’ of service-description from the previous section.

— 6: Exchanges: what passes between services, and why – Whilst the previous section looked at the services themselves, this one provided another visual-checklist to describe what needs to pass between those services.

In parallel with those posts, there’s also a slidedeck that summarises that whole content, that I did for a conference in London on the relationships between enterprise-architecture and systems-thinking, organised by Jiri Ludvik and others from SCiO. Here’s that slidedeck: ‘Bridging enterprise-architecture and systems-thinking – an introduction to Enterprise Canvas‘:

I’ll add a voice-over track somewhen, but it’s actually quite self-descriptive and self-contained, even with just the slides alone. Share And Enjoy, perhaps?

How do we use all of this stuff?

Most existing enterprise-architecture tools and model-types seem to be developed and used primarily for what I’d call ‘final models‘ – the kind of static, unchanging ‘blueprints’ that represent the end-point of the design-process and the start of implementation. In practice, though, most our real work in enterprise-architecture seems to be about working with the ‘messiness’, assisting a myriad of stakeholders in the enterprise – all of them with their own often mutually-exclusive values, viewpoints and perspectives – to work their way through all of the conflicts and confusions and uncertainties towards a real shared and practical intent for the enterprise.

As I’ve said elsewhere, I view enterprise-architects as the custodians and promoters of a core idea, that things work better when they work together, on purpose. Yet that ‘working-together, on purpose’ doesn’t happen by itself: there’s a lot of ‘mess’ to work through first (and continuing onward, too). And we need tools that work with the fact of that ‘messiness’, rather than pop up to pick up all of the credit when all of the hard work is already done.

That’s the real role for Enterprise Canvas: helping us in working through the ‘messiness’ stage. That’s why it’s designed to work not only as a ‘finished’ UML-like notation:

…or something that looks good in a book or on a blog-post:

…but, even more, in sketch-type scrawls on a whiteboard, such as this:

…or this:

Scribble. Scrawl. Sketch. Scratch it out and start again. Stick on a sticky-note or two. Capture it on camera, then move on. Again. Argue. Disagree. Discuss. Dialogue. Dance around the description – how do we say this? how can we best describe it? what’s different? what’s the same? what’s new? what’s old? could we do it this way? or better that way? what works? what doesn’t work? how, when, why, who, with-what? Then do that all over again, with the next stakeholder, and the next, and next. Meet up with a senior executive before breakfast; follow up with a fork-lift truck operator in the warehouse at mid-morning break; maybe a programme-manager and a process-designer at lunchtime; facilitate for a full-on clash all afternoon between the org-dev guys, the devops crew, the CIO who’s worried about what’ll happen to all her legacy-systems in the move to mobile, and the legal office who says that none of it’s compliant with the new regulations coming down in China next month. And do the whole thing all over, tomorrow, and the next day, and the day after that, day after day, all with yet another group of stakeholders each time. “Things work better when they work together, on purpose”: yes, that is indeed the outcome that we’re aiming for – yet it takes a lot of work to get there…

That’s what most of real enterprise-architecture work is like. By contrast, the notion that enterprise-architecture is mostly about hiding away in some ivory-tower, churning out pretty diagrams that make sense only to other architects, would seem little more than a laughable luxury!

What I’ve long since found, in my own practice, is that one of the best ways to tackle this ‘mess’ is to start from the idea of services – that ‘everything in the enterprise is or represents or implies a service‘. Yes, we do know it’s a bit of a kludge in some ways, and that other approaches are entirely possible, sometimes maybe even better than a service-based approach in some contexts: but this way is a lot simpler, simply because it allows us to work with the exact same consistent frame everywhere, whatever and wherever it is that we’re working on at the moment. Simplicity is its own huge dividend when we’re working with a full-on mess of mutual misunderstandings and misinterpretations…

So yes, Enterprise Canvas has its own somewhat-strange notations, some which might at first make sense only to other architects: but for the most part, all they are is a set of visual-checklists to help us ensure that we don’t miss anything important when we’re working in the midst of the mess.

And yes, Enterprise Canvas has its own somewhat-idiosyncratic-seeming set of terms and terminology, some of which we perhaps might indeed have to keep to ourselves and our conversations with other architects: but those particular definitions are essential if we’re to maintain consistency and rigour of description across the entire enterprise-space – and keep our own sense and sanity together in the process, too…

We translate into others’ terms as much as is needed: that’s the whole point of our work, really, to act as translators so as to help all those different people to work better together, on shared-purpose. But amongst ourselves, as those everything-to-everything ‘translators’, and for consistency across the whole, we need a terminology and a set of checklists that are consistent everywhere. That’s why we need a fully-consistent approach to enterprise-architecture, fully-implementation agnostic at the more abstract levels, such as that which a service-oriented style of architecture provides. And that’s why we need something like Enterprise Canvas, to provide consistency and rigour – a form of discipline that even the least-disciplined can follow – across all of ‘the mess’.

Scribble. Sketch. Scrawl. Scratch it out and start again. Stick on a sticky-note or two. Capture it on camera. Again. Again. And yet again. Yeah, it’s a mess, much of it. And those standard ‘final models’ notations aren’t much use for that – more often a hindrance than a help, if we’re honest about it. Yet Enterprise Canvas is a real help for that – and yet also translates cleanly into those formal models once the dust has settled down. That’s what this is all about.

Makes practical sense now, I’d hope?

(And yes, I haven’t forgotten that I’d promised a worked-example: but reality is that this post is, as usual, way too long already – so I’ll do it as a separate post, coming up next.)