In the first article of this series, the idea of an emergent environment was introduced. There are several key properties of a setting where an emergent approach for process development can be highly effective. These include environments where there is:
Lack of CertaintyDesire for AgilitySkills Disparity
Increasingly, senior executives of organizations are promoting the need for enterprise agility – they want to decrease the time between identifying a course correction and implementing the changes necessary to take it. Externally, this can take the form of shortening the time required to provision or launch a new product offering. Internally, it might be an initiative to close the books a few days sooner after the end of the quarter.
The term course correction is used here deliberately. An emergent approach is one that evolves from experience. Many leaders no longer assume they can arrive at a five year plan that will be exactly right if only followed to the letter. The business planning process has become more iterative, and in so doing, invites on-going review, revision or even abandonment of initiatives as new information comes to light.
This of course means that senior managers are having to build into their processes the ability to capture and deal with uncertainty. Professionals who deal with the management of business processes need to provide mechanisms to support that.
Emergent Environments
Uncertainty affects more than just the overall strategic planning function. Within a corporate culture there may be a reluctance to leave off practices which have worked, apparently well enough, for a long period of time. The struggle in Information Technology projects between a Waterfall and Iterative approach is an excellent example. The move to a Service Oriented Architecture is another. Organizations frequently need time, and successful experiences, to become convinced of the value of a change in fundamental process.
Skills Disparity refers to the range of capabilities within an enterprise. It describes the situation where external experts are brought in, and there is a need to transfer new skills to employees. Equally well it applies to the veteran of twenty-five years, who intimately understands the organizations history and has a wealth of knowledge about products, services and systems. As retirement looms, there is a risk that this wealth will leave the organization. The need for processes for transferring those skills, and updating the practices where they are used, is a indicator of an emergent environment.
On some level, every environment reflects some of the characteristics described above. Having identified the properties that fit an emergent approach, the next step is to define the approach itself. The critical piece of the puzzle to resolve is how something as abstract as a strategy can become a measurable (which is to say tangible), manageable process. Patterns for Designing Good Solutions
As building architects have known since Christopher Alexander published his groundbreaking work on Patterns¹, design models have a structure and a language of their own. Design patterns are especially useful for communicating an abstract set of problem and solution elements from one concrete setting to another. Business process analysts can benefit by employing them.
One of the most significant design patterns for application in an emergent environment is the ‘Report by Exception’ pattern. Exception in this example is not as limited as a program that ‘throws an error’. Instead, the business process designer can benefit from defining the allowable parameters within which a process can operate. Only when the process finds itself operating outside the approved range of times, values, functions does it raise an exception.
Contrast this with the Polling model. Traditional approaches to monitoring status is to poll or query each entity to be managed on a scheduled basis. This ‘checking in’ approach is active and generally controlled centrally, where status results are aggregated and communicated onwards to other interested parties. The problem becomes one of bandwidth. If each polling operation takes a second and the maximum throughput of the communication channel is 100/sec, the maximum number of entities that can be managed is 100.
Under the report by exception design pattern, the same communication channel can support many more entities, to a maximum of 100 concurrently reporting exceptions!
This design pattern can be easily applied as a means for managing a large number of distributed telecommunications nodes over a network with limited capacity. But beyond managing widgets, it applies equally well to business processes and the operational entities that make up the decisions contained with them.
Modeling business process to limit the call on resources to exceptional situations makes a good deal of sense. Instead of communication channel, an example might be a call center with resources such as level three technical support. The principle still applies. By establishing the exception boundaries of a process, and building on a Report by Exception basis, it is not necessary to trap and investigate every single transaction that forms the process. The process can be observed in operation and provide notification only when certain thresholds are reached or breached.
When the GoF² published their first work on software design patterns, they defined as part of that effort ‘The Observer Pattern’. That pattern describes an approach for software programs to essentially listen for events. Other patterns, such as Event Notification provide software designers with ideas for how to code for complex situations in their environment, such as how to listen for and respond to events that fall within or outside defined parameters.
There is a direct relationship between how these patterns are used for programs and their affect on business process definition.
¹A Pattern Language – Christoper Alexander
²(Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) is a software engineering book describing recurring solutions to common problems in software design. The book’s authors are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They are often referred to as the GoF, or Gang of Four. – from Wikipedia)
Applying Design Patterns to Business Processes
The view taken here is focused on gathering validated requirements and communicating those prior to the detailed design or implementation of software intended to address them. In an iterative, agile environment the feedback between design and deployment is a loop. Where to start can become somewhat arbitrary. It might seem natural to begin with the plan, or the top-down objectives and flow through to elaboration and deployment, then revisit how the experience affects the plan. No doubt, in some situations this approach is exactly right.
However, since business processes frequently already exist in some form, it can be beneficial to first evaluate the situation on the ground, defining the deployment environment, and apply that to the planning process from the outset.
By linking the design patterns used for application development directly to the requirements definition, a business process analyst ensures a tighter alignment between the solution developed and the business problem to be solved.
In this case, the observer and notification patterns relate to the modeling of business decisions.
Decision Models³ provide for representing business judgment within structured families of rules, conditions and conclusions. The application of observer and notification design patterns to decision models allows for exception handling to be identified from a business standpoint. Once decisions are defined as containing the the default and exception thresholds, rules for notification, approval or alternate handling should be clear to the solution developers. They can then focus on the how, rather than discerning what needs to be accomplished by their code.
This should demonstrate the role for meta-data surrounding transactions, the rules underlying them, their exceptions and the business decisions that they affect.
Summary
Enterprise Agility does not exist in a vacuum. Lessons learned, even painful ones, do not necessarily present themselves fully formed in the minds of participants and observers at the end of a project. Skills do not reliably transfer from veteran to recruit by osmosis. These things occur as a result of managed processes.
To increase confidence that the enterprise can respond to change, can do so quickly while raising skills and practices to a consistently high level, tighter alignment with the definition of business problems and the development of software solutions is required. One way to achieve this is to apply software design patterns, such as Observer, Notification and Report by Exception to business process definitions.
Having defined some of the characteristics of an emergent environment, the next article in the series will drill down into techniques for predicting probable outcomes to emerge.
³The Decision Model – B Von Halle, L Goldberg,
