This is an old slidedeck (March 2006) that I rediscovered the other day on my filesystem, but it still seems relevant in that, even at that early stage, it illustrates strong crosslinks between enterprise-architecture and systems-thinking - particularly service-oriented architectures, the 'tetradian' dimensions (here as machines, knowledge, people and business-purpose), and a somewhat-extended version of Stafford Beer's classic Viable Systems Model. It's also slightly unusual in that it cross-references to FEAF (US Federal Enterprise Architecture Framework) rather than TOGAF, as we'd found the latter to be unhelpful and misleading for that particular client. The client themselves were in the logistics industry - hence the pseudo-logo in the upper left of each slide. It was a real presentation for a real client, presenting to other architects in our team some research I'd been doing, on how we could rethink our approach to enterprise-architecture as we started to break out of the classic IT-centric box. It's in a style I wouldn't use these days - way too many words! - and it's been somewhat 'de-identified' for reasons of commercial confidentiality, but otherwise it's exactly as presented to my colleagues at that client. One minor note: the 'X/C/M/P' extensions to the Viable System Model, in slides 19, 20 and 28, relate to work we'd been doing at the time on integrating quality-system concerns - management of exceptions, corrective-action, issue-tracking and process-improvement - into both enterprise-architecture and the Viable System Model itself. I haven't seen any other reference to this type of integration, either before or since: it may be useful to quite a few people, on both the enterprise-architecture and systems-thinking sides of that discussion, and also to quality-system folks as well. In short, yes, it's old, but it may still be useful for some folks in enterprise-architectures and elsewhere. Hope it helps, anyway.

1. 1
Meta-frameworks:
Making the Blueprint more accessible
Tom Graves
Tetradian Consulting
Date: Thursday 9/03/2006

2. 2
Purpose of this review
Explore options to make the Blueprint more meaningful
• to business staff
• to operations staff
• to non-IT staff in general
Build on success of existing IT-oriented work
• identify architecture to extend Blueprint into non-IT spaces
Stronger support for Business / Operations goals
• broader and deeper cost-tracking and cost-reduction
• process-improvement, reduced-time-to-market, improved resilience,
adaptability, agility in Logistics business-areas beyond IT

3. 3
Connect to extend
The Capability Model has proved a great success
– success because it connects with the Business / Operations world
– Top Level Capability Model diagram is often on display in offices, etc
Current Blueprint has a strong emphasis on IT…
– information-systems, star-schema, technology models, applications, projects,
service-components, etc, etc
– Logistics’ proven methodology has external validation (KPMG, Kearney etc)
– crosslinks to industry IT-architecture models such as Zachman Framework,
Federal Enterprise Architecture Framework (FEAF)
…but will this be a liability as we extend toward Business?
– the Capability Model is almost the only part non-IT staff do already use
To extend the business usefulness of the Blueprint,
we must break free of the tendency towards an IT-centric view

4. 4
Too narrow a view?
Like the old New Yorker cover,
IT architecture tends to see
the world as flat, with itself at
the centre of it all...
...and everything else of
decreasing importance the
further away it is from that
centre.

5. 5
A broader view of the enterprise
By contrast,
enterprise architecture needs
to see the world as a whole,
with no real ‘centre’ as such...
...and be willing to explore and
map every area of the broader
enterprise, to create a greater
understanding of that whole.

6. 6
Some known challenges of FEAF…
FEAF’s Reference Model hierarchy makes sense in an IT-centric world…
…but it’s too limited to be useful for most Business or Operations staff…
…the BRM is similar to the Blueprint Capability Model, but that’s about all.

7. 7
The FEAF hierarchy…
This would be more useful for business if it wasn’t quite so IT-centric…
…is IT really the only ‘technology’?

8. 8
The FEAF hierarchy, sideways-on
Linking well to Zachman, a really useful set of questions…
…if the FEAF architecture allowed us to apply it to more than just IT…
…which it does, if we fill in some of the known gaps* in FEAF itself.

9. 9
Filling in the gaps…
Look at those two side-blocks on FEAF…
…we need to remember we’re dealing with
business systems, not just IT systems
‘Human Capital’
is People
‘Other Fixed Assets’
is Technology
…this ‘Technology’ is only IT – but
should be Knowledge in general
“A business system consists of manual process/activities, logistics equipment
and information systems” – Logistics: Definition of Blueprint Terms

10. 10
FEAF is a useful map for IT, but…
We must remember FEAF shows only a small portion of the whole…
…and it’s that whole that we need to iterate towards…
…not merely the FEAF subset.

11. Much the same applies to TOGAF...
The Open Group Architecture Framework (TOGAF) is similarly IT-centric…
…yet it’s the architecture of the whole that we need to iterate towards…
…the whole enterprise, not just an IT-oriented subset.
11

