At this point, it makes more sense to start labelling the posts by session title rather than presenter, since we're getting into some pretty detailed breakout topics. This one was presented by Roger King, Director of BPM Product Strategy & Management at TIBCO, and Justin Brunt, product manager for iProcess.

Most of the technical people working TIBCO's BPM group seem to be vestiges of the Staffware acquisition; many of them are still based in the UK, where the development is still done.

They started out with a review of what's happened in the products in the past 12 months:

• Business Studio 1.x, a standalone modelling and simulation product aimed at business analysts; the free downloadable version released in November already has more than 10,000 downloads. Modelling is done in BPMN, and XPDL is supported for import and export -- necessary for even getting the models into the iProcess Suite for execution, since there is no shared model with the process execution environment. It also supports imports from Visio and ARIS. There's some more advanced features as well: a hierarchical organization of business processes and associated assets; and process simulation with SLA indicators and reports.
• iProcess Suite 10.5, with improved work queue performance and scalability to support more concurrent users, better performance for sorting and filtering (always slow with most BPM products) and faster startup time. It also included an enhanced web client based on General Interface, with GI or custom forms support and a number of other new functions.
• iProcess Insight 2.0, the BAM product, which I reviewed in a post yesterday.

What's coming in the near future:

• Business Studio 2.0, with support for the full BPMN 1.0 specification and XPDL 2.0. I keep meaning to download Business Studio and do some comparative analysis with some of the other downloadable modelling products, but I may wait until version 2.0. I wrote about a few of the new features from Tim Stephenson talk yesterday, but here's a recap. In the process analyst perspective: design patterns/fragments to speed design, refactoring, concept modelling with UML support, import/export of EPC/FAD from ARIS, and custom XSLT translations to XPDL. In the process architect perspective: service registry, native services such as email and database connectors, direct server deployment and version control
• iProcess Suite core component support for some new platforms, including 64-bit Windows Server and Red Hat Linux; direct deployment from Studio to Engine (although it's not clear if this is via a shared model or just automates the import/export process); and new audit trail entries. They've also simplified installation.
• Web services capability, with support for WS security at the transport and SOAP layer, and support for withdraw actions and delayed release.

They went on to discuss a number of key themes in product development for this year and beyond.

They're gradually migrating to a single modelling/design environment -- Business Studio -- although they're still not quite there yet; this will provide a more consistent experience for both business and IT users of the design tools. This supports the move to full model-driven development by allowing for the easy integration of forms design into the Eclipse-based environment, which can in turn generate GI, JSP or other runtime forms for the updated iProcess web client. Business rules definition will be in the Eclipse-based design environment, although it's not clear if they're using a third-party BRE or have their own rules technology. The old modelling environment, Business Modeler, isn't going away any time soon, but new feature development will focus on Business Studio so will encourage migration. Like most vendors using this tactic to get existing customers off an old product, I expect that they'll hear grumbling about this for years.

The out-of-the-box web client will be simplified and made to look more like the familiar Outlook client, with improved performance. The UI will also be exposed as components and services to allow them to be included in custom applications or portals, and they'll ship an out-of-the-box BPM portal using TIBCO's portal platform to show how this can be used. There will be better MS-Office integration and an Eclipse-based desktop application.

They're also going to provide a project collaboration portal for BPM projects, to allow people developing TIBCO BPM applications to collaborate. They're also adding in some governance capabilities to help handle the lifecycle of BPM projects and assets.

King mentioned my presentation from yesterday directly, and commented that they're going to be supporting more of the BPA tools for import soon, including Proforma. They've obviously identified that it's important to be extremely open from both a standards and BPA support standpoint.

Next on the list is goal-driven BPM, or virtual processes, where there may be too many process alternatives to model explicitly and the optimal runtime process has to be generated based on process parameters and environmental factors. This sounds like fuzzy future stuff, but would be great if they can pull it off.

They're also developing workforce management and more complex resource modelling for the purposes of business optimization.

There was a brief point at the end about preparing for the next generation of SOA, although no time to talk about what this means; I would have loved if this session had been a bit longer.

Posted by Sandy Kemsley at 04:08 PM in BPM • BPM standards • BRE • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

Last in the morning's general session was Tom Laffey, TIBCO's EVP of products and technologies, and Matt Quinn, VP of product management and strategy. Like Ranadivé's talk earlier, they're talking about enterprise virtualization: positioning messaging, for example, as virtualizing the network layer, and BPM as enterprise process virtualization. I'm not completely clear if virtualization is just the current analyst-created buzzword in this context.

Laffey and Quinn tag-teamed quite a bit during the talk, so I won't attribute specific comments to either. TIBCO products cover a much broader spectrum that I do, so I'll focus just on the comments about BPM and SOA.

TIBCO's been doing messaging and ESB for a long time, and some amount of the SOA talk is about incremental feature improvements such as easier use of adapters. Apparently, Quinn made a prediction some months ago that SOA would grow so fast that it would swallow up BPM, so that BPM would just be a subset of SOA. Now, he believes (and most of us from the BPM side agree :) ) that BPM and SOA are separate but extremely synergistic practices/technologies, and both need to developed to a position of strength. To quote Ismael Ghalimi, BPM is SOA’s killer application, and SOA is BPM’s enabling infrastructure, a phrase that I've included in my presentation later today; like Ismael, I see BPM as a key consumer of what's produced via SOA, but they're not the same thing.

They touched on the new release of Business Studio, with its support for BPMN, XPDL and BPEL as well as UML for some types of data modelling. There's some new intelligent workforce management features, and some advanced user interface creation functionality using intelligent forms, which I think ties in with their General Interface AJAX toolkit.

Laffey just defined "mashup" as a browser-based event bus, which is an interesting viewpoint, and likely one that resonates better with this audience than the trendier descriptions.

They discussed other functionality, including business rules management, dynamic virtual information spaces (the ability to tap into a real-time event message stream and extract just what you want), and the analytics that will be added with the acquisition of Spotfire. By the way, we now appear to be calling analytics "business insight", which lets us keep the old BI acronym without the stigma of the business intelligence latency legacy. :)

