« Spreadsheets and BPM Part 2 : Maturity of BPM | Main | Swimming with the Whales (from the point of view of the Whale) »

This is the third, and final part, of my blog posts regarding what we can learn from spreadsheets and non-traditional application development. The first part discussed how spreadsheets are a positive example of how line of business experts can develop their own applications. The second part discussed some of the challenges the BPM is in replicating the successes of the spreadsheet vendors, most notably the traditional enterprise software business model.

The essential point that I wanted to make with this series of posts is that, while BPM is unique in many ways, it does have some important parallels to other software categories. We, as the BPM community, should be doing a better job of learning from the successes and failures of the past. In this post I'd like to discuss several related technologies and the lessons that I think we, as BPM vendors, can learn from those technologies.

Spreadsheets

I'll start with spreadsheets, since that has been the example we've been discussing the most over the last few posts.

Things that spreadsheets did well that we should emulate:

• As I said in my first article, the model must be the implementation. Imagine if analysts had to send their spreadsheets over to IT where the spreadsheet is imported into a different tool, the cells "implemented", and an EXE generated. No one in their right mind would have used a spreadsheet if they had to go through all of that. I feel the same way about BPM tools that require a conversion step between an "analyst model" in BPMN and a "developer model" in BPEL. It's pure insanity.
• Quick iterations are important for business users. For non-technical users it is important to be able to get immediate feedback on changes. If a business analyst changes a process model they should be able to test the impact immediately. This immediate feedback both helps analysts learn the tool as well as prevents there from being a large integration and testing cycle.

Things that spreadsheets didn't do well, and we should just learn to accept:

• IT isn't going to be able to control everything. Most Excel spreadsheets are ugly hacks. But they work and they are "good enough" for the business users. Yes it would be nice if there was a re-usable library of spreadsheets with a sales forecast spreadsheet. It would be even better if every department used that same spreadsheet. But every department manager has their own way of doing things. (Which is why everyone is doing their sales forecasting in Excel instead of using the sales forecasting feature of the CRM package.) We need to treat processes as valuable assets but we also must accept that departments will make their own choices regarding their processes.

Business Rule Engines

What I consider a sister technology to BPM (and others consider a subset of BPM), Business Rule Engines have been moderately successful. While they haven't taken off outside of their key verticals (financial, manufacturing, heathcare & insurance mostly) they have generally been successful in delivering more control directly into the hands of line business. Like BPM Business Rules implementations also have multiple competing stakeholders and have to balance the needs of the business for flexibility against the scalability and manageability concerns of IT.

Things that Rule Engines do well that we should emulate:

• Rule Engines (in general) treat rules like enterprise assets: including tools for cataloging, managing, and searching existing rules.
• Rule Engines (in general) are good about managing the deployment lifecycle, coordinating the description of rules by the business, any additional development by IT, QA, and deployment.

Challenges that Rule Engines have that we should learn from:

• No matter how pretty an interface you have, line of business experts are not programmers. (More on this later in the week.)
• Standards (like JSR 94) aren't very interesting if the standards don't allow portability. (If you can't move your rules from one vendor to another the only benefit of the standard is to ISVs.) Rule Engine lock-in is very hard to avoid due to a lack of standards about rule portability.
• Standards (like JSR 94) aren't very interesting as a communication protocol if the standard doesn't include enough functionality to be comparable to proprietary alternatives.

Portals

A few years ago portals were the hottest technology on the market. Except that everyone had a different definition of what a portal was. Some vendors supplied complete out of the box systems while others vendors were essentially frameworks and toolkits from which portals could be built. Some vendors focused on security and integration, while others focused on knowledge management and publishing. Portals were really a conglomeration of multiple existing technologies where the integrated whole was greater than the many parts. Any of this sound familiar? It should, because all of these statements could equally apply to the BPM industry.

Things that the Portal vendors did well that we should emulate:

• Portals (in general) did a good job at selling the business value of their technology. Despite the fact that there were often multiple disparate stakeholders involved in portal decisions, portals have become a mainstay of enterprise technology.
• Portals, in general, did a good job at integrating with third party systems. Enterprise Portals, like BPM, typically require integration with third party systems in order to build meaningful systems. The leading portal vendors did a commendable job in making that integration possible.

Challenges that the Portal vendors have had that we should learn from:

• Standards aren't very interesting if the standards don't include enough functionality to be comparable to proprietary alternatives. JSR 168, while promising, has generally been a disappointment for real deployments due to its lack of support for intraportlet communication. And while more functional standards like WSRP are emerging they continue to lag significantly behind the proprietary APIs.
• Widely varying areas of strength. While this is really both a strength and a weakness, I believe that the reason that no dominant portal player has emerged is because there are so many different ideas about what is important in an enterprise portal.

There are lots of other examples out there, I'd be interested to hear some your own comparisons in the comments.

Posted by davidogren at 01:05 PM in BPM | Digg This | Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/525

Posted by: James Taylor at July 25, 2006 11:49 AM

Posted by: Phil Ayres at July 25, 2006 06:46 PM