Nathaniel Palmer wrote a review of Lombardi's Blueprint that I thought was interesting. So after my conversation on "Enterprise 2.0" with Sandy Kemsley a couple of days ago I thought I'd go back to that.
You see, I agree with Nathaniel's assessment that platform-level BPM-SaaS (or any other integration-intensive platform) is a non-starter (for the relevant future, anyway). Like any new technology (for purposes of this discussion, let's assume "SaaS" is new and that it's a technology, both of which are bad assumptions but that's another discussion) it will be mis-used by existing players and only new ideas will bring out its primary benefits. Remember the move by the mainline DOS players to Windows? They all died because they viewed this new thing as just a re-swizzling of their old thing... when in fact a new design approach was required.
So if you want to look at the BPM market I think there are 3 or 4 "buckets" that a process platform addresses.
- Modeling
- Execution
- Monitoring
- Reporting
I suspect we could quibble at the edges but generally that's what there is to this thing. Each of us vendors make implementation choices that we can debate, but the functional buckets are pretty much those four. Let's take a look at what's required for each of those, and where new technology or services could make a difference:
Modeling doesn't require integration and it benefits from collaboration. Now, there are advanced use cases where integration into and introspection of existing systems will help build scenarios for simulation, but in general, the bulk of the work done in the front-end of the modeling life-cycle looks like an OK fit for something delivered over the web. SaaS is not simply about a scalable way to deliver functionality, it facilitates collaboration if you tap into that part of it. The web allows people to get together to do their human-based work. If the tool you are providing also is easier than competing alternatives, structures data and puts in an accessible place and can hand it to you in a standardized format, then SaaS gives you a very scalable way to deliver this capability. That's where salesforce.com excels: doing something that was already being done but in a better way. In addition to that, if there are new concepts in this tool, then even better. At Lombardi, we think Blueprint is both easier to use than modeling alternatives (like salesforce.com) but also we think there are some new ideas (like integration with our behind-the-firewall BPMS). Easy access at the beginning, and tightly-coupled standards-based round-tripping when you move to execution.
Execution is different. The aspect of BPM process execution that I find most interesting is the execution that is done to make existing alternatives more flexible. BPM isn't a rip-and-replace thing where you should be building a new application. In fact, a BPM system should host as little system-of-record data as possible (other than the intrinsic SOR data that execution and monitoring spins off, process analytical data about the process performance... which I think is the most interesting aspect of BPMS-based execution!) If you aren't integrating to legacy systems, then all you're really doing is building a workflow application. Been there, done that, more silos, more support headaches for IT. That's not the process problem for the Global 3000. These companies have significant dollars invested in their systems and now those systems are holding them back. They can't dump them, their whole business depends on them. At the same time, these big systems just can't be changed fast enough. SOA alone isn't the answer, because the problem is not that the system-to-system transactions aren't working... it's the patchwork quilt of systems and humans that want to work together in new ways that aren't able to move fast enough. So service-enabling legacy systems as a part of a larger SOA is a Good Thing, but it's a Good Thing so that you can consume them in the new human-facing processes unified across the new business initiatives. BPM (and SOA) is a part of that. A BPM layer can be inserted and extended... it is more flexible for new things, and it masks the old thing while making the whole process seamless across the multiple systems. Well, anyway, the point of all this is that integration of the process platform into your business BPM is heavy, heavy lifting. If it's not heavy lifting (the low hanging fruit of unintegrated workflows) then all you have is a portal, a form and a workflow engine... you're not doing BPM. Unintegrated workflow applications using SaaS? Sure. Core-process BPM execution? Nope, not well suited to SaaS. (Of course, you could see a path from modeling to unintegrated prototype - one that "executed" - and then a transfer into a behind-the-firewall platform, but to me that's just modeling, so I'd put that up above...)
Monitoring. This part of BPM gets very interesting and sometimes not well understood. Not only should BPM offer up technologies that are agile, but BPM is the conduit through which we make business decisioning more agile. In fact, my experience (from many years pre- and post-BPM) is that being able to make informed business decisions is the longest pole in the tent of agility. And having good information is getting more difficult because of the morass of systems and silos (Ex-hell, as a customer calls one popular spreadsheet silo...). So monitoring complements execution and is equally important to execution for almost any process of consequence. You probably won't execute all of a core business process, but you will have to monitor key parts of it to provide the process-oriented "perspective" to management so they can know when, where, what, who and why of improvement. The reason is simple: any core process will already have some systems in place to support it. They may not be great (hence the need for BPM) but they will exist, resulting in more integrations, therefore not a candidate for SaaS (again, in the relevant future).
Reporting. The results of execution and monitoring need to be visualized. I think interesting Saas-based work may be done here around real-time collaboration and real-time data visualization. This is an area where a lot of vendors will be tempted to simply put their BI tools into SaaS. That won't do much in the market. But there is opportunity here, I think, to use the SaaS platform for something very interesting... the integrations required for reporting databases are so standardized these days - and the performance of modern data warehouses is so good - that some of the technical hurdles that we talk about in the execution and monitoring sections, above, don't exist (although the political hurdles of data access still do). I am watching this space for interesting developments, though... things like what businesses (like IBM) are doing in Second Life fall into this category, for me. In addition, I certainly would consider a future where a product like, say, Blueprint, might want to visualize the execution artifacts of a product like TeamWorks. Now wouldn't that be Enterprise 2.0'ish!
Well, those are my thoughts on when and where SaaS innovations may play a role in BPM in the next couple of years, and also on how Enterprise 2.0 (so-called) might transpire. Enterprise 2.0 is, to me, about the merging of the public and private delivery platforms accessible by a person in their worklife. By merging these platforms and leveraging each one to its fullest, we can do a better job of delivering the right stuff to the right person at the right time at the right cost. Enterprise 2.0 isn't Web 2.0 because the relative importance of "me" is reduced. As someone pointed out in Sandy's conference the other day, "this isn't communism, we have to think about corporate profit." And as I pointed out, it's also not about anarchy. It's about looking across the landscape of the enterprise and using every technical asset at our disposal, and leveraging it to the fullest. Where BPM comes into play is that it directs the order in which you create this leverage. It is the basis for understanding your business. If you marry these two ideas, BPM directing the Enterprise 2.0 leverage, then you'll be more quickly on your way to closing the gap between your PE multiple and Google's!
Technorati Tags: Enterprise 2.0, IBM, Sandy Kemsley, Nathaniel Palmer
