Gary Comerford:

I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the ‘whole level of detail’ issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.

So true.  BPM depends upon building the right abstractions for your business, and business processes.  Getting to the right level of detail (rather than the lowest) allows us to build solutions at the right level.  When you see flowcharts covering a wall (or more than one screen in Visio) – the yellow flags are waving.  Slow down, caution.

There are lots of arguments for and against Apple’s integrated approach.  As I recall from economics and watching certain industries, there’s an efficiency to horizontal scaling of an industry. But, we’ve seen the design benefits of the integrated approach with Apple.

But if you’re trying to put products into consumers’ hands, or customers’ hands, there’s a cost to depending on horizontal layers of industry to delivery much needed components into your end-device or product.  The risks are manifest in RIM’s reported results this quarter:

RIM just announced on its earnings call today that it won’t be ready to release new smartphones running the QNX-based BlackBerry 10 OS until late 2012.  [...]

Co-CEO Jim Balsillie said the company is waiting for new chips that will allow RIM to make dual-core phones with LTE. Those chips won’t be ready until late next year.

So… the phones were first late in the upgrade cycle, waiting for the work to get software ready on QNX… then they were later still waiting on dual core chips (as of early this year).  Now they’ll be an additional year late… because they’re still waiting on dual core chips.

Of course, one wonders why they can’t release these phones with 3G and dual-core chips.  Seems to work okay for Apple.  Maybe it is just a smoke screen.

But if it isn’t, it is a cautionary tale against building product plans against moving targets.  Don’t assume another vendor’s components will be there for you unless they already exist or can be produced in volume today.  Apple’s approach to getting deeply involved in the supply chain pays dividends by helping avoid these kinds of public delays.

(So does not announcing a product release until you are, you know, actually releasing a product)

Fabienne: Whose motorcycle is this?
Butch: It’s a chopper, baby.
Fabienne: Whose chopper is this?
Butch: It’s Zed’s.
Fabienne: Who’s Zed?
Butch: Zed’s dead, baby. Zed’s dead.

- Pulp Fiction

There have been raft loads of articles and blogs written about “Millenials” over the last few years (not to mention Generations X and Y).  Chris Taylor has decided to take his shot, on BPM for Real-  “Does Generation Z have a ’2-second advantage’”?

What happens when a whole generation that has lived their entire lives with the ability to feed information to themselves (and at a time and format of their choosing) becomes the dominant group in the workforce?

My bias against these generational stereotypes is well recorded, but let’s review this one.  I expect predecessors to Generation X wondered what would happen when kids showed up at work who grew up their whole lives with a computer at home.  Of course, only a minority of kids at that point – but still more than in any previous generation.  Maybe it is because I was one of those lucky kids that I’m not particularly concerned about the changes this will effect on our society or workplace.

Chris Taylor explains:

I recently read The Two-Second Advantage, a Malcolm Gladwell-like book about how we learn and build mental models that predict what will happen next based on experience and data that arrives so quickly it would overwhelm–if not for our learned ability to work through it. Most of Generation Z has been living in a state of information overload longer than any human beings before them, and the result should be a capability to handle a complex world even better than we do. They should have more complete mental models for the workings of the world due to their ability to know whatever they choose, whenever they want. If you buy into the ideas of this book, they are likely developing a “two-second advantage” that should give them a leg up on the older generations.

Perhaps the new generation will be better equipped than the previous.  However, the world will change fast enough to make them feel as ill-equipped for the next transition as many of of those writing about Generation Z appear to feel now.  By objective measures, the rate of change appears to be increasing.

But the way information-technology-adept people deal with the world is not by addressing its complexity, typically.  It is by simplifying it.  Rather than having more complete models, they technologically adept will have meta-models that don’t require completeness.  We just had the Austin City Limits Music Festival here.  In the complete model world, I’d know pretty much all the acts performing, and that I was interested in, and on which of 8 stages they’re playing, and at what time.  I’d do my research before the concert and figure it all out in advance by sampling songs by various artists that are performing.

In the simplified world, as I’m walking to the concert I download an iPhone App that tells me what bands  are playing on what stages at what times.  I can quickly browse the bands and see if any of them appeal.  I can group-text my friends to find out what they’re listening to (more than one stage is active at the same time) – and that’s built in to the app if I don’t already use a group-texting application.  You can guess which of these two approaches describes my ACL Festival experience…

Think how “getting directions” has changed since GPS and maps have become so ubiquitous on cell phones.  You don’t really need directions, you just need a destination.  The only directions someone needs to give you are the little bits that never show up in a navigation system or map: “don’t turn in the first drive, use the second driveway”.

So the software and hardware is delivering the results of increasingly complex interactions with other systems.  Let’s face it, my iPhone computing directions to a destination using maps and GPS is much more complicated from a systems view, than someone scribbling directions on a piece of paper.  But the end-result to the user is actually simpler than the old way of doing things. I think that’s actually the metaphor to use going forward. The touch interfaces today give even infants a chance to interact – because the cause-and-effect is more clear.  So the interaction isn’t just the tactile (as it might be when they play with a physical keyboard), it is direct manipulation – something their brains are already wired to learn from.  The systems of the future (software and hardware) are likely to appeal more directly to the way our brains already work – and thus feel more natural to us, even as they get more complicated in principle, behind the scenes.

It isn’t really an issue of generational advantage- if you buy into Malcolm Gladwell’s thinking on practice – it takes about 10,000 hours to become an expert at something.  Any one, of any age, can become an expert if they put in that 10,000 hours of purposeful use with technology.  There’s no reason to let your kid be the only one in the house with a “2 second advantage”.  I watched my own parents leapfrog technology shifts.  They both bought iPhones before most of my friends.  They still have trouble using Microsoft Windows.  But they use their iPhones and iPad, and Kindle, just fine.  Don’t let these generational tags define you, or your views of others.  Besides, the idea of “2 seconds” being a short time is already a sort of generational bias, isn’t it?  But it does roll off the tongue better than a 2 nanosecond advantage.

Keith Swenson just put out an interesting blog post on Self-Organizing Business Networks- there’s a focus on what makes for enterprise social software, and what the “social” part really means.  But this particular bit caught my attention:

Most current systems are built in such a way that they require a technically knowledgeable person to make these reconfigurations.  I am NOT suggesting that we simply open these capabilities up to business users.  Instead, I am suggesting that the system should be built from the very beginning to allow this kind of change; so these changes are safe for users to do.  It needs to be easy as well.  A system that requires coordinated changes in multiple places (such as adding a network user, and adding them to access control) is going to be difficult and error prone.

