Skip to main content

Author: Hari Shankar

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:

  1. Resolve the exception using the system as part of the activity (Automatic resolution pattern; e.g., Re-try transaction)
  2. Resolve the exception manually as part of the activity (Manual resolution pattern; e.g., Fix data issue and re-try task)
  3. 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)
  4. 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)
  5. 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.

Ignoring Complexity is Not Simplicity

Simplify. This seems to be the buzzword in the projects.

Business owners demand it. Project Managers utter it. Architects revere it. Unfortunately IT seldom delivers it.

How can Business Analysts contribute to the goal of simplification? Let us begin with the definition.

What is Simplifying?

Simplifying tends to get misunderstood. Project Managers and Business Owners often treat it at a superficial level. Business Analysts are encouraged by project stakeholders to ignore complexities and focus on simplistic situations. Simplifying is not about being reducing capability. It is about delivering more by choosing smart solutions.

“Very often, people confuse simple with simplistic. The nuance is lost on most.” Clement Mok

For instance, if there is a significant data integrity issue in a project striving for automation, the issue of data purification and reconciliation is often ignored. While the automation functionality may be delivered (often at a high cost), automation ratios continue to suffer.

Simplifying, in the actual sense, involves taking a complex process and re-engineering them to manageable entity. It requires delving deep rather than staying superficial. Simplifying necessitates focus on non functional requirements such as: Scalability, performance, reliability, security and inter-operability.

Techniques for Simplifying

“Simplicity is the ultimate sophistication.” Leonardo da Vinci

Some of the problem solving techniques that can be applied in various business analysis competencies are highlighted below:

Systems Thinking

One of the common problem-solving approaches, useful especially in the initial stage of the project, is to understand the eco-system of the problem domain. As part of enterprise analysis a holistic view of the components of the domain and their interactions needs to be mapped. Context diagram is a handy tool in documenting the results of the systems thinking. System thinking helps to simplify by focusing on:

• Interdependencies (cause effect modelling)
• Goal alignment (ensuring all value streams work towards achieving common goals)
• Convergence (removing redundancies and improving system performance as whole).

Process Patterns

At a business analysis level, identification of process patterns helps to standardize and improve consistency. All business domains over a period of time tend to exhibit entropy. Identifying the essential process patterns helps in implementing control mechanisms that will reduce process deviations.

For instance a campaign management process, irrespective of the channels that is used (direct marketing, phone, internet etc) would have a process pattern like:

Identify target market, contact target customer, promote concept\educate customer, provide offers and initiate fulfilment.

Process patterns help to maintain consistency, minimize and reuse design and improve throughput. It engenders focus and removes activities that do not contribute to the goal of the process.

Think Data

Data elements are the fundamental building blocks in any system. They tend to get more complicated and maintenance intensive, causing data attrition. In a study done by IBM, data quality even in best maintained system has an attrition value of 2%..

Business analysts can simplify the way in which data structures are defined, maintained, displayed to the users. Identifying core and meta-data relevant to business is an integral part of requirements analysis. Naming standards help reducing the profusion of multiple terminologies.

Organizing data structures smartly ensures that business processes operating to maintain the data can be simplified.

For instance, in a telco domain, if the fulfilment process does not define data structures for service level agreements consistently, service assurance processes will suffer.

And Finally

Business Analysts can gain significant benefits by simplifying the way requirements are documented and communicated.

Using relevant diagrams, requirements management workflow tools, modelling data analysis and presenting them innovatively to stakeholders is a critical component of business analysis.

User stories, scenarios and narrative techniques can help the reader to engage and understand requirements better.

Taking a leaf out of Ernest Hemmingway’s book might perhaps help: “My aim is to put down on paper what I see and what I feel in the best and simplest way.”

Don’t forget to leave your comments below.