Home > Blogs > Achieving agility - process management is not enough

Achieving agility - process management is not enough

Many IT analyst firms write a great deal about achieving business agility. Some time ago a group of Gartner Group analysts wrote a linked set that was particularly thoughtful and made me think about the need for both decision management and process management.

Agility is defined by Gartner as "the ability of an organization to sense environmental change and to respond efficiently and effectively to that change"[2]. I like the definition as it talks about sensing, which neatly includes expected and unexpected changes as well as sudden and gradual ones, and because it emphasizes efficiency and effectiveness in response. It is not enough to respond quickly to be agile, one must also respond appropriately.

At an overview level, one paper [1] discussed both how a focus on agility is a necessary consequence of the accelerating pace of business change and that technology has a role (though not the only one) to play in this. Clearly people are always going to be a bottleneck when it comes to change, that's just how people are. Indeed one of the papers discussed "Human latency"[4] as something that reduced agility. Some technology approaches make it harder to be agile and some make it easier. Some help you persuade people to change, others to implement the changes once they get agreed. Some, like business rules, can replace people in time-sensitive processes by helping you automate decisions. Indeed the paper on Communication-Enabled Business Processes discussed the class of process initiated by an application and gave some examples of how and why you might replace human decision-making with automated decision-making to streamline and improve a process[4].

Gartner has an agility cycle that it uses to show both how agility is achieved and that it is ongoing. These are described in some detail [1] but the basic steps are:

  • Sense
  • Strategize
  • Decide
  • Communicate
  • Act

These seem to me to be eminently sensible, though I suspect that Strategize and Decide will be done iteratively together in many cases. This cycle is referenced by all the other papers as the basic approach to delivering agility. Clearly different approaches are called for and different issues arise in each step and the papers do a good job of discussing this.

Two of the papers discuss approaches to agility that are getting a lot of press currently - Service Oriented Architecture or SOA[2] and Business Process Management or BPM[3]. Both papers, it seems to me, make it clear why SOA and BPM can be necessary for agility in some (perhaps many) circumstances but not sufficient for it in most.

  • Gartner makes clear their opinion that you need access to a wide range of metadata to succeed in delivering agility, even with SOA[2]. Indeed Gartner estimates that some 50% of SOA projects will not achieve maximum agility because they won't deal with Metadata properly[2]. As the report says "real-time actions" require this metadata[2]. The report talks about models and metadata together and that you must have explicit rule models as well as process and data models to deliver on SOA's agility promise.[2] For those who like to use the Zachman Framework, this matches nicely with his concept that motivation (the "why", often represented by rules) is distinct from process and data - see this or this.
  • BPM is also commonly touted as a source of business agility and Gartner makes some key points around "shared control between business managers and IT professionals"[3]. I have talked before about the importance of ensuring that the decisions within a process are not "black boxes" so that the process owner can share control of these decisions also. It also says that IT staff must stop performing "all the front-end analysis, process design and testing"[3] and make these shared activities. The use of business rules and a business rules management system can help give business users confidence that they understand what is going on, what is being decided, and so set up processes for this kind of collaboration.

The main paper for those interested in business rules discusses how agility and rules are complements not contradictions and emphasizes that "Hard-coding your business rules will severely limit the agility you can expect to achieve"[5]. Modernizing legacy applications to take advantage of business rules is a key way to enhance agility and this also makes it clear why BPM and SOA along won't generate the agility you want - if you are hard coding business rules into your services or your processes you are going to be limited, no matter what. You are also not going to get the collaboration you need as your business users can't read code, let along write it. This paper also discusses how rules contribute to all 5 stages of the agility cycle - by helping explaining what happened when you sense a change; by helping business and IT collaborate to strategize about what could be done; to make it easier to analyze and test possible rules so as to decide what option to take; to communicate the rules effectively using formats common to both IT and business people; and to act in an automated yet agile way.

As the paper concludes "for many operational and transactional settings, explicit business rules offer a fast path to agility that is worth investigating"[5]. Could not agree more. 

Here's the list of Gartner papers:

  1. Achieving Agility: Defining Agility in an IT Context
  2. Achieving Agility: SOA Will Build Organizational Agility, but Watch the Hype
  3. Achieving Agility: BPM Delivers Business Agility Through New Management Practices
  4. Achieving Agility Through Communication-Enabled Business Processes
  5. Achieving Agility: The Agile Power of Business Rules


Author, with Neil Raden, of Smart (Enough) Systems.

This post is reproduced from James Taylor's Decision Management blog

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.