It’s the end of day 2 at Gartner BPM 2013, and I’m in my first session with Janelle Hill — hard to believe, because usually I gravitate to her topics since she’s such an insightful speaker. She admitted that she is feeling like it’s day 4 (of a 2.5-day conference), so glad to know that I’m not the only one experiencing a bit of conference fatigue. Of course, this is my third week in a row at conferences, so that could be a contributor, too.
She’s doing one of their short “To The Point” sessions, only 30 minutes including Q&A, with a quick review of dynamic BPM and what it means to change a process in-flight. There are a number of things that can be done to change a process, ranging from small changes such as reassigning work during runtime, deleting outdated activities, or changing a monitoring dashboard; to mid-range changes such as adding new performance metrics or changing a business rule; to large changes such as major resequencing or mapping to different underlying services. This was a bit of a confusing classification, since some of these were clearly runtime changes to a specific process instance or set of instances, while others were more design-time template changes that would impact all process instances created from that point on. Regardless, it comes down to what kind of things you might want to change in your process, and what could be considered as changes that business could make directly or could collaborate on with IT. And, as soon as process changes are made by the business — or made at all — there need to be changes to the mindset: developers no longer should think about building to last, but rather building to change. This seems like just good practice for most of us, but there are still a lot of enterprise developers who don’t think about a modular service-oriented architecture, and using declarative business rules to enforce constraints.
She finished up with some must-haves for enabling dynamic BPM, which were all technology-based; this was a bit disappointing since she only briefly addressed the topic of what cultural and role/responsibility changes need to be made in order to have business people actually make the changes that the technology now allows them to make. The technology in this area is becoming fairly mature, but I find that the mindset required for IT to relinquish control of process changes, and business to assume responsibility, is the part that’s lagging. She did point out that business people are becoming more comfortable with being involved with model-driven design, but it’s way more than just knowing how to use the tools.
The part I always fall down on is it’s these people’s processes, not mine. They know what they need to do, I’m just the implementer. Sometimes I think there’s a fear on the part of the client when they ask IT “Can I/it do this?” as if they’re seeking permission or is it allowed. My response always is “Do you want or need it to?” #justsayin’
Patrick, you have an excellent point, but keep in mind how many large organizations tend to infantalize their business users when it comes to how their core systems work: I see a lot of IT people with disdain for business people, quite likely forgetting why they (the IT people, that is) even have a job.
Agreed, the disdain part still exists in many corners. Amazing in that we’re supposed to align with and support our business partners.