Directionally this is right – it isn’t about exposing business to the complexities of IT administration, it is about writing software, apps, or mediums that don’t require such technical reconfigurations.

There’s an argument that says the world is too complex for humans to understand.  Further, that by thinking we understand cause-and-effect, we’re doomed to act in ways that have unforeseen (usually negative) consequences.  It is a really interesting debate, and informative on the more than two sides represented.

Personally, I found myself rejecting this notion as useful.  Not that the notion of complexity isn’t useful – but letting it paralyze you is not useful.  When it comes to running your business, simplicity is more powerful than complexity.  A combination of relatively simple interactions has more power than a complex single interaction.  Simple interactions are more replicable, more scalable. I would focus more on enabling “emergence” than disabling decision-making by leaders.

Simplicity and abstraction go hand-in-hand.  The iPad has a significant amount of complexity baked in – from the hardware, to the software, to the production processes that lead to its creation, to the design processes that lead to its conception.  But to me, it is just a glossy glass enclosure that responds to my touch.

Does my touch cause the apps to do what they do?  Actually, it doesn’t matter whether touch is causal or not – it is, at minimum, so highly correlated between action and reaction that it feels like causation.

And that’s what we should be striving for in our businesses – that our actions would achieve the results we’re looking for – will feel like causation – though there may be a complex choreography and it may not be driven top-down.

There was a truly fantastic quote in the original HBR article:

“If you want to build a ship, don’t drum up people together to collect wood and
don’t assign them tasks and work, but rather teach them to long for the endless
immensity of the sea.”

- Antoine de Saint-Exupéry

Sometimes simple is best.

IBM Impact Blog has published a guest post written by yours truly.  It is part of a four-pillar effort, and the theme for the pillar of my post was simplicity.  So why talk about upgrades if the goal is simplicity? After all, there’s no such thing as simple upgrades of in-flight process data is there?

My thought in writing this way was to focus on how to simplify your approach to upgrading, and also to cover the good work IBM has done to make upgrading easier when you can’t take some of the shortcuts we outlined.  You can find more material on the topic of simplicity on the BP3 blog using the simplicity tag.

Upgrading is also fresh on IBM customers’ minds these days.  We’re getting more requests than ever for help upgrading.  Happy to contribute back to the community a little advice about how to get from point A to point B.

Joannes Vermorel, of Lokad, has guest-posted on A Smart Bear blog on the topic of email.  Specifically, why your company should have a single email address.  But to the BPM consultant, it reads like an email process manifesto for your company.

It is a fascinating read on (email) process, thought that wasn’t necessarily the intent.  Some of the highlights:

1. The dangers of building too much process too soon – before the true requirements emerge.  Spinning off too many email addresses complicates your organization’s ability to respond correctly.
2. The problem with exposing your internal processes and organizations to your customers and partners, by having many different contact email addresses for your company.  Your customers and partners don’t care about your internal structure, they just want one contact point that works.
3. How to deal with inbound email flow – routing emails to the people most appropriate to respond.
4. The benefits of shared information within your team.  Everyone knows about the communications happening, and can see the history and context.

Along the way, we learn from Joannes that not advertising a public email is bad.

What are the benefits to moving to a single email account?

• Improved responsiveness
• Smarter replies (better quality)
• Peer reviews of email communication
• Better Morale
• Resilience to turnover

That’s a pretty good benefit from a process change.  Joannes sums it up:

Finally, I believe that the single email approach remains valid no matter if you happen to be two guys in a garage or MegaCorp Inc, but I digress. Are you still exposing a number of emails not equal to one? What are you waiting for?

I think the biggest point to take away – is keeping it simple for customers, and not foisting your own company’s complexity upon them.  That sounds like a great principle of process improvement to me.

Adam Deane on Business Users and Programmers:

But the best differentiator pitch that I’ve heard being used is the “business user oriented” vs “programmer oriented”.
The claim is that business users can use the tool. I think it’s a great differentiator.  Although it usually doesn’t have much truth to it – it’s still a great market positioning pitch.

You see.. (and I’m trying to hide my sarcasm here..) BPM tools that use programming are bad for you.

If you need to open Visual Studio to build a workflow – it means you need skilled programmers, which means high salaries, and they need to write code, which means you need a tester, a team leader and a project manager (more salaries).

Every time the customer wants to change the business process you need the programmers to recode, recompile, retest (long deployment, or no changes – you can pick). Sophisticated code means that you need to rely on the IT team which means that you are tied in with that programmer/team. If the programmer leaves – no one will dare to change their code (who wants to be responsible for code that someone else wrote.)

“If you need to open Visual Studio to build a workflow” – then you’re doing it wrong.  A good bpm tool doesn’t require you to build your workflow in C++/C# or the like.

Of course if you’re opening visual studio to do an integration – have at it.  To build something custom that will plug into your BPM solution – have at it.  BPM should make certain things easier than traditional development tools (and a “workflow” sounds like one of those things to me).  It doesn’t mean that you won’t still need traditional development tools for a BPM deployment, but you shouldn’t have to write your process flow in assembly language any more than you should have to write it in C++.

Incidentally, I don’t agree that “business can do everything” is a good pitch, though I do agree with Adam that it is horribly oversold.  The business and IT have to work together to make BPM successful (or, arguably, nearly any long-term IT or business investment).  Vendors oversell this all the time, which accounts for Adam’s sarcasm.  But, conversely, companies purchase tools that bring too much complexity to the simple stuff, or tools that start simple but don’t scale with complexity.  What do I mean?  I mean that as you add more process intelligence to your tooling, complexity should increase at a linear (or less) rate.  If you experience complexity increasing at a greater than linear rate, you’ll hit a point where the system can’t be maintained – the interconnectedness and interdependency of the system is too complex for someone to properly understand, modify, and maintain.

That’s why it is important for the “workflow” to be simple.  Because it can be.

The phrase “It just works” didn’t first come into use during Apple’s WWDC 2011 keynote in June.  I first heard the phrase with respect to software when I was taking a NeXT programming class (cs193e) at Stanford – Julie Zelenksi, our lecturer, had three phrases that stuck with me for life:

• “Right?!” – affirmation, agreement, eliciting agreement, filler, etc.
• “That’s a feature” – when confronted with a bug or lack of a feature… obviously meant in jest.
• “It just works” – describing the magic of many of the object oriented techniques we used in class – reflection that just worked, prototypes, messages, Interface Builder and AppKit.

(I wouldn’t even claim to be there near the beginning – these phrases had the well-worn comfort of years of personal use even the very first time I heard them.)

