Adam Deane has once against sparked a discussion in his comments – this time about BPM and BPO – and he ends with the question: “So why are BPO and BPM not talking to each other?”

I might not have commented on the post, but for reading Neil Ward-Dutton’s response, and then Evan McDonnell’s response. Neil points out that CapGemini’s BPO offering uses IBM BPM (Lombardi), Steria’s F&A uses Nimbus/TIBCO.  And AWD from DST.  So it looks like there are a few examples – perhaps not getting much press.

Evan’s comments were even more interesting to me, crediting BPO providers with some foresight.   He rightly points out that BPO has largely been “lift and shift”, and that they’re running out of steam (but trust me, there are still low wage geographies and polutions for BPO providers to exploit).  Evan goes on to describe the BPOs with foresight and the great benefits they will achieve by adopting BPM.

I have no argument with that – clearly any company with scale, and customers, will benefit from good leverage on a BPM suite/system/solution.  BPO providers are, after all, just companies like yours and mine.

But I took some issue with the idea that we aren’t hearing about their success because they’re keeping it secret, and wrote:

I file this under “I could tell you about our successes, but then I’d have to kill you” (smiley face)

BPO organizations are/were not exactly known for being innovators. I didn’t notice any of them “anticipating” the lack of cheap labor – their whole business was typically based on the premise that the cheap labor pool was virtually limitless. It is no surprise that they are late to BPM, late to process improvement (for real). And a BPO’s process improvement is not for the customer’s benefit, it is for their own. As a customer to a BPO firm you have to own your own process improvement.

You might think I’m crazy or talking nonsense. Does Apple leave it to their suppliers to figure out how to improve their processes or their manufacturing? Or do they go in there and make it happen at a detailed level? Don’t think you can just hand off and walk away. If you do, you’ll find something that went from differentiator (when you made it a core competency) to commodity (when you stopped differentiating on it), eventually turn into a weakness and a cost center (after BPO has set in for a couple years). Only by then, you’ll have lost the critical internal organizational expertise to run that outsourced process…

There are benefits to BPO, but big risks as well. Handle with care.

Of course, many people would argue that most companies don’t do this investment in process and people – but whether companies do or do not invest, it is pretty clear that they should be investing.

As for BPOs, trust me, when a company’s whole business model assumes that individual people are not valuable nor interesting, it is hard for them to suddenly retread for the world where skilled labor is more expensive, and choosier.  Instead, they migrate down the experience ladder, or the education ladder, until they find people who meet the right cost structure (often regardless of the impact on customer outcomes).

To the BPOs out there: invest in people and process, it is the best way to add value for your customers.  But to the customers of BPO vendors – own your own processes.  Improve them.  Don’t let all the benefits of process improvement accrue to someone else.

Neil Ward-Dutton of MWD Advisors is attempting to uncover for their customers the true differentation between BPM vendors.  This isn’t easy – partly because they can all hide behind a common modeling paradigm (BPMN, among others), and an expert in any one of them might be able to build a solution to a given business process problem.

But to actually deliver on the promise of re-use, agility, and scale, if the BPMS doesn’t support your efforts organizationally you will run into roadblocks that have consequences… We’ll get to those in a moment… Here’s Neil’s take:

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Neil has hit it exactly.  The separation of concerns seems like quibbling between different philosophical approaches at first – but it is more important than that.  But when the separation of concerns is poor, or when the support for agility is poor, what are the consequences?

• The level of product and technical expertise you need to maintain your solutions goes up.  You can’t easily integrate people who are new to BPM to your project, and even when you do they have to be incredibly skilled computer scientists.
• The level of specific knowledge required of your business (and your technical hacks) is too high to easily bring new people into the project.  Anything they touch may have unintended consequences – sometimes far reaching and affecting more than just the process they intended to affect.
• Fear of change.  If a small change can have broad negative consequences or unintended side-effects outside of the process we’re editing, we will fear changing it.  We lose agility.  We might abandon a common implementation in exchange for process-specific implementations – and therefore losing the benefits to efficiency that re-use provide.
• Testing overhead.  If a small change in one process or process area can affect a broad array of other processes, the testing overhead is quite high.  Essentially I have to re-test everything.

But these are just the tactical problems. The real problem is that your BPM team won’t achieve the business outcomes you’re looking for – the I in ROI will be more expensive, the time to market slower, and the R lower.  It can wipe out much of the promise of BPM in the first place.

You can see some of this differentiation when you hear pundits and gurus talk about how “rigid” BPMS’ are – this says more about the BPMS they’ve been using than it does about the notion of a BPMS.  Meanwhile, some of us are pretty happy with how flexible our BPMS is… draw your own conclusions.

Neil’s next point:

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Reading this, it reminds me how much hue and cry there was over a certain company with a BPM product, buying an upstart company with an allegedly overlapping BPM product…. There was real differentiation in the process repository and in the basic architecture of the design environment.  But it was the kind of differentiation that customers and analysts would often miss – because the value isn’t as apparent in iteration 1 of project 1 (although it is apparent if you do them side by side).  It becomes much more apparent in iterations 3 and 4, projects 5 and 6.  If you’ve owned a BPM product for more than a year and you’re still looking at getting process #1 deployed, I’d recommend two things:

1. See about getting some professional help from a boutique consultancy focused on project success.  If you’re already working with one, consider a new one.
2. If that doesn’t get you on the path to more productivity and better use of your product, consider a different BPM platform.  You might have picked the wrong one.

Meanwhile, keep an eye on MWD’s research and their attempts to delve into the real differentiation between BPM vendors, and don’t just get caught up in the bright shiny features they’ll parade in front of us.

Analysts were predicting more consolidation in 2011, and it looks like the late-year acquisitions are happening again.

First, doc capture specialist Kofax has acquired Singularity, a BPM and case management provider.  Kofax has been part of many a BPM project, whether they realize it or not, as the doc capture element.  Almost every BPM project needs that transition from “physical world” to “electronic bits” or “process world” – and document capture is a common entry point.

Neil Ward-Dutton, of MWD, comments:

In a call first thing today, Kofax CEO Reynolds Bish highlighted that he expected the acquisition to double the size of the company’s addressable market – in large part through the expansion of sales coverage and effort for Singularity’s products, which Singularity itself had largely confined to the UK.

In other words, Kofax expects to expand the reach of Singularity, as well as of their product set itself.  Interesting, to me, was that Singularity’s revenue mix was 50% services, and that Kofax intends to adjust that downward.  Good news for Singularity partners or services experts.

