BPM Think Tank Day 1: BPDM

I’m in Fred Cummins’ BPDM workshop, where his stated goal is to provide a general understanding of BPDM, engage us in a discussion of the requirements, and discuss the implications of BPDM to enterprise agility. Fred’s an EDS fellow who writes occasionally on the EDS Next Big Thing blog.

BPMN and BPDM are both standards that are designed for use by business people, with the inclusion of non-automated as well as automated business processes, and they are both business models as opposed to execution models (like BPEL, WS-CDL or proprietary vendor execution models). BPMN is a standard for the graphical representation of a business process, whereas BPDM is the XML file format in which such a representation can be stored: hence, a tool might display a business process as BPMN and save it as BPDM (which makes BPDM competitive with XPDL from WfMC, which I previously discussed as a file format for BPMN, although Cummins later stated that the scope and goals of BPDM exceed those of XPDL).

We had a lengthy discussion about the relationship between choreography (a collaboration between multiple participants) and a business process/orchestration (how one of the participants manages their view of the interaction): the roles typically map directly between processes and choreography, whereas only the steps in a process that involve interaction with another one of the participants will appear in the choreography. BPDM is intended to capture both orchestration and choreography information, although there was some discussion about whether BPMN has all the graphical representation for everything needed for choreography. It does include the concept of pools (like swimlanes, but representing different organizations, not different functions within an organization) and can collapse a pool so that it is effectively a black box, so I think that it has most or all of what’s required for representing inter-organization choreography. An organization only needs to map the other parties in a choreography as a black box (i.e., a collapsed pool), whereas it will map it’s own internal activities fully within swimlanes in its own pool.

Cummins then moved on to the hot topic of BPM and SOA, with the following definitions/relations:

  • BPM: Business processes are the orderly execution of activities that achieve defined objectives.
  • SOA: Services offer capabilities that can be used in a variety of contexts.
  • Business processes may use services to achieve their objectives.
  • Services implemented with explicit business processes can be more quickly adapted to business changes.

Personally, I find that list a bit circular, and I think that his “definition” of SOA is actually a definition of services — maybe a bit of a fine point. He made a vague point about how processes and services provide different levels of granularity of agility, then came back to make two statements about agility:

  • Primary impact of business changes is on the business processes and organizational structure.
  • The actual work (concrete services) and data of the business tend to stay the same.

I posit that business processes can change in response to changing business because they’ve been implemented using BPM tools that enable this agility, and services tend to stay the same because they haven’t been architected to allow for change. Possibly Cummins’ views are a reflection more of EDS’ client base and their own practices than what’s really possible in terms of agility. Of course, there’s also the view that published services need to stay the same (or at least their external interface) since the publisher may be unaware of all the uses of the service and doesn’t want to risk breaking it, but that doesn’t mean that a service shouldn’t undergo internal optimization or an extension of its functionality as long as it can be easily changed to adapt to changing business requirements.

There’s a lengthy discussion going on now about the difference between defining a meta-process and defining a paradigm, which is getting just a bit too esoteric for my taste (the accusation “you’re being too rigorous!” was just flung around the room), but does remind me that OMG is a standards organization and this is exactly why I prefer implementation to theory, in general… (several minutes elapse)

Cummins finished up with some things that are being considered for BPDM but are still unresolved, such as the integration of business rules (and presumably a BRE) into a business process model, and the integration with strategic planning that’s necessary to make business process modelling a fully participating activity in enterprise architecture.

At the end of it all, this workshop had a lot less to do with BPDM than I wished that it had, and a lot more about some particular views on SOA and business agility that didn’t really have anything to do with BPDM. I understand that BPDM is still a work in progress, but it would have been nice if the artists had unveiled the canvas for us to take a preliminary peek.

Jeanne Baker, who sat in on the session, pointed out that this think tank is for all standards groups, and that last year’s think tank resulted in the merging of BPMI into OMG due to the overlapping scope of BPMN and UML activity diagrams. Maybe the next move is to bring together XPDL and BPDM instead of indulging in an unwanted standards war for business process metamodels.

James Taylor blogging on ebizQ

I really hate that the bloggers that I read daily are making me work by changing my RSS feeds 🙂

