More industry consolidation
In a previous post I wrote about IBM buying Lombardi, and noted that I expect to see more industry consolidation. Well, we didn’t have to wait long to find out which merger is next. They say things occur in threes, so I wonder which BPM company is next….
The IBM acquisition of Lombardi was interesting because IBM needed to fill the department level workflow product need. This is where Lombardi is being positioned, according to IBM.
Progress software’s move for Savvion was much more interesting because Progress did not have a BPM system, or history of workflow systems. Instead, Progress has a wide range of SOA systems and tools, and a strong offering in the CEP (complex event processing) and BTA (business transaction assurance) space. With these offerings, Progress would more likely be positioned to sell products and services to the IT architecture crowd more so than the business. Now with a full stack of BPM, CEP, transaction monitoring, ESB, and data services, Progress is very well positioned to be an aggressive competitor in the BPM market.
I’m very interested in this Progress and Savvion merger because it shows the BPM industry is evolving into more event oriented processes instead of people centric activity. CEP (complex event processing) refers to the idea that things happen that are not necessarily all part of a process. For example, I can correlate streaming data from traffic, weather, positions of my delivery vehicles (from GPS), and incoming orders from my order system. In a BPM world these events would only come together when they are relevant to a given activity. In an event driven world, these events could potentially affect each other at any time, regardless if there is an active process task or not. Many of these might not even be part of the BPM system. When the filtered events are correlated to something interesting, a process action can be signaled. Examples of process action include starting a new process for corrective action. You could also interrupt, continue, or end a process that is in-flight.
The over-all strategy of CEP + BPM means that there is less integration time for systems. Instead of routing all event activity load through the BPM system, the CEP system handles complex correlations of events, and aggregates them down to things that a BPM system might be interested in. Also, you can get a broader perspective of multiple process instances simultaneously, especially when activities are in-flight. For example, a delivery truck is running late. With BPM only, it’s likely that you would not know this fact until the truck is overdue. With CEP, I can constantly monitor all trucks via their GPS signal, and report all positions to a dashboard. Furthermore, you can correlate to traffic data in-route, and determine exactly how late the truck will be. This allows an organization to react to exceptional conditions in real-time. Keeping in mind, most transport companies (and other industries) do this sort of monitoring anyway, but not automatically. Without CEP + BPM capability, you would have to perform these correlations manually, which might require a huge workforce. The key here is that the events are reported in real-time, and the event correlations are more accurate.