Meanwhile, in another corner of the BPM world, Progress has acquired Corticon, a pure-play rules management (BRM) vendor:

Progress is pitching Corticon as a crucial ingredient as it continues to develop its RPM story, and this makes sense. Progress’ Savvion BPM technology already had a fair business rules capability (BizRules) as an integrated component, but my view is that Corticon’s technology is more widely-applicable, as well as being widely acknowledged for a very strong ease-of-use story, enabled by its heavily model-driven and graphical approach to rule specification. Its open stance towards rule management repositories will also serve it well, as Progress seeks to blend Corticon’s tools into broader capability mixes.

In a previous life, we used Corticon for rules for a while.  We didn’t find it particularly compelling and ended up writing our own, similarly non-compelling rules solution.  More often than not, customers would use ILOG or Fair Isaac or Drools. But it has been several years now, and no doubt Corticon has made some progress in that time (pun intended!) on their rules capabilities.

The conclusions I’m drawing from these acquisitions:

1.  BPM and Rules are a natural combination.  BPM seems to be the value driver, as it is the rules vendors getting gobbled up.

2.  BPM and Content Management or Document Management combinations are also happening.  But the major BPM vendors have (largely) already purchased Doc Management or Content Management solutions… So the remaining players in these spaces are forced to go pick off the weaker BPM vendors instead (OpenText acquired two of them, Lexmark acquired Pallas Athena, and now Kofax is in on the act).

3.  There’s still a lot of shakeout to occur in the market – and execution at a detailed level for each vendor is really going to matter.  At this point it isn’t all marketing fluff – real differences in product are apparent.  But the target keeps moving.  A well-integrated solution that is coherent to the end-user is going to win the day.

MWD has a great series of posts entitled “Calling BS on…”

In a recent installment, the topic was calling BS on “Our technology makes your business more agile.”  Of course, it is silly to think that any technology by itself can make your business more agile:

Making a business – or at least, the parts of it that make sense – more agile requires you to review and be prepared to change people’s incentives, business measurement systems, skills and training plans, information sharing and collaboration practices, operating models and procedures, and management culture – and probably more. Even if we just confine ourselves to the technology domain then increasing business agility is likely to require you to review architecture, governance, portfolio and change management practices. If you don’t at least think about this stuff, then the most you might be able to do is increase potential technology flexibility.

It’s nice to see some of the stereotypical pitches blown up in this series…!

As Neil says:

The key realisation here is that agility is something that – if you’re serious about it – has to be sustainable and sustained for the long haul. It’s not something you can just worry about for 6 months and then forget about.

Exactly.  Which is why it is so frustrating to hear pundits or analysts say that something like “continuous process improvement” is a pipe dream.  What they’re saying is that companies should throw in the towel and just stop trying to keep up with a changing world. That’s madness for a corporation.  If a corporation wants to be agile, it takes constant attention.  This isn’t a philosophical point, it’s just reality.

Neil Ward-Dutton is following up on previous work he’s done looking at BPM practices at big firms. We’ll start with this, wherein Neil tells us Capgemini are lining up their ducks:

Top Line Initiatives within Capgemini are identified where a need is seen for an internal ‘accelerator’ (my word) that can place the company to play in high-growth market sectors – and furthermore, where the potential is seen for the company to grow at twice the overall market growth rate. In line with BPM having been identified as a Top Line Intiative, Capgemini is looking to grow its BPM project delivery business 40% per year for the next 4-5 years.

Well, this is both what is right and wrong about the big consulting firms.  What’s right: they’ve realized BPM is a growing market opportunity and worth investing in.

What’s wrong:  that’s the only motivation behind these companies getting into BPM.  There’s no passion for business improvement, process improvement, or business process management.  There’s no raison d’être.

But there are a few other positive notes here to pick out:

The company has realised that the traditional body-shopping approach doesn’t work; and it’s also realised that trying to push a significant proportion of project work offshore is also going to be difficult – particularly in the early stages of engagement with a customer. Rather, it aims to create small project teams of between 6 and 12 consultants, working onsite with customers and getting business and technology representatives from the customer’s side collaborating with them as much as possible. It’s aiming to structure projects to deliver results in 3-6 months, and its goal is to build relationships with clients so that it can set up sequences of such projects that overall create engagements that last 2-3 years.

It is encouraging to hear that some of the big consulting firms are finally coming to grips with this – the project work for most BPM projects needs to be local.  Now if only customers will come to the same conclusions…

What Capgemini sees as small teams (6-12) would represent large BPM teams if they’re only focused on the BPM parts of the business (and not supporting aspects, e.g. technology integrations, etc.).  CapGemini is focused on the right time-frames:  3-6 months for results. The “2-3 year’s” for overall engagements however- when you’re a smaller firm like BP3 that longer term relationship has to be earned, we don’t go in assuming it will be there.  We execute the project, and try to acquit ourselves well enough that if there are additional projects we’ll be invited into planning discussions – or better yet, invited to help funnel additional project ideas into funded projects.

Great read on Capgemini – and instructive for other companies looking at BPM services…

TIBCO has announced its acquisition of Nimbus today:

Nimbus provides a strong complement to TIBCO’s event-enabled infrastructure software platform. Whereas TIBCO has traditionally focused on the automation of data, systems, and processes, Nimbus allows business users to collaboratively describe and document all aspects of a business – from operational best practices to organizational and system models. These are combined with robust governance capabilities that can deliver a process-focused “Intelligent Operations Manual” across the enterprise, linked to supporting data and systems. Nimbus focuses on the vast majority of processes that are often not captured in enterprise applications and automated workflows, and it has found particular traction with business transformation, compliance-led, and continuous improvement initiatives.

On the face of it it seems like a very complementary acquisition – I don’t see a lot of overlap between the market needs Nimbus addresses versus the market needs TIBCO addresses.  This might be seen as a move by TIBCO to inject some more business-friendly DNA into its veins, as right now TIBCO is seen as more of a speeds-n-feeds vendor than a business process management vendor.

Neil Ward-Dutton was first to the presses with his analysis of the buy:

Nimbus is happy to point out that historically it’s had a hard time selling to IT, and this has slowed down sales cycles; part of the challenge for it has been that Control doesn’t fit neatly into any mainstream product category (including BPA). TIBCO can help with the IT selling angle; but it’s important to recognise, too, that Nimbus can potentially give TIBCO a massive leg-up in terms of developing a more business-engaged field sales capability.