James Taylor, who I have referenced in posts about business rules, is now blogging on ebizQ, although it’s not clear if he also intends to keep his old blog going as well. Personally, I have trouble enough keeping up with writing one business blog, and my wine blogging has suffered for it lately.

Business-IT collaboration in rules and process

A great post by James Taylor on business and IT collaboration as it applies to business rules:

This might lead one to suppose that business users should just be given tools that let them right the rules themselves in some unconstrained way. Like the healthcare folks I was talking with, I don’t think so. The reality is that the rules must be deployed in a real system with performance and scalability needs. The rules must execute against data stored and managed in other information systems. Business users are not as used to the discipline of QA and testing that most organizations would want to see before new rules are rolled out.

He goes on to discuss how to create the right environment for business and IT to collaborate on business rules management.

Now, just take his post and replace the word “rules” with “process”, and you’ve made my case as well.

James Taylor reporting from Gartner BI

James Taylor‘s been at the Gartner Business Intelligence Summit this week. On Monday, he posted some great thoughts on process, rules, BI and agility:

You can use business rules to automate decisions in business processes and then use analytics to optimize these decisions and hence the processes…

You must be able to change a process that you are monitoring when your monitoring tells you that something is wrong. Real-time measurement should not be combined with systems that take weeks or months to change.

Although there are caveats to that last sentence — for example, some real-time measurement is intended to allow the human elements in a process to change rather than the system, such as work re-allocation — I’d still like to have it tattooed on my forehead for every client to read. Making measurements with the intention of enabling agility is useless in many of the BPM installations today, not because the underlying BPMS isn’t agile, but because the customer chooses (or is coerced) to undertake a huge degree of customization that effectively pours concrete over the system.

Then later that day, he posts more on how BPM, BRE and analytics go together like chocolate and peanut butter (that’s my characterization, but I’m sure James would agree) — that seems to be a popular theme at the summit. He also posts about the Tuesday and Wednesday sessions, although less BPM-related than the Monday sessions.

Maybe because I come from the BPM side of the house, I don’t really see why the big fuss to rename parts of the BI space: BI seems to be an outdated term now, referring only to reporting on historical information from a data warehouse or operational data store. Other terms like CPM (corporate performance management), BAM (business activity monitoring), CEP (complex event processing) and EDM (enterprise decision management, which also involves BRE) have sprung up to cover the near-real-time space that I still think of as BI — after all, there’s much of the data aggregation, analytics and other common technology at the core. Many of these newer terms are touted as “[something more fabulous] BI”, such as James’ reference to EDM as “deployable BI”, but it feels a bit like the emperor’s new clothes. Maybe they’re all just BI 2.0.

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.

Business rules out of the trough

Jim Sinur, who is THE name in BPM at Gartner, has a recent article about business rules. He believes that BRE is finally out of the trough of disillusionment (a part of the Gartner “hype cycle”, and not a good part as you might guess by the name) and finally has the functionality and ease of use for mainstream usage:

Today’s rule technologies run well on all mainstream technology platforms and are being included in hybrid business and infrastructure solutions running in high-volume situations. Because of this change, a number of technology sectors are embracing and embedding rule technology, including Business Process Management (BPM), application integration, simulation, and Business Activity Monitoring (BAM).

He goes through 12 reasons to embrace rules technology (the BRE 12-step program, if you like), split across beginner, intermediate and advanced uses of BRE. Pretty much everything that you would ever need to convince your organization to take a good look at BRE is there, ranging from agility to cost savings to understanding the business to complex problem-solving to dynamic policy compliance.

BRE is definitely a boon to business agility if it’s used properly and control is (at least partially) in the hands of the business. As I’ve pointed out in the past, however, acceptance is still a bit of an uphill battle in spite of the obvious benefits. In particular, I consider BRE to be essential as a component of (or tightly integrated with) BPM in order to handle the necessary complexity, to allow sharing of rules across applications, and most importantly because it enables changing in-flight processes. Having BRE in your BPM also helps with your compliance initiatives as well as agility. Remember that BPM focuses on how people and systems interact, whereas BRE focuses on how decisions are made, and you really need both in order to build good process management.

By the way, I welcome any comments from the business rules experts (which I’m not) on the proper acronym for business rules these days: BRE? BRM? BRMS? Help me out!

Gartner disses tactical BPM

In the findings from their Insurance Industry research meeting published this week, Gartner states the bleeding obvious:

