Category: process

business process management

Ovations BPM framework

Sunday night, I had dinner with Doug Reynolds from Ovations (caution: website misbehaves on Firefox), who make a .Net BPM framework that sits on top of FileNet, K2 and other BPM products. I’ve known Doug since the late 1990’s, when I owned a small SI firm and he worked at Meta Software, then through 2000-1 when I worked at FileNet and he was one of the founders of the Meta spin-off Cape Visions (now just a shell company since the technology was sold to FileNet to become the core of their Process Analyzer product). After that, we lost touch — my last memory being of drinking tequila together in a bar in Huntington Beach — until last November when we reconnected at FileNet’s user conference. He’s now the President of Ovations’ US operation (Ovations is headquartered in South Africa), building the North American market for their framework, OvaFlo (the name of which really makes me think about menstrual cycles, but never mind), and associated services.

Doug and a colleague showed up in Toronto this weekend, and we spent a good few hours in one of my favourite Ethiopian restaurants talking about Ovations’ framework, competing frameworks, hockey, BPM products, the fact that they showed up in -10C weather with no gloves, and the need for a general unified theory of BPM. Okay, I made the last one up, but we did wax a bit philosophical at times.

There’s still a need for some sort of framework in many of my customers’ implementations, especially around case management activities and, to a lesser extent, work assignment, but many of the ones that I’ve seen in the past tend to reinvent some or all of the BPM functionality within the framework, thereby cutting you off from the specific functions — and advantages — of the underlying product. Personally, I’d never recommend using a framework that completely hid the underlying product; although it might be an advantage to the framework vendor to support multiple vendors’ BPM products completely under the covers, for the customer it usually means that the framework provides only the least common denominator of functionality and contains a whole lot of other crap to not only make it vendor-independent but have it appear identical regardless of the underlying product.

The result of all this is that Doug will be giving me a remote demo sometime soon so that I can check out the framework for myself. More to come on this one.

BEA snaps up Fuego

BEA bought Fuego today, which starts to bring home the predictions about consolidation in the BPM marketplace. Press release here on ebizQ or here on the BEA site, which includes the usual hyperbole from the CEO:

We are now the only company to offer a unified SOA-based platform to integrate business processes, applications, and legacy environments.

There might be a few of BEA and Fuego’s competitors that disagree with the “only” qualifier, although this marriage of ESB, BPM and other integration technologies does provide good coverage of the space, reminiscent of the Staffware acquisition by TIBCO a few years back. Fuego will form the foundation of BEA’s new AquaLogic Business Service Integration product line, and give BEA a much better story for talking to business executives, instead of just chatting with the IT guys like they’ve been doing in the past.

This is the second key acquisition for BEA in the past year, following their acquistion of Plumtree last summer. They’re definitely building out their integration capabilities, and doing so by including products that are fairly platform-agnostic for the widest appeal. The real test will be to see how tightly this stuff is integrated a year from now: it’s not enough to just slap a BEA label on Fuego software, there needs to be technical infrastructure reasons and goals for making an acquisition like this.

One interesting thing that I noticed from the press release and the conference call is the strong link made between BPM and SOA (something that I’ve been writing about for some time). On the conference call, Mark Carges from BEA refers to BPM as “the fastest growing segment of SOA”.

You can hear a replay of the 20-minute announcement conference call at mshow using the show number 292109.

Investing in BPM webinar

Understand that first of all, I think that Bruce Silver is a very smart guy, and don’t take it the wrong way when I say that he is a less-than-scintillating speaker. He was featured on Appian‘s Investing in BPM webinar today, and his talk turned out to be just a slight expansion of his Intelligent Enterprise article that I discussed earlier; it wasn’t exactly edge-of-the-seat stuff. Maybe he should spend less of his time reading from a script, and more just talking about this subject matter that he knows so well. And although he was giving a beginner’s guide to BPM, I have a bit of a problem with him starting out his talk with “I want to talk to you about a new kind of software, business process management…” New kind of software? Not.