It sounds like a good synergistic match.  Neil characterizes Nimbus as a company with “annual revenues of around £10m and around 100 employees” – which implies the purchase price was easily digestible for a company the size of TIBCO.  Still, as we’ve seen with the IBM acquisition of Lombardi, sometimes a small (relatively) acquisition can have an outsized impact on the buyer.

Clay Richardson of Forrester also weighs in on the purchase:

So, why did TIBCO acquire Nimbus?  In many ways this deal is a nod to the “Empowered BT” trend, where more technical capability is being moved into the business.  For vendors like TIBCO, this means building – or buying – functionality that puts business stakeholders in the driver’s seat.  Over the past six months, one of the top inquiry topics I’ve seen from clients is around “models for increasing business engagement within BPM suites”.  In short,  I’ve fielded numerous calls from business stakeholders scratching their heads saying “I wrote the check for this BPM suite, but the IT guys are the only ones that can touch it.”

Empowered BT trend is a great way to sum up with the Nimbus folks (Ian Gotts in particular) have been preaching in their blogs and sales pitches.  Clay wraps up with this note:

TIBCO’s acquisition of Nimbus will be welcomed news to existing TIBCO customers looking to improve business engagement and – if executed effectively – should allow the developer-centric vendor to compete more effectively against more business-oriented players such as Appian and Lombardi  (i.e., IBM BPM 7.5).

I got a chuckle out of the last line.  But Clay is right – TIBCO needed something to help them compete with more business-oriented products on the market – what isn’t clear is whether Nimbus also needed to partner up with someone to keep going (as one person on twitter put it – is the lack of execution for one just as bad as the lack of business-focus for the other?).  I’m looking forward to seeing how well Nimbus is integrated, what role Ian Gotts is taking on, and how the analysts view on this acquisition evolves over the coming weeks.  So far no one is arguing that this is a bad fit… but we’re only a few hours in!

Neil Ward-Dutton may be late to the party with his post on the OpenText / Global360 merger, but it is a good read:

So, having set out to purchase Metastorm in February, Open Text has followed up less than 6 months later with the acquisition of Global 360. It’s not much of a secret that Global 360 was looking to be acquired; the hiring of some key webMethods executives in 2008 signalled the start of a concerted effort to shape the company up for a sale. Still, it caught many industry observers (including me) by surprise to see the company follow so closely in the footsteps of another BPM technology vendor and be snapped up by Open Text.

The surprise factor may be one of the reasons this acquisition made so much more news than the Metastorm acquisition.

Neil Ward-Dutton and MWD have published a brief piece about TIBCO and ActiveMatrix BPM. There’s a more in-depth assessment available as well, coming down the pike.

A couple highlights from his write-up:

• Revenue was up 25% year-on-year
• License revenue up 32% year-on-year
• Non-GAAP operating profit up 31% year-on-year.

TIBCO is now rapidly approaching $1 billion in annual revenue; and its acquisitions have helped it broaden its market footprint into healthcare, retail and other industries.

But specifically the BPM part of the business doesn’t seem to be standing out (the growth doesn’t look that different from the company as a whole):

Q2 BPM license revenue was 9% of the total $83m; that’s around $7.5m. TIBCO declares that this is up 33% year-on-year – which is a good sign – but I’m guessing that at the moment, the company hasn’t yet seen a return on its very significant redevelopment investment.

From what I understand ActiveMatrix BPM was a “start over” rewrite of their BPM offering… and from what we’re seeing/hearing anecdotally, it is taking acts of heroic proportions to make big deals happen.

Incidentally, wholesale rewrites of a product are rarely the right thing to do.  They open up all the existing customers to re-examine their go-forward choices… and then they have a new, less mature product to go pitch against entrenched competition.  Let’s suppose you build a better mousetrap that scales better (in theory).  Prospect A says “can you show me the three references where it scales to x million transactions per time unit?” and… well you can’t, can you?  It is a new product after all.  And then if you get a customer to buy into it – maybe it scales, maybe it doesn’t.  Scale is just one dimension- there’s feature-fit, UI/UX, production support, etc.  So many unknowns to answer, that the old product had answers for (maybe bad answers, but answers nonetheless).  But, ironically, a company does have to have the courage to rewrite pieces of their software – or to acquire new pieces of software (as Tibco has done).  Sometimes the difference between a product rewrite and a “module” rewrite is one of perspective, but one rule of thumb is that the product is a SKU – something you sell.  A module isn’t sold independently.

I think the move to ActiveMatrix BPM was more problematic than it appeared on the surface. Putting the $7.5M in perspective… if that is up 33% over prior year, they were as low as $5.625M the year before… This is about the scale of pure-play BPM vendors… but TIBCO + Staffware used to be much bigger than those vendors at the time of their merger…  Their momentum seems to have been in the wrong direction… (when I worked for one of those pure-play vendors, we always looked forward to competing against Tibco in a BPM deal cycle…)

Pega has has impressive financial performance over the last few years, as Neil Ward-Dutton documents:

The company is currently publishing full-year revenue guidance of around $430m for 2011 – up from $330m or so last year – which means it’s grown 30% in each of the last three years. As it digests its Chordiant acquisition and finds ways to combine the technologies it now has to hand for new customer scenarios, the company is clearly riding high and full of confidence[...]“

But Neil asks a few questions that I think are pretty interesting:

But – is it actually a BPM technology provider?

Well, it spent a lot of effort getting re-branded as a BPM provider a few years ago, when BPM was an up-and-coming tag for a category of software.  But Pega was never really a pure-play BPM software vendor. This is the first time I’ve seen an analyst of any kind question whether Pega is really in the BPM business.

So onto the other question, quickly: is Pegasystems a BPM technology provider? In his opening keynote, Alan Trefler claimed that the company’s recent growth makes it more than 10 times larger than its nearest pure-play BPM rival – but in truth this comparison is a little sneaky. Pegasystems isn’t really a BPM pure-play.

It is a BPM technology provider – but in the same way that SAP’s BPM investments make it a BPM provider.

It actually does matter – the difference between the mentality of a pure play and an SAP is larger than one might think.  The distance is so great, in fact, that IBM bought Lombardi to get that pure-play DNA into its veins.  But Neil doesn’t find that question nearly as interesting as whether Pega is selling to IT or selling to Business.  It is an interesting point:

They talk about Pega technology as a way to make the thorny tradeoff between the need for consistency in business execution, the need for competitive differentiation, and the need to specialise execution for particular markets and segments. They are fantastic advocates for the business benefits of working with Pegasystems. But these are not people who really naturally engage with the idea of ‘situational layer cakes’.

