High-level product info

Dave McCann, FileNet’s SVP of Products, is talking in some very broad strokes about product directions, and I’m yearning for more details on all the new announcements. I suppose that will come mostly in the breakout sessions, I just need to be patient. He’s also talking a lot about content, which is not my focus (in case you haven’t noticed already) — I consider content to be like the air we breathe: it’s always there, I just don’t think about it.

A few interesting factoids that he’s dropped into his talk based on his conversations with customers: a large insurance company who sits on the FileNet technical advisory board stated that the largest cost in their IT budget is integration between all of the vendor products that they own. Yikes! A European customer told him that 82% of their IT budget is committed to maintaining what’s already in place, with only the remaining 18% to spend on new technology. These two facts taken together point out the need for easier ways to integrate all the things that are there, which will free up part of the budget for new technology that will help companies maintain a competitive advantage. The need for consistent architectures and reusability has never been greater.

He’s finally onto the process stuff, and is talking about the recent and upcoming enhancements to the BPM product suite:

– Productization of the Business Process Framework, which is a BPM application development framework developed by FileNet’s Professional Services for use in their own customer engagements, including things like case management and skills/roles management. They’re being very careful about positioning this so that it’s not perceived as being too competitive with partner solutions, although I’m sure that there will be a few partners who are going to be a bit put out by this.

– Business Activity Monitoring as a new product, replacing the rudimentary Process Analyzer that has been holding the fort in the BAM area for the past few years. Shipping in December. I’ll definitely be going to the lab on this later this week, since this is something that I constantly talk to customers about.

– Enhanced integration with business intelligence, especially through their recent cozying up with Cognos. I’ll be talking about corporate performance management, and mentioning Cognos specifically, in my breakout session this afternoon, since I feel that this is a critical step for most organizations.

– eForms enhancements, which are always interesting but a bit peripheral to what I usually do.

– A business rules connectivity framework that integrates to Fair Isac, Corticon and Resolution in addition to the longer-standing integration with ILOG. BRE is another functionality that I feel is essential to BPM, as I discussed in my course on the weekend.

He’s also talking about the FileNet Enterprise Reference Architecture, which fits nicely as a technical architecture for ECM against a full EA context.

The most exciting thing about the features that will be released next year is full BPMN support, which further validates my personal preference for BPMN over UML for process modelling.

All-in-all, I’m quite pleased with what they’ve announced in the BPM area, since it’s addressing some key weaknesses (like BAM) that have existed in the product suite to date.

Convergence of BPM and BI

If you’re interested in more about the Forrester report about BPM and BI that I mentioned a couple of weeks ago, but still don’t want to shell out the cash for it, you can find a more complete summary on here on BPM.com (registration required), written by a Forrester VP who was one of the original report authors.

The more that I look at compliance, which I’ve been doing a lot of lately, the more that I understand that BPM needs to feed its performance data into a larger BI infrastructure. And I can buy into what the Forrester report refers to as Process to Data, or P2D (as if we needed another TLA), which is the two-way synergy between BPM and BI: BPM feeds process performance data to BI, and BI invokes processes in BPM in order to gather information. However, I have to draw the line at their statement:

BI and BPM can no longer live without each other, and the time is right for these technologies to merge.

I don’t think so, any more than BPM will merge with any number of other technologies, although obviously there will be closer and closer integration ties in order to make all of this work smoothly. BPM and BI are strong, distinct markets served by a variety of strong vendors, and customers develop quite a bit of loyalty to their BPM and BI vendors because both of these technologies are pervasive in an organization’s IT infrastructure. If BPM vendor A decides to merge with BI vendor B and suggests to their customer that they should change all of their existing BI from vendor C to vendor B, there would be a great deal of rolling around on the floor and laughing. There’s a much stronger argument to be had for merging BPM and BR (business rules), but I don’t think that’s going to happen either, for much the same reasons: both technologies have strong, independent markets (that is, the technologies can exist successfully in organizations without each other) and there is little reason for a customer to want to buy their corporate-wide BR from their BPM vendor, or vice versa.

If the merging that Forrester suggets actually occurs, we’ll end up with monolithic Swiss-Army-knife-like vendor offerings from a few large players — how retro! — and a lot of unhappy customers. What most customers want is the best of both worlds: the best-of-breed technology, and the minimum amount of integration; hence the huge popularity of SOA. In the past, you couldn’t get both: you could buy best-of-breed from different vendors and take a lot of effort to integrate it, or you could buy a fully-integrated suite from a single vendor that included at least one sub-optimal component. Today, however, with the advent of integration standards and SOA, the integration effort for properly-constructed products from different vendors should be no more than that required for products from the same vendor.

My conclusion: as long as the vendors do what they’re supposed to in order to enable easy integration, there’s very few customer drivers for merging BI and BPM.

Who touches production?

Last week’s post on the BPM/BR webinars originally contained a lot more of my brain pouring out onto the keyboard because of things said during both of the webinars about business, IT and production systems, so I gathered up all the ideas and let them stew for a few days.

