Hashtag time… #BigData. #Mobile. #Social. #Rules. #HistoricalReporting. #PredictiveAnalytics. #ComplexEventProcessing. #Portals. #Solutions. #InternetOfThings.
Some of the hashtags above are trending, and some were either trending long ago or long before Twitter, Google+, or Facebook came into existence. Regardless, all of them have their respective places in today’s modern enterprise, and all of them can be valuable components of BPM applications. But are they BPM core competencies? Does it matter?
In a word, yes; it does matter. It matters for warehouse stores like CostCo and Sam’s Club, who remain focused on selling bulk items at low cost. It matters for software vendors like Microsoft, whose long-term success in the operating system and office/productivity suite markets are testaments to their focus on those areas over the last thirty years. And it matters for BPM software and services vendors, who have built businesses on the solid foundation – that is the BPM core competencies.
In simple words, they are business process modeling and execution. No matter what additional capabilities are added to today’s BPM suites, it needs to remain easy to model simple to complex business processes, and the execution engines need to continue to provide the ability to efficiently manage and execute those business processes. Let’s spend the rest of our time taking a more in-depth look at those areas and some of the ways in which they could evolve over the next several years.
Today’s business process modelers are advanced and sometimes – gasp – sexy tools that allow us to very effectively model even our most complex business processes. Unfortunately, as we’ve added capabilities to those business process modelers, we’ve sometimes strayed from published standards, at times making it difficult or impossible to port process models from one BPM system to another. Perhaps we could strive to adhere to BPMN standards more closely, building extensions where required (and they are required) but focusing on the standards wherever possible? Yes, vendors are sometimes motivated to make it more difficult to move away from their tools, but those same vendors want to make it easy to migrate to their tools… Such portability would make that easier. Additionally, perhaps we can make it easier to extend the process modeling frameworks to add additional capabilities? For example, perhaps a customer might want to integrate to a “NoSQL” database to store data for historical reporting?
Similarly, our execution engines are models of efficiency. In many cases, they’re able to handle staggeringly large volumes of transactions extremely efficiently. But are they “open”? More specifically, is it possible to interact directly with the engines using open standards? I’ve worked recently with a customer who wants to be able to easily interact with process instances to update state within those instances; perhaps surprisingly to some readers, that is not easy with all of today’s process execution engines. And why do we still have to accept that our BPM process engines can only handle either asynchronous (usually human-centric) or synchronous (fully-automated) process models? Why can’t a single engine do both effectively?
We’ve come a long way in BPM, and our customers have more power available to them than ever before via the inclusion of additional, powerful features. However, as an industry, we need to remain focused on our core competencies – they got us to this point – and on ensuring that we strengthen our capabilities in those areas of core competency. Such a focus would serve us well in 2014 and beyond.