Tom Graves / Tetradian

Continuing on the theme of the ‘This’ game for engaging people in enterprise-architecture exploration and development, as described in the two previous posts ‘This: an exploratory game for service-oriented EA‘ and ‘More on the ‘This’ game for enterprise-architecture‘.

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?

A great session yesterday with Kevin Smith, brainstorming ideas for the ‘This’ game for service-oriented enterprise-architecture.

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?

For a while now I’ve been brewing a kind of ‘exploratory game’ for enterprise-architecture, with the somewhat uninventive title of 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?

One of the points that came up in the previous posts on the management-architecture theme is that most management-structures are top-down, which doesn’t fit well with the ‘everything is just another service’ nature of most service-architectures – especially at a whole-of-enterprise scope. Yet if so, how can we create a better balance in the overall management-architecture? What can we do about that, in an enterprise-architecture sense?

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

Read more…

What do I mean when I say that, in a service-oriented architecture of the enterprise, we need to view management and the like as ‘just another service’?

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?

Why is management the way that it is? Does it work well that way? And what part does the architecture of management play in determining how well it does or doesn’t work?

(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…)

Read more…

Mildly amazing – I did meet that deadline.

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’m currently trundling my way through writing the next book, The Service Oriented Enterprise – still on-track for publication at the end of this month, I’m delighted to say – and came across an interesting point about Stafford Beer’s Viable System Model that I hadn’t noted before. It may be important for anyone who’s applying systems-theory principles in enterprise-architecture.

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?