I’m sure Pega would argue that they just have to do both – sell to the business and IT.  That’s not a bad recipe.  But from reading Neil’s post, it sounds like Pega isn’t sure what its organizing principle is – what is the mission?  Improving business processes?  Improving customer service?  “Driving Customer Success” is admirable but bland -  it describes a whole host of companies in different industries…

Good coverage of Progress’ analyst day by Neil Ward-Dutton:

My concern at the previous year’s event was that Progress was in danger of painting itself into a corner: by highlighting RPM as the “next step beyond BPM”, it was in danger of creating for itself a very specialised niche. It seems that the company understands this challenge, and is doing some things to try and avoid this particular trap. We heard about three specific initiatives, all of which are related.

Like Neil, I like(d) the definition of RPM, but worry(ied) that it would paint them into a corner if they became only about a special subclass of BPM.  I think this is the danger to the vendors pursuing ACM vis-a-vis BPM as well (less so to those vendors who claim to do both).  Neil’s assessment is that they’ve avoided that trap, which is good.

The biggest transformation still facing Progress is to be more business-facing in both sales and delivery.  They have a well-respected technical heritage, but appealing to the business hasn’t been the reputation historically, and sounds like something that still has room for  improvement.

Great stuff from Neil, debunking yet another generational myth pushed upon us by the likes of Time and Fortune:

I don’t know about you, but when I was a young adult I wanted every minute of my life to have meaning too! I was self-absorbed, narcissistic and impatient. Outspokenness, inability to take criticism and a sense of entitlement are characteristics of young people – and have been for 40-50 years. Now I’m older I hope those characteristics have lessened, and I believe there’s no reason to expect things to be different when Generation Y workers take on management positions.

If you go back and read what Fortune and Time wrote about Gen X 10-12 years earlier, it sounds suspiciously similar… As Neil says, this line of reasoning seems lazy and without any real rigor.  It doesn’t even pass the common sense test.

+1, Neil.

The early reviews of IBM BPM 7.5 were out last week, while IBM Impact was still in full swing.  It seems that the analysts in attendance were of differing opinions about the strength of IBM’s update to 7.5 – with Clay Richardson disappointed, and the other analysts ranging from reassured to impressed.

Clay’s review (“IBM Adds Fresh Coat Of Paint And New Tires To BPM Offering, But Still Needs To Rev Engine“) starts off:

So far, IBM is following the product integration roadmap John Rymer and I laid out in our report published immediately following IBM’s acquisition of Lombardi.

I’m sure IBM looks at it as, they were following their own roadmap and some of the points just happen to coincide with what analysts were clamoring for. One thing that the analyst community doesn’t seem to be comfortable with is that IBM doesn’t say much about future releases – they cite disclosure rules – and they only announce releases within the same quarter they’re to be released.  But beyond that, I think it is quite right that the decision about *how* to integrate Lombardi and WPS had not been finalized at this time last year.

With today’s announcement, IBM checks off the first point of integration on our list: establishing a single repository across Lombardi Teamworks and Websphere Process Server. With Business Process Manager V7.5, IBM will deliver a single repository for process assets that leverages Lombardi’s impressive “snapshot” version management and governance capabilities, providing a unified approach to administering and reusing process and integration assets.

I imagine that this retrofit to WPS and integration designer was actually quite a lot of work – and likely addressed the hardest technical parts of the integration of these two products.  But Clay goes on to say:

Although IBM has done a great job of delivering a unified repository, the core BPM engines and development environments will continue as standalone and separate entities — at least for BPM V7.5. While this is not surprising — we predicted that it would take three to four years for IBM to completely integrate Lombardi and WPS into a single unfied environment — we expected IBM to communicate a strategy or vision for merging the engines as part of this announcement.

I think this is a distinction that won’t matter to users.  It might surprise Clay to know that Lombardi, since 2005, effectively had two engines under the hood.  But it certainly never felt that way to users.  And with the integrated rules engine in IBM BPM 7.5, you could say it has 4 engines.  The point is – as long as the functionality works well together, this distinction won’t matter to process authors.  There’s also an option to deploy the whole stack into a single VM – particularly useful for developer machines.  Most people won’t quibble over different sections of code running inside a VM.  After all, an engine is just a body of code that transforms inputs into outputs based on current state plus a model which provides context.  A good BPMS will have more than one such body of code.  Even a good rule suite will have more than one engine.

So the issue in the future isn’t how many engines IBM will have embedded in its BPM suite.  The questions to ask are:

1. Will future versions feel like one product or two or more products.  Clearly the direction is to make IBM BPM feel like one product.
2. Will new versions of IBM BPM provide the same transformations of input to output given the same state and model context.

Information Week ran a story that reads very much like Clay’s:

IBM’s approach can be contrasted with that of Oracle, which took a decisive step in 2010 when it integrated the AquaLogic BPM system it acquired with BEA with its own legacy BPM product. That move yielded a single product and a clear roadmap, but it also forced existing customers of both products to do considerable migration work to move forward.

Except that when their article contrasts IBM and Oracle, it fails to mention that Oracle bought BEA in January 2008, nearly 3 years earlier (Clay, however, was more fair in his comparison).  And yet the expectation is that IBM provide this transformation in a year.

But while Clay was focused on the need to consolidate engines, others focused on the market signals IBM was sending.

As Bruce Silver wrote in his rebuttal:

Some have called it just “a new coat of paint” on the existing offerings, because the (Lombardi) Process Designer and the (WPS) Integration Designer tools are both still there, and both runtime engines are still there as well.  But that misses the point.  Where IBM last year was pushing separate fit-for-purpose BPMSs – something nobody really wants – they now can offer a single BPMS that has the combined functionality of WPS and WLE.

I agree with Bruce – at a detail-level, it also ignores the interface makeover WPS Integration Designer got, to match the repository unification (which added significant versioning functionality to WPS).   At a big picture level, it misses the point, which Bruce makes:

Beyond that, this announcement represents a major shift in IBM’s strategy for addressing the BPM marketplace.  You might even call it a palace coup:  the Lombardi/human/business-centric value system overthrowing the old WebSphere/integration/developer-centric value system, or even a BPM perspective rising above the SOA perspective.  Given the existing installed-base investment on the two sides, this is truly a wag-the-dog moment.

I think this represents IBM’s move to capture the business-oriented perspective of the BPM market – something that was part product functionality, part product design, and partly go-to-market.  Bruce’s summary:

And here’s the thing:  it’s ONE product.  You get it all.  Business-empowered design, what-you-see-is-what-you-execute, and instant playback.  SOA and integration services.  Powerful business rules. [...] but I think everyone is surprised they got it done already.