After the requisite 20 minutes of “independent content” that the vendors use to hook you into attending their webinars, Appian’s Director of Product Management, Phil Larson, stepped in and talked more about BPM in general and about their product. He was interesting enough to keep me on the line for the remainder of the webinar, and he had good illustrations of some of the concepts, including the prettiest diagram that I’ve seen to show how BPM and SOA fit together. Not the most complete, but sometimes you just need a pretty version to make your point.

Larson quoted from the recent Forrester report — “[Appian] has the widest breadth of functionality among the suites we evaluated” — although he didn’t mention the bit that came later in the same paragraph of the report: “However, breadth comes at the expense of depth in features like simulation and system-to-system integration“. He showed a snap of their BPMN implementation, which gets good marks off the bat for having the swimlanes running in the right direction.

I’m not sure if Appian will have the webinar available for replay later, although it’s not really worth it unless you’re a true beginner. I think that you can get most of the information from Silver’s portion of the talk from the earlier-reference Intelligent Enterprise article, and most of the Appian information from their web site.

Forrester Wave for Human-Centric BPMS

Forrester just released a report on human-centric BPMS, and Lombardi is just busting with pride over their position: so much so, that they’re giving the report away here (registration required). Phil Gilbert must be doing a little happy dance, especially considering that their “dot size” has increased from a tiny blip on the radar to a more respectable market presence. Forrester’s had a soft spot for Lombardi for a while: the March 2004 “Pure Play BPM” wave (that’s when we were still calling this “pure play”) had Lombardi at the cusp between Strong Performer and Leader. Relative positions of many players have stayed pretty much the same since then in the Forrester rankings (Garter’s rankings are quite different), although TIBCO and Pegasystems have made significant increases in market presence. I’d have to say that Forrester must have been looking mostly at the American market presence, since TIBCO (which was still the Staffware product during the 2004 ranking) had a huge presence in UK, European, Australian and other markets that I saw.

Excerpts from Forrester’s executive summary regarding those in the Leaders category:

Lombardi Software, Pegasystems, and Savvion lead with comprehensive suites that foster rapid, iterative process design; Appian leads with a richly featured suite for people-intensive work; and TIBCO leads with a human-centric BPMS that leverages its integration-centric product.

In fact, later in the report, they more categorically state “Lombardi Software, Pegasystems, and Savvion lead the pack — hands down“, then they proceed to break out the specific reasons for their evaluation. However, they also stated “If you could only buy one BPMS product, Fuego offers the best — bar none — product supporting human-intensive and system-intensive processes“, an assessment with which I don’t disagree, after seeing things like Fuego’s web services introspection (although I still insist that they put their swimlanes sideways). They go on to say that “Appian and FileNet innovate beyond the boundaries of human-centric BPMS” by integrating collaboration tools that allow a non-standard process to go off the rails in a somewhat controlled manner.

One thing I didn’t like is how Forrester categorizes business processes:

  • Integration-intensive
  • People-intensive
  • Decision-intensive
  • Document-intensive

I don’t really agree with this categorization, first of all since it’s not normalized: integration-intensive and people-intensive certainly are at opposite ends of the same scale, but their definition of decision-intensive is really people-intensive with a strong need for business rules (which I think are necessary pretty much all the time), and document-intensive is just people-intensive with a lot of scanned documents involved. Although document-intensive processes would always be people-intensive, I believe that decision-intensive could fall anywhere along the integration-to-people scale since it is primarily about the use of business rules. Although many organizations are still choosing separate products for integration-intensive and people-intensive (or human-interrupted, as one of my customers once so charmingly put it) processes, the real issue in this report should be about any given product handles all three of (what I see the artificial divisions of) people-, decision- and document-intensive functionality.

The last half of the report shows the explicit criteria ranking for each vendor, and a detailed paragraph of strengths and weaknesses for each vendor. Definitely worth the read.

Implementing BPM

The flight home from Mashup Camp was a great opportunity to catch up on my notes from the past couple of weeks, including several ideas triggered by discussions at the TIBCO seminar last week: some because I disagreed with the speakers, but some because I agreed with them. I split my opinions on the discussions about implementing BPM systems, specifically about the role of a business process analyst, and agile versus waterfall development.

