There's a guy I know who's incredibly gifted when it comes to building things. I've watched him repair a barn, build a new shed, put up a roof - you name it; if it can be done with wood and tools, this is the guy to do it. And I've never seen him use a plan - he just knows what to do.

The trick of it is, he never takes on more than he can do by himself. While he's very skilled, probably the most tangible evidence of that skill is he knows better than to overreach himself. He knows that what he's doing is within his capabilities, and there's no way he could build an office building or a skyscraper by himself without plans, assistance, and government approval.

The task of organizing services in an SOA environment is a lot like building something. You start with elementary services - security, auditing, some fundamental business processes - and you put together a composite application, much like my friend knows how to put together a shed in the yard.

A shed is useful and does real work (well, it actually stands there, but the work it does in keeping the rain and snow off of things is good enough). Likewise, a simple composite application can be useful and do real business tasks, like taking an order or updating a customer profile.

But if everyone builds sheds without plans, you're bound to encounter someone like me who should never operate power tools. Then the neighborhood goes downhill rapidly. It's much like that without Business Process Management in the SOA world.

Business Process Management, and the things that usually accompany it such as unified security and overall management, is the blueprint and design of the SOA world. Just as in construction, you wouldn't want anyone to build a large-scale building without plans, reviews, approvals and designs based on years and years of engineering knowledge; you also wouldn't want an enterprise to go full scale into the SOA world without BPM.

Business Process Management provides the rigor and discipline necessary to build a successful enterprise architecture using SOA concepts. The design of a business process in a BPM tool allows a company to realize what their service catalog is, what it should be, and how they can use their current environment to accomplish the purpose of the process most effectively. It provides the tools necessary to utilize underlying services and coordinate the transactions and information that are necessary to accomplish the completion of a business process.

A process may encompass many things. There may be multiple transactions. Consider purchasing a book online; in addition to a transaction to actually locate the book in the warehouse and pack it, there would also be a transaction regarding shipping, another for inventory, and yet another to do the credit card processing. All of these things are likely to be separate, short-running processes, but the business process can be much longer lived and involves invoking all of them at the appropriate times. It may also involve revoking or rolling them back under appropriate circumstances, such as in the case where you're buying a book by Sean Rhody and it's on permanent back order (sorry about that folks).

Likewise, the process of governance that goes along with agreeing to the design of a business process is similar to the system of permits and reviews that a contractor needs to go through to get approval of the construction. Governance of services is critical when we have to deal with things that cross organizational boundaries and may be shared between organizations (i.e., resolving the age old question - "who's going to pay for that").

This issue will address some of the challenges of BPM. In the mean time, I'm going to find my buddy and sell him my power tools before it's too late.