Is it a right time for Federated BPM?

“BPM is an organization wide initiative” was the most famous premise a few years back. But for all practical reasons, organizations started BPM and SOA initiatives in pockets. Over the time, organizations ended up with few BPM domains with different governance models. There can be variety of compelling reasons for an organization to have different BPM domains, and some of the decisions might have happened without choice.

Mergers and Acquisitions (M&A) was one of the primary reasons for BPM selling like hot cakes. But with M&A came a different challenge, with merged or acquired organizations already having a BPM infrastructure, a choice was needed to be made for migration of the business processes into a single unified platform. This proved to be expensive and risky, and so without choice organizations settled for multiple BPM domains. Also, diversification of vendors had caused many organizations with diverse BPM domains, with different BPM product stacks.

Federated BPM is the need of the hour. With federated BPM, one of the existing BPM domains in the organization has to act as a master and rest of the BPM domains as dependent domains. Usually the domain with the most visible and top level business processes would be chosen as a master domain. All the top level business processes would be triggered from the master domain and subsequently routed to dependent domains.

Federated BPM is more of an enterprise architectural strategy which comes with a lot of challenges. Users might need a unified process portal platform, universal BAM and reporting capabilities, process metrics with KPIs and SLAs collated from different domains, uniform security implementation and many more. The challenges presented by Federated BPM architecture are many, but is it worth it, is it a right time for Federated BPM?