As long as I’ve been working with workflow and BPM products, the vendors have been claiming that the business users/analysts can design the process flows and modify them in response to changing business conditions, and in fact have implied (or actually stated) that the business side would make changes to the business process in production. And, as long as I’ve been working with these systems and their users, that has never happened.

I haven’t worked much with business rules systems, but I see a lot of the same type of claims about business users/analysts being responsible for modifying the production systems and that gave me a bit of hesitation because I know how that really translates over in BPM land. Both of the BPM-BR webinars reaffirmed my suspicions: no one really lets the business side touch a production business rules system, even if it has a pretty user interface. Give the business a sandbox for changing testing rules, but they’re not going to be the ones responsible for regression testing these against what’s already in production, and then getting them into production.

In the second webinar, John Rymer (the Forrester analyst) stated in one of his slides that business analysts will make changes, thereby providing the business agility promised by these systems, but when he returned to the point later, he requalified this as “business analysts or garden-variety programmers”; what he really appeared to mean is that you don’t have to use a highly-trained business rules specialist to do this — quite a bit different than what was stated on the slide, or implied by most of the BR vendors.

Furthermore, during the Q&A at the end of the webinar, Rymer admitted that the “single source of truth” that he referred to earlier in the presentation would be governed by IT, although the content would be developed collaboratively with the business.

I don’t disagree with this: I think that if IT is responsible for care and feeding of a system, they should be responsible for making what are essentially programming changes (albeit through that pretty UI) to a production system. As I mentioned previously, in most cases the business side doesn’t have the systems skills to take responsibility for this — not that they’re stupid, but they’ve developed their skills in other areas that IT is clueless about, such as how the business actually works. The big problems are:

  • How do you distinguish between a change that can be made by the business versus one that must be handed over to IT? The answer to this lies in assessing the potential damage that can be caused by making the change in the absence of regression testing against the existing environment.
  • How do you ensure that when IT must make a change, they make the right change? The answer to this lies in communications and signoff procedures between the business and IT, particularly in making sure that they are using the same language and that the change requests are in writing.

And now we’re putting together two types of systems — BPM and BR — that both state (seemingly erroneously) that business users/analysts can make changes during production. Yeah, right.

After more than 15 years of working with BPM vendors who were passing around the same Kool-Aid, the BR vendors should take a lesson from what you lose by overstating ease of use, and provide some realistic guidelines for exactly what who’s going to do what in a real BR production environment.

BPM and compliance

I happened across this article on how Sarbanes-Oxley is a “business blessing in disguise” since it can show you where your organization’s weak points lie, so that presumably you can fix them. Although it’s primarily discussing ERP systems, this same concept (business improvement/competitive advantage through compliance) is an area that I’m addressing for a client right now by looking at how BPM fits into the compliance big picture. That has me thinking about all sorts of things: BPM, business intelligence, business rules, performance management, compliance, and how they all fit together. You can be sure that there will be more on this in the future.

BPM and BR: Mars and Venus again

As I mentioned in this post, there’s a bit of Mars and Venus about BPM and business rules (BR).

I’ve viewed two BPM-BR webinars recently. The first, a replay from back in March on the convergence of BPM and business rules; since I’ve been writing a lot about this topic lately, I gave it a quick browse. It’s hosted by BPM Institute; there are a lot of other webinars (“round tables”) on BPM-related topics on their site, both past ones that you can replay or future ones that you can sign up to attend live. The speakers in this webinar were from Knowledge Partners and Pegasystems, both heavily into business rules: Knowledge Partners is a business rules consultancy that also does some training and software extensions that integrate business rules with other platforms such as RUP, and Pegasystems is a BPM vendor whose product is built on a rules engine.

You’d have to have your head in the sand not to notice the importance of business rules in BPM, but if you’re still having trouble convincing anyone, then this webinar might give you a few pointers about why it’s so important. From a business standpoint, the two key drivers for having BR in your BPM are agility and compliance: the rules that define your business must be flexible and extensible (agile), as well as explicit and measurable (compliant). To have these rules explicitly defined and managed by the business community, separate from the logic in the BPMS, goes directly to the issues of agility and compliance. The speaker from KPI made the point that your business is already running by these rules, whether you know it or not, and by collecting them into a BRE, you’ve made a step towards getting control of your rules and procedures (and therefore compliance).

To decide where the interface lies between BPM and BR, take a look at your processes (c’mon, I know that you’ve modelled them already) and highlight the activities that involve decisions and rules, such as scoring. These activities are where you’ll invoke business rules, whether directly in the BPMS (as with Pegasystems) or by calling a third-party rules engine. These rules should be directly tied to business motivations/key performance indicators. Then, walk up KPI’s pyramid:

[As a side note, I especially like the second step in the pyramid: “understand which rules are worth managing formally, and why”. Organizations typically get locked into the old way of doing things not because things are done in a certain way, but because no one understands why something is done that particular way.]

The KPI speaker pointed out that there are often different groups within an organization who are looking at BPM and BRE, with one from the business side and the other from the IT side. She mentioned the scenario of BPM being driven by business and BRE by IT, but I’ve seen it the opposite way around recently with a large insurance company client. In fact, I think that most people who even think about this see BPM as still “belonging” to IT, whereas BR “belongs” to the business. I could write a large tome on why they both belong to the business, but that’s for another day.

