≡ Menu

Just how much agility can SOA (or BPM) really deliver anyway?


A couple of links today made me think about agility in the context of BPM and SOA. My friends at Zapthink pointed me to a Tom Sullivan post on backlogs as a measure of success which caught my eye because the use of decision management technologies often reduces IT backlogs (by empowering business users – wiki entry). and that led me to one of Dave Linthicum’s on SOA’s ROI coming primarily from agility.

Now agility is defined by Gartner as “the ability of an organization to sense environmental change and to respond efficiently and effectively to that change”. 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. It seems to me that the discussion of the value of SOA (and indeed of BPM) in delivering agility is often far more narrow than this.

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. SOA and BPM can be necessary for agility in some (perhaps many) circumstances but not sufficient for it in most. For instance, they don’t help you sense the need to change and, if the change required is to the business logic that drives your response, they don’t really help you respond either. Many of the changes required to be agile are changes in the way a company responds to some event or condition. The decisions taken by software are critical, therefore, as they determine how the company responds. SOA makes it easier to isolate a change like this while BPM makes it easier to change the flow of actions after the decision. Only separating out and managing the decision itself will truly maxmize your agility, however.

Gartner estimates that some 50% of SOA projects will not achieve maximum agility because they won’t deal with metadata properly, mainly because real-time actions require this metadata. I interpret this to mean that you must have your business logic as metadata by building explicit business rule / decision models as well as process and data models to deliver on SOA’s agility promise. You also need to ensure that the decisions within a process or a service are not “black boxes” so that the business owner can share control of these decisions. As Gartner said “Hard-coding your business rules will severely limit the agility you can expect to achieve”.

I wrote a longer post on this over on my ebizQ blog – Achieving Agility, some notes after Gartner


Comments on this entry are closed.

  • Mark Eastwood December 2, 2007, 11:22 am

    James, I’m not sure I follow the phrase at the end “you must have your business logic as metadata”. If I define metadata as “data about data”, then I don’t usually think of rules as being the same. That said, I do beleive there’s a place for rules and place for BPM and both are part of an SOA strategy and have their strengths and their place in the architecture.