Bruce has another post on the BPMS Endgame which predicts that IBM will focus on BPMN2 engine work for the 8.0 release timeframe.

Neil Ward-Dutton also rebuts Forrester’s assessment:

However when you look deeper, the release of Business Process Manager marks a significant departure for IBM, and warrants a thorough reappraisal of IBM’s competitive position.

He also hits on a few key points of integration:

1. Unified repository toolset
2. Unified governance toolset
3. Single Deployment runtime foundation (no more copying EAR and WAR files around)
4. Single Administration environment

Better yet:

Business Process Manager makes the relationship clear: Process Designer is aimed at business-facing teams collaborating to optimise business processes; Integration Designer is aimed at IT teams working to orchestrate the integration of systems to support the optimisation of those processes. Again – these two environments work together through the use of a shared repository and governance toolset.

Tony Baer also humorously commented on the Lombardification of IBM BPM.  Unlike David Brakoniecki, I couldn’t resist revisiting the analyst reviews.  David points out a few of the “unsung features” in the 7.5 release:

• A powerful REST API which in theory should allow better and richer user interfaces to be built
• A new charting technology (based on iLog jViews, I think)

I’d add to that the deployment characteristics – the fact that we will be able to build solutions with both the Process Designer and the Integration Designer – and then manage and deploy them from the same repository, to the same run-time clusters – is a big improvement over the state of the art in the previous versions.  And it appears to be a big improvement in how both WLE and WPS previously managed deployments.

Sandy Kemsley took more time to write her analysis, and it demonstrates her extra time to reflect.  I liked the shout out to our sleuthing out the announcement ahead of time (maybe IBM should include me on their analyst briefings so that we’ll be embargoed as well!…).  She writes:

It’s important to look at how the IBM organization has realigned to allow for the new product release: Phil Gilbert, former president and CTO of Lombardi, now has overall responsibility for all of WebSphere BPM – including both the former Lombardi and WebSphere BPM products – plus ILOG rules management. Neil Ward-Dutton referred to this as the reverse takeover of IBM by Lombardi; when I had a chance for a 1:1 with Phil at Impact, I told him that we’d all bet that he would be gone from IBM after a year. He admitted that he originally thought so too, until they gave him the opportunity to do exactly what he knew needed to be done: bring together all of the IBM BPM offerings into a unified offering. This new product announcement is the beginning of that unification, but they still have a ways to go.

When the buyout happened I often heard this argument that Phil would be gone within a year.  But, living in Austin, I’ve seen a few promising startups purchased by IBM in my day (Tivoli and Webify just to name two), and I’ve also known Phil for… 10-12 years now.  My sense was that IBM has the scope and opportunity on the big stage that Phil would really relish taking advantage of.  IBM is big enough to make the right role for someone like Phil – in a way that very few companies can.  If they were willing to do it, I felt like they had a chance to hang on to Phil.  I felt the same way about most of the people acquired with Lombardi – some would leave, but IBM has the reach and size and money to keep people if it chooses (and if it acts in time).

Regarding that “two engines” argument from Clay:

However, from the customer/user standpoint, it’s wrapped into a single Process Server, so if IBM ever gets around to refactoring into a single engine, that could be made fairly transparent to their customers, but would likely have the benefit of reducing IBM’s internal engineering costs around maintaining one versus two engines.

I think Sandy hits it just right.  The issue isn’t how many engines are under the hood – it is what does it feel like to the customer.  Regarding the lack of a cloud offering for BPM: “They need to rethink their strategy on this, and stop offering expensive custom hosted or private ‘cloud’ platforms as their only cloud alternatives.”  Again, I think Sandy’s right. It is hard to tell in what time frame it really starts to hurt, but the trend lines are there, and they’re plain to see.

Great reviews and perspectives to soak up.  Nothing I like more than reading these competing perspectives and conclusions and then reconciling with my own opinions and the impressions of the BP3 team.

Joe Heller, CIO of Caterpillar, gave an outstanding lesson in lasting business partnerships at IBM’s Impact conference on Day 1 (Monday, April 11th, 2011).  Joe was highly quotable (“There is dirt in the wrong place all over the world, and we are there to put it in the right place”), but beneath these quotes is a deep sense of business value over time.

And he wasn’t shy about sharing real dollar values in savings.

I think David Brakoniecki sums it up best in his post:

83 years of Partnership – Caterpillar has had a relationship with IBM for 83 years.
From a business perspective, I find this mind-blowing.  Having worked the last 12 years in small businesses and start-ups, I’m lucky if I can point to a continuing business relationship that goes back 5 years.
In recent times, the recession has claimed several major brands so it’s easy to forget that long-term business partnerships are not only possible but also worth having.  It’s mpressive that the CIO of Caterpillar was willing to stand on stage and say that IBM has never disappointed him in his 38 years of working together.

It is a pretty remarkable partnership.

Other thoughts on Day 1′s General session:

• The video wall is truly massive.  The room itself is massive.  And I can’t imagine how they’ll fit more than 8000 people in one room next year.
• It is also interesting how cultural differences come out in a conference like this.  At one point, Marie Weick, in the middle of a very well-delivered segment, repeated some advice once given to her: “In your career you can only move forward or fall behind”.  From the perspective of someone outside the corporate ladder-climbing world, this sounds off – a career is more than two dimensions measured forward and back.  I would wish for everyone to realize that early in their career rather than late.
• Dr. Burns has one of the most compelling cases for application of technology – pediatric care.  It is well worth watching on the livestream video.
• It takes an immense amount of coffee to serve this many people.  Don’t expect to find coffee at the coffee stations right outside the main event.
• Impact Day 1 kicked off on an odd note, with the opening musical performance.  At some point three of the musicians switched from instruments to iPads to finish their musical number (and of course, you can’t tell if they’re actually playing or if it was all pre-recorded, but one wonders).  It was an interesting choice to kick off the conference.

Notes from the Rest of Day 1

After the General Session, I wanted to see what IBM was saying about “which BPM to use” in one of the early sessions of the day.  Sometimes it is good to get the official positioning so that you understand how far out of alignment your own opinions are.

IBM’s positioning of BlueworksLive is:

1. No training to use
2. Social Application, which helps scale social talk across the business
3. Doc and discovery tool that is easy to use
4. Automate simple processes

At this point, I noticed the room was full.  More than full.  This would continue in virtually every BPM session that touched on Lombardi heritage at all.  IBM’s conference organizers continue to under-estimate the demand for Lombardi-BPM-themed content – but we can hope that next year will be different under the IBM BPM branding.