At WWDC, Steve Jobs trotted out the phrase again, as a worthy successor to recent superlatives like “magical” and “amazing”, and it caught the attention of journalists (Philip Elmer-DeWitt has a great collection of quotes from some of the best articles covering the WWDC). But as MG Siegler notes, it isn’t an accident when Jobs picks a catchphrase like this.  It is intentional choosing and repetition to enforce a message.  I don’t doubt for a second that the *internal* messaging behind the scenes at Apple was similar, with Steve Jobs demanding that iCloud services “just work” without requiring explanation as to why or how.  Its a perfect kind of demand – no, don’t tell me the 15 reasons something doesn’t quite work the way I want – just make it work.

This contrasts harshly with the Android ecosystem, as noted by John Gruber, and fully expounded upon by Harry McCracken in Time (John captured the money quote perfectly):

But there’s never been a time when so much of the new stuff I look at is so very far from being ready for mass consumption. Sometimes it’s a tad quirky; sometimes I can’t get it to work at all. And when I call the manufacturers for help, they’re often well aware of the problems I encountered.

The pressure Apple is putting on other handset and computing manufacturers is causing them to release buggy, beta product.  And their primary software partner this time around is a company that mostly ships products in Beta status (Google):

One notable example was Motorola’s Xoom tablet, which arrived back in February with rain checks for three of its notable features: 4G support, Flash, and support for its MicroSD slot. Today, some owners have the update that enables MicroSD, others don’t, and everyone’s still waiting for the overdue 4G upgrade. Sounds like a beta product to me.

Contrast to what Apple is attempting to do – “it just works.”  As MG put it with respect to iCloud:

With iCloud, Apple is transforming the cloud from an almost tangible place that you visit to find your stuff, to a place that only exists in the background. It’s never seen. You never interact with it, your apps do — and you never realize it. It’s magic.

Exactly.  The cloud is in the background rather than front-and-center.  And while Google provides for a good cloud experience for technophiles like myself, the cloud *is* the experience, via the browser.  Apple wants the cloud to be invisibly supporting what you do with your devices – devices Apple sells.

This focus on simplicity has benefits.  iTunes may not be the prettiest software from a firm known for good design, but “it just works” – and it appears to be the first platform approaching 1 billion users in a logarithmic way even as it passes the 220 million mark. iOS’ growth curve is following an even steeper trajectory.  The market seems to be saying that “it just works” matters.

MG Siegler follows up with:

And the truth is that this is the point where we may really start to see some truly fundamental differences between Google and Apple after the past few years going head-to-head with feature matching. Apple is going after consumers who have absolutely no idea what the cloud is, and don’t care. Apple is saying they shouldn’t care. It all just works.

Actually, it isn’t just targeting consumers who have no idea what the cloud is.  It is also targeting technophiles who just frankly are tired of dealing with everyone else’s beta software.  At some point we want tools that “just work” so we can get our own, more interesting, technical work done.  If anything, the most advanced technical people I know are even *more* appreciative of the magic behind the black box.

But lest you think that Apple has given off the feature-matching in favor of the iCloud, Marco Arment reminds us that actually, the feature completeness efforts of Apple are like a steamroller:

Every time iOS or the iPhone is updated, Apple picks away at that list. They started with the big ones: purchase price, 3G, GPS, copy and paste, advanced security features, Exchange, multitasking. More recently, they added Verizon support, and it wouldn’t surprise me to see them quietly hit Sprint and T-Mobile in the future, picking away at that list even further.

With iOS 5, they’ve hit tons of relatively minor shortcomings. Notifications. Quick camera access and a hardware shutter button. Wireless sync and backup. They’ve even added a preference to have the camera-flash LED blink on new notifications, supposedly as an accessibility feature, but also conveniently to appeal to BlackBerry owners addicted to that blinking LED.

Apple has steamrolled over almost every meaningful advantage that competitors have. And they’re not stopping.

I think Marco is right.  Apple started with the differentiating NEW features (integrated iPod functionality, and touch screen interface) and then rapidly added to its arsenal (3rd party apps, cut-copy-paste, multi-tasking, etc.).

This is just further evidence, if that was required, that Simplicity is a great design principle.  If calling it “it just works” helps drive the point home and make it an easier rallying point, I’m all for it.  BPM and enterprise software vendors take heed-  we all need a bit more “it just works” in our software experiences.   This logic also needs to inform consulting firms – we need to treat usability and user design as a first class citizen – but failing that, we consultants need to ensure that our processes “just work” for our audiences…

Anatoly has posted another process pattern: the Incoming Processor Pattern.

It is a good pattern – and actually forms the basis for a lot of variants of that pattern (in a sense, it is the base case of a wide variety of patterns).

Essentially, Anatoly describes a process that begins with a message start event listener:

Beyond that, Anatoly points out there is a challenge with respect to having more than one instance of this process:

But here is the question: how would the message from client John Smith find its way into specific process instance associated with him? Let’s not forget that there are about thousand of instances behind the single pool “Credit card issuance” shown in the diagram. [...]

But when a message is sent into the middle of a process (i.e. to the intermediate event) one must specify the process instance ID. Moreover, the process instance ID is the internal BPMS data so we can’t expect that a message from an external entity (from collapsed pool on a BPMN diagram) would contain it explicitly. In our case it’s just client’s words “hello, I want my card.”

He even diagrams this “incoming processor”:

I found his description of this pattern interesting, because the BPMS that I use most often (Lombardi / IBM BPM) wouldn’t require the incoming processor pattern for this use case.  The typical case for BPMS’ is that the event listeners can hear events targeted at their process instance id.  But Lombardi took a different tact that IBM has preserved – events “correlate” on any piece of process instance information – process instance id is certainly one option, but so is a name, or a debit card number.  And the logic to find and message the right process instance is built into the engine.

Not only that- a message my correlate with more than one process instance -automatically- based on the various correlations.

So this is a case where the BPM engine allows the models to be both more expressive and more concise, and to leave the incoming processor logic as a black box that “just works.” But if your BPMS doesn’t do this for you, or if you need to do additional pre-processing logic before the process instance is triggered, this pattern will do the trick.

Once again, a great, thought-provoking post from Anatoly’s blog.

Much has now been written about IBM BPM 7.5.  We’ve blogged about it before Impact, and we’ve obliquely referenced it since Impact.  And we’ve enjoyed reading all the other reviews out there.

So we won’t rehash the feature by feature, blow-by-blow nature of product reviews (we’ll save that for another post!).  Let’s just take a big step back and look at the big picture, and I’ll tell you how we, at BP3, really feel about it.

