John Evdemon makes an informative post about the Zachman Framework and end up on a discussion of “process reification” which he explains is the action of converting an abstract process into a concrete, executable process. Such a conversion is often touted as the Holy Grail of BPM. While such a conversion is often desired, I would remind the reader that it might be better not to convert in the first place: A Model Preserving Strategy assures that the designer creates an executable model in the first place, and that the model executed is always what the designer drew.
JP Morganthal makes an important post reminding us to Keep Your SOA and BPM Initiatives Separate. Read through the comments and you will see precisely why there is a problem in the community. I have met so many people that think that BPM is just a scripting language for SOA services. These people will argue at length that “BPM is a part of SOA because SOA is useful without BPM, while BPM is useless without SOA” (this is an actual quote from a noted BPM expert who shall remain nameless for this post). JP makes the point very well, but let me put my spin on it:
- SOA is ultimately about “code reuse” and simplifying code maintenance. Instead of distributing a piece of code throughout your computing infrastructure, you can deploy it in one place and call it from anywhere. The goal of SOA is optimization of IT resources.
- BPM, far from being simply a scripting language for the above, is the practice of supporting office work to accomplish business goals. The goal of BPM is improving your business.
Yes, if the business process needs to retrieve information at a point in the process, then SOA is recommended but OOA (Object Orientated Architecture) will work as well if that is all you have. I too have seen projects get derailed by SOA when a less modern approach would have supported the business process as well. I think it was put best by the CIO of a major bank stood up in a session I attended and said “SOA is a tool we use, while BPM is what we do.”