One challenge that we run into: having a software developer design the business process.  Now, that’s no slam on software developers.  There are some very smart cookies out there writing software… but if you want to develop a business process, you need to make sure that the business likes the process before you write the code.

I believe that the person who develops the business process has to be seperate from the person who writes the basic code.  SOA supports this idea.  In SOA, the compositon is where the business process lives.  The services don’t care what order they are called in.

So if the developer doesn’t write the process… who does?  Is it the IT analyst?  Is it the IT project manager or IT solution owner?  Only if they are trained to create well-designed and efficient processes.  If they are not, then it’s not much better than having the developer do it.

Honestly, the benefits of shared processes in a company can be substantial.  Any process that does not differentiate the business in the marketplace should be considered as a candidate for sharing between lines of business… (as long as those lines of business already share data).  Sharing a process can provide real opportunities for reducing cost and improving efficiency.  Each unique process carries a cost… in training, in tools, in exception procedures…  The fewer, the better.

However, IT projects often do not have Business Process Management figured in.  BPM must be part of the way in which the software is understood, described, and communicated.  If BPM is considered first, then SOA can produce the benefits we want it to produce.  If BPM is not considered first, then you are cutting off many of the benefits of SOA. 

Don’t undercut the value of SOA by failing to manage the processes in your enterprise.  It would be a crying shame if you did.