They finished up with a 2-year roadmap of product releases, which I won't reproduce here because I'd hate to have to embarrass them later, and some discussion of changes to their engineering and product development processes.

Posted by Sandy Kemsley at 01:28 PM in BI • BPEL • BPM • BPMN • BRE • SOA • TUCON | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

I switched streams to the business rules symposium for the last breakout session of the day, The End of Requirements, because the description sounded too good to miss:

Business wants control of the business back. For years we’ve lived with a process where the business creates “requirements” and IT creates a business solution. While business processes are the lifeblood of an organization, rules are where the volume of business changes are. If the business is going to take back control of its own fate it all starts with making sure that the business rules they own are really under their control after they go into production. The current requirements process simply can’t handle that. It’s time to embrace a Business Engineering-based approach and move beyond the requirement-centric approach that we’ve love to hate.

He makes the distinction between knowledge and behaviour: rules is about (reusable) knowledge, and processes are about behaviour. For example, you might have a rule that would allow you to determine if a customer was a "good" customer, and you might use that knowledge in a process to provide a discount. He discussed different views of rules and how they integrate with processes:

• Rules as structural knowledge about business entities
• Rules as business judgements
• Rules that trigger events

Unfortunately, McWhorter didn't ultimately talk about how the business is going to get control of the business rules, or how it's going to work once they do, which is what I was expecting from the session description. He did finish up with a call to arms to bring a design function back into the business side -- sort of like what business analysts are supposed to do, but don't because they don't have any design training -- which would allow proper designs to be created before things are ever passed on to IT.

Posted by Sandy Kemsley at 04:57 PM in BRE • BrainStorm2007 | Permalink | TrackBacks (0) | Add to del.icio.us

