John Hoogland, CEO of Pallas Athena, gave the opening keynote this morning, discussing how BPM has changed since the early days of workflow and painfully customized EAI to today’s landscape of BPM and SOA. He also contrasted what he sees as the old style of assembly line-style control flow unique to US and UK companies, and the more “one and done” style prevalent in Europe.
He went through a montage of BPM vendor websites – pointing out that the smaller the company, the clearer the message – and noted that the key message on all of those sites in 2009 is agility. The promise of all of these vendors is that change is key, and that this change can be done by the business, without IT. BPM doesn’t bring flexibility: it brings control. It gives more flexibility than the processes within legacy applications, but is inherently less flexible than a process that is not under the control of a system. Agility is more than flexibility, it’s about change but in a controlled environment: change in control.
He did a closer look at many of the vendors’ messages, pointing out the nonsense of much of the marketing speak about how easy and beneficial that BPM is. Agility in that context means that the process can be re-modeled; in fact, that’s often the only point of agility that the BPM vendors allow (although I would argue that integration of rules management creates significantly more agility without process model changes).
From a modeling standpoint, having users involved in process modeling does bring agility through faster and better design decisions. Separating process flow from legacy applications also provides agility. However, these processes need to be released within an IT infrastructure, serve the needs of the entire enterprise, and tend to be fairly complex: all recipes for killing agility. Even looking at the vendors’ architecture diagrams of BPM, it is always shown as a very small component within a much larger IT ecosystem; this is typical of what I see in large implementations, where the BPM part of an enterprise project is just a tiny piece of the whole project, even though it is labeled as a BPM project. Other factors also impede agility: the issue of migrating work in progress when the process model changes, including changes to related services. The conclusion: although the vendors make process model changes look easy in the demo, it’s not that easy in reality.
Complexity of process models is also an issue. In practice, exception handling tends to cause process models to balloon far beyond the “happy path” that you model on day 1, as do regional differences, handling of unexpected external events, and interfaces between departments and with systems. For example, you really don’t want separate process models for each region, you want a single model that can handle the regional differences, but that creates both a more complex model plus a nightmare of change control. However, if business users have the ability to change their local processes through parameters without having to change the enterprise-wide process model, things become much simpler. What parameters should be available for change on a local level, then? Hoogland suggests rules/decisioning, prioritization, resource allocation including role assignment, deadlines/SLAs and other factors. This requires an explicit step during the process design to design what parameters have to be able to be changed by the business users on the fly without changing the process model (I am going through exactly this exercise now with a client, and completely agree with his assessment), and ensure that the BPMS is capable of providing those as parameters under direct control of the business.
He ended up with some final thoughts about how the market is confused by vendors and analysts leaping onto new concepts and techniques too quickly, and how we waste time and energy on non-issues such as BPM standards.
He mentioned my post yesterday about the process model comprehension tutorial, and agrees with my assessment that the vendors have a huge amount to learn from academic research. I’m beginning to think that my true calling is as an evangelist bringing the word of new and useful academic BPM research to the BPM vendor community, although I have no idea how to monetize that. 🙂
There was a good Q&A following, with discussions on the potential value of bringing academics and vendors closer together; he admitted that a year ago, if asked to attend this conference, he would have been concerned only with whether there would be customers here. Now – hopefully due to some of my prodding of the vendors encouraging them to attend – he understands that vendors have a lot to gain from seeing what the academic BPM community is doing. There’s definitely monetary issues: academics need funding in order to continue research, and much of the research is still sufficiently early that a significant amount of research and development would still be required by the vendors to bring it to market. Many small vendors just can’t afford their own pet researchers such as IBM and SAP have, and are very focused on getting a product out this year as opposed to investing in the long-term potential from BPM research.
There must be a way to have funding flow from BPM vendors to BPM researchers without having a vendor try to control the speed and direction of the research, and without even having a specific researcher tied to a specific vendor. Is there a place for a virtual institute of BPM research spanning the many great BPM research institutions, funded by a consortium of vendors, with all having access to the end results? I’m thinking that for less than the cost of having a booth at a Gartner conference, a BPM vendor could contribute significantly to BPM research and reap the rewards.