Someone described BlueworksLive as “Powerpoint for process applications”.

There is an open question for IBM, which remains unanswered: How to support the partner community with this product?  IBM really depends on its partner channel to expose customers to products.  Unfortunately BlueworksLive leaves a lot to be desired from a partner point of view (one could even argue that the automation is competitive with partner service offerings).  I think the answer is to simply add a few features that will make this product more partner-friendly:

• the ability to move models from one corporate account to another (so that I can move drafts created in my sandbox to the customer’s BlueworksLive spaces).
• an expert BPMN diagramming mode that allows expert modelers to be more precise in their process definitions.
• more features like the “playback” feature that was introduced in the last BlueworksLive update.

Next, IBM positioned IBM BPM as targeted at the high volume, repeatable processes, while BlueworksLive is focused on the long tail processes.  Both products offer “tooling that is easy to use” (relatively speaking), “transactional integrity and scale”,  “unified environment for governance, visibility, and control”, and versioning.  (Of course, they achieve this in very different ways and targeted at different processes and users.)

Next up, I went to a hands-on lab for BlueworksLive. But, being a newcomer to Impact, it wasn’t what I expected, so I said hi to a few people and then went to take a certification test in another room.

Lunch was a forgettable affair in the trade show area.  We left lunch quickly and met up with the analysts and bloggers who were sequestered on the first floor of the conference getting the low-down on all things IBM.  Flournoy and I were able to meet with Neil Ward-Dutton , and then he was nice enough to call out Sandy Kemsley (nice to meet for the first time!), Clay Richardson, and Bruce Silver.  It was great to hear their early impressions on the IBM BPM 7.5 release first hand – it definitely added color to the blogs they wrote later.  We shared notes and there was, generally, consensus (except for Clay).   It is too bad they are isolated from the rest of the conference, I think it would be really interesting for them to see how other people interpret what they’re hearing in typical Impact sessions (I imagine they got some of this if they stayed through til Tuesday or Wednesday).

In the afternoon I saw the “Measuring Quality” session by Fahad Osmani and Sean Pizel, of IBM.  It was a wide-ranging presentation, best to get the presentation slides rather than rely on my notes.  They suggest some new measurements for BPM projects, and pointed out that programs that deliver value, repeatedly, almost always turn into successes.

We then went into a meeting with folks from the IBM partner enablement community.  We were impressed by how motivated IBM’s partner groups were to make sure BP3 is successful as an IBM partner.  It was an intense and productive conversation, and we left with concrete follow ups.  The quality of the meetings their partner group set up for us was quite impressive.

After the partner session, I made it to the second Lincoln Trust presentation of the day (I had heard great reviews of their first session of the day, just prior).  In this session they talked about their strategy for addressing a high volume of processes (100′s) with a small team and small budget.  The answer, of course, was to have standard lightweight process definitions that could represent more than one of these processes.  The key outcomes they were looking for were tracking (for visibility), standardization, and governance.  By implementing lightweight processes that could act more generically, they gave themselves a lot more data about each process before investing in building something more technically demanding.

The Lincoln Trust approach reminds me quite a lot of the Banco Espirito (BES) approach.  At this point, the team dove into technical details behind their implementation (great content).

We had dinner with a fellow BPM practitioner and long-time colleague, and then headed over to iTKO’s party at Tao Beach, where we were able to catch up with friends at their company and IBMers who also joined in.  iTKO was a Diamond sponsor of Impact – quite a step up from last year.  They made a big splash and they’ve had a great year.  Kudos to the iTKO team for a big contribution to the quality of the conference.

At the end of Day 1, I was motivated and exhausted. It was time to rest up for Day 2.

Neil Ward-Dutton of MWD recently claimed that Capgemini is pulling it together for BPM. It is an interesting area to keep track of and MWD is one of the best at covering these issues (largely because they seem to be a bit tougher on vendors than other analyst firms):

I’d come across a number of cases where BPM projects had turned out to be tougher than they might have been because the incumbent CSI provider had failed to really understand how they could add value. From what I was seeing, many smaller and more specialised local firms were doing great work supporting business’ BPM needs; but the larger players just weren’t “getting it”.

Amen.  Neil hit the nail on the head.  If anything, he was too nice about it.  Some of these bigger players aren’t just not “getting it” they’re actually destroying value in some cases.  Much of this is simply driven by the penny-wise, pound-foolish nature of business today:

In the pursuit of lower cost-per-hour, we’re seeing people staffed that simply aren’t qualified to do the work.  And then more raw numbers of people are staffed at this lower rate.  And the customer, and the big vendor, think that a large quantity of lower-skill “resources” will make up for the missing small number of experts (and not just whiteboard experts, I’m talking experts that write code and get their hands dirty).

Worse, I’ve seen companies look at a project – a team with 1-2 BPM experts and 40 Java/SOA resources – and focus on cost cutting for those 2 BPM experts.  Everyone depends on the SOA team delivering quality work on time, but the SOA team is staffed with $25-50/hour subcontractors who have never really done this stuff before, and produce about less output than 2-3 experts with Hibernate and Spring would.   But companies focus on how to get the rates down on those 2 “expensive” BPM experts – because obviously swapping out a cheaper resource there will fix the problem right? Instead of focusing on the fact that they don’t have the right kinds of people on their SOA teams: a few highly skilled experts rather than an army of low-skill-level novices.

As I’ve said many times before:

An hour of labor is not the output of your well-spent money, it is the input.

An hour of labor is an input, along with skill, experience, context, intelligence.  The output is a deliverable, an outcome, a business result.  Therefore, the quality of that input has a dramatic effect on the quality of the output.

Neil thinks the big vendors may be turning their lack of focus on BPM around – Capgemini is launching a Pega practice, and several other big firms have had similar announcements, with Pega, Cordys, IBM, etc. .  I still think the best value for your money is going to be the pureplay BPM Services firms – I’ve said so before (and I’ll say it again!).

These big vendors announce initiatives all the time – and it always involves hundreds of people in the press release.  I wouldn’t hold my breath – I’ll just wait for the success stories to show up in blogs and analyst coverage.  I’d venture that most of these firms won’t pick up the right BPM DNA unless they acquire a boutique BPM firm to get it (much as IBM purchased Lombardi, partly to pick up its BPM DNA). 

I’m a fan of MWD and their coverage of BPM and related topics.  They have a bit of edge to their analysis, and aren’t afraid to go out on a limb.

