Its been too long, with lots of work, travel and vacation, apparently leaving me with no time to blog. I'm back, but a little rusty and jetlagged, so bear with me!
James Taylor posted today on Enterprise Decision Management Blog about a post by Roeland Loggen on his blog - BPM Suite as a component in a logical architecture. Roeland proposes a BPM-centric architecture that plugs into a range of other components to handle administrative type processes.
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.
As ever we should avoid point to point integration of every component in the architecture, instead components should offer services that can be consumed by one other, both for rigid (generic) use cases and to meet application specific requirements. Having SOA technology and a strong integration platform underlying the architecture seems like an essential requirement. SOA technology also provides the ability to host the final application as business services that can be reused in other applications across an organization or by business partners.
A benefit of taking a services approach is that generic architectures like Roeland's are simplified - they are effectively flattened; every component can benefit from every other and the architecture doesn't need a hundred lines showing the explicit connections between all of them since the connections are handled by the SOA / integration backbone. This backbone may utilize a range of technologies, and may be effectively hidden from view. Without fancy drawings, the generic architecture becomes a simple list of available components that have been plugged into the backbone, for example:
- Business Process Management (BPM) - incorporating BAM and process analytics
- Decision Management
- Case Management
- Content Management
- Customer Database / Information System
- Document Capture
- E-Forms Management
- All plugged into a SOA/integration backbone
Taking this stack approach allows business analysts to concentrate on using the components providing higher level business value in the most effective way - not the forced integration of monolithic products. Any particular business application can reuse the same architecture and technical backbone, and will benefit from platforms that are more interconnected out of the box. Specific connections (drawn on an 'architecture' diagram) now represent business use scenarios, and the value of each interaction can be easily seen, especially where new integrations may need to be built. Here is a simple example:
The application here is a fairly generic application processing solution, which shows an architecture that highlights the interactions between the components, already relying on the implicit (and invisible) technology backbone and any available services that are already in place. A different application could show very different connections, allowing the 'architecture' diagram and implementation to closely reflect the business value of the application. The technical architecture would be no different from before - a plain old stack implemented once and used over and over.
Picking a stack that can handle the high level business requirements, while being architecturally strong enough to hide much of the technology complexity, and still allowing the flexibility to meet specific application requirements across many different applications is hard work. Organizations looking to get the best value from their technology investments should look beyond simplistic 'drag and drop' and developer toolkits to ensure that new technology really can deliver complex applications fast, while allowing constant enhancement and new applications to be based on a common platform that can perform as needs grow.
Technorati tags: Financial Services Technology solutions-architecture BPM EDM
A post from the Improving New Account Opening blog