Tactical BPM Approaches Will Cause Rule Management Nightmares for Healthcare Payers

It’s been pretty obvious for some time that BPM should not be a tactical, departmental decision, regardless of your industry. I’ve been working in this industry long enough to remember when BPM (workflow or EAI, before the Grand Consolidation) was sold as an application. Then, it was sold as a toolset. Then (again), it was sold as an application. Now it’s being sold as infrastructure, and I think the vendors finally have it right.

As soon as you start looking at your business processes, you’ll find something in your organization that could be helped out by the functionality provided by a BPMS: automation of manual steps, orchestration across disparate systems, process governance, whatever hits the hot buttons. And what you’ll find in almost all cases is that the actual business processes span several business departments, although the systems that support them don’t, leading to a lot of manual processes handling the interfaces between departments. So although you could make a tactical decision to buy a BPMS just for a specific business department’s urgent needs, if you don’t consider where the tendrils of that process reach, then you’ll still be stuck with those manual handoffs to areas outside the core of the process. The only path to a solution is to have BPM as part of the enterprise-wide infrastructure that supports all business departments, so that your business processes can extend their reach across the organization (and beyond) in the most effective way possible.

The same goes for business rules, which is part of what Gartner is saying: although they state that rules need to be integrated across applications and multiple rule engines, I’d go a step further and say that a common business rules engine (BRE, or BRMS) needs to be part of the enterprise-wide infrastructure as well. It’s critical that different departments have access to the same business rules: the same rule might be applied at a step in a back-office process, by call centre staff during a customer call, and by auditors when creating compliance documentation. The same rules need to be universally accessible by applications throughout the organization, without the propagation delay or lack of synchronization that could be caused by using multiple BRE.

Your business processes and business rules reach across your entire business. Your BPMS and BRE have to do the same.

Business (rule) analysis

I received the call for papers for the 9th International Business Rules Forum, which has prompted me to browse through the other business rule-related tidbits that I’ve been viewing over the past few weeks. If you’ve been reading Column 2 for a while, you already know that I think that business rules are a crucial feature in BPM, whether the BPM contains them inherently or as an add-on: you can find some of my previous posts on BPM and business rules here, here, here and here.

Rolando Hernandez recently posted a short term outlook for business rules — in short, that BR provide huge competitive advantage through business agility — plus an opinion on the differences between a business analyst and a business rules analyst.

The business rules analyst is focused on separating rules from code. The rule analyst walks and talks business… The rule analyst talks about business rules and business logic. The rule analyst means business.

The business analyst sees rules as code. The business analyst talks about the system. A business analyst is often a systems analyst by nature, and by training… The systems analyst means code.

I don’t think that there is a big difference in the inherent skills of business analysts and business rules analysts; rather, I think that systems analysts need to stop foisting themselves off as business analysts. Rolando starts a paragraph describing the business analyst (“the business analyst sees rules as code“), segues through an assumption (“a business analyst is often a systems analyst by nature, and by training“) and by the end of the paragraph is referring to the systems analyst rather than the business analyst, as if there were no difference. Yes, this happens, but it’s unfair to paint all business analysts with the same brush.

I also see the opposite problem, where a business user is designated as a business analyst, even though he (or she) has no skills or training in analysis; since he’s not trained to write requirements that are both necessary and sufficient, the resulting solution will not do what the business needs it to do. Furthermore, since he’s probably not up on the latest in associated technology areas, he’s unlikely to think outside the box because he doesn’t even know that the box exists.

The trick is to meet somewhere in the middle: a business analyst or business rules analyst needs to be focussed on the business, but be aware of the capabilities and limitations of the technology. The first job of the business (rule) analyst is to determine the business requirements, not write a functional specification for how the system might behave, as I’ve posted in the past. A business analyst needs training in the business area under study, but also needs training and experience in gathering requirements, analyzing business functions, optimizing business processes and documenting requirements, plus a high-level understanding of the functionality (not the technology) of any systems that might be brought to bear on a solution.

Changing business models = changing business processes

I read this post by Alex Osterwalder on the external forces that impact an organization’s business model — technological change, competitive forces, customer demand, social environment, and legal environment — which in turn has me thinking about how these business model changes impact business processes.

