BPM-EAI

What’s the meaning of ‘externalization’? In the context of software design, we take externalization as the strategic (I used this word intentionally to stress upon the fact that it has long term strategic benefits) separation of certain overarching capabilities (that otherwise are inherently embedded inside the software all over the place) from the rest of the capabilities. In simple terms, the way I view externalization it is very similar to MVC (model view control) principle: It separates the ‘global control’ aspect from the ‘local execution’. This way, I have flexibility to:

• One) focus upon the end-to-end view of the design without infecting that with low level details/concerns of local execution capabilities
• Two) provide the freedom to plug in adequate local execution capabilities (and change it as we want) without breaking the global configuration

Let us come down to specific to make more sense of what I said. There are 4 critical architectural capabilities as greatly being discussed across the globe today which are fantastic realization of the design externalization strategy. Here are those fantastic four with the illustration of the two benefits that I described above:

1. BPM Layer - Transaction flow externalization: BPM in its purest form externalizes the business transaction flow or the business process flow. What it means that we can construct the global wireframe of the business process with end-to-end view and then decide at which point of that flow which kind of business transaction capabilities need to be plugged in. At those point, appropriate invocation of transactions/application services will be done. With this kind of approach, we can instrument and administer the overall IT solution capability at two level. First level at the global flow level where it allows us to reorganize, enrich and mold the overall flow according to end-to-end view-point. Second level, it allows us to replace a given transaction services/capability (at a given point in the flow) with another one without disrupting/breaking the overall flow including replacement of legacy applications with new generation applications.
   
2. BRM layer - Business/transaction rules externalization: BRM layer allows us to extract all the rules that are implemented the process logic and make them independently executable policies. This way, a transaction logic or a BPM layer flow becomes the overall wire-frame in which rules can be executed. By externalization, rules become independent and individually available objects (local execution) that can be plugged in the global wire frame of the application (transaction delivery) or BPM (overall process delivery).
   
3. MDM layer - Master Data exchange/management flow externalization: This is important one here. MDM as a design strategy allows externalization of the process/flow for the data events. Through MDM, we can separate out the individual data transactions across multiple data masters from the overall control/flow in which these events are plugged into. So it could be same update customer master data event that could be plugged into multiple data flows arising from variety of business processes. Having said, that, based on my experience, I found that many organizations tend to complicate the MDM layer by intruding the MDM capabilities/software scope into BPM space. If MDM layer is over-engineered to start designing the business process capabilities also, it will lose its strength and actually make the architecture highly fragile and complicated. So MDM needs to be carefully integrated with the BPM such as business process flows are managed by BPM and then at appropriate nodes, MDM services are plugged in to execute data events necessary to keep the data masters clean and consistent.
   
4. ESB layer - Event/message flow externalization: ESB or the erstwhile middleware capability is externalization layer for managing the execution of event and services messages. ESB separate out the overall flow and orchestration of these messages from the execution of individual messages/events. This again is integrated as a capability with both BPM and MDM layers to provide them event management, service management and message management capabilities. From BPM layer, at some node when local transaction execution capability has to be invoked, it is orchestrated by the ESB event/messaging wire-frame that knows precisely which all touch points to be connected in order to get the transaction nodes executed within BPM flow.

Diagram below gives pictorial understanding of how these different externalized layers interact with each other.

I  do realize that possibilities with such view-point is diverse and hence it will be interesting to hear from others on this.