Continued from Part 6.
Part 7: The New Arrivals. In the years following the dot-com bust in 2000, a number of new BPM vendors came into being, mostly in the coveted pure-play space. (Funnily enough, “pure-play BPM” is now not the desirable place to be, having been replaced by the “BPM suites” space that, according to some large analysts’ research, seems to have nearly identical functionality to pure-play BPM.) In many cases, these were started by those who were bounced out of their previous positions during the bursting of the bubble, so there was a lot of experience being put to the task of starting this new generation of BPM vendors.
The big advantage that a new vendor has in any industry is the lack of baggage, and nowhere was this truer than in BPM: they could start designing the next generation of BPM without having to reuse their existing technology or support their installed base, because they had neither. The BPM market needed to be reinvented, and these upstart young companies were the only ones who could shake things up enough to do it. I’m not going to credit the new arrivals with all the innovation in BPM during that time, but they certainly lit a fire under the old guard. Suddenly, we had BPM calling web services, or being called as a web service, in order to speed integration (and eventually become part of the SOA ecosystem). We had BAM, or at least some half-decent process monitoring and analytics for a change. We had simulation and optimization. We had integration with third-party modelling tools. We had business rule integration.
The startup environment during that time wasn’t the best — not a lot of venture funding around for technology, the perception that this was just a rehashing of the well-established workflow market — but a few of the vendors have become successful and many others are still straggling in their wake.
Meanwhile, the established BPM vendors had a big challenge on their hands: although few of the upstarts were challenging them directly for sales, the new guys were changing the perception of what the BPM market should be, forcing the big guys to follow suit as Gartner and the other large analysts published lists of must-have features that included this new functionality. Many of the larger vendors lagged badly in implementing new features, and look a little tired these days in comparison to the shiny bright newcomers. In some very conservative industries, such as financial services and insurance where most of my clients are, this hasn’t been a problem because they’d rather pick a vendor with a longer track record and the proven ability to process hundreds of thousands of items per day. However, this is where many of the dinosaur-like CIOs are fighting the losing battle against the push for emerging technology, and eventually the new kids will prove themselves scalable and stable enough for even the most conservative industries.
Even if none of the post-2000 vendors survive the upcoming bout of acquisitions, they have to be credited with not just injecting new life into BPM, but helping to reinvent it.
Next: The Current State
ahh..nice !!
For a while, I thought you had forgotten this series, yeah you must be busy with other stuff too..
anyhoot, I was going to email you to ask you whatever happened to this series, but now I dont have too :)-
thanks for the post. I have been following this series of article !!
Just ran through this series of posts. This is a very interesting perspective on BPM. I and most of the others I know who are doing BPM work usually tell the story from the perspective of how BPM eveloved as a management discipline (sometimes called process-oriented/centric/based, focused management) rather how the software tools converged to finally address the real needs of the business. So, I won’t comment on the accuracy or potential skewing of this technology-oriented timeline (I do know a couple “pure-play” vendors who would argue about some of it with you though). From my POV, it seems like the tools lag the need which is why they have evolved the way they did… as the tool vendors recognize what people are actually trying to do with their products, they added functionality. I think that trend has continued and now some of the “suites” are recognizing a need to integrate BA & BI functionality way beyond BAM’s capabilities (as you put it, only “half-decent”) if they really want to have a round-trip inclusive BPM solution. I think it is important to keep in mind what the context, scope and nature of the real “problem set” when discussing the options for solutions. Today to really support an enterprise or large-scale business process management discipline, requires 4 or 5 different tools that don’t naturally play nice together. So the suites still have quite a way to go to be complete solutions. Hope you follow the “history” with a future trends episode… looking forward to next installment. BC
Brett, I probably should have called it a short history of BPMS, since it is more about how the tools developed to meet the business needs. I agree that no vendor does it all, and in fact I typically still see at least two BPM products in any large organization that I work with: one more human-focussed, one more integration or B2B-focussed. Getting all the tools to play together is the challenge, in spite of web services and some other standards that have improved the situation somewhat.
BPMS can be used to understand organizations through expanded views that would not otherwise be available can be used to organise and present.Although the initial focus of BPM was on the automation of mechanistic business processes, this has since been extended to integrate human-driven processes in which human interaction takes place in series or parallel with the mechanistic processes. And I think that the future development will be devoted to this process.
Sandy (the other one!), I don’t think that BPM started with integration-type processes, as you imply in your comment, I think that there were two separate threads (human-facing workflow, and integration-focussed EAI) that eventually intertwined to create BPM. Lately, however, the term BPM has been co-opted somewhat by the integration vendors, such that some people have been using the term “human-facing BPM” for that side of it. I consider it all BPM, and to be a true BPM suite, you need to cover the entire spectrum to some degree.