Swimming with Fuego

A few more random thoughts in my journey through trying out Fuego.

My first thought on playing with the process designer was that I really liked it because it shows the process activities in swimlanes. The activities are colour-coded (red for human interaction, blue for system-executed), and the shape of the activity icon tells you something about what it is, or you can define your own activity icons on a per-activity basis, which is kind of cool.

But wait… swimlanes are supposed to run parallel to the flow, not perpendicular to it: if the flow runs horizontally (as it does in Fuego and most other process modelling/design tools), the lanes should be horizontal (which they’re not in Fuego). This has the effect of projecting (in a mathematical sense) the two-dimensional orthogonal nature of a swimlane diagram (activities in time sequence versus role) into one dimension: time, with roles dependent on the time axis. This makes for some weird anomalies such as roles repeating along the time axis, and showing automated steps as part of a human role assignment.

Whether you use UML activity diagrams or BPMN or venerable old LOVEM diagrams, swimlanes are supposed to be, by their very nature, orthogonal to (and therefore independent of) the time-based flow of the process, so that you can see all the activities for a single role in a single band regardless of their position in the flow.

BPM, Six Sigma, & the Road to Process Perfection

An article in Business Integration Journal about using BPM to achieve Six Sigma objectives, by Carl Hillier, a former colleague of mine at FileNet. I first met Carl about 10 years ago when he was a FileNet systems engineer in London and I owned a professional services firm that helped customers implement FileNet systems, and I’ve always had a great deal of respect for his opinions (although not always for his choice of bosses): not only is he smart technically and knows more about FileNet BPM than just about anyone, but he can write beautifully coherent sentences about it.

Of course, he does give space to the FileNet party line in several spots, (“a robust BPM solution provides a fully integrated content repository” — I consider an integrated content repository to be “nice to have” but not essential), but he does hit the nail on the head when he talks about BPM helping to provide a “closed loop” environment for Six Sigma’s Define, Measure, Analyze, Improve, Control (DMAIC) continuous process improvement cycle through the inclusion of process analytics and simulation.

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.

EA in the past

This was pretty funny… I received this email yesterday:

Looked interesting, so I clicked to read the abstract:

Butler Group believes that now is the time for organisations to start considering and deploying Enterprise Architecture based around a balanced business process and information view of operations. It is crucial that business and information requirements drive the creation of IT services. In many instances a rudderless IT department adopts a technology push approach due to the absence of any easily understood corporate direction and poorly articulated strategy.

To remain competitive organisations must urgently address the growing dislocation between the business requirements and IT deliverables. This issue is directly impacting the enterprise’s ability to make quick, accurate decisions and causing the slow implementation of the determined course of action. The gap between IT capability and business needs cannot be allowed to continue. Adoption of an end-to-end Enterprise Architecture approach will help to re-align IT developments with business objectives.

Excellent stuff, I completely agree with all that. Then I glanced at the report publication date: February 2004. 2004??!! February 2005 would have been bad enough, but eBizq is hyping an enterprise architecture report that’s 18 months old? Maybe they should have edited the abstract to begin “A year and a half ago, Butler Group believed that it was then the time for organisations to start considering and deploying Enterprise Architecture…”

To be fair, however, so few companies are taking EA seriously that there is probably still a lot of timely information in the report, but I’m not sure who would shell out the big bucks to look at last year’s news.

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.

Fuego and Plumtree

I don’t mean to be blogging just about Fuego these days, although since I’m in the middle of evaluating their product, I’m probably more attuned to stories about them. I found Gartner’s assessment of the recent Fuego/Plumtree OEM agreement interesting:

Fuego’s original equipment manufacturer deal with Plumtree is the first strategic relationship between a business process management suite vendor and a complementary middleware vendor. This is a game-changing event that will pull Fuego ahead of its closest competitors in the crowded BPMS market.

The agreement was made in May, but Gartner’s comments just published this week.

Business Performance Management survey

If you caught their webinar on Business Performance Management and Optimization a few weeks ago, you’ll know that ebizQ is putting together a survey on business performance management for their Buyer’s Choice Awards. You can help create and weight the criteria that will be used in the survey if you’re so inclined.

I’m still having a bit of trouble with the whole business performance management thing. The goal is to optimize business performance by aligning what goes on in the business with the corporate KPIs (e.g., customer retention rate). Okay, it makes sense that you focus on doing things that provide measurable improvement to the business; in fact, it’s not only common sense, it’s very similar conceptually to Six Sigma and a number of other business improvement practices that have been around for decades. A somewhat more esoteric goal of business performance management is to allow an organization to make decisions in real time, and become predictive rather than reactive. Lots of potential pitfalls this; it harkens back to the agility problem, which says that organizations aren’t being agile even when they have the capability to do so. Also, BPM definitely plays a major role as an input channel to business performance management, but don’t follow into the trap of optimizing operational processes while inadvertantly blowing your KPIs.

Business performance management is being defined as a combination of methodologies, best practices and technologies, where the technology includes event/process monitoring, management dashboards, rules engines, business intelligence, simulation, collaboration and potentially the kitchen sink. Maybe that’s why we have so many vendors claiming that they’re in business performance management: by this definition, there’s probably fewer software vendors who are not included than who are. In some cases, the technologies of business performance management are collectively referred to as BAM; in other cases, BAM refers only to the event/process monitoring. Personally, I would go for the former definition, but I don’t have a lot invested either way.

My problem is this: what distinguishes the concept of business performance management from that of the decision support systems (DSS) or executive information sytems (EIS) that we built in the 1980’s, except that the technology is a bit more advanced? This is being hailed as the new saviour of business, and I feel a bit like I’m looking at the Emperor’s new clothes.