The folks over at ebizQ have started up a discussion on Best Practices when getting started with BPM. A couple of good responses from other folks so far, each one reflecting a bit about that person’s background or interpretation of “getting started” ! (Is getting started the point at which you decide BPM makes sense for your business? or the point at which you decide to evaluate BPM? Is it pre-vendor-selection or post-vendor-selection? … etc. )

I wrote a quick response last night (taking advantage of the free wireless promotion on American Airlines – thanks gogoinflight! (Incidentally, as much as it might seem like work/internet is invading one of the last places where you might have some thoughts to yourself, it really does make the time go by faster on the plane when you are connected).

Following is my off-the-cuff response to the topic, also posted on ebizQ:

There are so many best practices to consider. But I think if you are truly “just starting” with BPM, it is important to coalesce a core, multi-disciplined team to spearhead your early efforts. It will be important to invest in this team your vision:

• for the business
• for the business process management that will support that business
• for the role of this new BPM team in enabling that vision….

And that investment needs formal and informal time, group time and individual one-on-one time. This is the time to practice some of that L thing – Leadership. Take your team to lunch. Get to know them, make sure that they share your values at least regarding this endeavor. Hold whiteboard sessions to explain your approach, rather than just emailing out powerpoints (yuck).

Now. Who should be on that team?

1. Business SME (subject matter expert)
2. BPMS expert (expert in the tool)
3. (if #1 or #2 don’t have it, get someone with some Process Improvement expertise)
4. Integration expert
5. Project manager
6. Sponsor (um, likely that’s you)
7. Executive sponsor (someone who can go to bat for you, if you’re not an executive)
8. Add people to the team as it becomes clear what capabilities you’ll need. Add carefully. The first few people you pick are crucial.

You can have more than 1 of these, and you might have one person who plays more than one role, but you really can’t accept part-time contributions for the core team unless THIS is their first priority (outside of the exec sponsor). If they can drop everything else to help you, then you can accept their help. But if they have something else that is first priority, odds are that they will leave you hanging when you need them most. That doesn’t work for BPM.

In particular, why our own integration expert? because integration teams are notoriously the long pole in the tent for most BPM projects (and often BPM projects are required to go through whatever the current integration orthodoxy is). BPM tools provide good integration tool sets, but the software they integrate with has to be prepared to hold up the other end of the bargain – and that’s what takes so much time.  The integrations BPM projects require aren’t hard, but the integration teams are likely working on the “5 year plan” and your BPM pilot project is definitely not on that plan.

If you have the right people, and direction, you’re probably halfway there. Now get to work :)

Looks like BPM companies are starting to crow about their growth and reveue prospects.  Savvion announced that it won every competitive deal they were in, Appian announced the best first half in their history, and Pega announced 1Q earnings of $9M, though they havent (yet) announced Q2.

However, outside of Pega, who of course is publicly traded, the results lack enough meat on the bone.  If Savvion won every competitive deal they were in, and Pega‘s license revenue was up 60%, then that statistic tells me that Savvion is missing a lot of deals (maybe north of $50M worth).  Appian quotes statistics about customer acquisition and “new orders” but leaves us wondering how that turns into revenue – ie, if orders are up 67%, does that mean that Revenue is up a similar amount?  bookings?  or did the ASP (Average Selling Price) decline?  Can’t tell.  Further muddying things is the fact that Pega doesn’t break out any of its non-BPM revenue from its BPM revenue.

I haven’t seen Q2 or 1H announcements from Lombardi or Intalio yet – but if I missed them please chime in here and help me out!

UPDATE: Pega’s Q2 results came out, and it reported 25% increase in revenue from Q2 2008 to Q2 2009.  Pega’s CEO reports that they are growing faster than “the market” though I’m not sure if he means the software market or the BPM market in particular. 25% growth is a pretty good result in the 2009 economy.

UPDATE (8/25/2009): Lombardi issued a press release on its 1H2009 results.  In the press release, Lombardi reports double-digit growth (though 10-99% is quite a range), and it also reports being profitable and adding to its cash reserves.  Lombardi goes on to tout its historic growth rate, market share gains, analyst reviews, product releases, etc.

Phil Gilbert writes provocatively, as usual, in When Process is Your Product.  Fresh from a trip to India to meet with some of the world’s top outsourcers/offshorers, Phil asserts that these are the new strategic partners to the Fortune 500 and:

To put it bluntly, a great outsourcer may be better at quickly improving your business than you are. Why is this? Because, these companies are quickly achieving the cultural maturity required for BPM that eludes even the most progressive companies in the world.  [...]

If change is so hard, then why is it moving faster at outsourcers than at beleaguered companies? I think it is because process is their product.

I’m not going to debate his assertions, but that last sentence got my attention: … because process is their product.

Well, at some level, isn’t process everyone’s product?  Maybe not process generically – but the specific processes that make your business work?…  This concept gained a lot of traction when Dell was taking the PC market by storm with a better process than the competition, rather than a differentiated product (notebook, desktop).  But in some sense, the process of acquiring the hardware is part of the what Dell was selling – the lower cost structure, taking ownership of inventory at the last possible second, the customization, the quick turnaround.

So, aren’t the processes that your customers interact with part of what you sell?  And isn’t what you sell your product?  So, if it isn’t quite accurate to say that process is your product, is it fair to say that it is inextricably entangled with your product and with your customers’ perceptions of your product?  And with your company or brand? And then haven’t we come full circle?

I think the answer is essentially yes.  Therefore, whenever you consider outsourcing your product, you have to be careful. You don’t want to forgo outside expertise at the expense of speed or quality.  But you want to make sure that you absorb expertise and culture internally that will nurture and sustain your Product (your Process!).

Does this mean you don’t leverage outsourcing?  If I rephrase this to take away the locality aspect- does this mean you don’t leverage vendors?  of course not.  But I think it will be increasingly natural to demand a better process (product) from your vendors – you are, after all, their customer.  Phil writes:

But what if you could simply augment your business people in order to graft the culture of change? Is this a new value prop for the Indian companies?

I’m not sold that the IT outsourcing firms will lend you a BPM culture.  Too much time and distance and competing interests between staff for that.  But again, it doesn’t mean that you can’t demand good process of any vendor you work with, and long term contracts that imply more efficient delivery over time.

So if your “product” includes the processes that affect your customers, are you investing adequately in the process?  Are you investing as much in the processes that delight your customers as you are in the nuts and bolts of your product?  Are you investing in the processes that create repeat business?  In the processes that help customers extract more value from your product over its lifespan, or extend its useful lifespan?

If you’re not, it may be time to re-evaluate that.

Max J Pucher writes a pretty thorough rebuttal of the idea that BPEL matters.  He starts by pointing out that the defenders of BPEL often malign those who question BPEL’s utility.  Mr. Pucher has quite a few controversial posts and discussions in the BPM space, and this post is no exception. I can summarize his article in a few key points:

• BPEL is not widely supported.  There are over 200 BPM vendors, and less than 10% support BPEL, and by Mr. Pucher’s reckoning, their support is partial at best.
• Avoiding “vendor lock-in” is not a valid goal of BPEL – because there is still vendor lock-in with BPEL implementing products.  I happen to agree that it is a bit naive to think that software you buy from a software vendor won’t entail a certain amount of vendor lock-in.  Transferring execution details from one body of software to another and expecting complete faithful reproduction is non-trivial.  Just think about Java Virtual Machines – without a robust specification test to validate against, these JVM’s would never approach parity.  Even so, software vendors usually only warranty their products against particular JVMs and even JVM versions. He quite rightly points out that the combinatorics on database, OS, JVM, appserver, rules, security, etc. make it nearly impossible that an implementation can merely be lifted from one BPEL vendor and run inside another BPEL vendor’s platform.
• Since BPEL is XML that we hope never to lay eyes on, why is it the representation that we hope to preserve?  Aren’t the diagrams more useful to preserve?
• BPEL doesn’t address key business requirements – such as monitoring the execution of the process for important business metrics.  And the business shouldn’t really care how the process is executed so much as those metrics… So is BPEL missing the point?

His conclusion:

Conclusion: When BPEL and even BPMN are looked at from a pragmatic business need perspective the only acceptable benefit is that products that use them have similar functionality and people designing processes will find it easier to switch products.[...]

Well, this is a significant benefit – but it is not what the vendors of BPEL vendors will claim – “model portability” and vendor independence.  As usual, interesting stuff from Mr. Pucher, and a little different perspective on the BPM space.

Dennis Byron has picked up the torch for the stack vendors again in his latest missive on eBizQ. First we start with the fear (some call this FUD for Fear, Uncertainty, Doubt):

But for business process management (BPM) decisions in your company, the issue is pretty clear. Another leading BPM point product will bite the dust, raising the question whether there is a future for BPM point products. IT managers and staffers have to ask–again and constantly–do I want to bet my job and my enterprise’s success on BPM point products anymore? Or is it time to move to a BPM suite? (Forgetting the technical, functional or philosophical arguments for point products, I’m not sure that all the point product suppliers don’t want to be acquired anyway.)

Ah, so now we’re betting our jobs on these flighty little startups?  Well, and it turns out that the “Pure Plays” are, in fact, BPM Suites, not single point solutions – so perhaps he isn’t making a stack vendor vs. pure play argument?  I’ll leave it to Dennis to clarify.  In fact, during one sales cycle of a BPM pureplay against BEA, BEA attempted to convince the customer that the pureplay vendor was about to be acquired – attempting to scuttle the deal.  No more than 8 weeks later, Oracle announced their bid to take over BEA.  I’m not sure that the big boys are actually safer than the pure plays in this regard…

Next, Dennis moves to close the deal in favor of the biggest integrated software vendors in the world:

Of course if you finally bite the bullet on the BPM suite philosophy issue (vs. BPM point product), why not go all the way and buy into the entire Oracle, SAP, TIBCO–and now Software Ag–stack (vs. a BPM suite from a BPM supplier that does not develop and market an entire stack)?

Well, of course the answer to this is simple:  None of these vendors has a compelling BPMS suite when compared with the so-called “Pure Plays”.  This isn’t just my opinion, it is backed up by the last 6 years of Gartner and Forrester research in the BPM space – where essentially they find that 6 years down the road, the big boys are still “just 2 years away” from having a real BPM suite.  And the touch points between BPM suites and “the rest of the stack” are really well-defined, and based on open standards (web services that can be auto-discovered, J2EE containers that are nearly commoditized).

Finally, Dennis ends with something I really don’t understand:

But don’t compare the IBM deal Phil writes about with all IBM deals. As I said in my earlier blog post, don’t compare IBM with Oracle, SAP, TIBCO, etc. And don’t compare sales/marketing tactics with value.

I just have to ask the obvious question:  why not?  It isn’t the first (nor the last) time IBM will use this tactic on a deal.  In fact, it is probably IBM’s most common tactic against BPM suite vendors like Lombardi.  And why not compare this to the sales tactics of Oracle, SAP, TIBCO, etc. when we already know that they engage in similar tactics?  BEA did this with Fuego.  Oracle bought BEA.  Do we really believe they won’t engage in some of the same tactics?  SAP has a long history of doing this kind of thing as well. Apparently we’re just not supposed to compare them because… well, just because.  Or because Dennis says so.  That isn’t a good enough reason for me.

Look, I’m not saying that it is immoral or evil to do these things – it is just a business tactic designed to outflank smaller competitors (and smaller competitors have their own sales tactics).  But the reason this outflanking maneuver is needed is because the product they are pushing is provably inferior.  If it wasn’t, the IBM’s and Oracle’s of the world would love to go head-to-head with the little guys and pound them to dust.

Having been on both sides of this equation, I can tell you it was quite fun when you had the superior product AND financial resources to really take it to the little guy in a head-to-head competition.  When you don’t, the flanking maneuver can be effective so long as the customer values the other pieces you are selling, or so long as you can convince them that another product is actually the most important thing to focus on (preferably another product that the smaller vendor either doesn’t have or has very weak representation in). I think part of the challenge for the stack vendors lately is that most customers already own their raft-load of other software (J2EE containers and integration technologies and ERP systems), and so the customer doesn’t have a compelling reason to look away from the head-to-head value proposition of the BPM software evaluation…

Alex Schleber has a great post on why learning to Search is so important in the 21st Century.  He makes some great points in support of his argument that you need to be an expert in search to be more efficient and effective going forward, and then he offers some great search “tricks” to improve your results.

The fact that search is crucial is no mystery to me, though I can’t really take credit for that insight.  My mother, before she retired, was a Reference Librarian for the Medical library at the University of Florida’s Medical School / Shands Hospital.  She transformed her technology profile and skillset by focusing on search, which was the most useful thing a reference librarian could be good at after all.  She persistently taught herself how to do LexisNexis searches, Medline Searches, etc.  And then she began teaching classes to other library staff and medical students so that they would know how to perform extensive medical research queries.  During the ’90s, reference terminals were becoming increasingly available for students and doctors to perform their own searches.

I got my first summer job as a research assistant for a doctor doing endocrinology research at Shands. I was still in highschool, but I knew how to do reference searches, and my mother taught me a few tricks for narrowing searches once I found a good article to use as a reference.  I learned how to require terms, exclude terms, etc.  And I got the job largely on the strength of my ability to search (is it any wonder that when you were asked to find this background source material, it is called “research”?).

As the total volume of information increases, being able to perform effective searches only becomes more important.  It isn’t just the information on the Internet, which is problem enough for searching.  It is our own personal information that, for most of us, has exploded in volume.  But finding that emailed receipt, that account statement, the important message from your boss, or the report you were working on last year all gets harder without good use of Search.

So, BPM practitioners.  Add Search on your list of skills for today and tomorrow, right next to “BPM”.

(And if you haven’t added Alex’s blog to your reader, you should)

A quick recap of the stack vendor vs. pure play debate:

Round I occurred primarily on the ebizQ BPM In Action blog moderated by Dennis Byron, in the following posts:

• Appian/Why Not BPM?
• Pure Play vs. Stack Vendor
• Do Stack Vendors Stifle Innovation?
• How Do Stack Vendors Price BPM Software?

I think Round I essentially ended with Dennis and I agreeing to disagree – but I think the majority of comments that got past moderation supported my view.  He asked me for specific examples of stack vendors engaging in this behavior of giving away BPM while charging for, say, Websphere – before he would believe my assertion that stack vendors will give away a component against a pureplay vendor to win a deal (not just in BPM, but in any space).  Well, unfortunately any information I have along those lines is not something I’m able to disclose except in the most general way, which wouldn’t fit his definition for specific data point.

Round II is captured best in two blog posts on the BP3 blog – (and I welcome comments on our site, as they are only moderated after the fact – your comments will show up right away, and you’re only subject to moderation if they are viewed to be spam by askimet).

First, there was Stack Vendors vs. Pure Plays, and then there was a followup about Oracle’s acquisition of SUN.  In the latter post I focused on why stack vendors don’t have enough focus to really innovate… In the former post, I focused more on the overall debate:

[...] if a vendor is giving a piece of software away, you should be suspicious- anything a vendor is giving away for free (or nearly so) isn’t likely to get a lot of investment of R&D dollars going forward.  Software companies tend to invest where they see a competitive edge, and they tend to discount and under-invest where they don’t.  It isn’t irrational behavior, and it isn’t a question of good/bad or good/evil – its just the trade-off of stack versus pure play.

For some reason, others doubt these basic laws of Software physics, but I don’t.  As you can imagine, I was quite pleased to be vindicated at least partly by a recent post from Phil Gilbert, President of Lombardi, entitled with the usual flair:  “Flash: Free IBM BPMS Worth Exactly What it Costs” (for the humor impaired, he’s saying it is worth exactly the zero dollars it costs to buy it… ).  Phil rips IBM pretty good in his post, and I couldn’t resist quoting him…

So, here it is, quoted for you Dennis:

Today one of our customers said they were told by IBM: “why spend your money with Lombardi, we’ll give you our BPMS for free.” I finally agree 100% with IBM on something: their BPMS is worth nothing. Getting a cheap BPMS is like buying a dancing elephant for a dollar: cool, but who can afford to feed it?

I particularly like the dancing elephant line… but for Dennis Byron, I think you have your specific example.  Let’s take that elephant line again though.  Right, someone has to feed the elephant.  This isn’t just you, the customer.  Yes, Phil argues that the customer will have greater development and maintenance costs, and fewer process benefits, using IBM’s BPMS than by using, say, Lombardi’s.  But it is also about IBM.  How will they afford to pay their development staff on their BPMS if they are giving it away?  Someone has to be paying for software in order for IBM to maintain their development team – they have to feed the elephant.  If they can’t explain how many developers they have, how much that costs, and how their zero price solution will pay for those developers, you have to wonder how long Big Blue will keep making that investment, no? This same logic applies to smaller stack vendors, only moreso – they don’t have the financial resources of an IBM.

How else to Stack vendors use undue leverage to get a sale in a software category they aren’t really any good at:

But this notion of getting “free” or highly-discounted software from strategic vendors has currency. How many times has your company picked up some crap from some vendor because it’s on a discount schedule and you have to buy x amount of software each year to “maintain your discount.” So let’s discuss the cost of software, and the value of software.

Yep, that’s right.  They get you to buy into the notion of “maintaining your discount.”  Wow.  I sure hope my local car mechanic never learns that trick.

I have another example.  The McDonald’s near my office started giving away McCafe drinks earlier this year – to get people to try them.  I tried my free McCafe – and it was so bad I went screaming back to Starbucks.  The difference between a McDonald’s and Stack Vendors is that at McDonald’s their food/drinks have to be good enough to get my return business – I tasted the drink, and rejected the free value proposition.  At a big Stack vendor, they’re hoping you don’t actually “drink” that free drink – they just want to book the revenue, prevent a “competitor” from getting a toehold in their turf, and help you “maintain your discount.” If you don’t taste the software, you may never know you’ve been had.

As long as IBM is giving BPM away for free, maybe its time to ask why Websphere isn’t free… after all, JBoss is… Maybe they can explain why Websphere is worth some coin and JBoss isn’t?  And then maybe you can ask IBM why that same logic might not apply to the BPM space?

Phil, thanks for re-opening the subject and thanks for a very entertaining read!

Quick update: from a more recent Dennis Byron post on Open Source vs. Licensed Software:

The IBM-sponsored speaker is Matthew Brown of Forrester and the subject is portals rather than BPM but the findings and the underlying thought process can be applied to any project. The message is simple: open source Ts&Cs are like any other license Ts&Cs. And license Ts&Cs are only a small fraction of your IT project costs whether it be for BPM or anything else. And sometimes open source Ts&Cs can dramatically increase the rest of the IT project costs. To the caution of “pay me now or pay me later,” add the caution “what I give you with one hand, I take away with the other.”

Let me put this in context… IBM came to this conclusion:  License costs are a small fraction of your IT project costs.  Apply this to the debate above – that free BPM software can incur costs that far outweight the licensing costs of the paid BPM software  – whether it is opensource or just free.  And you’re actually more at risk if it is free, but not open source because you can’t modify or improve the source code yourself…

Well, this was a surprise for me this week – the news that Software AG (SAG) is buying IDS Scheer.  Clearly there are complementary businesses from the perspective of what they’re tackling (SAG being integration centric, IDS Scheer being very modeling and enterprise architecture focused).  Everyone seems to be waiting for the other shoe to drop – what will Oracle, SAP, and other players in the space do as a result of this acquisition?  Are more acquisitions to follow?

As Forrester points out, “IDS Scheer needed an execution engine in order to remain relevant and credible in the eyes of process pros responsible for expanding enterprise BPM initiatives.”  So it looks like a good fit from that perspective, and also from the point of view of altering SAG’s image as being too integration-centric (reinforced by acquiring Webmethods).  Forrester expects a successful marriage, with the “big losers” being the big partners of IDS Scheer: Oracle and SAP.

More coverage from “BPM in the Real World” on ebizQ here.  Based on a reading of posts on Twitter, there is some speculation that SAG now becomes a tasty target for SAP.  But then, SAP isn’t known for paying a big premium in its acquisitions…we’ll see.

Jim Sinur wonders allowed whether you can Time Box BPM efforts effectively… and concludes that in some cases you can, in some cases you can’t.  In favor of the “yes” argument:

Benefits flow early and the project sponsors look like heroes. Success breeds success and a BPM program can take off early. Anybody want to say “no” to instant savings?

Indeed, who would want to do that!? And then Jim puts up another strawman for the “No” argument:

What sometimes happens when this approach is taken is that sooner or later a project that implemented benefits may have to give them back to help the overall process. [...]

Not only might it knock out strategic benefits, the conversion costs could wipe out a period of the savings. Why make false starts when you can do it right once?

Well, quite frankly, you can’t do it right once.  That is the false choice in the comparison.  IF you could do it right once, this would be a valid decision tree – but since you CAN’T do it right once (with any reasonable probability), this point doesn’t hold much water for me.

I don’t believe this is a six-on-one-hand, half-a-dozen-on-the-other issue.  Time boxing works – and specifically it works more often than a big-bang deployment.  The point is that since we can’t get a software release right in just one release, the goal is to approach the right answer increasingly accurately across a set of smaller, less expensive releases rather than one big release.

Yes, there is the caveat that you must keep corporate objectives in mind, and that in a future time box, some of the gains in one area may slip in order to achieve a bigger overall gain.  But in practice I have experienced that kind of “back-sliding” as a pretty unusual circumstance.

When giving back benefits did happen, it was a classic case of “squeezing the balloon” – where one group with relatively inexpensive staff optimized their process around reducing hard costs (measurable as headcount).  They neglected that their optimization created additional work for other parts of the organization, where the staff was actually more expensive – and therefore, they increased overall cost to the organization instead of reducing it.  But the increase of cost can be hidden as soft cost – a slightly decreased productivity by a large number of people is difficult to notice via anecdotal or sampling data.

Time boxing is key for creating a pattern of delivering, of being accountable, of having a delivery process that has integrity.  The alternative has a much higher probability of failure.  In this blog, we typically refer to “time boxing” as “Iterative Development” and time boxes as “Iterations”.  But both terms are valid taxonomy.  They’re also similar to concepts in the Customer Development process (generally popularized by folks like Steve Blank and Eric Ries among others).

I’ve been a skeptic of XPDL as the pre-eminent format for BPMN-drawn Models, but I’ve also been encouraged by Keith Swenson’s efforts to prove that it could be the de facto standard for BPMN model exchanging.

But it looks like my judgment that XPDL would only catch on with vendors like Lombardi (who have been beating the drum for BPDM and BPMN2 for some time) only if BPMN 2.0 didn’t sufficiently address the interchange problem might be a little off.  Lombardi just announced that its Blueprint July ’09 release supports XPDL!  It could be that Lombardi is voting with its feet – perhaps BPMN2 doesn’t seem to solve the problem(s) they were hoping it would with regard to model interchange.  Or, perhaps they see XPDL interchange as the Right Now solution, and don’t see an advantage in waiting on BPMN2 support. After all, not only would Lombardi have to build the BPMN 2 export/import functionality, they would then have to wait on myriad other modeling tools to pick up the baton in order for there to be anyone to “interchange” with.

By picking up XPDL support, Lombardi Blueprint can now exchange models with a host of other modeling tools listed on the XPDL vendor site (perhaps Lombardi will now be added to the site).  Bruce Silver has already assessed portability between Blueprint and Process Modeler for Visio.

Update:  more info from Keith Swenson on his blog, regarding exporting from Blueprint and importing into Fujitsu’s Interstage BPM.

In a recent post, the Case Against Window Dressing, I pointed out that a process can be deployed with nearly all the integrations scheduled for version 2, and that window dressing should be kept out of the project in the first version.  Sandy Kemsley pointed out:

Unfortunately, if you’re dealing with an enterprise that insists on having everything in V1 because they usually don’t get a V2, it will be hard to break the pattern of over-building.

She’s right.  Its hard. Here are a few coping tactics to get you past the Version 2 Barrier:

1. First, admit you have a problem.  Take an honest self-appraisal of your organization and make sure you understand whether you’re organization is going to either have trouble buying into a multiple-release approach, or whether they’ll have trouble believing it will really happen.
2. Try to line up organizational support and funding for more than one version up front.  Don’t wait until version 1 is on the verge of deploying to look for budget for version 2!  You have to line up the support early.  In order to get the support, you need to be willing to accept conditions, such as showing a certain ROI or meeting certain budget constraints for version 1.  If you don’t line up the budget for 2 versions…. Break your release into two versions anyway, within the approved budget.  Find a subset of the process that garners ROI without using up all of your budget.
3. Show incremental releases that don’t go to production.  The point of this exercise is to show progress to your stakeholders.  Get the business used to seeing interim progress during your project.  Get IT used to being accountable for proving progress throughout the project and not just using status reports to do it.  Don’t show anything fake.
4. Next, get the business involved in prioritizing what goes in and out of the next incremental release.  The incremental releases are your chance to get prioritization input from the business while the project is still in flight.  That’s important when you’re working on a fixed budget.
5. Finally, live up to the commitment you have made to get started on V2 right away.  Or even before V1 ships, if you really want to send the right message.  Don’t put the team on hiatus for three months.  Get started.  Odds are that there are a set of ideas that did not make the cut for V1 but that have obvious appeal or ROI.  Get started working on those right away.

No doubt, it takes leadership to accomplish these things, but is it too much to ask to expect leadership to support a vision beyond a single roll-out of a process?

John Reynolds’ has a good post over on his blog on Programming Language Sociology and he draws connections between his work in the C++, Java, and BPMS communities.

I have slightly different biases… My early experiences with C++ were using standard template libraries to generate “typed” lists of objects for a class on C++ in college.  At the same time, I was taking a class on NextSTEP programming (CS193d) which employed objective-C.  I discovered the elegance of having all objects respond to standard messages, and I experienced first-hand the “problems” that C++ purported to address with heavy-handed solutions.  Many of those “problems” weren’t really high-occurrence defects for me, as a programmer – paying the price for a solution to a problem I didn’t have!  (as an example, take the strongly-typed list container…) So I was never a huge fan of C++, but unfortunately (for me), it won the battle over objective-C.  (The silver lining, of course, is that Apple’s platforms for both the Mac and the iPhone make heavy use of objective-C, so I can at least enjoy a renaissance of objective-C in the mobile world)

I considered Java as a language a step up from C++.  I think it better-addresses modern programming problems – machine portability, connecting to remote objects and services, memory management, etc. It isn’t that there aren’t great applications for C++, there are, but Java better addressed the next set of challenges.

You could consider BPMN a “language” that addresses the current (for John Reynolds and I, and for many in the IT space) problem space of business process definition and implementation.  As John says, part of what makes the BPM tools exciting is that they are good tools for speaking the language that solves business process problems.  The tooling has a long way to go to meet our expectations of what it will do for us in the future, but it has come far enough that there is no longer any excuse for putting off BPM implementations, waiting for a better mousetrap.

Lately there’s been a bit of a buzz about CRM.  Not sure what caused it, but here are three thoughtful articles on the subject:

1. Derek Miers’ post on Case Management revival
2. Bruce Silver’s commentary regarding a new OMG spec RFP for Case Management.
3. Paul Vincent’s blog for Tibco, where he mentions PRR and DMN… and Case Management yet again…

I’m still waiting to see a really good case being made that Case Management requires or lends itself to different technical solutions than, say, BPM.  Having said that, I’m also sensitive to the fact that as BPM was picking up steam, many in the SOA stack community wondered why BPM wasn’t just a “feature” of SOA.  The fact that I don’t yet have the information to prove to myself that Case Management has technical requirements not addressed by BPM, does not mean that such information won’t be forthcoming.

Update: Bruce Silver has another update – apparently there was a bit of controversy about the case management proposal at OMG recently, and a little bit of blogosphere dust-up resulted.

Having just referenced Connie Moore’s thoughts on collaborative BPM, it seems a propos to then turn our attention to “the process wiki” – which I learned about through Keith Swenson’s blog post (“Rise of the Process Wiki”) on the subject (and I’ve since seen a couple of additional references).

If something like the process wiki takes off, it could really change some things in the BPM world.  I’m still a little underwhelmed by what is already in the wiki, but I think that is partly because the vendor-specific collaboration forums offer more interaction with the models directly.  But, where I can see real value is in promoting discussion of the processes that are posted, trade-offs in design, etc.  That’s where it would play to a wiki’s strengths, in my opinion.

You can find a pretty good discussion of the site on Keith’s blog, as it dovetails nicely with his interest in model portability and XPDL as a vehicle for such.

Connie Moore’s (of Forrester) recent posting on collaboration and BPM got my attention primarily for the following quote:

But I’ve been a voice crying in the wilderness. I’m not kidding.  Whenever I would talk about collaboration with BPM vendors, they would somehow think I was talking about straight through processes between companies. That’s collaboration, right???  And whenever I would talk about BPM with content and collaboration vendors, they would look at me blankly and mumble something about using simple workflow for approving documents.  It felt like two disconnected worlds that desperately needed to find each other.

I can very well imagine this conversation with these vendor communities.  Connie sees reason for optimism, and I agree – but we still have a long way to go on this front.  Keep fighting the good fight!

Appian has just recently announced updated Sharepoint support on their website.  Support for wikis, and other bottom-up IT technology like Sharepoint, is likely to gain relevance in BPM deployments, in my opinion.  ActionBase takes one approach – allowing more adhoc processes to be defined in Microsoft Office documents.  It looks like Appian is enabling task lists to be treated like process steps in Sharepoint.  From Appian’s release:

Of course, many other BPM companies offer their own version of SharePoint integration, but I would like to think Appian has offered a unique spin on this integration that raises the bar for all other BPM vendors.  Appian not only allows SharePoint users to easily publish task lists and process reports in native SharePoint dashboards as webparts, but also Allows process designers to control and orchestrate all objects in SharePoint in an Appian process model.

Some of the other features discussed, such as creating a sharepoint site to support a process or process instance, are more similar to offerings from Lombardi, which also offers a Sharepoint integration.  I’m curious which BPM package offers the best Sharepoint integration capabilities, but I haven’t the time and resources to do the research on that front!  Opinions welcome in the comment section -