This is precisely why I look at issues of enterprise architecture and BPM together, even when a client has specifically engaged me for a BPM initiative. In a perfect world, the following occurs:

  1. A business model changes based on internal or external factors
  2. One or more business processes have to change to respond to the changing business model
  3. The business processes are implemented using a BPMS
  4. EA provides the linkages between the business model and the information systems (including the BPMS) so that the right changes can be made to the process in order to respond to the changing business model

Unfortunately, there’s a lot of roadblocks to establishing what I feel is a fairly obvious requirement for remaining competitive in the face of changing business models:

  • Impact analysis: many organizations don’t document their business models (by this, I mean their high-level company business models, not their departmental business processes and procedures), or don’t make adequate links from their “strategic planning” sessions to all the layers below that have to implement those models and plans. Because of this, there is no clear link between the change to a business model, the change to an underlying business process, and the change to the supporting information systems.
  • Automation: many organizations are still using manual processes and decision-making for well-understood business processes. For example, some insurance companies process all of their claims manually; others have greatly improved productivity by using automated adjudication systems that pass only the more complex claims to a human claims adjudicator. Although the former may understand that a BPMS can help their business, they see it primarily as a way of paving the cowpaths so as to provide faster movement of information between the same old human decision-making processes, rather than a tool for automating some of the steps and — with the addition of business rules — removing some of the human decision-making.
  • Agility: some organizations that implement a BPMS end up with automated business processes that are frozen in time due to an excessive amount of customization around the implementation. Although they’ve achieved automation (albeit, optimized for a point in time usually about a year prior to implementation), they’ve completely lost agility due to the complexity of changing the BPMS by creating a legacy business process.

These issues, which I often uncover during a client assignment, require more than just a few tweaks to their BPMS: they require that both EA and business rules be brought into consideration in order to provide the business agility that the client is expecting.

To begin with, EA can help to create the necessary models and the linkages between the layers to allow the impact of a business model change to be reflected in the business processes and the supporting information systems. If you can’t do impact analysis, then you don’t have any type of reliable business agility since you won’t understand all of the impacts that a change to any part of the organization might have on other parts.

BRMS are an essential facilitator to business agility. First, because they put the business rules in the hands of the business (or at least in a form that’s understood by the business), so that there’s much less latency in the process of changing business rules. Secondly, if a shared repository of business rules is implemented across the organization, then a change to a business rule can be immediately be reflected in every process and system that accesses it, from the next call handled by a call centre operator accessing a CRM, to work in progress in a BPMS.

Of course, I see BPMS as a given for business agility: it lets you automate business processes while still involving human intelligence at the points required in the process; integrate business rules for decision-making; and more easily make changes to the business process with less user retraining. There are good and bad ways to implement a BPMS (as with any system), and care must be taken to integrate other tools (such as BRMS or BI) where appropriate, rather than go down the path of excessive customization which can hinder agility.

The bottom line is that although a BPMS can be a huge contributor to business agility, it can’t do it alone: you need some amount of EA in order to understand what you’re supposed to be doing with that BPMS (that’s the business-IT alignment that everyone talks about), and you need some other tools like BRMS to keep things agile through a minimum of customization.

When rules rule

Rolando of the BIZRULES blog shared his thoughts on the recent International Business Rules Forum: a major shift being that people are no longer asking what they should do with BR, but are asking what else they can do with BR. He also references an Intelligent Enterprise article on balancing the control of business rules between business and IT.

I’m finding BR to be a bit of an uphill battle with many of my clients, in spite of the clear benefits of integrating a BRE with BPM to provide more business control over processes. Some BPM vendors, such as Pegasystems, are built on a BRE so that functionality is there from the start; most others, however, have recently built integration to one or more BRE’s to provide equivalent functionality. In either case, the ability to execute a business-controllled rule at a point in a process makes a lot of sense for both business and technology reasons: in-flight rules changes (typically not possible if you define the rules directly in a BPM vendor’s process definition logic); increased control by the business over the business rules; more robust decisioning features; decoupling of complex and changeable business logic from the process execution engine; and the ability to reuse the same business rules in other systems unrelated to BPM, such as CRM.

The concept of business rules isn’t new, but in my practice (focused on financial services and insurance), I see it primarily in insurance underwriting. Given the rules-driven nature of financial businesses in general, there’s a lot more out there that could beneft from business rules, with or without BPM.