First of all, the business process analyst role: Michael Melenovsky sees this as important for BPM initiatives, but I tend to feel the same way as I do about business rules analysts: just give me a good business analyst any day, and they’ll be able to cover rules, process, and whatever else is necessary for making that business-IT connection. Furthermore, he sees the BPA as a link between a BA and IT, as if we need yet another degree of separation between the business and those who are charged with implementing solutions to make business run better. Not.

There were some further discussions on how business and IT have to collaborate on BPM initiatives (duh) and share responsibility for a number of detailed design and deployment tasks, but this is true for any technology implementation. If you don’t already have a good degree of collaboration between business and IT, don’t expect it to magically appear for your BPM initiatives, but do take note that the need for it is at least as great as for any other technology implementation. How we’re supposed to collaborate more effectively by shoehorning a BPA between a BA and IT is beyond me, however.

Melenovsky also had some interesting “lesson learned” stats on the correlation between the time spent on process discovery and model construction, and the success of the BPM initiative: basically, do more work up on your analysis and up-front business-focussed design, and your project will be more successful. Gartner found that over 40% of the project time should be spent on process discovery, another 9% on functional and technical specifications, and just 12% on implementation. In my experience, you’ll spend that 40% on process discovery either up-front, or when you go back and do it over because you implemented the wrong thing due to insufficient process discovery in the first place: as usual, a case of choosing between doing it right or doing it over.

That directly speaks to the need for agile, or at least iterative, development on BPM projects. You really can’t use waterfall methods (successfully) for BPM development (or most other types of technology deployments these days), for so many reasons:

  1. When implementing new (and disruptive) technology, whatever business tells IT that they want is not accurate since the business really isn’t able to visualize the entire potential solution space until they see something working.
  2. While IT is off spending two years implementing the entire suite of required functionality in preparation for an all-singing, all-dancing big bang roll-out, the business requirements will change.
  3. During that two years, the business is losing money, productivity and/or opportunities due to the lack of whatever BPM is going to do for them, and is building stop-gap solutions using Excel, Access, paper routing slips and prayer.
  4. That all-singing, all-dancing complex BPM implementation is, by definition, more complex and therefore more rigid (less flexible) due to the amount of custom development. It makes sense that you can’t use a development methodology that’s not agile to implement processes that are agile.
  5. The big bang roll-out is a popular notion with the business right up to the point when it happens, and they discover that it doesn’t meet their needs (refer to points 1 and 2). Then it becomes unpopular.

Instead, get the business requirements and process models worked out up front, then engage in iterative methods of designing, implementing and deploying the systems. Deliver “good enough” processes on the first cut, then make iterative improvements. Don’t assume that the business users aren’t capable of providing valuable feedback on required functionality: just make them do their job with the first version of the system, and they’ll give you plenty of feedback. Consider the philosophy of an optional scope contract rather than a fixed price/date/scope contract, whether you’re using internal or external resources for the implementation. Where possible, put changes to the business processes and rules in the hands of the business so that they can tweak the controls themselves.

What Are The Analysts Looking At?