12. 12
An Operations view of FEAF?
FEAF does provide a good framework for an IT view of that whole…
…yet only limited support
for a Business view…
…and almost nothing for an Operations view.
The Blueprint needs broader description of Logistics’ enterprise architecture.

13. 13
Bredemeyer on enterprise architecture
“Increasing the scope of Enterprise Architecture to encompass more
disciplines increases the benefits to be gained:”*
– EA = Technical Architecture: reduce IT complexity and costs:
• increased convergence consolidates purchasing, lowers training costs, etc
– EA = Enterprise-Wide IT Architecture (EWITA): support collaboration
among different parts of the enterprise:
• shared access to information across business and with partners / customers
• elimination of duplication across different functions or business units
• address concerns that cut across business units, such as integration
– EA = EWITA + Business Architecture: increase enterprise agility and
alignment with business strategy
• enable changes in business strategy with quick-response changes in enabling
processes and technology solutions
• inform strategy more effectively with strategic paths to identify and integrate
technology-enabled opportunities (and threats)

14. 14
Strategy and enterprise architecture
The three layers of Logistics’ Business Systems Strategic Plan*
Information Technology
Architecture (EWITA)
Information Management
& Process Support
Maturity/
Commercial
Focus
Impact on
Long-Term
Profitability
Enterprise-Wide
underpins
End-to-End
Technical Architecture (TA)
underpins
Productivity Improvements
EWITA +
Business Architecture (BA)
underpin
Customer Information,
Wireless Capabilities,
Leading-Edge Track & Trace
The desired profitability cannot be achieved without the required level of
enterprise-architecture maturity to underpin each layer of the plan.

15. 15
Bredemeyer on Enterprise Architecture
Enterprise Architecture is the architecture of business capabilities*
Need to design business capabilities
– people
– process and
– technology
Business Architecture
Information Business Processes Org. Structure
cross-cutting concerns
concerns
cutting EWITA
cross-cross-cutting concerns
cross-cutting concerns
cross-cutting concerns
EAI EAI EAI
(business capabilities)
cross-cutting concerns
“Enterprise Architecture recognizes that the organization is a
system, and the crosscutting concerns must be addressed first at the
overall system level.”

16. 16
Need for a larger scope than just IT
It’s why we need an integrated view of business systems…
…rotating constantly
between views…
...EWITA and Business Architecture,
…to maintain that sense of the whole…
together...
…and also including the business dimension – symbolised by

17. Business system as ‘viable system’
To broaden the overall scope, think of organisation as organism.
In a ‘viable organism’, every system and subsystem has some means:
- to do its tasks (a ‘doing system’)
- to sense (and report on) its internal and external environment
- to remember (a repository of knowledge about its past)
- to coordinate its activities with other systems
- to plan its activities (strategy and tactics, often with others)
- to adapt to and, where possible, improve its environment
And in principle, at least, it will have a sense of its own purpose.
This is recursive, like a multi-faceted hierarchy: each layer is similar to,
yet different from, the layers ‘above’ and ‘below’.
17

18. 18
Stafford Beer’s ‘Viable System Model’
In Stafford Beer’s ‘Viable System Model’*,
each system (or unit at a given layer)
contains a set of specialised sub-systems:
• 5 – policy / purpose (green)
• 4 – ‘outside / future’ [inc. strategy] (yellow)
• 3 – ‘inside / now’ [staff management] (red)
• 3* – sporadic audit / review (pale blue)
• 2 – coordination (mid blue)
• 1 – operations (lilac)
These interact with each other to act on and
with the external world (the amoebic ‘blob’
to the left of the diagram).
The model is recursive: each layer contains
the next, to whatever depth required.

19. 19
VSM interactions for self-adaptation
Interactions between these sub-systems
support improved processes and/or self-adaptation
to a changing environment:
• X – exception-management for short-term
(‘1’ « ‘3’, ‘1’ « ‘4’)
• C – corrective action (review of ‘3*’ / ‘X’ «
‘3’ / ‘4’, also driver for ‘P’)
• M – issue-tracking / issue-management
(usually triggered by ‘X’, ‘2’ and/or ‘3’)
• P – process-improvement (interaction up
and down between any ‘1’… « … ‘5’)
We can use these ‘systems’ as filters to
review Capability Model / Business Model.
Gaps would point to unrecorded functions,
lost opportunities for improvement,
and/or untraceable costs.

20. represents untraced
opportunities for improvement?
20
Blueprint coverage of VSM systems
0 5 10 15 20
represents untraceable costs?
5 - Policy / Purpose
4 - Future/Out
3 - Inward/Now
3* - Random audit
2 - Coordination
1 - Operations
X - Exception mgmt
C - Corrective action
M - Issue tracking/mgmt
P - Process improvement
Number of Business Systems containing activities
for each VSM system (‘5’-’1’) or their interactions (‘X’-’P’)*

