Perhaps the simplest way to show the differences is to map them to service-oriented architecture and thence to Stafford Beer’s Viable System Model . The VSM consists of a recursive set of six ‘systems’:

• the ‘management-services’ set:
  • system-5: policy and purpose – “decisions to maintain identity”
  • system-4: strategy, ‘outside, future’ – “development, research and marketing”
  • system-3: tactics, ‘inside, now’ – “operations planning and control”
• the ‘pervasive-services’ set:
  • system-3*: audit and quality-management
• the coordination-services set:
  • system-2: coordination for ‘develop the business’, ‘change the business’, ‘run the business’ – “regulation and tactical planning”
• the ‘delivery-services’ set:
  • system-1: subsidiary services or tasks to enact the actual service-delivery (each of which is also a Viable System with its own system-5, -4, -3 etc)

Almost by definition, architectures all tend to operate somewhere as or between system-3* and system-2 – representing and promulgating enterprise-values such as consistency, integration and effectiveness, and assisting in coordination to enhance these. But in terms of scope:

• enterprise architecture deals with system-5 type concerns, bridging over into system-4 and on ‘downward’ from there
• business-architecture has its emphasis on system-4, with some cross-links into system-3
• TOGAF’s ‘information-systems architectures’ tend to sit in system-3, with some links into system-2, down into system-1, and in some parts into system-3*
• process-architectures and TOGAF’s ‘technology infrastructure architecture’ sit fairly solidly in system-1

Seems to make more sense in those terms, anyway.

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?