Reviewing the Reviews and the Experience: Appian Tempo

Scott Francis
Next Post
Previous Post
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.
  • Pingback: Tweets that mention Reviewing the Reviews and the Experience: Appian Tempo » Process for the Enterprise -- Topsy.com()

  • Bruce

    It’s not about selling social to other BPMS vendors’ customers or competing in the non-BPM world. It is about becoming the enterprise choice for BPMS.

    • Agreed the end-game is about becoming the enterprise choice for BPMS. But there are different tactics for getting there, and more features for the “current” BPMS user base may not be the best way to win, versus capturing more eyeballs outside the mainline process participants. That’s the difference in strategy or tactics, if you will. I’m interested to see how it plays out.

  • Editor’s note: Updated the line breaks in the quotations. Somehow they got off in the original publish.