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

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

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

To put into context, consider a few scenarios:

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

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

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

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

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

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

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

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

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

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

So there we are.

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

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

Uh, no…

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

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

Ouch…

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

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

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

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

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

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

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

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

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

Comments/suggestions, anyone?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Some related questions on service-metrics and quality:

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

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

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

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

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

Some questions about responsibilities and stakeholders:

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

Some questions about composition, decomposition and implementation:

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

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

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

Some questions around requirements, conflicts and dependencies:

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

Some questions around the lifecycle of the item itself:

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

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

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

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

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

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

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.

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

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

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

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

I base much of my architecture-work on a rethink of Tuckman’s Group Dynamics project-lifecycle as an overview-model of the overall workings of an enterprise:

• forming: purpose, identity, strategy; also far-future
• storming: people-issues; kind-of orthogonal to time – anywhere from far-future to far-past
• norming: plans and schedules; also near-future
• performing: production; also ‘now!‘
• adjourning (or mourning): completions; also near- to mid-past

But when we look at the management-section of Beer’s Viable System Model, only three of those five are covered:

• system-5 ‘policy’: aligns to ‘forming’
• system-4 ‘strategy’: aligns to later part of ‘forming’, plus ‘norming’
• system-3 ‘direction’: aligns to later part of ‘norming’, plus ‘performing’

(For those who don’t know the VSM, ‘system-2′ is about inter-process coordination, and ‘system-1′ about service-delivery, the detail-level of the ‘performing’ phase: they don’t really apply here.)

There’s no VSM coverage at all of the ‘storming’ phase, the people-issues – which seems odd, considering Beer’s very strong personal bent towards left-wing participatory politics. And although VSM ‘system-3*’, random-audit, does sort-of touch the ‘adjourning’ phase, it’s only on a very occasional basis – not the continuous process needed for completions and lessons-learned and the like.

This may stem from the VSM’s history as a model of the information flows for management and the like; but it still seems a huge hole in the coverage of what’s actually needed for systemic design of management processes. Is there any way that the VSM does actually cover that hole? And if not, what would we need to do to fill it?