There's an awful lot of keynotes in this conference: a couple of overall sessions this morning, now "track keynotes" for each of the four tracks within the BPM conference. I'm in Bruce Silver's New Directions in BPM Tools and Technology session, where he started by taking a gentle poke at Gartner, saying that BPM is more than a management discipline (Gartner's most recent definition of BPM).

He started out discussing process modelling, and how it's inherently a business activity, not an IT activity, which speaks directly to the issue of the tools used for modelling: is there a handoff from a modelling-only tool to an execution environment at the point of business to IT handoff, or is the model actually just a business view of the actual implementation? With all of the vendor demos that I've done lately (I know, I have yet to document many of there here, but I'm getting to it), I've had quite a focus on the distinction between having a model shared between business and IT, and having a separate BPA tool that models much more than just the processes that will be implemented in a BPMS. Bruce positions this as "BPA versus BPMN" views towards describing process modelling, and doesn't see them in conflict; in fact, he thinks that they're ignoring each other, a viewpoint that I'd have to agree with given that BPA initiatives rarely result in any processes being transferred to some sort of execution engine.

Bruce, who often accuses me of being too nice, takes a stab a the vendors in a couple of areas. First is with their BPMN implementations, specifically that of events: he states that many of the execution engines just don't support intermediate events, so that the vendors conveniently forget to include those events in their BPMN modelling tool. Second is with simulation, and looking at whether a vendor's implementation is actually a useful tool, or a "fake" feature that's there to enable it to be checked off on an RFP, but not functional enough to make it worth using.

He has a nice way of categorizing BPMS products: by vendor speciality (e.g., integration, human-centric), by process type/use case (e.g., production workflow) and by business/IT interaction method (collaborative shared model versus handoff). This was interesting, because I wrote almost identical words two days ago in my presentation for the Shared Insights Portals and Collaboration conference that I'll be speaking at next month; great minds must think alike. :)  His point, like the one that I was making in my presentation, is that most BPM products have some strengths and some weaknesses that can make or break some process automation; for example, a product focussed on human-centric workflow probably doesn't do some nice integration tricks like mapping and transformation, or complex data objects.

He also makes a good distinction between business rules (implemented in a BRE) and routing rules (implemented in a BPMS): business rules represent corporate or departmental policies that may need to be shared across business processes, whereas routing rules are the internal logic within a process that's just required to get through the process but don't represent policy in any way.

Bruce thinks that BPM and SOA together is still vapour-ware for the most part: it's what the vendors are selling but not typically what they're delivering. In particular, he thinks that if the BPMS and the ESB are not from the same vendor, then "all bets are off" in terms of whether a BPMS will work with any particular ESB or other services environment.

The session turned out to be too short and Bruce couldn't even finish his materials, much less take questions: it was only 45 minutes to begin with, and shortened at the beginning while Bruce waited for stragglers for the previous session to make their way upstairs.

Posted by Sandy Kemsley at 01:20 PM in BPM • BPM standards • BRE • BrainStorm2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

If you're interested in the Discover business rules presentation that I blogged about from Gartner earlier this week, James Taylor has the slides over here.

Posted by Sandy Kemsley at 01:26 PM in BRE • GartnerBPM2007 | Permalink | TrackBacks (0) | Add to del.icio.us

Jim Sinur hosted a case study panel on scenario-based rules with two presenters: David Luce at UTi (a logistics outsourcing firm) and Husayn Alvarez-Gomariz at Micron (a semiconductor manufacturer).

Luce started out talking about UTi, and how as a logistics provider, they are actually a business process outsourcer. They pride themselves on customer intimacy, but that drives up their operational costs since there are so many manual, special-case processes. They were looking for ways to maintain the same level of customer intimacy while automating processes and rules wherever possible in order to increase efficiency and drive down costs, and what they devised was a rules-driven architecture where they use business rules as a policy validation tool. They've externalized rules from legacy code into a business rules management system, which provides them with the level of agility that they need to provide customized service to their customers while still automating their processes.

Alvarez-Gomariz discussed scenario analysis, and how to use scenarios to provide the agility to respond to changing market events. His talk was both detailed and abstract, not a good combination for holding my attention, although he had some good points about the intersection between BPM, BI and planning.

Like yesterday's panel session, this was really more like two separate 30-minute presentations, with no interaction between the panelists. This format should definitely be changed to something more interactive, or be labelled as consecutive short presentations rather than a panel.

Although it's only lunchtime, this was my last session of the day and of the conference: I'm on a flight back to Toronto in a couple of hours. I didn't blog about the fun at the vendor hospitality suites, but suffice to say that it included Michael Beckley in a very tropical hat (he also hade a "Made in Mexico" sticker on his forehead at one point, but I couldn't verify that statement with his parents), Scott the hotel bartender talking about SOA and Six Sigma, and a vendor ending up in my room for the night.