So it was with great interest that I clicked on the link to read the 2011 outlook for BPM.  Right off the bat, MWD notes that the BPM value proposition is holding strong even as the economy improves (something, I’ll note, that we at BP3 predicted in early 2010).  MWD reminds us of four value propositions from BPM:

BPM has four ways it can add value: driving operational efficiency and quality; driving product and service innovation; driving business model innovation; and lastly, driving improved collaboration between IT and business teams.

Typically everyone gets stuck on the first two.  Or, we dismiss the last one as not a value proposition in and of itself, but a constraint that needs to be addressed in order to achieve the value of BPM.

The one prediction MWD makes that I disagree with: the decline of the BPM Suite.  While the arguments MWD makes in this regard make sense and hold together, the force for consolidating SKUs among large software vendors is just too strong.  The labeling (BPM Suite) may change, and the specific components may change (perhaps BI, reporting, etc. will be split out… while rules and the like might be more explicitly included – we’ll find out!).  And bundling vertically in the stack (for example, including the application server with the BPM product) will likely continue.

I found MWD’s take on ACM interesting:

Adaptive case management (ACM) – Most importantly, perhaps, a group of vendors has spent significant marketing money and effort through 2010 attempting to “break away” from the BPM technology market segment, at least in part as a response to the impact in the market of activity from software platform vendors like IBM, Oracle and TIBCO.

That aligns with what I felt was going on with the ACM movement over the last year – more marketing and positioning than substantive differentiation.  Although, one can hardly blame them for trying to change the terms of debate, and the terms of product selection.  If you can create a new market segment you have a chance to be evaluated by every company in that segment. If you’re competing for the same market segment, many customers have already bought “one of those” and may not want to buy another one.

MWD also turns their attention to consultants and integrators, noting that their market momentum is increasing.  As MWD notes:  “Until a couple of years ago, almost all the activity from systems integrators and consultants associated with BPM practice was carried out by small, local specialist firms rather than the big players.”  MWD sees the big players finally getting serious about BPM practices – and he’s right.  But it is still the case that the most capable firms are these small, local, specialist firms – some might even say boutique(!) firms.  (As an example in the IBM Lombardi niche, I believe BP3 represents both the biggest and the most experienced firm for Lombardi BPM deployment.  We would definitely be considered a smaller firm, despite our ability to cover the US geography.)

Read the report – and get used to reading MWD’s analysis – it is among the best out there, and they often put out free or registration-only reports that can help keep you informed.

Neil Ward-Dutton of MWD Advisors takes issue with equating BPM with Taylorism:

So I was really surprised to find all the tweets pointing to this post (”You failed at Customer Service, so now try Social Processes“), which seemed to be equating BPM with slavish application of Taylorism and an overly internal perspective that is acting as a malign force in organisations claiming they’re improving customer service.

And:

The truth is that BPM is a tool that can be applied in a number of ways. Yes, it can be applied to business processes to drive out waste, and this is often the focus. It’s not always done well. But I’ve also found BPM to be practiced very effectively in dealing with customer service improvement issues. Here efficiency can be one of the concerns, but it’s not the only one. And where BPM succeeds, a customer-first perspective is the overarching view taken.

I find myself in agreement.  The final thought on this from Neil:

The point is, a fool with a tool is still a tool. BPM is a tool. A stupid know-nothing who is hell-bent on slavishly applying Taylorism in a customer service environment can cock things up royally using BPM practice, but that’s not BPM’s fault.

The Navy Seals have an expression for this in the US, that I think is appropriate (and which I may not paraphrase quite right):  “Equip the man, don’t man the equipment.”  BPM should be equipping process participants. But in order to carve out a space in the blogosphere or for their product offerings, some are finding need to criticize the very idea of BPM, rather than the specific implementations or practitioners who appear to be the problem.  Having seen a “bad” implementation of BPM, they’ve determined that BPM = Taylor = dehumanizing.  The only explanation offered for those who say that BPM is working (for themselves or their clients) is that they’re mistaken, or talking their own book.  If the ROI is big, it can’t possibly be right.  If customer satisfaction improves, it isn’t being measured over a long enough time frame.

It doesn’t mean BPM answers every problem, but clearly managing your business processes (BPM) can help you improve customer service.  To argue otherwise doesn’t make much sense – unless you are arguing with the specifics of how to manage the business processes (which isn’t the same thing as saying you shouldn’t use BPM at all) – a difference of tactics or approach, not a difference of doing or not doing.

MWD Advisors’ Neil Ward-Dutton has published a quick article on Blueworks Live:

The first represents a significant departure for IBM: Blueworks Live is now not only a platform for process discovery and modelling – it’s a platform for process automation and execution. Specifically: lightweight, immediate execution of simple approval worklists and checklist-style sets of activities though the quick creation of ‘process apps’. Process apps created on the platform can be immediately shared with other members of an organisation.

Look for more from MWD after the new version of Blueworks Live goes live on November 20th.

Phil gave the keynote at BPM 2010 yesterday, and Keith Swenson had the early coverage ready before EOD yesterday.  In this talk, it sounds like Phil has continued his main themes (since I can remember) of making BPM more and more accessible to the business.  As he often put it in the past, the IT folks are a small minority of the total population in a business (2%?), and “we want to focus on the other 98% of the people in the business”.

Every year this theme gets some tuning, based on technology and cultural developments.  This year the stats were updated a bit:

For every one 1 java programmer developing applications, there are 5 IT people supporting the technology infrastructure, to support the work of 240 business people.  Tools to date have all focused on the 6 people.

And the suggested general direction is evolving to include the idea of “following” elements of the business.  I’ve used the follow feature in Blueprint, and love it – sometimes simple features are compelling.  But I’d like to see “follow” functionality throughout the IBM Lombardi BPM solution – within the Lombardi Edition authoring environment, as well as in the run-time environment.

It sounds like Phil also took some shots at the standards effort behind BPMN.  This isn’t new – Phil has long been a proponent of having a standard, and having a standard storage for the notation.  But he’s also expressed his frustration in the past that the folks working on the standard were getting bogged down, taking too long, and getting too far into the weeds.  Fair criticisms that I think Keith and Bruce Silver and others would echo (including myself).  I’m glad to have BPMN, but I hope the standards folks take some time off and let it bake.

The central argument (quoting directly from Keith’s blog):

