Last week’s post on the BPM/BR webinars originally contained a lot more of my brain pouring out onto the keyboard because of things said during both of the webinars about business, IT and production systems, so I gathered up all the ideas and let them stew for a few days.
As long as I’ve been working with workflow and BPM products, the vendors have been claiming that the business users/analysts can design the process flows and modify them in response to changing business conditions, and in fact have implied (or actually stated) that the business side would make changes to the business process in production. And, as long as I’ve been working with these systems and their users, that has never happened.
I haven’t worked much with business rules systems, but I see a lot of the same type of claims about business users/analysts being responsible for modifying the production systems and that gave me a bit of hesitation because I know how that really translates over in BPM land. Both of the BPM-BR webinars reaffirmed my suspicions: no one really lets the business side touch a production business rules system, even if it has a pretty user interface. Give the business a sandbox for changing testing rules, but they’re not going to be the ones responsible for regression testing these against what’s already in production, and then getting them into production.
In the second webinar, John Rymer (the Forrester analyst) stated in one of his slides that business analysts will make changes, thereby providing the business agility promised by these systems, but when he returned to the point later, he requalified this as “business analysts or garden-variety programmers”; what he really appeared to mean is that you don’t have to use a highly-trained business rules specialist to do this — quite a bit different than what was stated on the slide, or implied by most of the BR vendors.
Furthermore, during the Q&A at the end of the webinar, Rymer admitted that the “single source of truth” that he referred to earlier in the presentation would be governed by IT, although the content would be developed collaboratively with the business.
I don’t disagree with this: I think that if IT is responsible for care and feeding of a system, they should be responsible for making what are essentially programming changes (albeit through that pretty UI) to a production system. As I mentioned previously, in most cases the business side doesn’t have the systems skills to take responsibility for this — not that they’re stupid, but they’ve developed their skills in other areas that IT is clueless about, such as how the business actually works. The big problems are:
- How do you distinguish between a change that can be made by the business versus one that must be handed over to IT? The answer to this lies in assessing the potential damage that can be caused by making the change in the absence of regression testing against the existing environment.
- How do you ensure that when IT must make a change, they make the right change? The answer to this lies in communications and signoff procedures between the business and IT, particularly in making sure that they are using the same language and that the change requests are in writing.
And now we’re putting together two types of systems — BPM and BR — that both state (seemingly erroneously) that business users/analysts can make changes during production. Yeah, right.
After more than 15 years of working with BPM vendors who were passing around the same Kool-Aid, the BR vendors should take a lesson from what you lose by overstating ease of use, and provide some realistic guidelines for exactly what who’s going to do what in a real BR production environment.