The NHS and Business Architecture

Philip Veasey – Ealing LINk

UNICOM Enterprise Architecture Forum, London, March 2012

Curing the NHS

Treatment Prescription

Diagnosis Symptoms

Horror Stories

• Lost body

• Lost referrals

• The staff were wonderful – really?

Symptoms

Political football

• Change initiative exhaustion

• Choice

• Not even trying to design

Symptoms

Close-up

• Too much perception management, not enough performance improvement

• Specific patient journeys optimised at expense of overall coordination system

• Restricted access to business architecture information – if it exists!

• Empire building

• Technology before process

Symptoms

Axum Change Framework

• Identify the stakeholders

• Determine which capabilities they expect

• Determine processes that can deliver the capabilities

• Plan changes to: – Culture

– technologies

– people organisation

– competencies

that will be needed to support the processes

Process

Tec

hnol

ogyCulture

Capabilities

Stakeholders

Com

petencies

Organisation

© Copyright Axum Ltd. 1995

Diagnosis

• No shared picture to support communication and cooperation: – Please let’s have pictures

– The one picture I have – governance

• No management of complexity: – No design to reduce it

– No record of it

– Lost opportunities for integration

• Non-cooperative stakeholders

NHS Governance

Business architecture

• Must be genuine: – Based on detailed knowledge – Boxes and arrows meaningful

• Process before people organisation structures – Effectiveness and efficiency before empire building

• Process before technology: – Business architecture before technical architecture

• Reducing complexity: – Recursive structures – Configurable business modules – Designed language of the future

Prescription

Pitfalls

• Complexity Management:

– Natural selection is a cruel master. We escape it by designing

– Limits of design. To be recognised but not used as an excuse for no design

• Knowledge hoarders

• Treating modelling as trivial

Prescription

Process modelling

• Needs to be creative, use top designers

• Model the whole industry or marketplace. Hugely complex in the case of the NHS

• Use Role Activity Diagrams (RADs - see last four slides) for process architecture

• NHS has a special need to trace accountability and responsibility rigorously

Prescription

Example of an Industry Model - The TV Industry -

A Process Architecture using RADs

– Top Level –

Policies

• No integration without investment in adequate corporate memory (so you know how to unpick it if necessary)

• Ignore politicians as far as possible

• Open information

Prescription

Treatment

• Over to you:

– If you work with NHS, press for Architecture

– Join LINks

• Ealing LINk:

– NWL NHS Integrated Care Pilot - RADs

– WikiArch ?? Extension to other orgs

Advantages of RADs

• Capture coordination

• Easily understood

• Usable from high to low level modelling

“Nothing else comes close in reflecting the

nature of processes involving humans.”

Capture coordination

• Emphasise visibility of interactions between roles - getting these right is the heart of business process design. Most process failures are failures of coordination.

• The RAD “interaction” is directionless. It allows the initial modelling of shared activities without any assumption of the logical ordering of the parts played by different roles. Very useful in modelling enterprises and marketplaces with many stakeholders (such as airports or NHS).

• Give roles high visibility, making their level of abstraction easier to manage. This makes the eventual mapping of process through to concrete organisation much easier.

• When a model is expanded (drill down), it is an interaction that gets modelled in greater detail not just an activity that has been arbitrarily assigned to just one role.

Easily understood

• Are nearly always understood quickly and easily by business users.

• Downward arrow of time helps to tell the story

• They allow parallel activities within roles to be seen with great clarity. This is partly because of adjustable width “swim lanes” and partly because the refinement construct allows the “shape” of the process to emerge.

• More than one box representing the same role, and containing activity, can appear on a single page. Again the “shape” of the process is clearer.

• These constructs also makes good use of space on the page allowing more of the story to be visualised in one eyeful.

Usable from High to Low Level Modelling

• Very easy to use for current process

• With right approach, give the best process architectures

• Allow the modelling of the dynamic creation of process instances, allowing the relationship of case processes and case management processes to be accurately modelled.

• According to the use the diagram is being put to, RADs allow state changes and sequencing logic to be identified as completely as is helpful.

• Can be developed, if appropriate, to a rigorous definition of a coordination system that is convertible to executing code.

• If systems are modelled as roles, provide an excellent way of designing the scope of Use Cases and demonstrating how they relate to the process.

Philip Veasey is a specialist in business architecture in which capacity he has helped organisations in many fields including: insurance, healthcare, aviation, local government, television and Government agencies. He has worked as an independent consultant since he left ICL in 1993 where he led the Business Reengineering programme. Email: pveasey@axumbpm.co.uk