I’m a Lombardi Customer… Now What?

First, for Lombardi customers.  There’s no doubt that this is A Good Thing.  The Lombardi Way has prevailed within IBM in a sense – the experience of IBM BPM is going to feel a lot like Lombardi – and yet a lot of time and effort is going into things Lombardi could never afford to invest in (configuration management, integration).  ILOG baked into the product line means no more guessing how best to handle rules issues in your processes.  There’s a clear migration path up to 7.5, and clear software entitlements. But most of all, IBM BPM makes Websphere manageable for the customers who really wanted BPM rather than Websphere (in other words, the app server is behind the curtain, not in front of it).

Most of all, Lombardi Customers can breathe a sigh of relief that IBM is not throwing out the golden goose that lays the eggs. From a Lombardi point of view, it is going to look like lots of extra goodies in the bag, with very few downsides from a feature-function point of view.

But I’m a WPS Customer… Now What?

WPS Customers should also be in good shape.  While the migration to 7.5 does not automatically convey the Process Designer, they’re existing WPS efforts should migrate up just fine (the WPS engine is intact).  If you add Process Designer to the mix, you’ll find you now have a great BPM tooling for addressing use cases that might have been more challenging in the WPS environment.  The new tooling should be more accessible to your team, and make it easier to address a broader set of use cases.  Most WPS customers won’t breathe a sigh of relief because (a) they always assumed WPS would dominate the ultimate BPM solution, or (b) because they are happy to have access to the Lombardi-style version of BPM.

I was about to Buy IBM WPS or Lombardi… Now What?

Just buy IBM BPM.  Your choices got simpler.  If you need to design integration flows with clear atomicity and transactional semantics, go for the advanced version of IBM BPM.  Otherwise, you’ll probably want to start out on the Standard version if you’re a larger company, and express if you’re running a pilot or smaller organization.  You no longer have to worry about betting on the wrong horse.  This is something we can give IBM credit for – their product strategy didn’t involve abandoning either of their main BPM product lines or leaving behind either set of customers.

I Work for IBM… Is This a Good Thing?

You bet it is.  Now you can sell and deliver on one value proposition with conceptually minor permutations.  No more product conflict.  The WPS heritage assets are now defined toward a different use case (automated workflows and integrations) than the heritage Lombardi assets (Human-centric BPM, if you will).  Build your processes in process designer, and build integration flows and lights-out processing in the Integration Designer.  And integrate the two in the Process Designer.

I’m an Analyst Covering BPM… Now What?

Well, I guess your job got a little easier.  IBM really has one BPM offering you need to analyze, rather than 2-3.  And it seems to capture the best attributes of Lombardi, WPS, and ILOG.  As Phil Gilbert said to us at bpmCamp shortly after the acquisition: “IBM clearly has the assets and technology to put together the best BPM offering in the market.”  The only question was: would they?  Would they actually put those assets front and center and create the offering?

Well they have.  Adjust those magic quadrants, waves, and rankings.

I’m a Lombardi Consultant or Consulting Firm… Now What?

This is nothing but good news as far as BP3 is concerned.  We couldn’t be happier with the direction IBM took with BPM 7.5.  Including dropping all the awkward naming of previous versions.  We believe we are the best Lombardi BPM services provider, and we aim to continue that record by aiming to be the best IBM BPM services provider.  We think IBM put the right horse (Process Designer) in front of the cart (Integration Designer), and we’re really looking forward to leveraging all the new features of 7.5 (to review: ILOG rules, Integration Designer, Profile Manager, Business Monitor, etc.).  We’re incredibly relieved that they didn’t EOL Lombardi.

And I think there will be a lot of WPS customers who will want to understand, better, what this whole Lombardi point-of-view is all about.  We think they’ll want to talk to someone like BP3.

It’s All About the Experience

Importantly, this release keeps the focus on the things that matter in BPM deployments – time to market, ease of use for the 80% case, ability to go as deep as need be in the 20% case, and a focus on the “business” view of BPM, not just the IT view.

But most importantly, this release signals that the engine(s) don’t matter… What matters is the EXPERIENCE.

IBM (and specifically Phil Gilbert) is planting the flag and saying the experience around BPM matters more than which specific technologies are behind it, it even matters more than the Websphere branding in front of the old names.  In the future, if IBM resolves the offering down to a single engine, it would likely be transparent to us because that engine would be running off of the repository we have today, and running behind the user experience we have today (or, an improved version of the same).  Do I really care if the code running my Process Designer-authored process is Lombardi heritage or WPS heritage?  I don’t really care, so long as it still behaves the same way.  In other words, so long as it implements the “interface” and gives me that “WYSIWYG” feel, I’m happy.

Much has been made by Clay Richardson and others about “multiple BPM engines.”  But trust me when I say that these engines consist of a relatively small percentage of the total lines of code involved in these products.  It is like the algorithmic core of a bigger software entity.  No one is suggesting that the ILOG engine has to be consolidated with the BPM engines to save cost.  It doesn’t make any sense to do that, does it?  So why consolidate the BPEL and BPMN engines? (Again, it may just not make sense to merge these two entities in a meaningful way).  IBM feels that it has already merged them in the two ways that matter most:

1. the BPM “engines” install, run, and operate as one software process or entity, inside a single JVM.
2. the BPM “engines” are unified behind common UI treatment, and common data models, reporting infrastructure, and rules interactions.  In a sense, they “behave the same”.  Users of IBM BPM won’t think of these things as separate engines. They might think of the modeling as separate user cases, but they won’t need to care, nor will they care, about what kind of “engine” is processing the model.  The diagram and details attached to it will define all the behavioral semantics.

I also had another takeaway from Impact, on the BPM front.  ACM is going to be a subset of the BPM offering, from a product point of view.  I saw two customer presentations that covered case management style dynamic processes that were home grown on top of their Lombardi implementations.  They were very interesting, and not that complicated.  And if these scenarios can be built on top of the platform, by customers… Certainly these are use cases that IBM could include in their BPM product offering – either as part of the IBM BPM offering or as part of the BlueworksLive offering.  Or both.  That’s the thing with IBM – they don’t have to choose, they can leverage the genius of the ‘and’. And if IBM doesn’t do it, someone like BP3 will.

Where Do We Go from Here?

Nothing has validated our investment in Lombardi more than the release of IBM BPM 7.5.  I think John Reynold’s post on the subject captures how I feel as well.  This is important. As pivotal as finding out last year at Impact that IBM was truly getting behind its new Lombardi BPM software.  This year it is pivotal in that we’re finding out that the last year has been one of real investment in the platform and real results.  This isn’t just window dressing, it is substance. I understand why people unfamiliar with the workings of Lombardi and WPS might feel differently, but with respect, they’re wrong.  If you know how it works under the hood, this is significant.