I hope that you enjoyed my coverage of the conference; I've had a lot of great feedback from people here, and I'll soon catch up with the comments that you've added to my posts in the last couple of days.

Posted by Sandy Kemsley at 02:59 PM in BRE • GartnerBPM2007 | Permalink | TrackBacks (0) | Add to del.icio.us

For the second half of this morning's vendor sessions, I sat in on Fair Isaac's customer presentation, Michele Sprayregen Edelman of Discover Financial Services on Managing Business Rules and Analytics as an Enterprise Asset. As the largest proprietary credit card network in the US with 50 million cardholders and 4 million merchant and cash access locations, they need to have a good handle not just on what their customers are doing, but on how current market trends will change what their customers want to do in the future.

To them, this means using an advanced decision management environment: start with criteria- and rule-based decisions, then automate processes with business rule management, then increase decision precision with predictive analytics, and finally optimize strategies with predictive analytics. They're only a few steps of the way along this route, but are starting to automate decisions in a more sophisticated manner for things such as individual purchase approval/denial, in order to increase revenue and reduce losses.

They wanted a modelling environment that could be done by analysts without requiring IT support, as well as methods for integrating with the transactional systems for automating decisions. They use other decisioning tools besides Fair Isaac's, including SAS, and combine the decisions from all of the systems in order to make the ultimate decisions. When you look at what they've done, even in the simplified diagrams that Edelman showed us, it's hugely complex but provides them with a huge competitive advantage: they're using automated decisioning in a number of different areas across their organization, including portfolio scoring, dispute processing, customer contact strategy and many others.

She presented some final recommendations, the primary one being the importance of the data infrastructure that's going to drive the decisioning.

Posted by Sandy Kemsley at 01:45 PM in BRE • GartnerBPM2007 | Permalink | Comments (1) | TrackBacks (1) | Add to del.icio.us

Jim Sinur took the stage for Are Rules Inside-Out in BPM?, where he claimed that he'd push the envelope in how we thought about rules. He started with how rules are a start, but agility requires a full business rule management strategy so that you can manage the rules that you've externalized, especially if you have multiple business rule engines. Now to be fair, many organizations haven't even externalized their rules yet from their enterprise applications and business processes, but if they ever do, they'd better be ready to manage them or they'll have a big mess of rules to deal with.

Today's business rules landscape is pretty confusing, covering everything from neural nets and expert systems to business rule engines and business rule management systems. If these business rules are too rigid (unchangeable), it impacts the agility of the business processes and the entire organization; if IT has to spend a huge amount of time and money to change rules, then you can be sure that it's not going to happen very often. However, IT is often unwilling to put control of the business rules into the hands of the business; there needs to be a way to have proper governance over changing of rules, but not so much control that it's impossible to keep up with shifting business requirements. In many cases, the business has no idea how difficult it is to change any given rule, and some standardization of this -- via rule externalization and management -- would also improve service levels between business and IT.