Citing an IBM study of customers, 2.5% of the processes are complex,  22.5% are somewhat complex (less than 200 steps),  75% are not complex at all.  This last category is done today by excel over email..  At Banco Espirito Santo the complex processes impact zero people,  moderately complex effects 2000 people, and the non complex effect 8000 people.  This organization has moved forward to allow business users to be “100% empowered to automate the non-complex processes”.  If your business is based on people (and there are very few companies today that are not) where is the value being delivered by your BPM?   Everyone is way too focused on the really complex processes.  IT was clear he felt that is what lead BPMN standards astray, and this research crowd should be mindful not to fall in the same trap.

BPM is a cultural issue, not a technical one.

(Neil Ward-Dutton focuses on the same part of Keith’s summary, with an emphasis on the cultural).

Keith comments that Phil stopped short of prescribing a solution to empowering business users to increase the support for business work… but I think he’s priming the pump.  He’s giving us a sense of what we’re missing today.  But if I know Phil, he has people working on it right now.

The future is focusing on the “B” in BPM – not the “N” in BPMN – and the vendors that can offer the most compelling solutions are going to reap substantial rewards.

So Jim Sinur really opened a can of worms the other day with his missive on BPMN, literally calling for it to burn baby burn – nothing like a gentle start like that to initiate a moderate discussion of the finer points of BPMN.  I couldn’t help but respond both within his blog as well as on our own blog.  I feel like Jim is letting the business off the hook – as he puts it – they don’t care about process, and they’re too busy making money to worry about process.  I think this is a cop out.  There is a comment thread on Jim’s blog that I’d recommend reading for the follow up discussion, and the original “burn baby burn” statement got walked back somewhat.

But the debate didn’t stay contained there.  Keith Swenson chimed in, taking advantage of the opportunity to pile on BPMN.  I can’t accept the black-and-white approach he is taking to the discussion, and so of course we had a bit of back-and-forth about whether BPMN is appropriate for no one in the business (his contention) or at least some people (my contention).  I was challenged to name people within the business who read or write BPMN, which was quite easy to do, because this is the kind of stuff we do every day for work.  I think the comment thread on his blog, and on Jim’s, or incredibly telling.

But there was also a great post from Neil Ward-Dutton on the subject, that captures my perspective perfectly:

Or – in other words perhaps – surely it’s not too much to ask non-IT participants in BPM initiatives to take a little time to learn some fairly straightforward modelling technniques?

From our case study work here I think what Scott is saying leads to a sensible, middle-ground answer – which is, that the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for “the business” is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that “the business” is some kind of homogeneous organisation with one set of skills, experiences and inclinations.

I literally could not have said this better myself. He goes on to make another important point I agree with:

At the same time, though, there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams. I’ve come across many BAs who know and use (aspects of) BPMN as part of their armoury. They’re not “IT people” – they have business backgrounds and they work in line-of-business departments.

Great read from Neil.

In the comments on this one, Keith takes a nice shot at my assertion that understanding just a few BPMN shapes will allow you to read someone else’s thoughts on a process, or to communicate your own basic processes to others:

Also funny is the comment that learning six (or 7) shapes means that you understand the non-trivial interactions between those shapes at run time without needing the programmer’s insight into how systems function. That would be a little like saying that learning 26 letters makes you a Shakespeare, or able to read all western European languages. (But I must avoid use of similes since this apparently is sometimes confusing.) BPMN certainly is useful is some situations, it simply isn’t useful in all situations.

For the record, I don’t find Keith’s “similes” confusing at all.  I find them inaccurate, misleading, and misrepresentative.  And when we turn the analogy on its head, I think that proves how pointless they are.  In practice, when people read Shakespeare they’re usually in school and get help from cliff’s notes, teachers, and fellow students.  Not unlike those working with business processes and BPMN … and other tools (six sigma, lean, value stream, etc.  ).  Once again, I’ll point out that analogies are illustrative, they simply don’t constitute proof or refutation.

Jakob Freund of Camunda commented on Keith’s blog and summed up a reasonable reader’s interpretation of both Jim’s post and Keith’s post:

I think the main problem is that in both blog posts (Jim and yours) this very important distinction between “all” business professionals and “business (process) analysts” was not made. Analysts are not programmers but very often part of a business department, therefore a subset of “business professionals”. To throw all “business professionals” in one pot judging there skills in working with BPMN (or whatever) makes a good headline, but does not say anything useful.

Furthermore, there has not been made any distinction between “creating” and “reading” BPMN diagrams, and between the extremely different grades of complexity a process diagram can bear (please excuse my bad English).

But those are exactly the parameters you always have to look at when judging modeling approaches (no matter whether they are control flow – based, grids, prosa or what ever).

I guess it just comes down to this: BPMN is quite useful.  It is even useful to people most of us would consider as “business professionals”.  But there are other quite useful tools in our business process management space, and there’s no reason not to use each one when appropriate.  I also recommend as practical reading, this post on practical application of BPMN by Jakob on his own Camunda blog.  I liked how he closed his last comment:

cheers from my customer’s office in Germany (currently introducing BPMN in a 80k-people company, and huh, it works for Business people, but it’s bloody hard work to make that happen  ).

Similarly, as I was writing on the same comment thread, I was about to head in to visit my customer, which also uses BPMN to communicate broad requirements between business stakeholders and IT.  Regardless of what the theory says, the practical reality is our customers’ businesses are using this stuff.

A while back, Bruce Silver wrote up another thorough review of a BPM vendor’s offering, and this time it was TIBCO’s ActiveMatrix BPM.  There were a couple of nuggets that jumped out at me:

1. TIBCO is pushing task distribution as being separate from process (or orthogonal, you might say).  It is an interesting wrinkle to their product.  I’ve run into a few cases where the “process” presented to me was really a “how to distribute work to the people on this team” problem, rather than how to manage the process or lifecycle of the stuff their working on (which might extend into groups that aren’t part of the same team).  But there have been only a few, relative to the total number of processes I’ve seen.
2. Apparently they borrowed one of the best features of Lombardi Teamworks (now Websphere Lombardi Edition): “The inline preview function allows playback of running forms from within TIBCO Business Studio.   This Lombardi-ish approach is carried forward in page flow modeling as well, using BPMN to describe each step in the page flow… an advantage (in my view) over the programmer-oriented approach of most ‘enterprise-class’ BPMSs.”
3. It sounds like they’ve added performance data tracking that approaches what Lombardi does.  I’ve been surprised that this early differentiator at Lombardi (circa 2004) hasn’t been more widely copied 6 years later.
4. There was another TIBCO BPM product, but I think that’s on the way out based on TUCON coverage.  BPM vendors need to take a page from Neil Ward-Dutton’s blog.  Bring your customers with you.

Thanks again to Bruce for covering all the product releases of note.