Kjell-Sverre Jerijærvi posted A SOA+BPM+CDM Ontology with a very nice graphic showing his point of view when it comes to the various aspects of Business Process Management (BPM), SOA and Event-Driven Architecture(EDA). Given his model, which I liked, Decision Services (wiki) are going to be in the Activity layer – not part of Entity Services but available to the processes and composite services that need them. So far, so good.
Kjell-Sverre then makes a statement with which I am going to have to take issue.
An aspect not shown in the model is that the need for agility increases towards the top, while the cost of change increases towards the bottom.
I think both parts of this statement can be challenged – that agility is more needed towards the top or interaction/process components – and that cost of change is higher near the bottom in the services being assembled. Taking the second one first there is no reason at all while the cost of change in the services should be high – it can be high if the IT department insists on coding everything procedurally, but declarative approaches like those business rules management systems (BRMS) and other model-driven approaches can dramatically reduce the cost of change within these services. In contrast, while the cost of changing a process flow may seem small, the cost in terms of organizational confusion, dropped compliance handoffs etc etc. can be very high indeed. But that’s not the part I really want to discuss.
The idea that agility is something much more needed in the interactions and processes than in the services that support them is not true as soon as one automates decisions. The decisions in most processes change much more often that the processes themselves. Take insurance underwriting. The logic for the decision to underwrite or not changes constantly. The process of collecting information, deciding to underwrite, informing the consumer and then fulfilling the policy has not change significantly in years (nor is it likely to). Critical business processes are, by their nature, stable except for case management and other fringe activities. Decision making is constantly impacted by regulations, past experience, market conditions, competitor and customer behavior and much, much more. Agility, then, in at least some of the services in his architecture is more important than it is towards the top of the graphic. Decisions need more agility than (most) processes.
Obviously there are dynamic, volatile processes. Equally clearly it is worth using Business Process Management technology to make sure that the changes that do happen don’t cost a fortune or take too long. However many corporate processes are not especially prone to change. How decisions are made, almost all decisions, changes constantly. Decision management is therefore critical.
I posted on this topic once before on my ebizQ blog.
Comments on this entry are closed.
Your refinement of my bulletpoint statement is good, we really do agree. I just see the decision service as conceptually being a part of the process, composition layer and the human task (workflow) layers, thus towards the top of my figure. I do not think Shy Cohen’s taxonomy ment for activity services to be the cutpoint for decisions, rather the process services.
In my opinion, the business capabilities delivered by a process stays relatively fixed, it is the flow of the process that changes most often and needs to be designed for agility. It is very important that the aspects of the system that needs agility most are the ones that need to be least expensive to change.
My main argument for the cost of change being higher for the lower layers are based on data contract (resources in JJD terms) changes; the more subscribers/consumers a set of activity and entity services have, the more impact introducing a new version of the serivce contract will have. And I think most solutions will involve coded compositions at the resource service layers, while the composition and business process layers will be declaratively designed.