The key is to understand where rules affect processes, and see where the ability to change rules for in-flight processes can greatly improve agility. Sinur went through the business benefits of rules, and some of the risks of fixed rules: primarily, business rule management is an enabler for governance. He also walked through different models for adopting rules: the safe and steady control model (slightly smarter process), the cautiously dynamic model (process with above average intelligence), and the aggressively predictive model (Mensa process). Obviously, the model has to suit the organization's risk tolerance as well as the underlying process, since these range from just automating some well-understood decisions to suggesting and implementing new rules based on behaviour within the process.

He has some great recommendations for getting your rules under control, including such thoughts as 15% of the rules are the ones that the business really needs to change to remain agile, so pick the right ones to externalize, and understand both the business benefits and risks associated with changing that rule.

Watch for Gartner's definition of what should be in a BRMS later in 2007, since this is becoming somewhat of a commodity.

Posted by Sandy Kemsley at 07:18 PM in BPM • BRE • GartnerBPM2007 | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Vendor announcements today seem to have a sci-fi theme: first it was IDS Scheer and Microsoft with the Alliance, and now it's Corticon with the Foundation: the Business Rules Foundation, that is. I had a sneak preview last week with David Straus, Corticon's SVP of Marketing, who did the most amazing thing for a guy with the word "marketing" in the title (much less an SVP): about a minute into our phone call, he said "wait, I can show you", fired up Webex, sent me an invitation, and 2 minutes later he was giving me a product demo.

Corticon's Studio product is a pretty capable business rules management system, and one of the 3 or 4 standard systems that ends up integrated into everything else, such as BPM suites that lack their own rules engines. You can define rules in a natural language, then use a decision table to map those rules onto conditions and actions, check for ambiguities and generate unconsidered cases. You can save a set of rules as a compiled service to run within their engine or to be called as a web service. You can even import (or create) test data to run against the rules, with the tests showing which rules were triggered in order to explain the decision. So far, so good: standard functionality with some nice features.

What they've announced today, however, is a version that separates the underlying services from the user interface, and allows those services to be embedded and tightly bound inside another application. The SDK opens up the ability for any application vendor to embed Corticon's rules capabilities within their product without having to use any of Corticon's user interface: they can create their own user interface paradigm for rules definition and integrate this with other parts of their appliation, so that the user is unaware that they are using software from two different vendors. The first big example of this is IDS Scheer's ARIS, which embeds the Corticon Foundation (essentially) inside its ARIS Business Rules Designer: I saw this demonstrated at the IDS Scheer user conference a few weeks ago, but didn't realize what I was seeing (although I knew that it was Corticon within ARIS).

Although the decision tables on the right look very much like the standard Corticon product, it's completely and seamlessly housed within the framework of ARIS: that's the ARIS repository tree view on the left. Since all of the new Corticon Studio is Eclipse-based, and most of the partner companies are using some sort of Eclipse tooling for their UI, this is a relatively painless integration.

There's some other interesting applications for this that Straus mentioned, such as Adobe integration for dynamic document creation (e.g., for contract creation with rules-based selection of clauses), and Microsoft Word integration. With it opening up for development as of the announcement today, I'm sure that there will soon be a number of other application vendors trying it out. I'm waiting for the BPM vendors to start embedding this within their process designers instead of the paltry expression builders that most of them have: this seamless integration of business rules with business processes would eliminate the current barriers to using business rules in a BPM environment.

What Corticon is after, of course, is the Holy Grail of business rules: a common rules repository within an organization that is invoked by any enterprise application requiring a decision (think cross-organization compliance). By making it easier to integrate rules directly into any application, they may be that much closer.

Posted by Sandy Kemsley at 10:20 AM in BRE • GartnerBPM2007 | Permalink | TrackBacks (0) | Add to del.icio.us

The first breakout of day 2, I attended a session on "Optimizing Process Through Business Rules" with Marshal Edgison, Director of Application Development for ELM Resources, a not-for-profit organization focussed on facilitating and processing student loans, about how they're leveraging both the process modeling and business rules modeling functionality of ARIS in order to drive their modernization efforts. The rules engine integrated into ARIS as the ARIS Business Rules Designer is Corticon.