…and Thanks!

Given that this is the culmination of hard work from so many people that I hold in high regard, it seems appropriate to say thanks.  I was recruited to Lombardi by Toby Cappello, Scott Bonneau,  and Phil Gilbert – not to mention Rainer Ribback and Brian Witherly.  And Lombardi allowed me to meet Lance Gibbs, and Flournoy Henry, among others.  We built the services team I wanted to build at Lombardi – geographically dispersed (localized), highly skilled, and very experienced consultants.  It was completely counter to the prevailing trends at the time: off-shore (remote), commoditized/cheap (lower skill level), and inexperienced consultants.  The results:

• a much more successful, and mature, customer base
• a better feedback loop into the product development team
• a great talent pool for pulling into other senior or leadership roles in the company
• lower financial risk to the company, at the price of somewhat lower margins on services.

Our competitors that relied on the prevailing strategies ended up with smaller companies, fewer referenceable and less mature customers.  I think the Lombardi brand, in consulting circles within BPM, will continue to be strong for years to come.  I want to thank Lombardi for giving me that opportunity to put my best ideas to work for the business.  And learning from round 1, we’re applying these ideas to BP3 as well – and earning the rewards of this long-term view.

Everyone who was a part of Lombardi, if they’re still paying attention, should feel a greater sense of accomplishment with this release, than they likely did with the original sale of the company to IBM.   Kudos as well to IBM, you have truly figured out how to leverage a fine asset on the product side, and I have no doubt about the dividends it will pay in the years to come.

OK folks. Back to work.

Great post from Marco Arment about a week ago, regarding the new Samsung products that are supposed to compete with the iPod Touch.  Just the beginning is telling:

Apple should be scared of the upcoming competition:

Samsung presented some of the first significant competition to the iPod touch…

I’d call it “potential competition” — it’s not competition if it doesn’t exist yet. And when it does, it’s not really a competitor if it doesn’t sell very well. It’d be difficult to say, for instance, that the Zune was ever really providing “significant competition” to the iPod.

in years…

…ever.

Both run Android 2.2 and will be upgradable to 2.3 in the future.

2.3 has been out for a few months already, and we know how good the Android device manufacturers are at getting updates issued after a device’s sale.

I thought the new target was 3.0.  The android ecosystem is just not up to the challenge yet.  And the manufacturers are having trouble matching Apple just on hardware innovation, forget the software for a moment.

Now, keep in mind, I’m not a fan of the iPod Touch.  I’d rather have an iPhone or an iPad.  But I’d sure rather have a Touch than one of these Samsung devices.

I’ve worked chiefly for 3 companies in my career.  In each of the first two, there was quite a focus on installation being easy.  This cuts against the grain for most enterprise software companies.  They mostly get used to a nice tidy sum of installation $ coming their way for each customer they sign up.

But those with a little more vision see a hard installation as a barrier to adoption of software.  The product experience starts with the install (if there is one).  The equivalent analogy for SaaS products is that the experience starts with registration.  The harder you make the process of installing or registering, the more people you’ll lose before you even get started.

Lombardi was big on the “express install” – a single installer that would lay down everything you need to build and deploy processes.  This mindset has, thankfully, been transplanted to IBM, and so far, it has stuck, even though the installer is something well north of 1GB.

Activiti is raising the bar in this arena – and one could argue that install experience is even more important for an open source project.  After all, if you have to configure a build before you can even run software, how many people do you lose during this process?

But as Joram Barrez writes, you can get Activiti started in just one minute after downloading.  Actually he’s a bit late with getting this news out, as it was also true of the alpha and beta builds.  But they’ve made some improvements, and more importantly, they haven’t made it harder as the product has matured.  Hopefully they keep a relentless focus on keeping friction costs low – it is much easier to avoid them than to get rid of the friction once it is introduced.

To me, this is just mounting evidence that the bar for Simplicity and The Experience is being raised higher.  The points of differentiation will be the how not the what.

This isn’t a review of Appian Tempo.  I’m a fan of what Appian is trying to do with Tempo and I hope there is more of this action in the BPM space.

Sandy Kemsley has a thorough review on her blog.  As usual, it covers the details, and the scenario of the demo quite well:

I had a chance for an advance briefing of Appian’s Tempo release last week; this is a new part of the Appian product suite that focuses on mobility, cloud and social aspects of BPM for social collaboration. This isn’t a standalone social collaboration platform, but includes deep links into the Appian BPM platform through events, alerts, tasks and more. They’ve included Twitter-like status updates and RSS feeds so that you can publish and consume the information in a variety of other forms, offering a fresh new alternative to the usual sort of process monitoring that we see in a BPMS. The free app for the iPhone and iPad requires an account on Appian Forum (the Appian user community site) or access to an Appian BPM installation (not sure if this is both an on-premise system and the cloud-based offering) in order to do anything so I wasn’t really able to check it out, but saw it on an emulator in the demo.

Sandy doesn’t pick winners and losers too often – reading between the lines she likes the indications of where Appian, and the BPM space in general, are going with mobile and social tech, but she’s seen enough demos not to get too excited.

Ann All has a further review (“I See the Enterprise Collaboration’s Future and its Name is BPM“), and is obviously impressed.  She attacks the shortcomings of products like Yammer, in that they can result in new information/communication silos rather than unifying an enterprise.  I can’t help but feel that that same fragmentation issue can be a problem for BPM-collaboration tech (How many BPM products does the average Fortune 500 company own?).  But Ann and Sandy both point out a key benefit of BPM + Social: tying interactions to real business events and outcomes.

Next up, Bruce Silver weighs in with his review, in which he not only praises Tempo but takes a few shots at the approach a few other vendors have taken (and it isn’t hard to guess which ones):

First, it’s really well executed.  Clean and smoothly integrated into the BPM environment.  Second, it seems a more reasonable implementation of the social/mobile idea than is typically offered by BPM vendors. [...] Tempo lets you create and track ad-hoc tasks, sure, but that (in my view) is not really BPM.  What’s important is it lets you also do real BPM, i.e. structured processes, within the same environment.  From your smartphone or iPad, you can perform tasks of  either type, often just by “swiping” the entry, quick and easy.   BPM vendors that insist on a separate “place” for users to do ad-hoc BPM are missing the boat.  Who wants that?

