[In part this is a follow-on from Dave Gray's excellent Dachis Group article 'Everything is a service': I strongly recommend to read that post first before continuing here.]

As Dave Gray indicates in his article ‘Everything is a service’, many people in and around business are seeing a ‘Great Reset’ – a fundamental shift in the nature of the economy, and with it a fundamental shift in the nature of a viable business: a change in focus from products to services.

In a product-oriented economy, an organisation’s market is built around transactions, exchanges of goods and services. Within this metaphor, services are quasi-products, another type of ‘thing’ to be ‘consumed’ by a passive marketplace of ‘consumers’. Financial services, for example, are packaged as ‘products’; so-called service-organisations sell ‘solutions’ to often-unspecified ‘problems’ that a ‘consumer’ is presumed to face.

Producers produce, consumers consume: the roles are explicit, and explicitly separate and distinct. The role of marketing there is to create a market ‘want’ – often entirely artificial – for whatever product the producers want to sell. The role of enterprise-architecture and the like is to support creation of the maximum volume of product for the minimum necessary effort and cost.

The overall view – perhaps still illustrated best by the implied left-to-right flow in the structure of the Business Model Canvas above – is a linear structure of processes. A supply-chain (‘Key Partners’) feeds into the business-processes of the organisation (‘Key Activities’), the results of which are then sold on to ‘consumers’ (‘Customer Segments’). The sequence ends at the ‘consumer’, or more specifically at the moment that the customer has paid for the ‘product’; and everything is centred around the organisation, as ‘the enterprise’.

This view of the market is also often possession-based, with very unequal power-relationships assumed between the organisation and everyone else: we talk about ‘capturing’ a market, ‘owning’ market-share, and so on. This often leads in turn to a very combative relationship across the market, both between organisations competing for ‘possession’ of market-share, and between an organisation and its customers, employees and broader communities – all of whom, perhaps unsurprisingly, may well object to being treated as possessed ‘objects’ or ‘subjects’ of the organisation.

In business terms, one of the key drivers behind the ‘big reset’ or ‘big shift’ that Dave Gray describes is that this model of the market is rapidly becoming less and less viable. Most markets are either at or approaching saturation-point; the hidden-costs are becoming more visible, and harder to externalise; and the supposed economies of scale of mass-production and mass-marketing deliver steadily lower returns, especially relative to smaller and more adaptable technologies and business-models. And in bald economic terms, there are practical limits as to how much ‘stuff’ we can continue to make and sell on a finite planet – limits which in many cases we’ve already overshot. Some real problems there… – and yet they’re inherent in that model of the business-market.

A service-oriented economy is radically different, in that the market is built primarily around relationships. As Dave Gray put it:

A service is at its core a relationship between server and served. Service is work performed in support of another. At every point of interaction, the measure of success is not a product but the satisfaction, delight or disappointment of the customer.

Within this metaphor, products are best understood as proto-services, typically as part of the means for self-delivery of some service. Everyone in the market is both ‘producer’ and ‘consumer’: the roles blur, and are inherently much more equal or peer-based in nature than in the product-oriented economy.

This view of the market is also based much more on mutual responsibilities: we talk about co-creation, about partnering in a shared enterprise. The power-relationships are much more equal, and necessarily focussed on building and maintaining mutual trust – rather than the combative contracts of the possession-model, which mostly reflect an absence of trust.

The overall model still has transactions and processes and supply-chains, but the perspective is different. As Verna Allee describes it, that linear ‘supply-chain’ is actually one view into a much more nuanced ‘value-network’; and a product- or service-transaction is merely one phase within a much larger market-cycle:

Importantly, the fundamental focus of relationships is inverted, from organisation-centric to customer-centric: as Chris Potts puts it, “customers don’t appear in our processes: we appear in their experiences”. The sales-focus also shifts from ‘push’ to ‘pull’, from manipulating or even forcing the ‘consumer’ into a single once-off ‘the sale’, to building a continuing long-term mutual relationship. All of this requires radically different approaches to sales and marketing, but it can be done – and increasingly, is much more profitable than the ‘push’ model.

[For example, compare your experience of the usual soulless time-driven 'customer-as-product' sales call-centre - such as that which interrupted me just now whilst writing this, and who cut me off in the middle of saying "Thank you, but no" - to an intentionally relationship-oriented call-centre such as that run by US retailer Zappos, which focusses much more on respect and mutual trust. Which approach would you prefer to deal with in your business day? The answer's fairly obvious: which is why the conventional call-centre model is becoming less and less viable, no matter how much pressure is put upon the long-suffering staff.

Another first-hand example: a couple days ago I was looking at cameras in the local branch of a medium-sized national chain of camera-stores. The absence of pressure was really noticeable; and the saleswoman's quiet passion for photography per se shone through. The change in energy of the place was very noticeable, compared to the last time I'd been there, a year or so ago: more like an Apple Store than a 'normal' sales-obsessed high-street retailer.

Talking with her, it became clear that the company had made that crucial shift from product-orientation to service-orientation. The key was that they'd come to understand they made most of their money not from selling cameras as such, but from the ongoing photo-print service. Camera-sales became viewed as a means to support that service: it needed to be profitable in its own right, but it wasn't the primary focus for profit. Hence it became much more important to match the camera to the client's actual needs - and that emphasis on matching real needs itself became a key foundation for mutual trust, and hence for long-term relationships that would be profitable to all parties.

Contrast that with the usual high-street high-pressure retailer, where the emphasis is more likely to be about offloading the highest-margin object that the 'consumer' could afford, then dropping the attention instantly so as to move on to the next 'punter' as quickly as possible. "I worked in a place like that for three months", she said, "and I felt like I aged ten years while I was there. Soul-destroying, for everyone. So I know why I'm working here! - because I want to be here."]

So what kind of enterprise-architecture do we need for a service-oriented enterprise? How does it differ from the conventional product-oriented architectures – particularly in its business-architecture and process-architecture? Probably the key requirement is an awareness of the implications of one simple statement:

A service exists to serve.

But what does it serve? And whom does it serve? Architecturally, those are not trivial questions…

In the highly unequal power-relationships in the conventional product-oriented model, the answers are very clear indeed: there is often a thin pretence of ‘customer-service’, but in reality the ‘consumer’ is deemed to exist solely to serve the organisation and its perceived ‘need’ to sell.

[And the organisation in turn is deemed to exist solely to serve the 'needs' of the stockholders, but that's another story...]

But in a service-oriented enterprise, there are two fundamentally-different types of service going on: and the architecture needs to support both of these.

One type – which we might describe as ‘horizontal’ – is the conventional ‘supply-chain’ structure: the service-producer serves the needs of the service-consumer. The issues here that the architecture needs to support are that:

• the relationships between producer and consumer are essentially peer-to-peer
• the roles of ‘producer’ and ‘consumer’ will often blur or even swap over, especially in the ‘co-creation’ relationships that are common in a service-oriented model
• the overall relationships are built via the self-reinforcing loop of the full ‘market-cycle’, as above

The other type of service is more ‘vertical’: within the context of those ‘horizontal’ supply-chain service-relationships, every player in the shared-enterprise serves the same overall vision and values. The market exists within the context of a broader shared-enterprise, defined by a distinct purpose or ‘vision’ and its associated values.

Remember Chris Potts’ point above, that “we appear in customers’ experiences”: there’s a crucial difference here between the organisation and those with whom it interacts. Architecturally speaking, the organisation chooses the vision and values to which it will align. When customers’ experiences – and, for that matter, suppliers’ experiences – happen also to align with that same vision and values, there is then a basis for a shared connection. Serving the same ends – the same vision and values – creates the basis for mutual trust, which then starts the market-cycle rolling.

So the service is delivered through the ‘horizontal’ connection; but the connection only exists because both parties share ‘vertical’ alignment to the same vision and values.

Note that the customers’ experiences – or even supplier’s experiences – may only align with the organisation’s chosen vision for a brief period: think of a restaurant at lunch-time, for example. But whilst that alignment exists, there is the basis for conversation and connection – and hence the first stage of the market-cycle already in progress.

[Back to the camera-shop. The focus throughout the conversation was photography, what kind of photography I might need to do, about cameras in general. Firstly, there was a conversation - which in some stores doesn't even happen at all; and the conversation didn't have an all-too-obvious undercurrent of 'how can we sell you a high-priced camera that you don't need?' - which I've had all too often in the high-pressure stores. Instead, I felt listened-to, respected, safe, served - all of which increases the likelihood that I'd go back there when I am ready to buy another camera. In other words, that first part of the market-cycle is already in progress; and I feel safe in the belief that the closing 'post-sale' part of the market-cycle would be there, too.

Yet note that I wouldn't go there to buy a sandwich, or clothes, or anything that wasn't about cameras - because that isn't part of their vision or purpose that they present. They're clear about what they do and what they don't do, and demonstrate their vision and values in practice: so I know when to go there, and when not to go there. Sounds obvious, perhaps: but some organisations are so sales-obsessed that they give the impression that they'll sell us anything, whether they have it or not, just to make up their sales-quota - and that's really confusing, for everyone.]

Architecturally, the vision and values are the core of a service-oriented architecture: everything in the organisation needs to be understood as serving that vision.

Hence, for example, the value of a service-viability checklist that explicitly includes tracing of support for each of the values as they touch on every aspect of the enterprise.

Hence also the importance of ensuring that that same vision is carried across any partner- or outsourcing-relationships – especially where key customer-facing connections are handled by outsourced others such as an external customer-service centre.

And hence also the importance of keeping the focus on those shared-relationships overall, such as with Chris Potts’ aphorism above. As enterprise-architect Pat Ferdinandi put it, in a comment on an earlier post here:

That’s a brilliant line by Chris. It’s the corporation’s adjustment between customer service and customer loyalty. Customer service is viewed as a “fix” of problems. Customer loyalty is earned by the customer’s experience with the corporation but not necessarily from the corporation. The experience can be from word of mouse of a trusted friend. The experience can be from reviews by “specialists” in the area.

There’s a lot more on these themes scattered around on this site, and in the various books. For example, take a look at the post ‘Where marketing meets enterprise-architecture‘, or any of the articles here on Enterprise Canvas; and the books ‘The Service-Oriented Enterprise: enterprise-architecture and viable services‘, and ’Mapping the Enterprise: modelling the enterprise as services with the Enterprise Canvas‘. The chapter ‘Step 1: Know your business’ in the book ‘Doing Enterprise Architecture: process and practice in the real enterprise‘ also describes the practical processes needed to set up the initial architecture-models for a service-oriented enterprise. It’s all there: all we have to do is do it.

It’s simple, and straightforward: yet it’s often not easy at all. And the reason why it often isn’t easy is because it does require a real shift in perspective, a paradigm-shift – and no-one should underestimate just how hard those shifts are in real-world practice. Yet also don’t doubt that, as Dave Gray says, it is the way that the business-world is moving: so as enterprise-architects we do have to support our enterprises in that change, in whatever ways we can.

Enough for now, anyway: comments, anyone?

The first question is a bit difficult, because the only correct answer would be that ultimately it’s right down at the sub-cellular level – which isn’t likely to be much help in most business-contexts…

So in practice the way we need to answer that question is actually the same way we would answer the second question: the ‘smallest’ service, and the boundary-condition for a service, is whatever and wherever we choose it to be.

I’m not being facetious here: I’m serious. This is actually a crucial point in all service-design – yet it’s a point that many people seem to miss.

First, another key question: what is a service? The short answer is that a service is ‘something that serves’. Which again might at first seem a bit facetious: but seriously, it’s not, because it encapsulates everything that really matters here. At this level, we need to keep to the abstract: hence we deliberately don’t say what the delivered service might be, but instead focus on the fact – or action - of ‘service’. And a service is a service because it serves: and, usually, that it serves or services the needs of something other than solely of itself.

Yes, very abstract – but actually very important from an architecture perspective, because it provides explicit constraints whilst at the same time keeping everything open.

To give a concrete example, consider a kidney. (Okay, you might prefer not, but it’ll do as an example, surely? ) What does a kidney do? From a services perspective, what does it provide? Assuming a living body, the kidney provides a number of services, such as removing excess water from the system, filtering out impurities, breakdown of certain by-products of digestion, some specific functions for the immune-system, and so on. We can then look at various service-interfaces at that layer (mainly the bloodstream and the bladder), the biochemical protocols and exchanges, whatever. All of this would make perfect sense to someone who’s studied anatomy, physiology and the like.

But notice that we’ve invented an arbitrary service-boundary here. We could go up a level, and bundle all of the functions of the kidney under the heading of ‘digestion services’. Or we could go down a level or two, to the individual services that the kidney provides. We could go down quite a lot further, such as to the ‘containment-services’ provided by certain types of cells that denote and delimit the outer edge of what we would generally think of as ‘the kidney’. Yet there’s nothing concrete or explicit that would always define for us ‘the‘ service-boundary: instead, we choose the level, and the service. The boundary of the service is whatever we choose the boundary of ‘the service’ to be.

So, to bring this back to business: what is a ‘business-service’? What denotes the boundary of a ‘business-service’? In practice, we’ll see exactly the same as with the example of the kidney: a ‘service’ is something that serves in some identifiable way, that we happen to describe as ‘a service’.

That’s it: there is no explicit ‘the boundary’ for ‘a business-service’. Which is why we end up with all sorts of names and terms being used, often interchangeably, for all sorts of different ‘services’ within business, with all manner of intense arguments as to which term fits what and which service is ‘above’ or ‘below’ or contains others, and so on. For example, look at all of the chaos and confusion around the following terms:

• business service
• business unit
• business process
• business function
• business capability

In architecture, each of those terms would have a distinct meaning: for example, in Enterprise Canvas, a service is a conjunction of function (a description of what should be done) and a capability (the ability to do something), whilst a process would chain various services together to deliver an overall effect on something. But in most business-usage they’re just alternative terms for ‘a service of some kind, at some level of abstraction’ – with different terms used almost at random as sort-of-synonyms for each other, at different levels of granularity or abstraction. Hence all the confusion, because that arbitrary scrambling makes it very difficult to work what the heck any of those terms actually mean in any given context…

But the quick solution is to recognise that in practice all of them are ‘services’. And once we accept that we are responsible for choosing ‘the boundary’ of a service, suddenly things can get a whole lot simpler. Choosing a boundary will itself imply the service-interface for that particular view or granularity of service. Identifying the interface then also leads us towards identifying the exchange-content, the interface-protocols, and the probable functions and capabilities that this service would require. And because we have that choice, we can move any or all of these around as appropriate, for better fit to what we have available in our architecture or whatever, simply by choosing a different boundary for the service. The boundary isn’t something that’s fixed, predefined, preordained: it’s our choice.

(By the way, we can see exactly the same kind of thing happening with the ‘mote’ concept in the metamodel-structure that I described in earlier posts. Several people asked “what is the boundary of a mote?”, “how big is a mote?”, “which metamodel layer does a mote sit in?”, and so on. The actual answer is “whatever we say it is”: it’s determined by our choice of the context, not by the structure itself. Technically, the mote-structure is defined at the M3/M4 level, but in fact any mote could be used directly at any layer, right the way down to the M0 model-level. And the size of the mote is “whatever it needs to be”: a tag-mote, for example, is tiny – we could almost describe it as being at the atomic level – whereas an complete model and its entire change-history would also be represented by the full related-mote tree of another single mote.)

Hence we come back to the core theme of a service-oriented architecture: everything is or delivers a service. Again, that applies at every level: in Enterprise Canvas, for example, the ‘service-in-focus’ might be anything from a single line of code to the entire enterprise – there’s no inherent difference other than as determined by context. Everything is a service; and the boundary of a service is what we say it is.

Hope that makes some degree of sense?

[Many thanks to Jan for suggesting the topic - and yes, please do comment on this if you wish?]

I was wandering around down town, doing the shopping. Outside this rather nice old traditional-style grocer’s shop, there’s a mob of 20-something students – Swiss, apparently – from the local ‘English as a Foreign Language’ college. Their lecturer is expounding about this shop, telling them in his somewhat condescending upmarket voice that it’s where they ought to buy real English food (??) to take home, and so on. Then he says:

If you see schoolboys walking down the road here wearing purple blazers, they are from the Royal Grammar School. They are the elite, the cream. At age 11 they have to take a special examination in mathematics and English, and only two percent pass that exam.

It’s kinda interesting to apply a services perspective to that assertion. All that the exam tells us is that it selects for ability in mathematics and native-language. Which means that those pupils will, in later life, probably be well-suited to doing tasks that deliver the kinds of services that make good use of those abilities. But that’s all that it tells us. Since every service is ‘just another service’, there’s nothing in there – nothing at all – that indicates that every one of those young students should therefore be described as ‘the elite’.

In service-architecture terms, everywhere and nowhere is ‘the centre’ of the enterprise, and every service is necessary to the viability of the enterprise, hence it makes no sense to describe any category of services – or the people who deliver those services – as ‘the elite’. (Individuals, yes, perhaps; a specific category, no.)

In short, the only reason why those students with that specific set of (proto)-skills in that location would be called ‘the elite’, is because people who are like them and have similar skills want to believe that they themselves are ‘the elite’.

In other words, it’s nothing more than a myth – the kind of circularly self-centric fantasy that’s guaranteed to cause serious dysfunction in a service-oriented enterprise-architecture.

Oops…

And yes, it gets worse! All the way through school, these young students will be told, time and time again, that they are ‘the elite’. That they are entitled to special privilege and special attention because they are ‘the elite’. Which they aren’t, because it’s just a self-aggrandizing fantasy.

Oops…

And wait – yes, it gets still worse! These young people go on to elite universities, elite business-schools, to become elite businessmen, businesswomen. Which they aren’t, because, again, it’s a fantasy.

Oops…

And now, yes, it gets worse again! – because they go on to become ‘the elite of the elite’, the ‘captains of industry’, the managers, who are ‘elite’ because they’re managers.

Yet management is ‘just another service’. There’s nothing inherently ‘elite’ about that set of services at all: every service is ‘just another service’, and every service is, by definition, essential to the enterprise. In a service-oriented architecture, there is no service that is inherently more important than any other: that’s the whole point.

Hmm…

So let’s ask a very simple question – a very difficult, dangerous, politically-explosive question: if every service is ‘just another service’, why is it that as a category, those who deliver the category of services that are called ‘management’ get to control more, and are given more, and paid more – often so vastly much more – than those who happen to deliver a different type of ‘just another service’?

Because as far as I can see it, from a service-architecture perspective, the only reason that they’re paid more is because they purport that they’re ‘the elite’. Which they’re not, because it’s just an arbitrary, self-important fantasy.

A whole load of smoke-and-mirrors to prop up the fantasy, of course – no surprises there. But beyond that there’s nothing of any substance at all: nothing more than a plaintive little chant of “the elite are the elite because they’re the elite”, and kinda hoping beyond hope that we won’t notice how empty that claim really is.

Oops…

Y’know, there might just be a problem there?

—

[And by the way, yes, I did indeed go to that kind of 'elite' school as a child. Which is why I do know, first-hand,  just exactly how vapid, shrill and empty those claims really are... Hey ho...]

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?

Value-trees are a key theme in the model I’ve used for describing the service-oriented enterprise. More specifically, they are the trails of ‘pervasive services’ that ensure compliance to enterprise values. In effect, they are the vertical, management-oriented analogue of the horizontal value-chains of the enterprise. But whilst the value-chains traverse through a single layer of the enterprise – the operations or service-delivery layer – the value-trees, must, by definition, pervade every part of the enterprise, from top to bottom, from abstract strategy to each individual process-step, each line of code. To give one example, we know from painful experience that quality-based themes such privacy or security or business-continuity cannot be patched on as afterthought once the design is complete: to make it work, we must include them right from the start. A key aspect of the value-tree is the trail of relationships and requirements that devolves downward from the enterprise values, and upward as confirmation that the value-requirements have been met.

In short, value-trees are the means by which the so-called ‘non-functional’ requirements are made functional in a business sense.

For the most simplistic example, assume that the only value in the enterprise is profit. (I did say it was a simplistic example. ) A suite of principles devolve from this value: for example, that the outcomes of value-chain processes shall be measured in monetary terms; that costs of all activities shall likewise be measured in monetary terms (hence Activity Based Costing, for example); and that verifiable mechanisms shall be used to contrast these two sets of measurements, to derive a measurement of the value in its specified terms – i.e. profit, in this example. To do this, we’ll need to aggregate (‘roll up’) all the outcomes and costs; and for management purposes, we’ll probably need to be able to disaggregate (‘drill down’) through the business-units and groups and clusters, all the way back down to individual activities. The connections and transforms for aggregation and disaggregation are the branches for the value-tree.

A classic PDCA (plan, do, check, act) approach to quality-management – i.e. management of the value-tree – means that the tree itself needs to be supported by four distinct types of activities:

• develop awareness of the value itself, and of the need to monitor the value
• develop capability to enhance monitoring of and improvement against the value
• measure compliance of activities against the value
• verify and audit to monitor and enhance compliance and continual improvement

(Note that some of these may be required to be kept separate, by law or other regulation – for example, financial reporting versus financial audit.)

Next, extend the example to a slightly more realistic set of values. This leads us to something like Balanced Scorecard, which defines enterprise value in terms of four distinct themes: together with the existing financial measures as above, we add perspectives for Customer, Internal Business Processes, and Learning and Growth. Each of these themes has its own value-tree. (One reason why Balanced Scorecard implementations sometimes fail to give the desired results is that the value-trees don’t reach down far enough into the enterprise: if we take a service-oriented view of the enterprise, every activity has a ‘customer’, has its own ‘internal business processes’, and its own capability and need for ‘learning and growth’.)

To extend this further, each of the ‘-ilities’ trails of ‘non-functional’ requirements implies a root-value – for example:

• quality (in terms of the delivered business services or products)
• security (in all its multitudinous variations)
• privacy
• trust and reputation
• health and safety
• environment and waste-management
• transparency and ethics
• efficiency and effectiveness

As described well in TOGAF, each of those themes devolves outward via a set of principles, which ultimately need to link to everything. But on its own, a principle does nothing: it must be applied in practice (hence the importance of governance), and needs to be testable – and that testability must likewise ultimately link down to everything. (Testability isn’t described as such in TOGAF’s definition for the structure of principles, but is described well in Volere, the requirements-modelling process recommended in TOGAF.) The requirement-trees are the means by which the ‘develop awareness’ of the value-trees devolves downward; the tests in those requirements form part of how ‘monitor compliance’ of the value-trees rolls upward.

So a value-tree consists of the following:

• explicit value or ‘theme’, as topmost anchor for the respective tree
• principles that express and describe the value in practical terms (upper branches of the requirements-tree)
• requirements and tests, all the way down to the finest-granularities (both goal-oriented [end-point] and mission-oriented [continual / continuing])
• measurements, with tree of transforms and identifiers for roll-up and drill-down
• support-processes (‘pervasive-services’) for ‘develop awareness’, ‘develop capability’, ‘monitor compliance’ and ‘verify’

Each tree is fairly straightforward in itself: the complications arise from the fact that many of them will present conflicting requirements (e.g. security versus trust, safety versus efficiency). Because of this, there needs to be a tree of relative priorities, some of which may be imposed from ‘outside’ (e.g. legal requirement for priority of health and safety before profit). Ideally, there needs to be one single ‘master-value’ which acts as the ultimate arbiter for priorities – hence the importance of an unchanging enterprise vision.

Better stop there for now: but as usual, comments/suggestions would be most welcome!

Another new book in my Tetradian Enterprise Architecture series went off to press yesterday: The Service-Oriented Enterprise: enterprise architecture and viable services. So there’s a good chance it’ll be back in time to take to the TOGAF San Diego conference, which was the real reason for the deadline. Good.

The ‘sampler’ version of the e-book is now up on the Tetradian website; likewise the full version is on the private ‘preview‘ section of the site (as ’9781906681173_services_EB.pdf’), with the same password access-code as usual. Comments much appreciated, as always!

Physical books should be available from Amazon and other retailers from about a week from now. Will post updates on that when they’re available.

Now, back to catch-up mode… a lot of backlog emails to deal with, for a start – apologies to all on that. More later.