They selected ARIS because they wanted a modelling tool that was not closely associated with the technology (i.e., from the process execution vendors) and could be used by business analysts. As a loan processing organization, their processes are very rules-based, and they found that their business rules were everywhere -- in application code, in database triggers, in user interfaces -- and were hard-coded into the system: the classic situation where business rules can be of enormous benefit. They saw an opportunity to not just model their business processes in order to get them under control, but modelling their business rules and encapsulating them into a business rules management system.

They recognized that BRMS could add agility to processes by automating recurring decisions, centralizing rules for easy management and consistent deployment, manage complex logic (they had over 1 million interdependent rules, although they fall into about 5 basic categories), increase development speed and reduce maintenance time and costs. With the ARIS Business Rules Designer, the rules could be seamlessly integrated into processes as automated decision points: ARIS defines the enterprise data model and vocabulary, and the BRMS leverages that vocabulary in transaction processing.

Edgison went through a case study of a new federally-mandated graduate loan program that came into effect in February 2006, with all participants required to support it by July 2006. Many of the financial institutions who are ELM's member organizations were unable to comply within that timeframe, and it took ELM six months and more than $500K to implement it. As part of the sales cycle for the ARIS Business Rules Designer, they redid this using ARIS and the BRMS: it took one day with four people.

He ended up with some notes on determining whether business rules are right for you:

• Do you have decision-intensive processes?
• Do you have operational inefficiencies around decisions?
• Do you have dynamic, frequently changing rules?
• Do you need better synergy between business requirements and IT implementation?

Although a bit wordy and totally unable to control one the audience member who asked about 12 questions, Edgison was a great speaker: very knowledgeable about both his projects and the importance of business rules in modelling processes, with the ability to communicate his ideas clearly and in a compelling manner.

Posted by Sandy Kemsley at 04:01 PM in ARISProcessWorld2007 • BRE | Permalink | TrackBacks (0) | Add to del.icio.us

Continued from Part 7.

Part 8 (the last): The Current State of BPM. Every analyst, vendor and customer defines BPM differently, because the current definition of BPM is very broad, and there are many vendors jostling for position within it. EAI/ESB-type vendors call their products BPM, but the products may contain only rudimentary human-facing functionality. Workflow-type vendors, also labelling themselves as BPM, lack the necessary infrastructure for integration, and often handle automated steps poorly. Some pure integration products call themselves workflow, just to confuse things further. There’s a lot of complementary products, such as process analytics and simulation, and business rules engines: BPM vendors will either tell you that a particular capability must be part of the base BPM product (if their product has it), or should never be part of the base BPM product (if their product doesn’t have it). And now there’s the whole SOA wild card thrown into the mix.

BPM is definitely a case where the whole is greater than the sum of the parts. It’s not just workflow plus EAI plus B2Bi plus business rules, plus plus plus: it’s the near-seamless integration of all of these tools into a single suite that provides an organization with the ability to do things that they could never do before. That doesn’t mean that all the tools have to be from the same vendor, but it’s essential to deliver all of the BPM functionality in a single environment of closed-loop process improvement.

Smith and Fingar’s book Business Process Management, The Third Wave describes this "third wave" as providing the ability to create a single definition of a business process from which different views of that process can be rendered and new information systems can be built. This allows different people with different skills -- business manager, business analyst, regular old user, programmer -- to view and manipulate the same process in a representation suitable for them and derived from the same source. They make a great analogy with HTML, where a business user may use a high-level tool like FrontPage to view and edit HTML, whereas a developer may edit the HTML code directly, but they’re still working from the same source. Round-tripping between a business analyst's modelling tool and a developer runtime environment is one way to do this, although it violates the "same source" in the purest sense, but we definitely have to get rid of the strictly one-way paths from business analysis to implementation that exist now in many organizations.

