At the Gartner BPM Summit last week it was apparent that a lot of BPM vendors are now making mention of SOA and some of SaaS. Although I agree there is tremendous power and opportunity in these complementary concepts (see my blog on SOA+BPM+SaaS here), based upon what I saw at the Summit, I’m not sure the BPM industry gets just how this all fits together just yet.
Here’s what I don’t think they get… The codependence of BPM and SOA takes on a rather circular definition: BPM enhances services, but services can also be processes. SaaS has a similar relationship with both BPM and SOA in that solutions made with processes and services are better off consuming components on demand, while at the same time a hosted environment is more useful if it serves components (in SOA fashion) enabling business processes to be modeled (in BPM fashion) including human-activities (workflow). With this interdependence comes a powerful extension to the original BPM concept; however the reality is that it requires tools and governance with content, all integrated into a common offering with hooks to further extension.
The traditional view of BPM is that it exists to manage system tasks as well as human-activities, (and of course the combinations of both). I had lunch with some folks from a competitor at the Summit last week, who observed that most businesses are not heavily automated so a great deal of business activity involves human interactions, and therefore very little can be put into transactions or services. Although I agreed with him that there indeed is a class of work that revolves around workflow-like activities, this work has also automation potential at the level that a service may be needed. Further, when those services (originating from human workflow) are reused, you essentially have the beginnings of an SOA.
Don’t get me wrong, of course a lot of business activity does not include the typical SOA components, such as systems, integration, transactions, data storage, etc. but there most certainly are parts of each business that do include these things, and the human part typically interfaces with them, and the more work the business can offload to the non-human part, the better. Furthermore, SOA’s are all about breaking up applications into smaller chunks, and occasionally those chunks automate something new and perhaps reusable by other processes.
I got the feeling from many vendors at the Summit that they look at SOA myopically, instead of truly uncovering what SOA can do for a company by enabling it to better manage what’s automated and what’s not automated, and therefore offering an integrated suite. SOA is not just infrastructure but also involves how a company developers and delivers solutions (whether they are process-based or otherwise). SOA involves combinations of parts or chunks (components or subsystems) that interact in a loosely couple way, without the overhead and dependencies of older distributed computing approaches (involving heavy state persistence and no clear interface-contract). The parts that make up the SOA are autonomous with respect to each other and agnostic to the dependencies of other part of the system. Each part has its own lifecycle and release path yet can participate in the interactions with other part in a composite solution (whether process-oriented or not). The composite solution governs all interactions by the same interface-contract and data flow. Eventually the components of the composite solution appear in multiple processes and as businesses achieve higher reuse, the system is more SOA, and if BPM is in the picture cohesively then processes and chunks of processes can also see meaningful reuse.
I think some traditional BPM guys are missing the power of SOA in that autonomous parts can be assembled into solutions that can act like canned applications people are used to, only they have increased agility and greater tolerance for change throughout the life cycle of a system. The legacy-way of building applications assumes tight coupling and homogeneity across the parts of the system, which create rigidity and large costs to change or enhance. Coupling SOA with BPM facilitates the consumption of services by processes, and services themselves may be process flows that can be leveraged in other flows.
Lastly, probably the biggest problem the traditional BPM folks have is they approach the market with merely a utility or infrastructure, and simply saying “SOA” or “SaaS” doesn’t make it a cohesive offering. Content and governance are key aspects of a unified SOA+BPM+SaaS strategy. Many of the traditional “utilities” and “infrastructure” have been acquired and merged with larger entities, such is the trend.
I was speaking with a VC friend this morning regarding the Workday (a company with an ERP SaaS offering) acquisition of Cape Clear (a company with an ESB/SOA offering) and what that means. I recited what I said above, that utilities and infrastructure ultimately gets snapped up by those that have content (or those that solve specific business problems). The trend is to move away from complicated utilities and infrastructure (by themselves) and end up with business solutions mapped to business needs, with utilities and infrastructure embedded in a cohesive environment. Content is king. Workday says it’s leveraging its Cape Clear purchase as “Integration on Demand,” which is another way of saying “Bring our Business Solution to meet your needs faster with agility”. I applaud Workday on their acquisition, it confirms what I see as the trend, and it makes me feel great about SunGard’s position with its Infinity strategy, because we have content (hundreds of applications), governance processes and methodologies, and, oh yes of course, utilities and infrastructure.
