James Taylor from EDM blog (http://www.edmblog.com/weblog/2007/08/process-transfo.html) and Phil Ayres of Improving NAO posted a reaction Improving New Account Opening: Component stack - a simplified architecture for applications - Solving complex business problems with financial services technology to my earlier post on an architecture around BPM.
A number of thoughts:
First on "liked his architecture except that I think the Decision Platform he identifies also needs to be able to support both the CEP and BAM components. After all, determining which process to trigger, which action to take or when to inform someone may be a non-trivial business decision and so require decision management. I also think that a decision platform needs both rules and predictive analytics, as you might expect, and that it needs to be available to all the various components that might need decisions (typically implemented through decision services perhaps as a decision service hub as Neil and I discussed in Smart (Enough) Systems). "
Yes - I agree on the coupling between CEP and Decision platform. Good point - knowing what to correlate when, and what process needs to be (re)started could be a complex task. I can see scenario's where for instance correlated events might (or might not) start up a fraud research process.
It's actually interesting to see that many BPM platforms currently have no to only limited inter-process synchronisation. This could also be a great area where the CEP & decision services could help out. For instance: deciding that a certain running process should wait, until a new event is handled by a new separate process. Think of for instance updating a customers address, while at the same time doing a claim process. You don't want to end up sending stuff to the old address (that just burned down!).
On the link between CEP and BAM I am still a bit puzzled. Possible one could see certain BAM data, that points to a certain event, which needs a decision? Not sure. And maybe only usefull in quite advanced BPM maturity environments (which, unfortunately also is true for the notion of CEP and Decision Services - I am not seeing them yet in client implementations - which will in the future lead to additional maintenance...)
For me a decision platform definitely contains BRM technology. What I am still thinking of is - what if a certain decision "service" actually needs some human knowledge? Does it mean that from the presentation layer we will get some possibility of opening a "decision to-be-taken inbox"? Or will decision services actually lead to a normal task (decide on XYZ and let the process know?".
Another thing I am still wondering is the balance between putting decision logic in components, or centralizing it all in a decision services hub. Sure, centralizing it sounds like a estethic architecture thing to do. But the amount of overhead is large. For every IF statement, a component would have to go centrally. And why? So that we can maintain it easier? A trade-off is needed.
A presentation I saw from the Business Rules Platform in the Netherlands talked about this as well. They proposed a mixed model where a decision service hub/business rules hub could either:
- Work as a central service
- Distribute the logic towards the components.
- Do both, but synchronize the logic
Interesting to see which model will emerge.
Phil proposed "James suggests some enhancements to the architecture, largely to ensure that the Decision Platform can interact with the Complex Event Processing (CEP) and Business Activity Monitoring (BAM) components. I agree with his rationale, and would even take it a step further - every component in an architecture (that isn't pure technology) should be able to interact with every other, ensuring that really advanced business requirements can be considered, offering more and more business value."
Hm. Not sure that I agree. Sure, interoperatability is a great thing. And yes, in my picture, although not shown, most components will be able to contact other services.
However, what we should not forget is, again, the notion of coupling. Providing a integration platform does allow for flexible communication between components, or call it services. However, this does not take away the notion of coupling. When I, as a service A, am using service B, I do know about it! I have knowledge of the provided functionality and data, so that I can use it and add value to it, for a certain requirement. Knowing about it is nice, because then I can make use of it. But it also leads to dependencies - changing B will need carefull consideration.
The more connections, the more "services governance" you need.
In advance one cannot predict the business requirements, so true: you would want an architecture that supports easy connectivity. But the objective of my architecture drawing was also maintainability and manageability. Based on an (okay, not disclosed :-) set of requirements, you would want to find the architecture coupling that is on one hand supporting the requirements and provide flexibility towards change cases, but on the other hand limits the coupling/knowledge. I wanted to create an architecture where most components know eachother on a lean, need-to-know basis.
Gentlemen, thanks for your feedback and reactions welcome!
Regards,
Roeland
2 comments:
the role of the decision platform in BAM comes when you must combine activity monitoring (account emptied, say) with a business decision (customer who emptied the account is a good one). The BAM component should not encapsulate a decision that is not specific to activity monitoring - this should be managed as a distinct decision.
One of the most interesting discussions I saw around how various kinds of process management and decisions interact was from Maureen Fleming of IDC. In this post I tried to show how decision services can help with the transfer or activity from automated processes to manual investigation or from sense/respond to exception handling. In general process platforms do a better job of including people than decision platforms (at least the way I mean them). That said, people like Robust Decisions do sell platforms for managing people-centric decision making and one could consider a decision platform as combining business rules, analytic execution AND human decision support components.
As for the decision hub piece this is more a logical than a physical construct. The problem is that if it is not easy to externalize and manage decisions they get buried in code or processes. A decision service hub infrastructure makes it easier for projects to manage decisions properly and that's its core appeal. The deployment of the decision services should still be distributed.
JT
Hi Roeland,
I agree with you that a service-based approach to integrations such as I suggested does need extra control, though I think this is completely do-able. Any integration requires the interacting components to connect correctly and talk according to a predefined contract. Using services in an 'enclosed' system like this is no different.
All that said, I think I wrote my discussion with a specific integration platform in mind (one I work with), so its likely that some of the capabilities of that platform for combining components like Decision Management and CEP were in the back of my mind as I wrote.
Either way, I still think that there should be a general connectedness and availability of components, so that customers can use the system in ways that the original designers had never envisaged. That of course requires a platform that is flexible and dynamic, but really can be done.
I am interested in the discussion that you and James are having - I'm definitely learning about some new interactions around EDM, CEP and BAM.
Nice post!
Phil
Post a Comment