It seems the most active discussion over the week of Thanksgiving was about Keith Swanson's post "BPM is not Software Engineering".? I haven't read Keith's Blog too often before, but I'm glad the discussion led me there as he has a series of interesting posts, and this one is one of the best.? The title is a bit misleading - my first reaction was that I was going to disagree with the content of his post, if not explicitly with the title.? However, as I read on, Keith makes a compelling argument as to why we should be precise in terms of what we call BPM and what we call Software Engineering. This started a minor dust-up of commentary agreeing, disagreeing, and quibbling with the post (go to the post's comment section to see the trackback links).
The key point to glean out of the article is that often Software Engineers (IT) think that Business folks can't do Business Process Management. But in fact, what the business can't do well is the software engineering that may be requried to support the business process.? As well, the business and/or IT may not have the "process" chops to define effective business processes.? So you may actually need 3 or more parties to arive at a good answer:? IT, Business, and Process experts.? And, if you don't have good representation for the customer voice, then you'll need that incorporated in most processes as well.
None of this says that you can't have more than one skill embodied in one person, but you need to have coverage of these perspectives.? Keith rightly points out that, for the most part, software engineers assume that the code IS the process, rather than just the plumbing for a process.? At BP3 we take a more wholistic view - the process is more than just software.? So I found myself agreeing with Keith, and only wishing the title had put me in the right frame of mind before I started reading it!