I hate to spend too much of my time dissing the analysts, but sometimes I really wonder where they get their information. At a seminar that I attended last week, Michael Melenovsky from Gartner characterized the current state of BPM as workflow-oriented departmental implementations that included software deals in the $60K range. That’s not what I’m seeing, although maybe my view is skewed because I’m actually helping to implement these systems rather than taking the long view from the top of an ivory tower. I’m seeing BPM projects spanning the functionality spectrum from human-facing to STP, and spanning multiple departments across the enterprise to become part of the enterprise infrastructure. Furthermore, organizations are spending a lot of money on them, and have budgeted to spend even more in the next year (I seem to recall blogging about a recent study that showed application integration as the #1 spend for CIOs this year, but can’t seem to find it).

Melenovsky also showed a graph of the “BPM stages of value creation” over time, which showed productivity as being the greatest value of BPM now, visibility having the greatest value by 2012, and innovation having the greatest value by 2017. Besides the obvious point that predicting anything to do with a still-fluid technology 11 years in the future is about as accurate as reading tea leaves, the idea that visibility won’t be the dominant value added by BPM until 2012 is just plain wrong. Process visibility kicked into gear as a dominant driver for BPM over the past few years of intense compliance scrutiny, and it’s already poised to overtake productivity as the biggest benefit provided by BPM. Although the definition of process metrics is still more of an art than a science, the various levels of process-centric business intelligence that provide process visibility (corporate performance management, business activity monitoring, complex event processing) are being mandated in the boardroom and implemented across the enterprise. Process visibility is the new black, and it’s in style now.

I also don’t see another 11 years elapsing before innovation overtakes visibility to become the primary value provided by BPM, since agility and innovation are so closely tied, but the Ouija board hasn’t yet given me enough information about when it will happen.

Separating rules and process

I’ve posted a number of times in the past about the importance of business rules engines (BRE) in conjunction with BPM in order to keep rules and process separate. To sum up my thoughts on this:

  • Most BPMS don’t have sufficient functionality in their in-process expression builders to offer true business rules capabilities. A notable exception is Pega, which is built on a rules engine. I’m not going to wax poetic on the benefits of business rules, since there’s lots of other people who can do that better than me, but take my word for it: you really need business rules.
  • Having the ability to change work in progress. If the business logic is embedded within the process map, then typically that logic is fixed for a particular item of work at the time that it is instantiated. For straight-through short-running processes, this isn’t a problem, but for long-running processes (with or without human interaction), it is, since most BPMS don’t provide for changing the business logic or process map for an item of work once it is instantiated. If the BPMS retrieves its rules from a BRE at the time that each rules-oriented step is executed, then the rules are as current as what’s in the BRE.
  • Using the same rules engine and rules across multiple applications, not just within the BPM. Imagine it: the same business rules about, for example, how you deal with a customer’s order in a particular situation being applied identically across your CRM, your BPMS, and any other applications that it might impact, because they all retrieve their business rules from a common business rules repository at the time of execution. This idea is just starting to creep into the consciousness of most large organizations (they’re still digesting the first two reasons), and is ultimately the most critical since it not only provides for greater business agility, but also has a huge impact on compliance.

This last point is exactly why I see Pega’s position as a disadvantage rather than an advantage: although they market themselves on the fact that they’re built on a BRE, the requirement for business rules in multiple applications across the enterprise is finally being recognized, and stand-alone BRE will become more commonplace in organizations in the next few years. And if you’re using Fair Isaac for all of your business rules across the organization, you’re not going to want to use a different, proprietary BRE inside a BPM product to re-implement some of the same rules that exist elsewhere in the organization.

I thought of this last week at the TIBCO seminar when I learned that they also have a proprietary rules engine embedded in their BPMS, although the BPMS is not based on the BRE (as with Pega), it’s just there to provide additional functionality, and TIBCO allows for integration with popular third-party BRE including Fair Isaac and ILOG. My prediction is that as organizations start to roll out these best-of-breed BRE across the enterprise, TIBCO will abandon their own rules engine in favour of integrating only with well-known third-party BRE.

TIBCO and AJAX first look

I spent this morning at a seminar co-hosted by TIBCO and Intelligent Enterprise, featuring Michael Melenovsky from Gartner. One of my reasons for attending was to find out more about TIBCO’s newly-released version of General Interface, which they purchased a year ago, and find out just how tightly that it’s integrated with the TIBCO BPM product. In other words, I was on the BPM mashup hunt that I talked about here.

Jeff Kristick, TIBCO’s Director of Product Marketing, gave a presentation where he showed a screenshot of an AJAX-based rich client interface to their BPM product (I would have loved to have seen a demo rather than PPT-ware). I asked if their out-of-the-box UI for BPM was AJAX-based, and he said that they had taken advantage of the acquisition of GI to rebuild their BPM interface using their own AJAX development environment, and that’s what’s shipping now. Cool.

GI is available for free for public applications, and really cheap for enterprise (inside the firewall) applications, so off I went to the TIBCO technical site this afternoon to check it out. Quick signup, wait for a password via email, then off to the download page. I noticed the page of sample projects, each with both a preview and the source code, so thought I’d check these out before installing. Clicked on the first “View Preview” link:

Yikes! You want me to give up Firefox for this? I’m sure that the 45% of my readers who don’t use IE agree with me on this one.

More on GI and the rest of the seminar after I remember where I hid IE…