Our organisations often place enormous attention on insubordination, a refusal or failure to follow ‘orders from above’; yet why don’t they place the same level of attention on insuperordination, the refusal or failure to respect the the same relationships and responsibilities to those ‘below’?

For that matter, why do we still prop up the misplaced myths of ‘above’ and ‘below’ anyway? After all, in a service-oriented view of the enterprise, there is no hierarchy - they’re all just mutual peer-level service-relationships, no different in nature from any other. And does anyone benefit from those myths any more? – other than people who need to prop up arbitrary and unwarranted delusions about their own importance?

This came up for me today from three different directions:

• reviewing several posts here on management-architectures, particularly ‘Rethinking the architecture of management‘, ‘Management as ‘just another service’ ‘ and ‘Rebalancing top-down management-architectures‘
• a Tweet from SystemsWiki, pointing to a brilliant HBR paper by Gary Hamel, First, Let’s Fire All The Managers‘ [PDF]
• thinking about ‘bosses’ I’ve known – some good, some not-so-good, and some just plain incompetent

I’ll happily give names to the good ‘bosses’ – Helen Mills at Australia Post, for example, or Graeme Burnett at DSTO. For the others, well, I’d best be a bit more circumspect, hadn’t I? – which is an interesting point in itself…

But there’s one of the latter that comes particularly to mind. It was on a large engineering-project a couple of decades or so ago; almost all of the team were contractors, some of them world-class level, because it was a genuinely innovative system that had to do things that had never been done before. To make it all work, and to hold the team together, we needed a manager at the same kind of skill-level. What they gave us instead was – to be blunt – an incompetent idiot, a classic civil-service time-server, eking out his last years before retirement. Not a good choice…

He was way, way out of his depth and his comfort-zone – a fact that became painfully obvious even before the first day was out. He had no experience or understanding of the inherent anarchy of innovation: as an ex-military-type, all he knew was command-and control. Which really, really, really didn’t work.

We limped on under his endless incompetence for a few months, until one day it all came to a head. At a particularly fraught team-meeting, every one of the contractors blew up at him, saying that he alone was the reason why the project was so far behind schedule; furious, he rushed out, accusing everyone of insubordination, and yelling – and I quote – that “I’ll have all of you frog-marched out of the establishment!”

At that point, the executive realised they needed to intervene, kinda urgently… The team explained to them that whilst, yes, they would perform best with a good manager, they would actually be better off with no manager at all than with this guy. And for once – hooray! – we actually had senior-management who had some real grasp of what was going on – and they agreed. So for the rest of the project, we ran as a self-organised team, without any manager at all.

In short, our incompetent manager had been fired for insuperordination – failing to deliver the required management-services to the level needed within that context.

Looking around at most management-structures, it’s clear that that needs to happen a lot more often…

And this, of course, is where it can get v-e-r-y tricky for enterprise-architects and the like. We can see what’s not working. We can see why it’s not working. We know exactly what to do to get it working again. And yet we’re supposed to pretend that the myths of management-hierarchy are somehow sacrosanct, that insubordination is real and punishable, but insuperordination and plain management-stupidity is not. We’re allowed – in fact required – to ‘fix’ anything and everything except that which is the blatant cause of the problems, namely those myopic myths of management, which we’re not allowed to challenge at all. Hmm… About time we started being honest this, don’t you think?

Implications for enterprise-architecture

Insuperordination isn’t just lack of leadership: it’s a structural failure of the management-model to support essential symmetries of responsibility in mutual service-relationships.

And as a structural flaw – one that has serious impacts on overall enterprise risk – it’s very much a concern for enterprise-architecture.

The key requirement here is to stop thinking in terms of hierarchies. If we take a service-oriented view, it’s clear that management-services have a very real function, as information-aggregators and resource-distributors, dealing with the trade-offs across a functional-silo.

Yet those types of services are not well-suited to managing end-to-end cross-silo process-flows: there needs to be a separate category of coordination-services that handles that task – a fact which immediately implies matrix-relationships of some kind.

And those matrix-relationships need to be peer-to-peer – which doesn’t fit at all with any Taylorist-style concept of top-down management-hierarchies.

In short, top-down ‘command-and-control’ hierarchy is an overlay on top of a tree-structure that arises naturally from aggregator/resource-distributor relationships. The tree-structure provides a genuine service; the hierarchy, all too often, a genuine disservice. Don’t conflate the two structures: they’re not the same.

The way to separate them is that the tree-structure could be viewed in any orientation: top-down, bottom-up, sideways-in, centre-out – it’s all the same. But the hierarchy is always described as top-down: it can’t be made to (seem to) make sense in any other way.

The top-down management-model is essentially a leftover remnant of a supposedly long-dead feudal past, in which position in that hierarchy denotes ‘rights’ to demand subservience on pain of punishment for ‘insubordination’. As a structure based entirely on ‘power-over‘ – with all the dysfunctionality that that implies – it can only be made to seem to work as long as there is no need to engage the ‘subordinates’ actually in the work: “check your brain in at the door” is how one colleague described it. But when the work does require that kind of personal engagement – as is becoming more and more common throughout almost every business context – then the overall system will either operate only at low efficiency, or even fail to operate all, if that ‘conventional’ command-and-control hierarchy is allowed to remain in place.

It’s an architectural choice. Command-and-control hierarchy will only work with low-agility: if we need to preserve command-and-control hierarchies, we will not be able to achieve high-agility in that context. If the organisation – or some part of the organisation – needs high-agility, we must define a structure in which that section of management is peer-based, as ‘just another service’ – and in which the responsibility-failures of insuperordination must be recognised as exactly symmetric with insubordination.