Let me take a shot at that.  The question isn’t, whether BPM users want a separate place for users to do ad-hoc BPM.  The question is, do regular users in the business want their ad-hoc stuff to be mixed in with other people’s BPM (which to them, may feel too heavy/complex so far)?  In other words, are we enhancing the existing audience’s experience with BPM (Appian’s Tempo) or are we trying to address a new audience (for example, the approach IBM has taken with Blueworks).  Both approaches have their merit, but I’ll admit Blueworks’ approach has less appeal to me as a consultant – that doesn’t mean that it won’t have *more* appeal to customers (for example, as a customer, we’re already using Blueworks internally and it took all of 5 minutes to get started). A couple other notes from his blog:

The hard part of BPM is the underlying architecture, the plumbing.  The “user experience”, not to diminish its importance, is technically easier to engineer.

Respectfully, I disagree. It *seems* like the underlying architecture is hard.  But, if it were truly hard, you wouldn’t see minimum half-a-dozen products that are pretty viable on the market.  I’ve worked in a product space where the architecture was actually hard.  We solved problems that no other vendor was even capable of solving.  Our engine would produce answers in seconds that took other vendors’ products hours, if they ever completed the computation.  That’s real differentiation in a hard space.  But in BPM engines, the differentiation is in the experience…

In fact, the underlying architecture and plumbing is becoming commoditized.  I don’t really care that much what engine is running my process… I care about the experience of developing and running my processes.  The experience is vastly more important than the plumbing.  And it is much harder to get right.  Not because it is technically difficult, but it is conceptually difficult to get right – and to say “no” to all the unnecessary stuff.  And once you get a bunch of code in place, it creates its own difficulty in changing to reflect the right experience. I’ll say it again, this is where the real differentiation is in BPM.  (And, to be fair, Bruce likes the Appian Tempo experience, which makes it differentiatingly good in his opinion).  Continuing on:

And once you face up to that, you don’t have to reconceive social/mobile BPM as something radically different, needing a totally separate product.  It becomes simply an alternative user interface that lets you extend real BPM to occasional users who wouldn’t otherwise participate, and enhance the value for regular BPM users by letting them perform process activities without being chained to the workflow inbox.  By making event streams and native smartphone UI a simple extension of the BPMS environment, not a whole “new new thing”, Tempo I think puts Appian in the driver’s seat in social/mobile BPM.

I like the idea of the alternate interface for BPM.  It was one of the first things that occurred to me looking at Blueworks (interfaces to existing BPMS installations for event feeds), but it is also so obvious that I’m sure it will happen in a future incremental release.  Actually, the technology to feed events into the stream from a BPMS (or Salesforce, twitter, or facebook) is quite easy across the products I’m aware of.  I like what Appian has done – but integration to their BPM suite isn’t going to be a selling point for customers who have already purchased, deployed, and invested in another BPM suite.  A separate, pluggable product might be preferred.  We’re watching the outcome of innovation being alive and well in BPM – surprisingly, at IBM, and less surprisingly, at smaller outfits like Appian and ActionBase, and in open source projects like Activiti.

It’s a very exciting time to be in the BPM business.  Congratulations to Appian for a great product release – I don’t mean any of my comments to denigrate their product offering – which I have not myself laid hands on – I hope their release is a success, and an indication or precursor of more interesting things to come from other vendors in our space as well.

In Part I, we explored the notion of open and closed, and what those words mean to customers and experts.  The basic argument: customers care about the “experience”.  Experts care about the nuts and bolts – and how fine-grained their control is. We used as a foil, Apple’s iPhone versus Google’s Android mobile OS.

Since that first post, there has been a little bit of evidence that the focus on “experience” pays off:

• Apple’s AppleTV topped Amazon’s Wish List in November. And iPads ranked #2 and #3.  Eight of the top 20 items listed were Apple devices.
• iPhone’s 4% market-share in phones yields 50% of the profit.  That’s simply incredible.
• And the halo effect appears to be in full effect, as interest in Apple Laptops is way up. The Changewave survey showed a surge from 25% to 36% in one month… What changed? The new MacBook Air is what changed.
• We’re about to see Verizon pick up the iPhone on Tuesday.  At first glance it looks like they’ve agreed to most or all of Apple’s terms.

Steve Jobs made a pretty compelling argument on the last earnings call in favor of the Apple approach : integrated focus on experience – “When selling to users who want their devices to just work, we believe Integrated will triumph Fragmented every time.” – this is a really good lesson for BPM vendors.

But why? Why is Apple a good example for BPM vendors to consider?

For a few reasons:

1. BPM sits at the top of a big pyramid of IT assets.  Any one of these IT assets could really undermine the experience of interacting with business processes that are affected.
2. BPM itself is an amalgamation of several different technologies, notations, standards, etc.
3. Integration is still the long pole in the tent
4. The Business is the customer.  They actually value simplicity and “it just works” over complexity and flexibility for the IT folks.  It turns out that flexibility for the business usually requires simplicity and a focus on the quality of the experience.

This is why it is so important for companies like IBM to push forward with Blueworks – in order to find the secret sauce of collaboration, process authoring, and process automation.  And equally, why it is so important for IBM to rationalize its product vision behind an offering that sells well to their business customers as well as their IT customers.   And it is also why it is important for Activiti to pursue initiatives like Kickstart.

But going deeper – it is why we need BPMS vendors to really focus on the fit and finish of the products they bring to market.  The workarounds, the kludges, the accommodations for bugs across many different versions of a product have profound costs:

• Slowing the rate of adoption in the industry – by impeding the rate of learning of new BPM experts who have to learn all the warts of each system, and each version of each system.
• Adding a layer of non-value-added code to accommodate product shortcomings.  If we were to apply value-stream analysis to code: value-adding code versus non-value-adding code, workarounds and kludges would certainly fit into the latter camp.  But usually these work-arounds are actually more expensive to maintain over time than the value-adding code, on a per-line basis.  Worse: they add no value except to make up for vendor shortcomings.
• They slow time-to-value for BPM projects by introducing friction that works against the productivity of process authors.

With the competition as plentiful as it now is in BPM, and in enterprise software generally, catering to the user experience is going to start to trump catering to the experts.  It isn’t that the experts won’t still have their place and role and value – they will.  But the real value they bring won’t be knowing about various product warts, it will be be about how to effect real business process improvement realized in software.

Perhaps another example would be useful.  Take a look at Gosling’s blog on Desktop Linux – “The Dream is Dead” – regarding why Linux has been such a huge success on the server side, but not on the consumer / desktop side.  Ultimately, Linux is an Expert’s dream operating system.  But it is a nightmare user experience for a novice user.  As a server product, Experts *are* the customers, and Linux has done quite well.  But in the desktop arena there was no business model to support a good user interface – and lack of a good user interface is actually what made desktop linux untenable.

