Contributed on October 29, 2014

4.3K

1.7K

Bridging enterprise-architecture and systems-thinking

Description

Presentation at Open Day on Enterprise-Architecture and Systems-Thinking, London, 21 October 2104, for SCiO (Systems and Cybernetics in Organisations) http://scio.org.uk/

This used my development-work on the Enterprise Canvas framework as a worked-example of how we might create tools to bridge the gaps between enterprise-architecture and systems-thinking, in support of organisations’ needs.

(This slidedeck also provides a useful overview and primer for Enterprise Canvas itself.)

Transcript

the futures of business
Bridging enterprise-architecture
and systems-thinking
– an introduction to Enterprise Canvas
Tom Graves, Tetradian Consulting: October 2014
An EA / systems-thinking tool…
citizen
(values)
customer
(value)
investor
(money etc)
validation direction coordination
guidance guidance
before before
supplier
relations
value-proposition
during during
supplier
channels
customer
relations
value-creation
customer
supplier customer
channels
after after
value-outlay
value-governance
value-return
investment dividend
mgmt-info
investor beneficiary
Setting the scene…
A core aim in
EA and systems-thinking:
things work better
when they work together
on purpose
For this to happen, we need
guided-conversations
that are actually
everyone’s responsibility.
What visual tools can we use
to engage people in this?
Let’s begin, though, with
a cautionary tale…
Motorola RAZR
– a hugely innovative
product
(in 2003, anyway)
– the outcome
of a new type
of innovation process
CC-BY-NC joshb via Flickr
did Motorola
forget their
process for
innovation?
– mere tweaks
to the product
four years
later, the
product was
gone – and
almost the
company too
CC-BY-NC-ND gordon meivia Flickr
Keep focus on the process
for tools-development,
not just any one product…
Our task here:
some frame or tool to guide
conversations about
things work better
when they work together
on purpose
…but we need to be careful
not to get too focussed
on the tool itself…
keep ourselves open to the
awareness that there are
always other ways to do this!
Where do we start?
Short answer:
start with what we already
have ready to use
in our ideas-toolkit…
Exploring the toolkit
On one side, there’s
enterprise-architecture…
Enterprise-architecture…
Zachman Framework
Enterprise-architecture…
Business Architecture
Data
Architecture
Applications
Architecture
(Information-Systems Architecture)
Technology
Architecture
The ‘BDAT stack’
Enterprise-architecture…
TOGAF (The Open
Group Architecture
Framework)
Enterprise-architecture…
PRM (Performance Reference Model) from
FEAF ([US] Federal Enterprise Architecture Framework)
Enterprise-architecture…
Process-models (lots of them)
Enterprise-architecture…
Capability-models (lots of them)
Enterprise-architecture…
Information-models (lots of them)
Enterprise-architecture…
Business-models (lots of them)
Enterprise-architecture…
And computers, of course.
(lots and lots and lots of them…)
Experience:
mainstream ‘enterprise’-architecture
maybe feels too IT-centric,
too fragmenting
and too incomplete?
My own starting-point was
more with systems-thinking
and other whole-context methods…
Systems-thinking…
vision
policy
procedure
work-instruction
more abstract
more concrete
ISO9000 quality-system standards
Systems-thinking…
Shared-purpose
(vision and values)
Integration
(how the market
links together)
‘Tetradian’ dimensions – physical ‘things’, virtual
information, relational links between people, aspirational
purpose
Relationships
(person-to-person)
Transactions
(products and services)
Conversations
(exchange of information)
Systems-thinking…
Rotating between perspectives…
Systems-thinking…
Modality – the MoSCoW set
(“Must, Should, Could, can-Wait”)
(or “Maybe, Sometimes, Could-be-possible, We-don’t-know”?)
CC-BY-NC-SA thisisbossi via Flickr
Systems-thinking…
Rotating between sensemaking-methods…
Systems-thinking…
Systems-interdependency maps
Systems-thinking…
Stafford Beer’s
‘Viable System
Model’
Systems-thinking…
Recursion and fractality in natural systems
CC-BY-NC-SA gjshepherd via Flickr
Systems-thinking…
Purpose
(forming)
strategy etc
People
(storming)
HR etc
Performance
(adjourning)
reporting etc
Preparation
(norming)
scheduling etc
Process
(performing)
production etc
Strategy (‘feel’)
Tactics (‘think’)
Operations (‘do’)
Extensions to Tuckman, and Five Element (wu-xing)
Systems-thinking…
Values Policies
Purpose
Commitment
Performance
People
Preparation
Process
Events
Trust /
Completions
(start here)
Success
(Initiating-Events)
(Completion-Events)
Extensions to Five Element (wu-xing) on leadership, flow
Systems-thinking…
externalised (objective)
Scientist
(‘outer truth’)
uncharted
swamp
Believer
(‘inner truth’)
Technologist
(‘outer value’)
Artist
(‘inner value’)
truth
(thought)
value
(feeling)
internalised (subjective)
Worldviews, deep-metaphors and modes of operation…
Systems-thinking…
power-over
power-with
power-under
power-from-within
person A person B
Models of power-interactions between people…
Systems-thinking…
An emphasis on people, and spaces…
CC-BY-ND alanclarkdesign via Flickr
Systems-thinking…
Include the people-story…
Systems-thinking…
An emphasis on the system as a whole…
CC-BY-ND Kecko via Flickr
Systems-thinking…
An emphasis on the system as a whole…CC-BY Fretro via Flickr
Experience:
all seems very powerful,
yet much of systems-thinking
and related disciplines
can be too ‘abstract’
for people to (want to) follow?
How might we link all of these
EA and ST themes together,
into something that will work
and ‘make sense’
for everyday EA / ST practice?
(What follows is my synthesis of all that,
to create Enterprise Canvas:
what you’d do might be very different,
depending on your experience and toolkit)
Remember the RAZR:
focus on the process
of synthesis
more than the product
of that synthesis…
Recursion:
this process for developing
a set of whole-of-context tools
for EA and systems-thinking
is itself an application
of EA and systems-thinking
About service
Start with an assertion:
Everything in the enterprise
is or represents a service.
(If so, we can describe everything
in the same consistent way.)
Why anything happens
A tension exists between what is, and what we want.
The vision describes the desired-ends for action;
values guide action, describing how success would feel.
The nature of service
A service represents a means toward an end
– ultimately, the desired-ends of the enterprise-vision.
Relations between services
Services exchange value with each other, to help each
service reach toward their respective vision and outcome.
Services serve.
(That’s why they’re called ‘services’…)
What they serve is the story,
via exchange of value.
(And if we get that right,
they can sometimes make money, too.)
Values and value
Each service sits at an intersection of values (vertical)
and exchanges of value (horizontal)
How connection happens
Value-flow is ‘horizontal’, but connection is first made by
‘vertical’ connection to shared-value and value-proposition
In more detail
value-add
(self)
customer-facing
supplier-facing
Interactions during the main-transactions are preceded by
set-up interactions (before), and typically followed by other
wrap-up interactions such as payment (after).
We can describe ‘child-services’ to support each of these.
Business-model as service
Crossmap between Business Model Canvas and Enterprise Canvas
Supply-chain or value-web
Services link together in chains or webs, as
structured and/or unstructured processes, to deliver
more complex and versatile composite-services.
Guidance for services
Keeping on track
Use the Viable System Model (direction, coordination,
validation) to describe service-relationships to keep this
service on track to purpose and in sync with the whole.
Keeping on track: VSM
Viable System Model, representing a fractal service
Keeping on track: VSM
Viable System Model ‘systems’ are orthogonal to each other
Keeping on track: VSM
Coordination and Validation don’t fit comfortably with Taylorism
Keeping on track: Direction
management-services
policy
strategy
direction
This is the equivalents of VSM system-3, -4 and -5
Keeping on track: Direction
interaction with
management-services
in parent-service above
management-services
policy
strategy
direction
policy
strategy
direction
interaction with
management-services
in child-services below
Interactions with delivery-services (system-1), and recursion
Keeping on track: Coordination
management-services
policy
strategy
direction
delivery-service
develop
the business
change
the business
run
the business
delivery-service
delivery-service
Extended functions for equivalent of VSM system-2
The VSM algedonic links
– ‘any-to-any’ connections –
provide another kind of coordination.
(Hard to show on diagrams, though.)
Keeping on track: Validation
Major extensions / rethink for VSM system-3*
Validation-services:
for each enterprise-value:
– build awareness of the value
– build capability to enact support
– enact in practice at run-time
– assess and review
(for continual improvement)
Investors and
beneficiaries
Investor and beneficiary
These flows (of which only some types are monetary)
are separate and distinct from the main value-flows.
Another useful assertion:
Every enterprise
is ‘for-profit’.
(We need to think of ‘profit’ in a much
broader sense than money alone.)
Investor and beneficiary
shared-enterprise
includes community, government, non-clients, anti-clients, others
market
includes competitors, supplier- regulators, others
prospects
customer-prospects
supplier organisation customer
includes investors, beneficiaries
Investors and beneficiaries are often outside even of the
market – yet are still part of the same shared-enterprise.
We need to consider
investments and returns
of every applicable type,
to and from
every type of stakeholder.
(‘Applicable type’ is determined
by the shared-enterprise values.)
Stakeholders in the enterprise
A stakeholder
in the story
is anyone
who can wield
a sharp-pointed
stake
in your direction…
CC-BY-NC-SA evilpeacock via Flickr
(Hint: there are a lot
more of them than you
might at first think…)
Values, value-flow, money
values
(‘why’)
(‘why’)
value-flow
(‘how’,
‘with-what’)
(‘how’,
‘with-what’)
profit
(money and more)
(money and more)
These are distinct flows – don’t mix them up!
Doing it right: values-first…
Values-first enables full connection with shared-enterprise
Doing it wrong: money-first…
Money-first causes disconnect from shared-enterprise
Always start from values,
not money.
If we focus on money,
we lose track of value.
If we focus on the ‘how’ of value,
we lose track of the ‘why’ of values.
Always start from the values.
(Not the money.)
Layers of abstraction
for service views
‘Rows’ – layers of abstraction
Enterprise
Scope
(context)
other other
Business-services
other other
Service-content
supplier customer
Service-design
supplier customer
Service-deployment
supplier customer
Action-record
supplier customer
Enterprise identity, vision and values
Lists of key players and items in enterprise
Roles / relations between / within key players / items
Actions / transactions – implementation-independent
Actions / transactions – implementation-specific
Actions / transactions – operations-specific (action-plan)
Actions / transactions – as actioned / completed (past)
Row-numbering aligns with Zachman
row-0
row-1
row-2
row-3
row-4
row-5
row-6
Each ‘row’ downward
adds something more
to the description.
Example:
row-3 is implementation-independent,
row-4 is implementation-specific.
Beware of mixed layering
E-commerce service
front-end
content
server
web-server
(Apache)
payments
processing
database
(Oracle 9i)
Fulfilment warehouse
Dayton,
Milton
Ohio
Keynes
Marseilles Den Haag
Example: Use solid-lines versus dashed-lines to represent
row-3 / row-4 layer-differences in model and model-entities
Layers in Enterprise Canvas
are layers of abstraction
within the same scope
– not arbitrary views into
different parts of the scope,
with arbitrary interconnections!
Row-0 example – ZapaMex
“making
feet happy”
enterprise-vision as identified by ZapaMex
Row-0 is solely the enterprise-vision and (optional) values
Row-1 example – ZapaMex
“making
feet happy”
Who What How Where When Why
Row-1 is simple lists from Zachman interrogatives,
describing entities needed to make the enterprise happen
Row-2 example – ZapaMex
“making
feet
happy”
leather
supplier
ZapaMex
designer
overseas
market-partner
shoe-buyer
medical
partner
competitor
Row-2 starts to show relationships across the enterprise
Row-3 example – ZapaMex
deliver
shoes supplier customer
receive
materials to
inventory
make shoes
store and
ready shoes
for shipment
obtain
materials
An overly-simplistic row-3, based on transactions only
Row-3 example – ZapaMex
procurement
product-development
+ marketing
receive
materials to
inventory
make shoes
sales and
service
store and
ready shoes
for shipment
supplier customer
accounts
payable
manage
budget,
operations
accounts
receivable
identify and
support
suppliers
obtain
materials
pay for
materials
identify and
support
customers
deliver
shoes
be paid for
shoes
Describe more of the row-3 detail for service-delivery
Row-3 example – ZapaMex
shared-enterprise
gain / maintain enterprise reputation
market
gain / maintain market respect
procurement
product-development
+ marketing
receive
materials to
inventory
make shoes
sales and
service
store and
ready shoes
for shipment
gain supplier
respect
gain customer
respect
supplier customer
accounts
payable
manage
budget,
operations
accounts
receivable
identify and
support
suppliers
obtain
materials
pay for
materials
identify and
support
customers
deliver
shoes
be paid for
shoes
verify supplier
satisfaction
verify customer
satisfaction
verify market satisfaction
verify enterprise satisfaction
Expand row-3 modelling out to the full enterprise-context
Internal structures
of services
Service-content
We can view what services consist of in various ways
– but eventually we’ll need the full detail
Service-content
What How Where Who When Why
In rows 1 and 2 (lists, and basic relations between entities),
we can get away with the simple Zachman-interrogatives
Service-content
Capabilities
Locations
Functions
Assets
Events
Decisions
For rows 2 and 3 (implementation-independent),
we start to need to become more specific
Asset (‘What’)
– a resource for which
the enterprise acknowledges
responsibility
Composition:
any combination of asset-dimensions.
Function (external of ‘How’)
– external-facing interface,
responsible for service-contracts,
protocols, SLAs, etc;
accepts and returns assets
Composition:
any combination of asset-dimensions.
Location (‘Where’)
– a position within the terms of
a specific schema
Composition:
any combination of asset-dimensions,
plus time-as-location.
Capability (‘Who’ / ‘How’ / ‘What’)
– the ability to do something:
– agent enacts the capability
– action asset-type acted upon
– skill-level competence of the agent
Composition:
agent / action: asset-dimensions;
skill-level: skills/decision dimensions;
also recursively consists of other services
Event (‘When’)
– trigger for a function and
underlying capability
Composition:
any combination of asset-dimensions.
Decision / Reason (‘Why’)
– sensemaking / decision-making
for the service, and/or its type of
guidance or governance
Composition:
any combination of decision/skills
dimensions.
Function, capability and service
service
capabilities
function
(interface)
Seen from outside, function and service may seem the same:
service is the whole thing, function is just its external-interface
Service-content
Starting in row-3, and downward to the real-world,
we must have the full detail of how all the elements intersect
Asset dimensions
Assets
Asset-types What
Phys
Virtual
Reln
Aspn
physical object, machine, geographic location etc
information, software-application, IP-address etc
link between people and/or to other tangible ‘things’
person-to-virtual or virtual-to virtual link (brand etc)
Physical
Virtual
Relational
Aspirational
Most entities will consist of any appropriate combination
– e.g. book is physical ‘thing’, contains information, is valued
Asset dimensions
Shared-purpose
(vision and values)
Relationships
(person-to-person)
Transactions
(products and services)
Integration
(how the market
links together)
Conversations
(exchange of information)
Asset-dimensions are essentially same as ‘tetradian’ dimensions
On relational-assets…
“Our people are our greatest asset!”
– the only time that people are ‘assets’
is when they are slaves…
The relationship is the asset
– not the person…
CC-BY-NC-ND littlejoncollection via Flickr
Decision/skills dimensions
Decisions
simple, linear, true/false or limited-quantitative
complicated, linear but allow for delays, feedback
complex, ambiguous, non-linear, ‘wild-problems’
uniqueness, extreme-uncertainty, ‘chaotic’
Decision/skill-types Why
Rules
Algor’m
Guideln
Princpl
Rule-based (trainee)
Algorithmic (apprentice)
Guidelines (journeyman)
Principle-based (master)
Most contexts will need to include combinations of these
Decision/skills dimensions
Decision/skills dimensions much the same as SCAN domains
Service-content
We can describe the content and structure of all services,
using this as a graphical checklist.
(Also illustrates that Zachman needs an entire extra dimension)
Products as exchanges
between services
Exchanges
Service Product Service
Products are exchanged between services
A product
is an outcome of service
and the promise
of future service.
Exchanges as assets
Assets
Asset-types What
Phys
Virtual
Reln
Aspn
physical object, machine, geographic location etc
information, software-application, IP-address etc
link between people and/or to other tangible ‘things’
person-to-virtual or virtual-to virtual link (brand etc)
Physical
Virtual
Relational
Aspirational
Products / exchanges are always (sets of) assets,
composed of combinations of the asset-dimensions.
Views across service-boundary
• Outside-out: Big-picture ‘world’, beyond even the market
• Outside-in: View from ‘outside’ into organisation
• Journey: Touchpoints between ‘outsider’ and organisation
• Inside-out: View from the organisation’s perspective
• Inside-in: View of the organisation to inside itself
Cycles of interaction
between services
The service-cycle
Shared-purpose defines the service-context
boundary of ‘market’
in conventional
business-models
Reputation / trust
Respect / relations
Attention / conversation
Transaction / exchange
(profit / value-return)
Completion
Reaffirmed trust
Overall flow of service and exchange follows a consistent cycle
Enterprise and service-cycle
shared-enterprise
includes community, government,
non-clients, anti-clients, others
market
includes prospects, competitors, regulators, others
transaction
supplier organisation customer
Reputation / trust
Respect / relations
Attention / conversation
Transaction / exchange
(profit / value-return)
(completion)
(reaffirmed trust)
Much the same themes apply to shared-enterprise and market
Enterprise and service-cycles
shared-enterprise
gain / maintain enterprise reputation
market
gain / maintain market respect
procurement
product-development
+ marketing
receive
materials to
inventory
make shoes
sales and
service
store and
ready shoes
for shipment
gain supplier
respect
gain customer
respect
supplier customer
accounts
payable
manage
budget,
operations
accounts
receivable
identify and
support
suppliers
obtain
materials
pay for
materials
identify and
support
customers
deliver
shoes
be paid for
shoes
verify supplier
satisfaction
verify customer
satisfaction
verify market satisfaction
verify enterprise satisfaction
The service-cycle applies across all of these connections
Asset-dimensions and service-cycle
shared-purpose (aspirational)
relationship (relational)
conversation (virtual)
transaction (physical)
(delivery of service)
(completion of actions)
(completion for provider)
(reaffirmed trust)
(completion for customer)
(completion for enterprise)
Different stages of the cycle emphasise different asset-types
(overall cycle needs to complete for trust to be maintained)
Project-cycle and service-cycle
Purpose
(forming)
strategy etc
People
(storming)
HR etc
Performance
(adjourning)
reporting etc
Preparation
(norming)
scheduling etc
Process
(performing)
production etc
Every instance of service is also a project in its own right
Five Elements and enterprise
An adaptation of Five Elements describes service-lifecycles
Five Elements and service-cycle
Values Policies
Purpose
Commitment
Performance
People
Preparation
Process
Events
Trust /
Completions
(start here)
Success
(Initiating-Events)
(Completion-Events)
Identify the elements that help to pull from one phase to next
Service-cycle and Enterprise Canvas
enterprise
vision Trust
value-proposition
value-creation
supplier /
customer
relations
supplier /
customer
channels
value-governance
value-outlay
/ return
Purpose
People
Perform
ance
Process
Purpose
People
Preparation
Process
Trust
Performance
Values
Policies
Completions
Values
Policies
Events
Events
Completions
Success
Success
Prepara
tion
‘Inside’ child-services of Enterprise Canvas shown to left;
‘outward-facing’ child-services shown to right.
Exchanges everywhere…
Similar exchanges apply across every interchange and flow
Wrapping-up…
Restate that assertion:
Everything in the enterprise
is or represents a service.
(If so, we can describe everything
in the shared-enterprise
with Enterprise Canvas.)
Remember the RAZR:
don’t focus too much on the
product (Enterprise Canvas),
focus more on the process
from which the product arose.
How would you
merge EA and ST together,
into something that will work
and ‘make sense’
for everyday EA / ST practice?
Further information:
Contact: Tom Graves
Company: Tetradian Consulting
Twitter: @tetradian ( http://twitter.com/tetradian )
Weblog: http://weblog.tetradian.com
Slidedecks: http://www.slideshare.net/tetradian
Publications: http://tetradianbooks.com and http://leanpub.com/u/tetradian
Books: • The service-oriented enterprise: enterprise architecture and
viable services (2009)
• Mapping the enterprise: modelling the enterprise as services
with the Enterprise Canvas (2010)
• Everyday enterprise-architecture: sensemaking, strategy,
structures and solutions (2010)
• Doing enterprise-architecture: process and practice in the
real enterprise (2009)