21. About Key Performance Indicators
21
If strategies drive the downward path from policy to action,
KPIs form the return / monitoring path – represented in
FEAF by the ‘balanced scorecard’ of the PRM…
…but we also need ‘horizontal’ KPIs to complete the picture

22. Service-oriented architecture (SOA)
22
As with IT architecture,
services are the key –
the balance-point
around which
everything else revolves

23. 23
The structure of a service
A service is also a ‘business system’: it comprises “manual process /
activities, logistics equipment and information systems”…
IT
People Technology
…in any appropriate combination, much like different soil-types.
Different combinations might be used in different contexts – Region
Hub versus Local Centre – but still deliver the same service.

24. 24
Services and infrastructure
As in a living organism, we need to distinguish between key
categories of services:
• specialist services form value-chains for E2E processes
– examples: dock management, sorting, transport, lodgement, retail
• infrastructure services provide support-services across other
services
– IT examples: networks, applications, SOE, help-desk, phone mgmt
– asset examples: building mgmt, power, equipment maintenance
– people examples: time and attendance, recruiting, rostering
– business examples: performance monitoring, strategy, scheduling
Each type of service may deliver via any combination of
IT/knowledge, physical-asset, people or business components

25. 25
Services and infrastructure
Accept
Parcels
Process
Parcels
Deliver
Parcels
Specialist services are linked along value-chains
E2E
value-chain
infrastructure
services
specialist services
Infrastructure services link across value-chains – and in some cases also
across other infrastructure services

26. 26
Services and the Cost Model
• Specialist-services are relatively easy to cost
– often correspond with Activities on the Capability Model
• Infrastructure-services are often (much) harder to cost
– few infrastructure-services are visible on the Capability Model
– costs tend to be absorbed in and concealed by specialist-services
• Support-services for infrastructure may be even less visible
– is especially true for abstract ‘services’ such as corrective-action,
knowledge-sharing, vision/values maintenance, ‘connector’ roles
• A key objective for a service-oriented architecture is to
‘surface’ all the hidden infrastructure – and its costs
– direct cost of the service, if fully supported and integrated
– opportunity-cost of an absent or under-supported service

27. 27
The systems trade-off within services
If its purpose is clear, a service may use any combination of people-processes,
machine-processes and knowledge-processes…
Cross-check with the EREAI checklist:
– Efficient (conceptual domain)
– Reliable (practical domain)
– Elegant (human/ergonomic domain)
– Appropriate (purpose/business domain)
– Integrated (systems domain)
IT
People Technology
…the key concern is effectiveness.

28. 28
Services and the Viable System Model
The VSM ‘systems’ also provides a useful checklist to evaluate services:
– 5: what is the service’s purpose? who/what defines policy?
– 4: what is the current strategy? outside relationships? who defines these?
– 3: how are the service’s tasks defined, managed and monitored?
– 3*: what random checks / audits are required to verify service performance?
– 2: how is the service coordinated with other services?
– 1: what does the service do? how does it do it? how does it support its
‘downline’ services (if any)?
– X: how does the service identify and resolve any run-time exceptions?
– C: what corrective-action does the service undertake for causes of issues?
– M: how does the service track and manage quality-issues and other issues?
– P: how does the service monitor and manage improvement of its processes?

29. 29
Summary
• Blueprint’s purpose was to maximise benefits of Logistics’ IT investment
– this will remain an important function, esp. of Blueprint Extension
• Its present IT-centric underlying architecture is powerful, but may be too
limited in scope to make sense to a general business audience
– IT-centric approach may also be problematic for cross-division integration
• A simple four-axis ‘meta-framework’ may help to broaden scope
– knowledge (inc. IT), people, technology, business
– rotate attention between these ‘dimensions’ of the enterprise architecture
• System-centric meta-frameworks are useful analysis/review-tools
– Viable System Model analysis of Blueprint completeness and Cost Model
• Meta-frameworks may simplify moves toward service-oriented architecture
– ‘specialist services’ versus ‘infrastructure services’
– understanding the ‘systems trade-off’ within services

30. 30
Footnotes / references
Notes
– Slide 6, “known gaps”: FEAF Performance Reference Model, Version 1.0 [2003], Volume
1, p.18.
– Slide 10, “increasing the scope”: Bredemeyer et al., “Enterprise Architecture as Business
Capabilities Architecture”, http://www.bredemeyer.com, slide 10.
– Slide 11, “three layers”, Migration Plan 12 April 2005v0.2.ppt
– Slide 13, “business capabilities”: Bredemeyer et al., op.cit., slide 15.
– Slide 16, “Viable System Model”: see, for example, Models for Change: The Viable
System Model, http://www.-staff.mcs,uts.edu.au/~jim/bpt/vsm.html .
– Slide 18: source is VSM Model.doc document attached to this slide-pack.
Contact details for Tom Graves
– mail: Tetradian, Unit 215, 9 St Johns Street, Colchester CO2 7NN, England
– web: http://www.tetradian.com