We’re advocating for a better Experience.  As Experts, we like the power of today’s BPM environments.  But when we’re users -as with phones -  we really appreciate the Experience.    We imagine the consumers of BPM software feel the same way.  Back to Sachin’s post:

And they don’t measure products by what they do, but by how well they do them. You won’t find a matrix where Apple compares their product to a competitor by feature. They measure products by the experience.

You know I like a good discussion of simplicity, but sometimes we have to call out the lack thereof.  The charts on the Aris BPM blog illustrating how simple the SAP BPM story could be:

From this “simple” slide, we’re to infer that SAP has a more complete offering (er, vision) for BPM than just NetWeaver. I agree with the author of the article that SAP’s BPM message needs to improve – by most definitions NetWeaver is more integration than BPM.  And SAP’s “CAF” (Collaborative Application Framework) which was once described as “beyond” BPM and coming in “two years”, sounded like a subset of BPM as well. There have been some interesting demos (Gravity).  But the thing that strikes me about the chart is that I still don’t understand what SAP products are doing for my business process needs.  I can’t tell if these are the names of SAP products or just general ideas of what you would want to do if you are at the intersection of management control and strategy (financial management??).

But the prescribed solutions are listed thusly:

1. The Forrester BPMS vision of SAP is mostly based on the capabilities of the Netweaver BPM platform and not on the complete BPM vision of SAP
2. SAP does not sufficiently communicate their complete BPM vision towards the market research companies like Forrester and Gartner.
3. The SAP platform is not considered the best of breed BPMS platform by the market research firms like Gartner and Forrester
4. The BPMS capabilities framework of Gartner and Forrester could be extended in order to capture the capabilities the SAP platform can offer.

So… the problem is that Forrester (and Gartner) are only looking at one of many products to place SAP on the BPMS frameworks… and that Forrester and Gartner aren’t sufficiently taking into account the SAP platform’s many other capabilities.  And, this is mostly a problem of communication/marketing, rather than say, substance.

In reading about RIM, I’m always amazed at how complex their statements are about their products.  It is almost the opposite of how Apple talks about their products.

Business Week’s quote of Balsillie:

“There’s tremendous turbulence in the ecosystem, of course, in mobility. And that’s sort of an obvious thing, but also there is tremendous architectural contention at play. And I’m going to really frame our mobile architectural distinction. We’ve taken two fundamentally different approaches in their causalness. It’s a causal difference, not just nuance. It’s not just a causal direction that I’m going to really articulate here — and feel free to go as deep as you want — it’s really as fundamental as causalness.”

Wow.  Sometimes complex language hides simple truths – usually truths we don’t want to face.

I hope RIM gets their product lineup act together. I was a happy RIM user for years (well, not so happy with voice quality of the phones, but the texting/email was great).  But I feel like Apple (and Android) have completely thrown them off their game.  They’re no longer pursuing their own best path, they’re reacting.  I’d recommend they focus on their own vision of mobile computing – and simplify.  Simplify the message, simplify the product line, simplify the hardware, and simplify the software. Make it easier for consumers to articulate why they use a blackberry instead of an iPhone.

Paul Vincent on BPMN 2 events (all 63 types of them) :

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate
• … across 8 situations classified by location in a process:
• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving58 63 event types defined [*1].Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

Paul is right: 63 is too many. But I think he also hints at the right answer: the tooling should be able to pick the right symbol based on the context of the detail of the event (or conversely, show the author the right context if they pick a specific event).  But there’s no reason for anyone to know 63 event types off the top of their head.  In fact, they really don’t need to distinguish between all of the 13 “main” event types in most cases.

It is up to the BPMS providers to make the authoring experience powerful and yet simple enough to be manageable and useful.  If the notation has gotten away from us a bit, then software can help reduce it back down to something manageable.  One interesting aspect is that many of these event types are not currently supported by BPMS vendors-  so depending on which tool you’re using you can cross off a lot of the potential event types!  That isn’t exactly what I mean by “simplifying” but it is one way to get there, I suppose.

Antiamba’s Ligurio says that “BPMN can bring death to your process“:

The problem lies that BPMN is so complex to implement, that people made some workarounds, simplifying process maps. If a business process needs to be mapped (some don’t like ad-hoc) it should be done in a way everybody understands it, and it can be exchanged using multiple platforms that support process notation. Once it does not happen, there is a high risk of losing process data, because you can’t use things like intermediate message, or timer, that was represented in the process repository you need to move. Thus, you are sending your process data to oblivion (and BPEL, if used, also).

If process map is an asset, imagine re-training people that work in call centrer executing business processes by the book, telling that the decision gateway changed to something different, because process maps were updated to other tool. This has an impact in the way people perform tasks and in customer perception how the company execute. If process managers don’t have this concern they are very far from process execution where everything happens.

I can definitely relate to his criticisms of the tools around BPMN.  We have a problem in our business right now.  Almost every BPM software package supports BPMN.  But what does “support” mean?  It usually means, the BPMS uses a subset of BPMN notation standard.  Anything produced would be BPMN compliant.  However, it does not mean that ALL BPMN notation is available.  Therefore, despite two tools speaking a “common language” there may not be a 1-to-1 translation of a BPMN model in one tool to a BPMN model in another tool.

The definition of BPMN 2 will help.  By defining a storage format, it gives vendors a more concrete target to hit in terms of export/import.  And it will make missing BPMN icons feel more like a bug than an annoyance.

But Ligurio takes the criticism to BPMN, rather than, primarily, the vendors.  Vendors have got to get their act together and embrace BPMN 2 more fully. He blames BPMN for allowing you to model things so many different ways – but in a modeling world absent BPMN, this problem is worse, not better.

Earlier in his post, Ligurio criticizes Blueprint for its Visio importer being less-than-perfect.  However, keep in mind that Blueprint is importing native Visio XML.  This is not some standard BPMN XML that Blueprint is importing – because Visio doesn’t produce it, despite using a BPMN stencil.  He seems disappointed with the idea of manually choosing that one kind of gateway icon maps to a split, or a decision gateway, rather than Blueprint just guessing.  Keeping in mind that Visio can label anything a split or gateway, regardless of what it truly is, this seems to be asking a bit much.  It isn’t as if you have to choose the mapping for every occurrence of an icon – just once per type.

