3. Symptoms
Horror Stories
• Lost body
• Lost referrals
• The staff were wonderful – really?
4. Symptoms
Political football
• Change initiative exhaustion
• Choice
• Not even trying to design
5. 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
7. 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
9. Prescription
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
10. 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
11. 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
14. Prescription
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
15. 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
16. 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.”
17. 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.
18. 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.
19. 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.
20. 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
