At this point, the business benefits of business process management seem clear. Virtually every sector of society, including areas that seem relatively impervious to dramatic change, such as higher education and government, are becoming much more outcome-oriented. And, as organizations start to focus on outcomes, an awareness and sensitivity to process cannot be far beyond. In fact, as the dean of the university where I teach once said, "If you don't like the outcome, the process must be flawed."

Along the same lines, the promise of service-oriented architectures to serve as a flexible application development environment to support BPM initiatives seems as though it could be realized. Conceptually, the advantages of SOA are clear, though it is still an open question whether the concepts will be translated into practice.

One of the major problems companies face is finding a process to initiate BPM or SOA projects. Most processes are cross-functional, which means that each process has many different stakeholders. It is never clear which of those stakeholders in a particular process will initiate a move towards BPM. But it is rare in the enterprise that all of the stakeholders will agree to modify, not only the way they do what they do, but also the way they think about what they do.

The same sort of difficulty is faced in trying to implement an SOA. By definition, application owners have to relinquish control over a part of their application. Within most enterprises, people are not trained to share nicely. They worry if they do not control every aspect of their application. And those fears are not entirely misplaced. Although, in theory, a single service can fill a need for many applications equally well, in practice, a service may be optimized for one application rather than another. It can prove to be very difficult to balance the needs of different application owners.

There is no shortage of advice about how to get started with SOA and BPM. Many of the most knowledgeable people in the field suggest that enterprises start small, with projects aimed at specific pain points. Over time, companies are urged to create centers of excellence to capture and codify the knowledge gained through those early projects.

That is sound advice, but not easy to follow because both BPM and SOA projects often face resistance from what seem like an unlikely source-the IT department. It's odd, by most accounts, IT can be the leading force when it comes to initiating BPM and SOA projects if the business side isn't interested. But often, when the business side is interested, IT isn't.

People who have been around technology long enough know that there is only one successful strategy to introduce new technology into an enterprise when there is organized resistance-guerrilla tactics. Just do it. Old-timers will remember that the personal computer was not warmly embraced at first. Nor were laptop computers, instant messaging, and so on. But people brought them in anyway. And when it worked, ultimately, the technology was embraced.

Elliot King, Ph.D., is editor-in-chief of BPM Strategies. He has reported on new information technologies for more than 20 years. He is also the chair of the Department of Communication at Loyola College in Maryland, where he founded the Digital Media Lab. King has co-authored five books and written hundreds of articles about the use and diffusion of new communication and information technology.
http://www.soainstitute.org