1
Meta-frameworks:Making the Blueprint more accessible
Tom GravesTetradian Consulting
Date: Thursday 9/03/2006
2
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
Purpose of this review
3
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
Connect to extend
To extend the business usefulness of the Blueprint,we must break free of the tendency towards an IT-centric view
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
A broader view of the enterprise
By contrast,
...and be willing to explore and map every area of the broader enterprise, to create a greater understanding of that whole.
enterprise architecture needs to see the world as a whole, with no real ‘centre’ as such...
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
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
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
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
“A business system consists of manual process/activities, logistics equipment and information systems” – Logistics: Definition of Blueprint Terms
‘Human Capital’is People
‘Other Fixed Assets’is Technology
…this ‘Technology’ is only IT – butshould be Knowledge in general
10
FEAF is a useful map for IT, but…
We must remember FEAF shows only a small portion of the whole…
…not merely the FEAF subset.…and it’s that whole that we need to iterate towards…
11
Much the same applies to TOGAF...
The Open Group Architecture Framework (TOGAF) is similarly IT-centric…
…the whole enterprise, not just an IT-oriented subset.…yet it’s the architecture of the whole that we need to iterate towards…
12
An Operations view of FEAF?
FEAF does provide a good framework for an IT view of that whole…
…and almost nothing for an Operations view.
…yet only limited support for a Business view…
The Blueprint needs broader description of Logistics’ enterprise architecture.
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
Strategy and enterprise architecture
Maturity/ Commercial
Focus
Impact on Long-Term Profitability
Technical Architecture (TA)underpins
Productivity Improvements
Enterprise-WideInformation Technology
Architecture (EWITA)underpins
End-to-EndInformation Management
& Process Support
EWITA +Business Architecture (BA)
underpinCustomer 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.
The three layers of Logistics’ Business Systems Strategic Plan*
15
Bredemeyer on Enterprise Architecture
Need to design business capabilities– people– process and– technology
Enterprise Architecture is the architecture of business capabilities*
“Enterprise Architecture recognizes that the organization is a system, and the crosscutting concerns must be addressed first at the overall system level.”
Business Architecture
Business ProcessesInformation Org. Structure
EWITA
EAI EAI EAI
(bu
sin
ess
cap
abil
itie
s)
cross-cutting concerns
cros
s-cu
ttin
g co
ncer
ns
cros
s-cu
ttin
g co
ncer
ns
cross-cuttin
g concerns
cross-cutting concernscros
s-cu
ttin
g co
ncer
ns
16
Need for a larger scope than just IT
It’s why we need an integrated view of business systems…
…rotating constantly between views…
…to maintain that sense of the whole…
...EWITA and Business Architecture, 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 environmentAnd 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’.
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:
The model is recursive: each layer contains the next, to whatever depth required.
These interact with each other to act on and with the external world (the amoebic ‘blob’ to the left of the diagram).
• 1 – operations (lilac)
• 2 – coordination (mid blue)
• 3* – sporadic audit / review (pale blue)
• 3 – ‘inside / now’ [staff management] (red)
• 4 – ‘outside / future’ [inc. strategy] (yellow)
• 5 – policy / purpose (green)
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
Blueprint coverage of VSM systems
0 5 10 15 20
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 activitiesfor each VSM system (‘5’-’1’) or their interactions (‘X’-’P’)*
represents untraceable costs?
represents untraced opportunities for improvement?
21
About Key Performance Indicators
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)
As with IT architecture, services are the key –the balance-pointaround which everything else revolves
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
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
Services and infrastructure
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
AcceptParcels
ProcessParcels
DeliverParcels
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
The systems trade-off within services
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
If its purpose is clear, a service may use any combination of people-processes, machine-processes and knowledge-processes…
…the key concern is effectiveness.
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
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
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
Top Related