In any given context, we can choose one model, or the other: they don’t mix well, and we can’t have both in the same context – as even current military doctrine [PDF] now makes clear.

If we want our organisations to work, we need to stop pretending that insuperordination doesn’t exist – and instead acknowledge that it’s one of the most serious sources of organisational risk.

That’s the message that we need to give to our enterprise-architecture clients.

Challenging, yes – but it’s the only way that this is going to work.

Comments/suggestions, anyone?

[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?

Quite a lot, as it happens. There are a fair few models that are explicitly designed to tackle this rebalance problem, and plenty of practical real-world tactics, too. In this post I’ll summarise the mechanisms that support this in Stafford Beer’s Viable System Model; a real example from the 1960s that uses some of the same principles as in the VSM; and two more recent examples, one from an engineering research-laboratory, the other from current Army doctrine and practice.

(Not too long this time, I hope?)

Viable System Model

Stafford Beer’s Viable System Model [VSM] was first developed back in the early 1970s. It’s well-established, well-proven, and applicable to any size of organisation – including the management of the economy of an entire country. At first glance, though, it looks like a straightforward Taylorist-style hierarchy, with the system-3/4/5 cluster as ‘the management’, and system-1 as ‘the workers’, each connecting in their own ways to the ‘cloud’ of the real-world:

Unfortunately this early diagram from the Wikipedia site, based on Beer’s original notes, is actually more than a bit misleading, because some of the most fundamental concepts of the model are not obvious, or not shown at all.

The first key point is that the model is fractal: the pattern repeats in a ‘self-similar’ way at every level. In that sense, everything is actually a ‘system-1′: whatever it looks like, whatever ‘system’-label it might have, it delivers some kind of service. Conversely, every ‘system’ or service contains within itself, in some form or other, the whole of this pattern: hence a ‘system-1′ delivery-service also contains its own element of ‘system-5′, ‘Decisions to maintain identity’ and purpose – in other words, more like Deming than Taylor.

Next, ‘system-2′, the set of services for inter-service coordination and ‘Tactical planning’, is not bundled into the ‘management’-cluster; and neither is ‘system-3*’, ‘Audit’ (which I usually expand to what I call ‘validation-services’). In effect, they’re orthogonal both to the ‘system-3/4/5′ management-cluster, and to each other:

If we try to hold to a strict Taylorist model of management, we would either have to subsume all of these functions into ‘management’ – where they really don’t work, because they need to be independent of management, even by law in some ‘system-3*’ cases – or else we’re likely to find ourselves with lots of fights and arguments from ‘system-3′ middle-managers about ‘insubordination’ by ‘system-2′ and ‘system-3*’.

To make this work, we need a structure that acknowledges the semi-autonomy of ‘system-2′ – particularly for cross-silo coordination and cross-domain change-programmes. It also must acknowledge the even greater autonomy of ‘system-3*’ – which does link strongly with the management-services, but usually at least one more levels ‘above’ its nominal level. In the inter-service relationships in Enterprise Canvas, this expands out a bit as the full set of services in the overall ‘Guidance’ cluster, where ‘system-3/4/5′ are the direction-services, ‘system-2′ the coordination-services, and an expanded ‘system-3*’ as the validation-services:

Yet there’s one more element in the VSM model that appears briefly in that VSM diagram earlier above, yet isn’t properly explained: a link that Beer describes as an algedonic connection. (It isn’t separately documented in Enterprise Canvas because in effect it’s just another type of inter-service connection.) The term literally means ‘pain/pleasure’, but the point is that it allows an ‘any-to-any’ connection that may bypass the ‘official-channels’ of the entire management-hierarchy, linking right from ‘bottom’ to ‘top’ if necessary. It’s typically reserved for emergencies, but it needs to be present if the overall system is to be viable.

That’s the core of the theory, anyway: let’s see how it works in practice.

Management on an aircraft-carrier

I came across this example more than forty years ago, in an article in Scientific American in the senior-school library, and it was one of the things that first got me started me thinking about enterprise-architectures.

The article was about management-structures in high-stress environments: the aircraft-carrier was one of four examples discussed. (Another was electricity power-distribution, but I can’t remember the other two.) The key point was that they all had much the same type of organisational structure, which we might describe as ‘hierarchy/flat’. Each environment maintained a very strict hierarchy, with defined ranks and roles, each with their own explicitly-defined responsibilities and reporting-relationships – so at first glance, the naval ranks on the aircraft carrier might seem little different in structure from those back in the dark days of Sir Cloudesley Shovell. Unlike in Sir Cloudesley’s time, though, the management-structures also supported ‘any-to-any’ links: even the lowest of ‘erks’ on the aircraft-carrier had not only the authority but the duty to go over the heads of their immediate officers and talk direct to the admiral if necessary – and the admiral and everyone else had an explicit duty to listen, too. In general, ‘any-to-any’ communication was reserved for emergencies only, and the ‘erk’ would need to be able to give fair reason to have bypassed ‘official channels’: but there are so many unexpected and unpredictable things that can go wrong on an aircraft-carrier that that option definitely needed to be in place – with official support and sanction.

(Another type of algedonic link common in many present-day organisations is an ‘open email-address’ for the CEO and other executives, that employees can write to, and expect an in-person answer.)

And whilst the Taylorist-style system of ‘ranks’ was strictly enforced, there were also explicit rules and rituals that emphasised that everyone was also equal. One example was that everyone – the admiral included – had to do their turn at the tedious task of ‘FOD’, or ‘foreign-object detection’: everyone in a line, shoulder-to-shoulder across the full width of the flight-deck, walking slowly along the whole length of the ship, to search for loose bolts or bits of wire that could puncture a tyre or end up in an aircraft-engine. Another example was that everyone, right down to the newest recruit, would each have their own birthday-cake baked for them by the ship’s cooks: the personal element of this was deemed so essential for morale that the admirals forcefully overruled an attempt by the Navy’s bean-counters to save money by getting the cakes pre-baked on-shore.

So that’s a ‘hierarchy/flat’ management-structure, designed to balance the need for clear command with the need to manage a wide range of largely-unpredictable emergencies. In the aircraft-carrier example it pre-dates VSM by a decade or two, but it should be clear, I think, that the same overall principles do apply.

Engineers and fitters in a research-laboratory

During one part of my aptly-named ‘career’, I worked for some years as a contract software-developer at an engineering research-lab. During that time I got to know well the fitters and toolmakers who constructed all of the test-rigs and other equipment used in the engineering experiments. I gained a lot of respect for their skills, and so did most other people at the lab – though for some of them that happened only after an interestingly subtle ‘teaching-ritual’…

Each year, the lab took on a new crop of graduate engineers. And each year, at the end of summer, they would arrive with their shiny new degree-certificates, certain that as now-qualified engineers they knew everything that there was to know about engineering. Unfortunately, almost all of them would assume that, solely because they’d had formal academic and analytic training, by definition they must know much more about engineering than any of the lowly ‘workers’ in the toolroom. Some of those new graduates were quite startlingly arrogant at first: in classic Taylorist tradition, they would give orders, and demand that others should follow those orders to the letter.

In reality, though, there are other kinds of knowledge than the purely academic: and if those new graduates were to become of any practical value as engineers, they needed to understand and respect that other knowledge. So each year, with the agreement of the lab’s senior management, the toolroom foreman would order a strange ‘work-to-rule’: the fitters were instructed to create equipment exactly as specified – even if it didn’t make sense.

The results of the work-to-rule were, often, uh, interesting… One new graduate delivered a design for a rotating component that specified a zero tolerance on both sides – which couldn’t be built on any equipment in the toolshop, and even if it could, it wouldn’t be able to rotate. Another graduate came in with a design whose components could all be made – but couldn’t be assembled, because there was no clearance to get in to tighten the bolts.

In most cases the new graduates immediately blamed the fitters for all of the problems: after all, the world should conform to our designs, shouldn’t it? The foreman would take each of the complainants aside and, uh, gently introduce them to the other side of engineering, about how to make things work in the Real World – about which the fitters knew a lot more than the new graduates did. If the graduates didn’t listen, or didn’t stop blaming everyone else… well, they soon found that it wasn’t just the foreman, the senior management were serious about this too – so serious about it that some of the graduates were politely requested by HR to find another job elsewhere.

The practical point was that the new engineers soon learnt that theory only goes so far: they needed the help and hands-on experience of the fitters in order to come up with designs that would actually work as intended. In a matter of months at most, we would see the new engineers working closely with the toolroom crew, in most cases developing strong mutual respect. Theory needs realism, and hands-on knowledge needs the support of a solid frame of theory – because in the real world, neither works well enough on its own. Overall, this was a deliberate process intended to create an appropriate balance between the two.

Officer-training in the Army

My niece’s husband is a career-soldier who’s now seen front-line service in a fair few conflict-zones. He’s now in his mid-30s, but by choice he’s still a sergeant: he’s been offered promotion, and even went on a officer-selection course at one stage, but he turned it down because, as he said, they seemed more concerned about which knife to use at a formal dinner than a knife he might have to use in combat. But he’s a good leader of ‘grunts’, and a very good trainer: and the army won’t let those skills to waste. So he now has a new job: teaching officer-cadets about the realities of the battlefield.

One of the first realities is that, despite what those officers might believe about themselves after leaving training-college, they’ll know almost nothing about the real world of the army under real-life conditions. What little they do know is often just enough to put everyone in real danger: a new lieutenant with those shiny new pips on his shoulders and an urgent need to prove himself will be a real risk to his platoon, especially out on armed patrol in unfriendly territory. That first year or so as an officer is, in essence, the first real part of his training: and it’s the troops under his nominal ‘command’ that are his trainers. And if our bright young lieutenant doesn’t get it that his job is to support them – not the other way round – then he’ll soon be pulled back to a desk-job for the rest of his life in the army – preferably before he gets anyone killed…

There’s a strong myth that the military is a rigid Taylorist-style tree-structure: generals give commands to colonels who give commands to captains, and on down to the ‘private soldier’ who must follow without question the orders of everyone else, and can never answer back. It’s true there’s still a strong element of that: but it’s there for the same reason as the ranks on the aircraft-carrier, because in a crisis – and the whole point of an army is that it does deal with crises – everyone will need to know their roles and responsibilities, and what to do to keep things on track. But the blunt fact is that rigid top-down command doesn’t work: that was the lethal lesson of the Charge of the Light Brigade. And in the complexities of current combat in counter-insurgency and the like, where every action or inaction by any soldier can have political as well as military consequences, there’s a real need to get a better balance between the aims of top-down strategy and the realities coming back up moment-by-moment from ‘the sharp end’.

Hence my nephew-in-law’s task, getting young officers ready for that reality. And hence, too, some radical revisions of military field-doctrine – such as the US Army’s ‘FM 5-0 Operations Process’ manual, using a much more fluid ‘design-thinking’ approach centred on ‘Commander’s Intent’ rather than explicit point-by-point command.

In effect, what we see now in many military command-structures is less like the old Victorian ‘command and control’, but something much more like a value-network or service-network in a service-oriented whole-enterprise architecture – the Services as literal services.

Summary

All of these are real cases where the organisation’s management, and management-structures, created a context in which top-down Taylorist theory could meet with Deming-style bottom-up practice, and together reach a mutual balance that would best serve the needs of the overall enterprise.

Yes, in each case, the hierarchy of ranks is still there: but that structure is there  for a valid reason, rather than solely as an expression of someone’s over-inflated ego… An important difference – and an important lesson that many businesses could also usefully learn?

This came up in a comment to the previous post ‘Why are the elite the elite?‘ The notion of ‘just another service’ is worth exploring more – especially as it has corollaries and implications that do have serious impacts on enterprise effectiveness.

(Just to make things clear: this is about enterprise architecture, not politics. Yes, as we’ll see, there are some significant sociopolitical ramifications from this, but that isn’t the focus here: the primary purpose is to explore some of the practical issues we encounter when scaling up a service-oriented architecture to a full whole-of-enterprise scope.)

Although I’ve said ‘enterprise’ above, what we’re dealing with here is mainly about management within ‘the organisation’ (organisation and enterprise are not the same).

What we’re actually dealing with is a paradigm-problem. On the one side, there are two fundamentally-different concepts of the organisation: organisation-as-machine, typified by Taylorism and the like; and organisation-as-living-organism, typified by various ‘systemic’ views such as those from Deming, Senge or Beer.

These two perspectives lead to two fundamentally-different views of the nature and role of management – which in turn have, as above, significant sociopolitical ramifications. But to get there, and to contrast those two views, we first need to do a couple of side-steps.

One of these side-steps is about purpose and the organisation.

In the machine-view, purpose is extrinsic: the purpose of the organisation is defined from outside the organisation. It’s just a machine: everything and everyone within it is, by definition, just another ‘purpose-free’ component of that machine. The machine itself is guided – or defined, perhaps – by the aims of the organisation’s owners, who provide the capital for ‘the enterprise’ and “the animal spirits of the entrepreneur” to set it in motion.

In the organism-view, purpose is intrinsic: the purpose of the organisation is defined from within the organisation. The biological metaphor here is the urge the survive and thrive, within a broader ‘enterprise’ represented by the ecosystem within which the entity exists. The organism is self-guided, self-directed, largely autonomous in the literal sense of ‘self-defined’ or ‘self-owned’. The classical concept of an external ‘owner’ doesn’t really make sense here – other than by stretching the view to include a metaphoric ‘farmer’, perhaps.

Which brings us to another related side-step about owners and rulers and property, because there are two fundamentally-different concepts there as well: feudal/hierarchical versus free-form/ecosystem.

(Note that this won’t suggest that one is somehow inherently ‘better’ than the other: they’re not. It’s more about ‘fit’ to the requirements of the context – ‘better’ only in a contextual sense, not an ‘absolute’ one. If you’re familiar with Spiral Dynamics model of social contexts, feudal/hierarchical is essentially Red/Blue, nowadays with a thin veneer of Orange; free-form/ecosystem requires system-awareness, and hence is in the Gold/Turquoise range. [Ignore the 'historical determinism' in Spiral Dynamics, by the way: to be blunt, it's garbage. But the core 'vMeme' model is sound, and can be very useful as a cultural-assessment frame in enterprise-architectures.])

A feudal/hierarchical culture is one in which there are strict relationships (‘fealty’) of roles that are ‘above’ or ‘below’ each other, and that identify respective authority, ‘rights’, responsibilities. A true feudal model has a single ruler (‘monarch’) at the ‘top’ of relationship-tree; a more literal hierarchy instead has some form of abstract concept (such as ‘God’, or ‘the Law’) that is nominally ‘above’ all others, but in essence and in practice comes to much the same as a feudal model. In both variants, each ‘inferior’ is the ‘subject’ of the respective ‘superior’ – literally, classed as a semi-autonomous extension of the ‘superior’, with no independent identity, existence or will.

(For an extreme near-present-day example, consider Gadaffi’s Libya, with Gadaffi himself as ‘Brother Leader’ who thinks for all, decides for all, and possesses all – and whose merest whim is Law. In principle, if fortunately not so much in practice, the Pope provides much the same role for the Catholic Church – subject only to the perceived ‘will of God’.)

‘Modern’ capitalism arose in the late 17th and early 18th centuries, in cultures that in essence were still largely feudal – in practice, at least, if not necessarily in theory. Aristocrats still held most of the land; but increasingly, the new merchant class held most of the money, and hence could claim a near-equal stake at the top of the tree-of-control. Beneath them in the tree were a wide range of agents: the bailiff, the steward, the factor, and so on. In modern-day parlance, these were the ‘managers’. And beneath them, as the ‘subjects’ of everyone else, were the ‘workers’ – the providers of Labour, to use the term from classic capitalism.

Taylorism in essence reflects and embodies exactly this type of feudal model: a rigid three-tier class-hierarchy. At the top we have the owners, who actually don’t get much of a mention in Taylorism as such: they set the purpose for the ‘machine’, issue commands accordingly, and are deemed to have the exclusive ‘right of possession’ over everything and everyone else. (Note, though, that with the invention of the ‘limited-liability company’ and other related changes in law, the old feudal mutuality of responsibilities is gone: all others are still responsible to the owners, but not the owners to their ‘vassals’ or to anyone else. In effect, the ‘social contract’ becomes one-way only: an obvious huge kurtosis-risk that few now seem willing to acknowledge…) Beneath them we have the managers, who in Taylorism do all the thinking for the ‘machine’, and maintain control: they interpret the wishes of the owners, and relay them as orders to those who in turn are ‘beneath’ them. And at the base of the tree, we have the workers, who do all of the ‘doing’ of the ‘machine’, and in essence are classed as mindless robots, subjects of everyone else’s ‘rights’ to ‘command and control’.

So in Taylorism, as in the Victorian battlefield, everyone has a fixed role in a fixed structure of top-down ‘command and control’ – owners own; managers think; workers do – and no-one can move outside of those preordained roles. Everything and everyone is a component within ‘the machine’.

By contrast to all of this, the ecosystem-model has no hierarchy at all: no-one has ‘rulership’ over anything else, there’s no command, and in many ways there’s no control either. The organism or ecosystem simply is. Sometimes there’s no real order as such – as in a colony of extremophile bacteria, for example. Often, though, there is some form of apparent order or collective purpose that emerges from the interactions in the overall context: the structure of a human body is one example of which we all have direct first-hand knowledge. Within a human body, it doesn’t make sense to use a ‘rulership’ metaphor, that “the heart rules the head”, for example, or “the kidneys rule the throat”. (Okay, people may well use such metaphors, but they don’t actually make sense in physiological terms, anyway…) Instead, the most accurate metaphor is that each cell and organ and structure offers its services in support of the whole.

So: what next? – especially in relation to the organisation and its management?

On the one side, we have the machine-metaphor. In Taylorism and the like, this aligns with a feudal-style tree-structure of ‘command and control’, a hierarchy of ‘bosses’ and ‘subordinates’. All of this is bounded by predefined rules and algorithms – hence ‘scientific management’. Everything and everyone is considered only to be a component – a nested structure of components within components within components.

On the other side, we have the living-organism metaphor. This aligns with a network-type structure, often with fluid roles and dynamic changes in relationship and connection. There is no identifiable hierarchy as such; instead, relative ‘positioning’ tends to be derived in an emergent way from the interaction of the whole. Instead of predefined roles, each entity – at every level of granularity or decomposition – offers services that contribute in some way to the emergent workings of the whole.

So how do these two models apply in the real world?

On the surface, most organisations still seem to use the machine-metaphor: there are explicit ranks, each with authority ‘over’ others, and so on. The nominal role of management is still a Taylorist ‘command and control’.

However this type of structure is very unwieldy, and slow to respond to change – certainly far too unwieldy for anything involving fast real-time action or real-time change. Even armies don’t use it any more – not on the battlefield, anyway, where ‘command and control’ has long since been replaced by a much more free-form ‘Commander’s Intent’. The same applies in Agile-style product-development, or in successful customer-service: the classic ‘command and control’ call-centre is frankly despised by almost everyone, especially those who struggle to survive within them…

So in practice, most organisations still present themselves as top-down command-and-control. But the reality is that, other than in a few quite narrow contexts, that isn’t how they actually work. Instead, to get the speed of response that’s needed in a real-time world, just about everything is structured around services – except for management, which still tries to cling on to command-and-control.

One of the real problems is that if we move to a service-oriented model – which we need in order to support the required agility and emergence in the market-’ecosystem’ – one of the crucial side-effects is that management can no longer be viewed as ‘special and different’. It’s not like the hierarchies of Taylorism: a service-architecture is a network-structure with no top, no bottom, and usually no identifiable centre either. In a true service-model, management is just another service, one that happens to provide management-type services to the whole. (I’ve described those services in some depth back in the various posts on Enterprise Canvas, hence no need to repeat it all again here?) And since in a service-architecture there’s no hierarchy-tree, no top, no bottom, no centre, management has no reason whatsoever to try to claim automatic or inherent priority over anyone or anything else: it’s just another service.

In a classic business-architecture, the first thing we usually do is try to map out the ‘org-chart’. What we discover very quickly is that that tells us almost nothing about how the work is actually organised. To get any sense of what’s really going on, and what and how and why anything connects with anything else, our best bet is to turn to a enterprise-architecture that starts from one very simple principle: that everywhere and nowhere is the centre, all at the same time. In other words, a strategy that leads naturally into a service-oriented approach to the architecture.

That’s pretty much where we’re at now with enterprise-architecture, and why a service-oriented approach to the architecture gives the best fit for most current business needs. But we keep on hitting up against that huge stumbling-block and bottleneck that we’re apparently not supposed to notice: namely that the hierarchical concept of management, that everyone seems to want to cling on to, simply does not make sense any more. Instead, the only thing that does make sense is the view that management is just another service, no different in rank or priority or the like from anything else.

Unfortunately, the political ramifications of that fact are huge. For example, if management is ‘just another service’, is there any reason why self-styled ‘senior management’ should always get the top floor and the highest pay? The short answer is no: no reason whatsoever. Oops… Think that blunt fact will be resisted – especially by those who currently claim to have the ‘right’ of command-and-control over all others? You betcha… and it won’t matter one jot that that kind of clinging-on to something that doesn’t make sense will make things worse for everyone, including themselves. It’s very, very hard to let go of privilege, of a sense of certainty in entitlement – especially when the blunt reality is that never were any real defensible grounds for that privilege in the first place. Tricky, that one… very difficult indeed…

Yet before you launch at me with some arbitrary accusation that I’m some kind of crazy ‘communist’ or ‘socialist’ or ‘anarchist’ or the like (okay, as an architect I might perhaps accept the ‘business-anarchist‘ label… ), notice that this is not about politics. It’s only about architecture – nothing else. All that I’m saying here is that a service-oriented architecture points us inevitably at the blunt fact that management is ‘just another service’. What we do with that ‘blunt fact’ is another question entirely: but that it is a fact is not in question.

Hope that makes a bit more sense, anyway?

(This is probably another politically-risky post for me to play with, but never mind… )

In recent weeks I’ve repeatedly come across four seemingly-distinct themes:

• deeper exploration of the architectural idea that everything in the enterprise is or represents a service
• watching architecture colleagues in several different organisations struggle yet again with inane demands from management-hierarchies that simply don’t work
• deeper exploration of conceptual flaws in current economics, particularly around the concept of possession and ‘rights of possession’
• watching yet deeper cracks appear in the current worldwide economic system

For me there’s been a kind of nagging suspicion that there might be some strong interrelationships across all of that conceptual space. Which in turn leads me to several deeply-worrying questions – from an architectural perspective, if nothing else:

• If everything is a service, what services – if any – does management actually deliver to the enterprise?
• If everything is a service, why should management be assigned any priority over anything else?
• Why are management-services and management overall so consistently and notoriously inefficient and ineffective?
• What part does organisational-structure play in rendering management-services so seemingly-ineffective in practice?
• Why is it assumed that ‘promoting’ someone into management will necessarily improve overall service-delivery?
• Why is it so often assumed that the most effective way of organising management-services is a top-down hierarchy of supposed ‘control’ of all other services?
• Following the trails of prioritised service-relationships, why are financial-shareholders so often assigned priority over every service, when in many cases the only ‘service’ they offer seems, in essence, little different from a ‘protection-racket’ – enforced compliance to demands under threat of removal of ‘protection’?
• In the current socio-political context, what – if anything – can we do architecturally to make any of this work any better?

For that matter, what can we do to make it safe even to ask such questions…?

Hmm…

(Warning: this will no doubt be another long post…)

Let’s explore a bit more about each of those questions above.

If everything is a service, what services does management nominally deliver to the enterprise?

In Enterprise Canvas, the services typically delivered by ‘the management’ are described as ‘direction services’, with three distinct components:

• ‘develop the business’ – identify organisational and enterprise vision, and keep the organisation on-track to vision (VSM: ‘system-5′, “decisions to maintain identity”)
• ‘change the business’ – explore external (and internal?) context, to identify required strategic change (VSM: ‘system-4′, “development, research and marketing”)
• ‘run the business’ – use tactical and operational information to assess activity, allocate resources and guide decision-making (VSM: ‘system-3′, “operations planning and control”)

In essence, in classic Taylorism, anything that is not specifically about production or service-delivery (VSM: ‘system-1′), and could be construed as in some way related to ‘control’ of others, is placed under the exclusive purview and privilege of ‘management’. Taylorism places a strict boundary – some would say a social class-boundary – between ‘management’ and ‘workers’. Yet from a service-architecture perspective, management itself is another form of service-delivery, namely the delivery of ‘management-services’ – it is not and cannot be viewed as structurally different from anything else.

If everything is a service, why should management be assigned any priority over anything else?

Short answer: no valid reason at all – from a services-perspective, anyway. It’s just another service, or set of services.

The only feasible reason why management might be assigned arbitrary priority over other services is from left-over delusions about ‘rights of control’. For the most part, these delusions arise from an unfortunate coincidence of functions within the ‘management-services’:

• services for strategic-assessment – potentially giving the delusion that ‘knowing more about big-picture’ inherently means ‘responsibility to tell others what to do’
• services for coordination of resource-allocation – potentially giving the delusion of authority over others via ‘right to withhold’, in turn arising from delusions about the (dys)functional role of purported ‘rights of possession’ within the broader society, and hence within an organisation’s economic model.

In short, architecturally speaking, this is not a defensible reason for priority. Every service is ‘just another service’ that is required for enterprise viability: hence no service can be said to have inherent priority over any other.

Why are management-services and management overall so inefficient and ineffective?

The main reason is failure to understand that management-services are ‘just another service’, without any inherent priority over any other.

Mistaken concepts of inherent-priority and inherent authority ‘over’ others underpin and maintain a broad suite of highly-addictive power-problems and power-delusions – see the ‘Manifesto‘ from my book ‘Power and Response-ability: the human side of systems, and the SEMPER framework documented in SEMPER & SCORE.

In essence, the assumption of inherent-priority feeds a possessionist delusion of ‘right’ to regard and treat others as either ‘object’ or ‘subject’ of self. For obvious reasons, this rarely works well in a social context…

What part does organisational-structure play in rendering management-services ineffective in practice?

The short answer is probably a lot – though it’s often far from obvious as to exactly how and why this should be so.

Two themes do come to mind. One is that the Taylorist split between ‘management’ and ‘workers’ means that anything ‘not-work’ is pushed into the ‘management’ space. (This is another variant of the same driver that creates IT-centrism or business-centrism, but kind of in reverse – more “I am not-that” than “I am that”.) A key side-effect of this is that the non-run-time coordination-services and virtually all of the validation-services are subsumed under the ‘management’ banner – where they most definitely do not belong. As the Viable System Model makes clear, these categories of services are necessarily somewhat orthogonal to the direction-services (‘management’); if they are in effect subsumed into ‘management’, the automatic result – as evidenced in every ‘control’-oriented organisation – will be the creation of somewhat-covert ‘shadow-networks’ in order to get the respective work done. This inevitably creatives inefficiencies, misalignment, miscommunication, and many, many conflicts with ‘the management’ – as can be seen in almost any Dilbert cartoon…

The other theme arises from the Victorian (and hence Taylorist) passion for hierarchies of ‘control’. A tree-structure works well as a means to aggregate information and develop abstractions and overviews, and also as a means to distribute guidance-information (and resources in general) from a central point. However, a tree-structure is not good for coordinating end-to-end business-processes, because it forces all cross-silo coordination up towards the ‘top’ of the tree, creating serious bottlenecks for flows. And as Deming showed, it’s also often a very poor structure for decision-making and control, because of the ‘Taylorist trap’: the skillsets and abilities needed to solve concrete front-line problems become less and less available the further ‘upward’ – more-abstract – that we move in the hierarchy-tree.

There are probably many other examples of how management-structures impact effectiveness: there’s a lot more exploration needed here. These two themes are destructive enough already, though…

Why is it assumed that ‘promoting’ someone into management will improve overall service-delivery?

In a technical sense, we could suggest that it’s an odd historical artefact of three related yet distinct strands: possession-based economics, capitalism, and the last vestiges of feudalism. Possession-based economics provides the notion of personal ‘rights’ to collective resources; capitalism provides the concept that ‘the owners’ have exclusive ‘rights’ to organisational resources, and hence have exclusive say in how those resources are distributed and used; whilst feudalism provides the notion of ‘superiority’ and ‘inferiority’, and the purported ‘right’ of ‘superiors’ to determine and demand the actions of their ‘inferiors’. The result is a peculiar tree-type structure that can work well for specific functions in certain specific contexts: the Roman army is perhaps the classic example. In all too many cases, though, it tends to collapse into a dysfunctional mess where position with the tree-of-control denotes ‘authority without responsibility’ – riddled with all too many illustrations of what goes wrong when ‘power’ is defined as ‘the ability to avoid work’…

In possessionist capitalism, ‘rights’ to organisational resources are directly related to ‘position’ on the tree-of-control; ‘promotion’ (and its counterpart ‘demotion’) is a re-positioning on that tree, and hence an amendment of ‘rights to resources’ – both organisational resources and, via ‘remuneration’ and the like, to societal resources. To put it in a less technical way, ‘promotion’ is the main mechanism within the current employment-based model via which competent people get more recognition and more ‘stuff’. Because the tree-of-control is associated almost exclusively with the management-services, this often means that the only available means of enhanced recognition and remuneration is via ‘promotion’ into the management-structure.

In principle, a management role implies increased responsibility to guide others: in a service-oriented enterprise, that’s the real purpose for the management-services – and when that is the purpose for a ‘promotion’ into management, it does work well. The problem is that the ‘management=promotion’ assumes both that the person both wants to do that type of work with that increased responsibility for others, and is competent to do it anyway – and in many cases the answer is ‘No’. Yet if the only means of increased recognition or resources is ‘promotion’ into management, then that’s what they’ll do – and sometimes they have no choice about it anyway.

The result is often serious damage to organisational effectiveness. The competence-problem is well documented in the Peter Principle, that “in a hierarchy every employee tends to rise to their level of incompetence”. The other side of the ‘promotion’ is that someone who is usually very skilled at some other type of service-delivery is no longer available to do that work any more. To make it worse, becoming out of touch with front-line service-delivery may result in a steady erosion of their original competence – yet they may still believe that they know as much, if not more, than those who are currently doing front-line delivery. Courtesy of Taylorist theories about the nature of organisations, they may even believe that they automatically know more than others because they have been ‘promoted’ to a management role. The consequences can be very messy indeed…

A first-hand example, from a place where I once worked as a contract web-developer. (I’ve tweaked some of the details here to protect my colleagues, but otherwise this is essentially a factual description.) A very experienced engineer, who’d been very effective as a cross-discipline trouble-shooter for many years, was finally forced to take ‘promotion’ into managing the overall section. He was not a good administrator – but unfortunately believed that he was, and quickly learnt to blame everyone else rather than take responsibility for his own mistakes. Worse, he decided that, as manager, he now had the ‘right’ to review and amend anyone else’s work, often without bothering to tell them. The climax came when he changed a core part of our application late one evening, bypassing the code-management system to do so, and causing the application to break the following morning, right in the middle of a demonstration to key stakeholders. After that, everyone learned to block him out from anything that they were working on. So the only effective result of the ‘promotion’ was that we lost a very good troubleshooter, and gained a barely-competent manager and a frankly dangerous meddler – all in the same person.

Why is it assumed that the most effective way of organising management-services is a top-down hierarchy of ‘control’?

Most of this comes from Taylorist and pre-Taylorist belief-systems, as summarised above.

The problem is two-fold. One part is that a tree-structure is a good way to aggregate and abstract from performance-information, and to distribute directions within any context where centralised decision-making makes sense. There’s therefore a tendency to assume that it will therefore work well in all contexts – which is not the case. In essence, if the work is essentially robotic, can be defined by simple rules, and aggregation of control- and performance-information can be handled by a simple tree-structure without ‘top-of-tree’ inter-silo bottlenecks, and the context itself is not undergoing rapid change, then a top-down hierarchy will usually work well. If the work is knowledge-based and/or relationship-based, requires any form of localised decision-making, or any form of ‘any to any’ communication, or the context itself is changing – all of which frequently apply in present business-contexts – then a top-down control-hierarchy will not work well, and an alternative structure for management-services within that context must be used.

The other part of this is a hang-over from feudal times, where authority, responsibilities and ‘rights’ were defined in terms of strict rules within their own networks of fealty-oaths. A duke had the responsibility to lead an army, but was also responsible to raise the funds and everything else that the army would need; a count was responsible for taxation within a region, which often entailed the need for a small army to enforce that taxation; and so on. A feudal model defines that all people ‘below’ in the tree-of-control are subjects – literally, subject to the will of the ‘superior’, or acting as extensions of the ‘superior’s will.

(Psychologically speaking, it’a a very interesting ‘racket’, because it enables all parties to claim the ‘rights’ to any rewards but also the ‘right’ to avoid responsibility for the consequences. The ‘superior’ orders the action, but can avoid responsibility only the ‘inferiors’ actually did the action; the ‘inferiors’ did the action, but can claim that they weren’t responsible because they were ‘only following orders’ from the ‘superior’. The Nuremberg Principles are now used to overrule this ‘game’ in terms of war-crimes, though not yet applied to business-crimes: it will be interesting to see what happens when they are…)

In short, it’s just an arbitrary assumption: nothing more than that. It’s the result of a classic logic-error, assuming that because something did work in one context, it must therefore continue to do so in that context and all other contexts. Architecturally speaking, we need to challenge this assumption in every case, because the consequences to the organisation’s effectiveness are not good.

Why are financial-shareholders so often assigned priority over every service?

Short answer: no defensible reason. In practice, it arises from interestingly-selective myopia, from the usual dysfunctionalities of the possession-economy, and from a failure to grasp that the fundamentals of capitalism have actually changed somewhat during the past few hundred years…

The myopia is that financial shareholders are merely one category of investors in the organisation and enterprise: in almost all organisations and enterprises, there are many other types of investment than money, and many other categories of investor. Financial-shareholders are also often some of the least-responsible investors, given that the shareholding may now last mere milliseconds in some cases, and that shareholding in limited-liability companies involves quite considerable ‘rights’ with almost zero responsibilities other than risk of loss of financial investment. Structurally, this represents a very high risk to the enterprise.

The arbitrary privileging of financial-investment, and purported ‘rights of possession’ solely on the basis of financial investment, are rooted in an early-18th-century model of capitalism that is ludicrously out-of-date relative to the present-day business-context. For example, given that the core capital of many current organisations resides primarily in the minds and relationships of individual employees, the shareholder-model is often tantamount to a declaration of ‘right of possession’ of those individuals themselves – a claim which, as Charles Handy and other business-writers have pointed out, is utterly indefensible in law, because it’s tantamount to slavery. Again, huge structural problems here, for business-architecture especially – with a real risk that some of these structural flaws are already moving towards a point of catastrophic-failure.

What can we do architecturally to make any of this work any better?

All of these are architectural problems, all with very severe consequences, and hence definitely of serious concern in all aspects of enterprise-architecture and its various domain-architectures.

However, in most cases they arise from very deep political roots – which are not fun to deal with as an enterprise-architect…

The key here is to remember that, especially at this level, the architect’s role is primarily one of decision-support – not decision-making. In most of these cases, the decisions belong to senior executives, boards and, further out, regulators and politicians and the like. We should not attempt to usurp any of those decisions!

What we can do, and should do (in my opinion, anyway!), is to gather the evidence that others will need in order to make those decisions. In many cases we also could or should develop and document preliminary options – including documenting the implications and social and other costs and consequences – so that, again, those others can make informed decisions (or at least, more informed decisions than they seem to do at present…). That’s our task here: attempting to do anything more than that will probably help no-one – and may cause a lot more harm than good, especially to us.

Probably the simplest way to deal with this, in an architectural sense, is to class all of the problems described above as ‘dispensations’, breaches of valid architectural principles that have been allowed to go ahead anyway because of some overriding reason. In most cases, we can document the reason for the dispensation as a ‘political’ or ‘gold-plated requirement’ (to use the respective term from the Volere requirements-framework) – in other words, an arbitrary choice that has no real reason other than that someone said “because I said so”. Because all unresolved architectural-dispensations should be subject to regular review, eventually someone will have the courage to tackle these problems – and we can then at last take action to resolve them. But until that happy day, we can at least ensure that they don’t shoved into the dreaded ‘too-hard basket’, where far too many important problems languish indefinitely without attention until they’ve already gone past the point of no-return.

Yes, it’s frustrating – very frustrating. Especially for those of us – such as most architects, perhaps, by now? – who can see where this mess is heading at present. Yet as architects, that’s probably the best we can do for now: so let’s at least do that, I would hope?

Over to you, anyway.

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!

I’ve always been impressed by their service, but this time they’ve really done me proud. I was afraid I wouldn’t have the books in time before I had to leave for the TOGAF conference next weekend, but I’m now a week ahead of schedule on that. Many thanks.

Recommended.

As of right now, that’s been hacked down to less than one chapter to go, and one illustration – though it’ll likely be one of the most difficult of the lot. But still, I do now have a better chance of meeting that deadline than I thought I had two days ago.

More details when it’s all done, anyway.