The more accurate criticism is that Blueprint doesn’t (yet) support things like complex gateways and attached events (and pools vs. lanes).  I know the Blueprint folks are trying to avoid these “advanced” use cases, but if they want Blueprint to stay relevant as users get more advanced or import valid BPMN diagrams from other tools, they simply have to add this functionality or risk becoming irrelevant. Having said that, Ligurio’s example diagram has a sequence flow crossing pool boundaries, which looks like a no-no according to the BPMN spec (they often get over-used in tools where they are supported).

He runs into similar issues with ARIS and ITP Commerce.  Bottom line: he has a 25-page process. It will clearly get mangled in import routines today, and require lots of manual work to clean up.

My advice:  for now, stick with one modeling environment.  Choose one that starts with modeling and lets you seamlessly add execution details.  If you use a “modeling only” environment it should stay at a very high level to work out concepts and disagreements – not to model execution-level details.

BPMN2 model portability, along with the diagram interchange format, will help these problems greatly.  But the commercial vendors have to step up their game to support a much larger subset of the BPMN specification if they want customers to consider them compliant.

Meanwhile, it isn’t BPMN killing your process.  It is BPMN exposing the problems in process definition and communication that were always there – but going unnoticed.  They’re now coming to light, and vendors have an opportunity to really address these issues.

A few weeks ago I had a call with Intalio’s Ishmael Ghalimi.  It was right before vacation, and the unfortunate side-effect is that I’m only now catching up with writing the post I meant to write when I got off the phone with him.

For the last couple of years, many of us in the BPM world have wondered what exactly Ishmael and his crew at Intalio were up to.  They made a series of acquisitions and investments, the purpose of which wasn’t quite clear to much of the BPM community, because it included a CRM solution and a focus on cloud computing.  But when we finished talking, it was clear to me that Ishmael has simply made a different bet than most of the rest of the BPM community.  While the mainstream of BPM innovation has been focused on BPMN2, modeling and collaborating in the cloud, and tweaks to the method and thought process like ACM… Intalio has gone a contrarian route-  retooling and refocusing on BPM in the cloud – but not by dabbling, by jumping with both feet, so to speak.  This is the long game rather than the dink-and-dunk short game.

It is a bold move, and Ishmael makes the argument that if you really want to play with the big boys, you need to make the investments that Intalio has made in a vertically integrated stack for cloud computing.  Rather than writing all the code from scratch, of course, Intalio is relying on a bevy of open source software.  A quick look at this page reveals just how many open source projects are involved in Intalio’s offering (and that’s just on the application engines side).

A heavy focus on open source software might cause you to wonder how Intalio makes money.  Intalio contributes to some of these projects, and just leverages some others.  the distinction that Ishmael made is that while the open source project for, say, the process engine (Apache ODE and Drools Flow), is free and open source… The entire integrated solution that Intalio is offering is commercial.  You are, essentially, buying a professionally prepared 10 course meal, instead of just getting all of the ingredients for free, so to speak. As Ishmael points out, customers do not mind paying for commercial software today that includes open source parts (nearly all of the commercial BPMS offerings today include at least some significant open source project code).

Ishmael went into great detail about the investment required to make Intalio’s PAAS offering virtualization- ready – the upfront investment to natively leverage SpringSource and the like is significant. But once there, it is much easier to scale application deployments.

We walked through a pretty compelling demonstration of the authoring tooling – which was browser-based, and he scored bonus points with me by running the whole stack on a Mac (attention commercial BPM vendors: your users and developers want Mac, iPad, and iPhone support).  The ability to model data, leverage it in user interface and process diagrams, and deploy it quickly, is compelling.  It doesn’t *feel* like a BPM tool, it feels like an IDE for building apps in the cloud.  Perhaps that is the intent.  To make BPM a feature of the environment, so to speak, rather than the centerpiece of the environment.

I asked Ishmael, given that this seems like both a horizontal and global strategy and a great number of component projects that make up their product offering, how does Intalio decide what NOT to do?  We had discussed why he had made the investments he’d made, but how do they decide what not to do?  Ishmael’s take is that they are throwing the long ball – seeing themselves as a much smaller version of a Microsoft of the 90′s, where:

• The operating system is the cloud instead of Windows
• The “development studio” is Intalio Studio instead of Visual Studio
• The productivity suite is Intalio Docs instead of or in addition to Microsoft Office

Another analogy he gave is RedHat – providing the glue to pull together open source projects into coherent commercial offerings.  There are many execution challenges, but if you pull it off and execute, you’re in very good shape because most competition is either too small to deliver, or too big to abandon their existing commercial software business (or not nimble enough). His example of too large:  he argues it would be very hard for IBM to come to market with an integrated product that is also virtualized for the cloud, because there are different P&Ls within IBM’s software group, who aren’t going to work together on one seamless offering. Others might argue these points differently, but given Ishmael’s thinking, the strategy he’s pursuing makes sense in that context.

The pricing model is free up to 5 users, and then scales up in price as you expand the solution.  This makes it easy to prototype solutions, and scale cost relative to the benefit achieved.

In some respects, what Ishmael and Intalio are trying to do is offer a compelling software stack for process applications in the cloud, but also removing many of the barriers to entry companies would normally face.  One could argue that they are trying to make BPM in the cloud simple enough that mere mortals can attempt it.  And Ishmael claims it isn’t just a superficial attempt to band-aide these projects together – that they’ve thought and worked hard on every level of the stack – from hardware, to virtualization, to Infiniband networking, to the more obvious software layers that developers interact with.  The conversation with Ishmael about these topics reminded me of my conversations with Phil Gilbert of Lombardi about making versioning relevant to BPM authoring (that it isn’t enough just to check things into subversion, that real versioning requires a much deeper understanding of process authoring).  Versioning was Lombardi’s long pass in the last couple of years leading up to the acquisition by IBM. And the point of this kind of deep investment in both cases is to create simplicity out of complexity – to provide truly useful abstractions to the customers of your software.

Three is risk that Ishmael and Intalio may have made this investment “too early”.  I recall in the 90′s a firm that made a bet on server-side Java runtime environments a bit too early – betting on JRun, which was a pretty immature platform.  A year later, when the product suite was ready, the whole thing could have been accomplished in 3 months on top of newer commercial application servers (e.g. Weblogic).

Time will tell if Ishmael’s long pass pays off – he’s either stolen a march on the competition, by getting “fully cloud-enabled” early, or he’s made the march too early and paid too heavy a price to get there.  If he’s too early, we’ll know because other “mainstream” BPM vendors will quickly follow with fully cloud-ready BPM stacks.  If he’s stolen a march, then Intalio will use its technical advantages (perceived and real) to drive more business at the expense of others.