metaframeworks: making the blueprint more accessible

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

Upload: tetradian-consulting

Post on 21-May-2015

523 views

Category:

Business


0 download

DESCRIPTION

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.

TRANSCRIPT

Page 1: Metaframeworks: making the Blueprint more accessible

1

Meta-frameworks:Making the Blueprint more accessible

Tom GravesTetradian Consulting

Date: Thursday 9/03/2006

Page 2: Metaframeworks: making the Blueprint more accessible

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

Page 3: Metaframeworks: making the Blueprint more accessible

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

Page 4: Metaframeworks: making the Blueprint more accessible

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.

Page 5: Metaframeworks: making the Blueprint more accessible

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...

Page 6: Metaframeworks: making the Blueprint more accessible

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.

Page 7: Metaframeworks: making the Blueprint more accessible

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

Page 8: Metaframeworks: making the Blueprint more accessible

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.

Page 9: Metaframeworks: making the Blueprint more accessible

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

Page 10: Metaframeworks: making the Blueprint more accessible

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…

Page 11: Metaframeworks: making the Blueprint more accessible

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…

Page 12: Metaframeworks: making the Blueprint more accessible

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.

Page 13: Metaframeworks: making the Blueprint more accessible

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)

Page 14: Metaframeworks: making the Blueprint more accessible

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*

Page 15: Metaframeworks: making the Blueprint more accessible

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

Page 16: Metaframeworks: making the Blueprint more accessible

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

Page 17: Metaframeworks: making the Blueprint more accessible

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’.

Page 18: Metaframeworks: making the Blueprint more accessible

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)

Page 19: Metaframeworks: making the Blueprint more accessible

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.

Page 20: Metaframeworks: making the Blueprint more accessible

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?

Page 21: Metaframeworks: making the Blueprint more accessible

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

Page 22: Metaframeworks: making the Blueprint more accessible

22

Service-oriented architecture (SOA)

As with IT architecture, services are the key –the balance-pointaround which everything else revolves

Page 23: Metaframeworks: making the Blueprint more accessible

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.

Page 24: Metaframeworks: making the Blueprint more accessible

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

Page 25: Metaframeworks: making the Blueprint more accessible

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

Page 26: Metaframeworks: making the Blueprint more accessible

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

Page 27: Metaframeworks: making the Blueprint more accessible

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.

Page 28: Metaframeworks: making the Blueprint more accessible

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?

Page 29: Metaframeworks: making the Blueprint more accessible

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

Page 30: Metaframeworks: making the Blueprint more accessible

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