Change Agent: Don't Bank on Reusing ServicesChange Agent: Don't Bank on Reusing Services

Go to any presentation on service-oriented architecture and you're sure to hear the word reuse at least a dozen times. SOA evangelists make reuse the ultimate source of the architecture's promised agility, cost reduction and business-IT alignment benefits, particularly when SOA is used for business process management. But in a BPM presentation, reuse plays a secondary role at best, certainly far down on the list of features and benefits. Moreover, I've heard from practitioners on both the SOA and BPM sides that reuse is, in the end, a phantom, not really there after all. So is reuse real?

First, let's understand what, exactly, is being reused. In SOA, the unit of reuse is called a business service. A business service is a "coarse-grained," or macro-scale, executable business function that can be invoked on command as a Web service. "Process an invoice" might be a business service, for example. It's bigger than a single API but smaller than a business process or an enterprise application. In SOA, applications and business processes are composed by "orchestrating" business services.

But what determines the size and scope of a single business service? To an enterprise architect, each service should be sized to optimize reuse. You might say that's circular logic, especially since--in a BPM context, at least--it's the business that best understands the demand for reuse across the enterprise. To many architects, however, optimum reuse is not determined by process-owner demand but by having "the proper level of abstraction," and on this front, process owners have no idea what they're talking about.

A good example of the problem is presented in an article by CapGemini's Steve Jones on "SOA Anti-Patterns". Patterns is geekspeak for best practices, so anti-patterns means worst practices. One of these anti-patterns, called Percolating Process, describes the crime of building a SOA implementation directly from a detailed "to-be" process model defined by the business. That's the way implementation works with most BPM suites, but Jones asserts such an approach leads to solutions that are inherently "difficult to manage ... impossible to change." The right approach, he says, is to create the services architecture independently of the process model. "This will provide the structure for breaking down the processes and creating a clear hierarchy of use." Since process owners on the business side have no tools or methodology for specifying that services architecture, this is implicitly an IT function.

In contrast, a leading BPM practitioner at a large insurance company told me recently, "We've built a repository of hundreds of tasks, activities, subprocesses and the like, [but] the only practical reuse on the business side is moving from 'as-is' to 'to-be.' ... Coming from a data-management background, I expected there to be great value in reuse. It turns out to be pretty much zip value and minimal opportunity, even when you force your methods to 'genericize' things," meaning, provide that proper level of abstraction. He went on to relate the tale of a Fortune 50 company that, after investing in building a component library and promoting it heavily for several years, netted fewer than 50 total components, of which only three or four were ever reused.

I think the apparent contradiction can be resolved by accepting that reuse, as defined by SOA architects, really means reuse of IT assets rather than reuse of business process logic. A business service that represents the integration of various information systems, but with no human tasks, fits that model well. A human workflow subprocess, no matter how abstract, probably does not.

In that respect, the business-IT alignment benefit that SOA supposedly brings to BPM may be overstated. To SOA architects, BPM generally means business integration, while to most process owners, BPM means improving human work. Even so, for SOA to succeed, the definition of business services needs more of a demand-side component to give process owners a seat at the table. And that probably means new tools and methodologies, shared by business and IT, focused not just on the level of abstraction, but actual demand for reuse.