Process Patterns – Applying Method to Chaos
Unpredictability. Randomness. Chaos.
They are the only certainty in the life of any Business Analyst. Even more so for the brave ones painting green-field processes for a large enterprise project.
Throwing up our hands in despair is not a choice. And making costly changes to a program of work midstream will not endear us with the Project Managers ( and that’s putting it mildly).
I was faced with such a challenge in the last year working as a Lead Business Analyst for a major program of work. Process patterns came to my rescue.
Patterns in real life
Humans are intuitively programmed to bring structure around us. Every successful civilization has worked on making society predictable. Our approach to science has been no different from life. We are governed by patterns — climate, seasons, diurnal dance of the planets in the solar system, etc. Where they do not exist we invent one — transport, communication, weekends, etc.
Astronomers see patterns in the random sprinkling of stars in the sky. Mathematicians look for fractal patterns even in the most chaotic distribution. Bio-technologists search for patterns in DNA. Climatologists study weather patterns to predict global warming effects. Every field involved in handling complex systems deploys the use of patterns to analyse and simplify.
Alex Bellos, in his fascinating book Alex’s Adventures in Numberland, talks of intricate design patterns in the mosque as a way of finding God through patterns.
Patterns in IT world
Patterns occur in everything.
Design patterns are a very common methodology in developing IT systems. Creational, Behavioural and Structural patterns are quite common thought processes used by Developers.
Data mining is deployed to understand information, correlate and study the behaviour of discrete data points. Statistical tools are very common to understand variance, randomness and distribution.
Interaction pattern is the development of a framework to model inter-organization interactions (can be used for intra-organizational too) to predict the exchange of information. Request, Acknowledge, Respond is such a pattern that could be deployed between a Customer and Supplier framework for interactions.
Process patterns is the emergent ability to define fragments that will provide a reliable mechanism for handling random events in a complex system.
Process Patterns
In the program of work I was involved in, I established the Happy Day Scenario using Level 4 processes at an activity level. Process patterns were then used to decompose individual Level 4 activity into Level 5 processes at the task level.
Embracing Murphy’s law, we soon firmed up that anything that can go wrong will go wrong. Data may be missing or inaccurate. System integration can break. People can make mistakes. Hence scenarios were soon approaching quite a large number. Defining a Level 5 Task process for each Scenario would have been a hopeless exercise. And we would have missed the forest for the trees. This is the key distinction for mapping patterns between Scenario-driven and Pattern-Driven.
The answer I felt was in the identification of the pattern in the process. For instance, a set of tasks could lead to the happy-day outcome. What would happen if things go wrong? We established a pattern for exception as follows:
- Resolve the exception using the system as part of the activity (Automatic resolution pattern; e.g., Re-try transaction)
- Resolve the exception manually as part of the activity (Manual resolution pattern; e.g., Fix data issue and re-try task)
- Resolve the exception and re-enter the activity (Activity Re-entry pattern; E.g., Fix issue and re-enter from the first task in the activity)
- Resolve the exception and re-enter from the previous activity (Process Re-entry pattern; e.g., Fix issue and re-enter process from an earlier activity)
- Resolve the exception by abandoning the process (Process Abandonment pattern; E.g., Cancel Order and re-commence)
Similarly, patterns were established for workflows, sub-processes, alternate flows and product types.
It was a fun exercise to map these patterns and ask our business stakeholders to challenge with scenarios. We were lucky to have a lot of black-hat thinkers who could come up with What-if situations based on data, systems or people exceptions and test the process pattern. The use of the right combination of process patterns stood the test in most cases.
Process Pattern led Design
Advantages of the process patterns were it fostered the need to design based on patterns. So the thinking is percolating to the way systems are developed. Further testing is simplified by testing the core patterns. Since we ended up with close to 100 process patterns (yes, it was a complex program), testing was prioritized for the critical patterns and scenarios chosen to ensure each pattern worked.
Process patterns provided us with some level of insulation from changes that are constantly happening in our business landscape. The introduction of new products, contracts or customer interactions have largely been channelled through existing process patterns.
And to quote Richard Bach below, the recognition of process patterns can help us see new horizons.
“A cloud does not know why it moves in just such a direction and at such a speed…It feels an impulsion…this is the place to go now. But the sky knows the reasons and the patterns behind all clouds, and you will know, too, when you lift yourself high enough to see beyond horizons.”
– Richard Bach, Author of Jonathan Livingston Seagull
Don’t forget to leave your comments below.