Furthermore, Smith and Fingar point out that in the world of BPM, the ability to change is far more prized than the ability to create in the first place, and that BPM has the potential to actually remove application development from the cycle -- the "zero code" Holy Grail that gets a lot of press these days. They make an analogy with VisiCalc, which took customized data analysis out of the hands of the IT department and put it in the hands of the business users, thereby taking software development off the critical path for achieving results.

Getting back to the point of this post, what is the current state of BPM?

First of all, we have several companies from the pure-play BPM/BPM suites market: they provide excellent human-facing BPM and at least adequate integration capabilities, with some providing outstanding integration. At the Gartner BPM summit earlier this year, they listed three "major players" in this category who had revenues upwards of $100M -- FileNet, Pegasystems and Global 360 -- and five "up and comers" with revenues above $30M -- Appian, Lombardi, Savvion, Metastorm and Ultimus -- while ignoring anything smaller than that. All eight of these vendors hit into the right zones in the Gartner and Forrester charts, which means that they either have the necessary functionality or are partnered with someone to provide it.

Second, we have a couple of integration-focussed BPM vendors who have purchased pure-play BPM vendors to create the complete range of functionality. The two highest-profile examples are the TIBCO acquisition of Staffware in 2004, and the BEA acquisition of Fuego earlier this year. In both cases, there seems to be a reasonable fit, but my concern is that the human-facing BPM side is going to become weaker since the main focus of these companies is on integration.

Third, we have the large software companies that have developed (or acquired) a BPM product: IBM, Microsoft and Fujitsu all spring to mind. In many cases, such as IBM and Microsoft, their BPM products are primiarly integration-focussed without a lot of human-facing support, and likely started as a "would you like fries with that" sort of offering for customers who were already committed to their architecture. IBM's MQ Series messaging is probably still the most commonly used piece of integration middleware in financial services, although I think that they call it (and everything else) "WebSphere" these days, and IBM rightly has it as a cornerstone of their BPM strategy. Fujitsu is the odd one out here, with what appears to be a fully-functional BPMS; unfortunately, they've been marketing it in stealth mode and most people are completely unaware of it: as I said in one of my posts about the Gartner BPM summit, "who knew that Fujitsu did BPM?"

We'll continue to see most of the business functionality envelope being pushed by the vendors in the first category as they seek better ways to integrate business rules, analytics, performance management and other capabilities into BPM; in fact, the most innovation seems to be coming from the smaller vendors in this category because of the lack of baggage that I discussed in part 7.

Because of the current focus on process improvement in all organizations, I don't think that there's any great risk of any of the vendors that I've listed here going out of the BPM business any time soon. However, the integration vendors will acquire some of the smaller BPM suite vendors to round out their portfolios, and the large software companies will acquire some of everything, in a continuing Darwinian cycle.

Before you vendors start adding self-promoting comments to this post, keep in mind that this is not intended to be a comprehensive list or review of BPMS vendors, and I know that you're all very special in your own way. :)

Posted by Sandy Kemsley at 02:00 PM in BPM • BPMhistory • BRE • ESB | Permalink | Comments (3) | TrackBacks (1) | Add to del.icio.us

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.

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.

Posted by Sandy Kemsley at 03:30 PM in BPEL • BPM • BPM standards • BPMN • BPMThinkTank • BRE • SOA | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

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 here 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.

Posted by Sandy Kemsley at 04:44 PM in BRE • Blogging | Permalink | Comments (1) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 04:36 PM in BPM • BRE | Permalink | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 01:24 AM in BI • BPM • BRE | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 12:57 PM in BPM • BRE | Permalink | Comments (3) | TrackBacks (5) | Add to del.icio.us

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!

Posted by Sandy Kemsley at 08:51 AM in BPM • BRE | Permalink | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 08:23 PM in BPM • BRE | Permalink | Add to del.icio.us

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.

Posted by Sandy Kemsley at 08:52 PM in BRE • SoftwareDesign | Permalink | Comments (1) | TrackBacks (0) | Add to del.icio.us