Yesterday’s live webinar was by TIBCO on increasing your BPM ROI by incorporating BR; there’s a registration form on the TIBCO site that I assume takes you to a replay of the event. The main speaker was John Rymer from Forrester, and he gave a good overview of how BR improves BPM. From his presentation:

  • Speedy, accurate business decisions and actions
  • Common expressions of policy, practices, other logic can be evolved in business time
  • Single source of truth for core business rules aids compliance reporting
  • Automation of conditional steps in flows and conditional calculations improves agility
  • Business analysts can make adaptations and change

He showed how these factors related to hard ROI in this chart:

This is not different from the KPI/Pegasystems webinar mentioned above; it all comes back to agility (by allowing changes to rules without changing the process flow, which is somehow seen as less agile) and compliance (through standardization and documentation).

Rymer sees three different BPM-BR implementation scenarios: the decisions are embedded within the BPM flow; the BPM is rules-based (like Pegasystems); or the BPM “calls out” to a general-purpose rules engine. There is a fourth scenario, which I have seen used (and have myself implemented) extensively, which is that the rules logic is resident in another system, sometimes a legacy system, and the BPMS integrates with that system in some way to execute rules. This is a broader definition of “call out” that includes his third scenario, and I’ve seen it often in insurance implementations where underwriting or claims rules are already implemented on a legacy system and just need to be called at a point in the flow.

Since TIBCO hosted this webinar, they found an analyst who speaks very well of the idea of having a BRE embedded within your BPMS; I don’t disagree with this, but I can also see the advantage of having the BRE as a foundation of the BPMS, as with Pegasystems, or even using a third-party external BRE that may also be in use for other rules applications within your organization. It works any of these ways; the important thing is to have a BRE in there somewhere.

No matter how it’s implemented, I imagine that some BPM advocates may see the integration of BR as somehow demoting the importance of BPM: for years, the BPMS vendors have been building increasingly advanced decision-making capabilities into their products, and now the BPMS will just be used to route work and call the BRE when instructed. My advice: get over it. Sure, you’re going to build much less complex decision-making directly in the BPMS once you integrate a BRE, but you’re going to get so much more in return.

BPM and Business Rules

Still catching up on some webinars that I missed, here’s one from June 30th about BPM and Business Rule Management Systems (BRMS). It’s hosted by Peter Carter of ILOG, and although he’s not the most dynamic speaker that I have heard, there’s some interesting content on the slides for those of you who might be working through the relationship between BPM and business rules:

  • BPMS focus on how people and systems interact
  • BRMS focus on how decisions are made

His point is that BPM can get you to a certain point in process automation, that is, where the only human intervention is for decision-making; BRMS can take you further to automated decision-making so that the only human intervention is for exception-handling. Of course, you can embed rules within a process map in any of the BPMS that I’ve ever worked with, but the rules are typically not explicit and may have to be replicated at a number of points in the process map, depending on the capabilities of the BPMS: most of the systems are really not built for explicit rules management. And, although all the BPMS vendors claim that it’s easy to have a business analyst change the process map at any time, in reality I’ve never seen an organization that would allow that to happen without (justifiable) layers of technical review and testing to ensure that the new process logic doesn’t break something. As I mentioned in this post, you’re pretty unlikely to find someone within the business part of an organization that is sufficiently trained/experienced in systems thinking to be able to make what are essentially programming changes, even if they are using a pretty graphical interface.

Business rules typically interact with a BPMS at a specific point in process, usually to generate a value and/or determine the next action to take based on the current parameters (e.g., pricing, eligibility determination, scoring, case assignment, data validation). That makes it a lot easier, and a lot less dangerous, to allow a business analyst to modify business rules without an undue amount of IT involvement: since the process map is not changed, there is no danger of work becoming orphaned or misdirected through a business rule change as long as the process map was properly designed in the first place.

This is why all industrial-strength BPMS are either OEM’ing a business rules engine into their product these days, or integrating tightly with one: you can’t swing an analyst’s report these days without hitting some new BPMS/BRMS alliance. ILOG’s certainly a driving force here, with alliances with Siebel, FileNet, Oracle, IBM, BEA, Fuego and a host of other major players. There’s one major exception to this alliance trend: Pegasystems’ BPM Suite is natively built on a rules engine, which has given them a leg up on the process+rules craze.

Going back to Mr. Carter’s presentation for a moment, I also like the way that he defines business rules from both a business and IT perspective:

  • From the business perspective, business rules are “formal statements of business policy that define or constrain some aspect of the business”
  • From the IT perspective, business rules are “business logic to be implemented in one or more business applications”

Too often the definition is made from only one of these two perspectives and, like Mars and Venus, someone doesn’t fully understand what was said.

If you want your business rules integrated with your processes, you’re going to have to figure out how your BPM tool and rules engine will integrate, then pull your rules out of the paper procedure manuals, mainframe applications, spreadsheets and all the other places where they live, and get them into that BRMS. Easier said than done, but rest assured that rules engines are here to stay in the world of BPM.