BPMI and OMG merge BPM interests

A press release from BPMI and OMG announced recently that they’re merging their BPM standards activities:

The combined activities will continue BPMI’s and OMG’s ground-breaking work and focus on all aspects of Business Process Management, including:

  • Refinement and promotion of BPMI’s Business Process Modeling Notation (BPMN) as the basis for business modeling,
  • Delivery of BPMI’s Business Process Definition Metamodel (BPDM), Business language, vocabulary, and rules,
  • BIM (Business Information Management),
  • EAI (Enterprise Application Integration),
  • B2B (Business to Business collaboration),
  • Web Services Information and Processes,
  • Security Policy and Management, and
  • Refinement, promotion and education of the principles, approaches and tenets of Business Process Management within the broader business community.

OMG will continue its tradition of innovation by integrating and reusing complementary business integration and web services standards such as WS-BPEL from OASIS, WSDL and XML Schema from W3C.

BPM standards just became one degree less confusing.

Process Orchestration 101

Today’s Integration 101 webinar talked about why it’s important to integrate applications. Basically, if you don’t, then you probably have the following problems in your business processes:

  • No real-time visibility into the process
  • Long cycle time due to manual data gathering and other non-automated tasks

In other words, your customer drops their information into a black hole and nothing happens for a long time, so there is a higher risk that they take their business elsewhere. Not only is the process inefficient (and therefore costs you more to operate), but it results in lost revenue.

When you use BPM for your large scale processes where several internal and external applications are integrated, you’re moving into the area of process orchestration: the BPMS is invoking, controlling and tracking what goes on in all of the applications. Add in a business rules engine to automate decision-making in the process, and BAM to publish a real-time view of what’s going on, and not only are things more efficient due to fewer manual steps in the process, but your customer can see what’s going on at each step of the process.

Realistically, the only way to do this level of enterprise application integration such that it’s maintainable, flexible, extensible and reusable, is to use a service oriented architecture to expose the applications’ functionality as services to be called by the BPMS. Otherwise, you’ll be right back in a spaghetti mess with the same (or competing) business logic embedded in multiple applications.

Enabling the Agile Enterprise

An interesting post on Rambling Thoughts about enabling the agile enterprise, particularly the benefits:

Through improved, more accurate, and timely reporting mechanisms an agile enterprise will be able to perceive the potential impact of events quicker. Alternate strategies can be rapidly assessed as relevant data will be more easily accessed. Agile enterprises can then react by implementing the required operational processes and IT systems with equal speed and ease. This will allow the results to be realized sooner and with less reduction in enterprise performance.

However, I disagree with his statement that “In contrast to pure workflow tools, that simply model existing business processes, BPM tools provide an execution environment for these workflows.” We’ve been executing business processes for many years with “workflow” tools; maybe he’s thinking of business modelling tools? He exhibits a bit of confusion about the definitions of workflow, BPM and EAI, but then considering the state of the marketplace, that’s not unusual.

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.

Blogroll, revisited

I was cruising blogs today and noticed a few people using Bloglines for their blogroll, so decided to do the same as “Blogroll” in the sidebar (the “Other Links” section following that is for non-blog links, created using Blogrolling). I like using Bloglines for linking to blogs because it keeps up to date with what I’m actually reading on blogs, and it uses the folders within Bloglines to create subheadings on the list. Right now, I have exposed my folders on BPM-EA-BI and Other IT, which are the only ones that are remotely related to what I blog about.

Integration 101 webinar

If you’re new to the world of integration, EAI, SOA and all those other good things, you can tune into the ebizQ webinar Integration 101 – From Application Integration to SOA on Tuesday at noon Eastern:

In this webinar, Roy Schulte, Vice President and Research Fellow in Gartner Inc., joins Lance Hill, webMethods Vice President Solutions Marketing, to make some sense of all the acronyms (BAM, BPM, SOA, EDA, CEP) and to describe at a fundamental level the different integration technologies that can be leveraged to integrate and enhance business systems and processes.

Roy Schulte is pretty smart about these technologies, and webMethods has just won the ebizQ EAI Buyer’s Choice award. Should be an interesting discussion.

More small business networking

I posted back in April about how I had started to use LinkedIn, and since then I’ve been actively working at building and using my LinkedIn professional network. I regularly review my connections to see if there is anyone who I should be following up with, and I sometimes browse my connections’ connections to see if there is anyone that I should be networking with. I started following that trail tonight, and a couple of hours later, here I am at 1:30am still poking around.

Christian Mayaud, a second-degree connection who has almost 8,000 connections of his own, lists his Sacred Cow Dung blog in his LinkedIn profile, on which I found his “Cheaters’ Guide to LinkedIn” (most of which I don’t see as “cheating” but as best practices for making the most of the network). That pointed me to two Yahoo! groups, MyLinkedinPowerForum and LinkedInnovators, which in turn contain a ton of other information about using LinkedIn for professional networking (plus a lot of the usual crap). Just when I was almost caught up on my reading…

Update: I saw this link this morning that describes to newbies how to get started with LinkedIn without being overwhelmed. I think that I’ll send it to all those people who accepted my invitation but still only have one contact (me) a month later.