Sorry for the provocative title; it was a cheap, transparent attempt to get your attention. If you've read this far, I'll assume it worked. Just for the record, this statement represents the diametric opposite of how the NW BPM team and I feel.
We on the NW BPM team believe that the only way to design executable process optimally is for IT and business to collaborate in a deep, meaningful way. To some vendors in the market, this means that the business uses one model to describe an abstract business process that then gets transformed into a technical model that can be refined into something executable. We find the inevitable loss in translation associated with this approach to be simply too high a price to pay.
The truth is that the business often still specifies its intent using word processing documents, presentations and spreadsheets with no tie whatsoever to a "real" model. My opinion is that the business analyst is one of the most underestimated personas in the software industry. I believe strongly that with the right model and tooling, the business will someday design executable business processes.
Does this mean that IT is a discipline of the past? Absolutely not!
We’re betting on our ability to abstract executable concepts so that the business can compose executable processes. That means that IT will continue to generate artifacts like services but will then be able to expose these to business analysts in a via business-consumable abstraction. Other composite process artifacts, like UIs and workflows, could be created by business analysts and refined by development as necessary. Deployment of processes, itself a process, would be subjected to the appropriate governanace, both business and technical.
We believe this approach will allow the business to concentrate on the business and IT to concentrate on what they do best: delivering technical artifacts and managing the IT landscape.
