Archive for July, 2008
Yesterday Lombardi updated the analysts with their 1H08 results. They are saying 85% license revenue growth (vs 1H07), 50% total revenue growth, and sales bookings “close to triple” last year, 20% ahead of plan for the year. They added 30 new customers, with growth especially strong in Europe. Average selling price - the make-or-break metric for any software company with direct sales - is up 20%, and CEO Rod Favaron said these factors in combination allowed Lombardi to “run on our own cash flow” for the first time in 2008.
Blueprint, Lombardi’s SaaS modeling tool, claims over 3000 paying customers in 100 countries. Lombardi calls it “our SaaS platform,” and Marketing VP Jim Rudden has been sparring with Appian Anywhere GM George Barlow in a BPMS Watch comment thread about which is the SaaS-ier of the two offerings. I’ll stay out of that one, but I was surprised to hear that while Blueprint gets credit for fully half of the Teamworks (BPMS) expansion (’upsell’) at customer sites, only a few (”3 or 4″) Blueprint-only customers have migrated to Teamworks. The new Blueprint release is pretty nice - Scott Francis has a detailed review of it - and I am currently working with Shelley Sweet on a training video that shows how to do basic process mapping with Blueprint. Look for that in September.
On the Teamworks side, the focus is addressing the move in the marketplace from BPM ‘projects’ to BPM ‘programs’, and the management and governance structures and tools required to make that easier. Lombardi thinks they are ahead of the competition on this, and among the pureplays they probably are. Of course, the big software companies (what Rudden calls the ’stackers’) always think in terms of enterprise programs, long-term maintenance and governance… often at the expense of rapid development and deployment at the individual project level. Teamworks (homegrown unified environment, not acquired products stitched together) already excels at the latter, and addressing BPM tooling at the enterprise level signals it wants to take on the big boys on their own terms.
July 30th, 2008
The $10 Million series A funding announced by Appian today will be used to expand in a number of areas - marketing, sales, and professional services - but of most interest to BPMS Watch readers, I think, is accelerating the company’s BPM-in-the-cloud offering, Appian Anywhere. Appian is one of very few BPMS leaders actively pursuing the SaaS model, and they believe they are ahead of competitors in both the “vision” and the technology.
According to company executives, Appian as a whole is becoming more “SaaS-oriented.” They believe SaaS represents an ”inflection point in BPM,” a must-have feature for any leading BPMS vendor, one that will bring new vendors into the market and chase out others unwilling to accept it. An important part of SaaS BPM is the new partner ecosystem it enables, including ISV application providers and professional services providers.
Today, two kinds of customers are attracted to Appian Anywhere: 1) large companies, where business cannot get IT to respond quickly enough for smaller-scale solutions; and 2) smaller companies for core business processes.
For example, Appian points to a large life insurance company that had trouble responding to requests from advisors and partners for marketing information in a timely way and provide accurate tracking and reporting. The project was too small to get IT priority, but the marketing department had their own budget. Appian built a demo in couple days that replicated the requested functionality, and proposed to build out the real solution and host it. That took one person about two weeks, which was billed up front, with the hosting billed on a monthly subscription basis.
The platform is hosted by OpSource on three data centers in the US and Europe. Customers pay per-user per-month, with pricing tiers based on the number of applications and the size of the system. For a single app with 70 users, a customer would pay $35 per user per month. A minimum 1-year commitment is required, but when the platform moves to a multi-tenant architecture, that will no longer be the case, just pay as you go. Finishing up the multi-tenancy piece will be accelerated by the new funding. When that is done, in Q1 2009, Appian Anywhere will become generally available, and supported by an online marketplace of application and service providers, similar to an iTunes store for BPM.
July 21st, 2008
Last fall I published my wish list for a few additions to BPMN. Typically these came from my BPMN training where a student would ask, How would you do this in BPMN?… and the spec provided no good answer. One of them, alternative entry points to a process, was explicitly addressed in the BPMN 1.1 spec in January 2008 using event gateway. For another one, the non-aborting “attached” event, I proposed a workaround valid in BPMN 1.1, but wished for a simpler notation. The desired semantic was picked up as a good idea by the BPMN 2.0 submitters, but without an explicit notation. The third one, which I called semi-structured behavior, is still an unresolved issue. Here again I proposed a workaround in the original wish list, but also unsatisfactory from a notational standpoint.
My new wish list carries forward the two unresolved items from my original list with an explicit proposal for a notation, and relates them to a longstanding problem in BPM, the difference between a task in BPMN and a task in BPEL.
First, a fundamental principle: In BPMN, if you can’t see it in the diagram it doesn’t count for much. A lot of the BPMN 2.0 discussion has focused on XML serialization and on attributes that don’t print in the diagram. Those things are necessary, but the notation is more important. It needs to be expressive, simple to draw, and semantically unambiguous.
A second key point: BPMN is really just about when activities occur in relation to each other, when they start, when they end, and what happens next. It doesn’t have a lot to say about how (the data, the implementation), and just scratches the surface of who (pools and lanes). But there is ambiguity about what is meant by ’starting.’ In BPMN an activity starts when it is enabled by incoming sequence flow. But to a business user, it starts when someone or something begins working on it.
So let’s start with the ‘task’ problem. In BPMN it just means a simple activity, i.e. having no internal structure defined by the model. It could be a human task, an automated service, or sending/receiving a message. In BPEL, task refers specifically to a human task. Leaving aside the ‘inline task’ variant of the proposed BPEL4People, a BPEL activity does not directly perform a task. Instead the process creates a task in a task management service (external to the process), which reports task completion back to the process. That’s because unlike an automated service, a human task is inherently stateful. The time when a task is assigned and made available in a performer worklist is not the same as the time when the performer begins working on it. This distinction is fundamental to human workflow, but ignored by BPMN.
With all this as background, let’s get to my new wish list.
Wish item #1 is the non-aborting attached event. There is consensus on the value of the semantic; we just need a notation. I propose to use the start event notation (single thin circle) drawn attached to an activity for this purpose. No need to add shapes to the graphics library when there is a perfectly good one available. So for attached event, I propose thin circle means non-aborting and double circle means aborting. Any event trigger for which attached intermediate event is valid should support both aborting and non-aborting variants, e.g. timer, message, and error.
Wish item #2 is a new BPMN attached ’started’ event that means “performer has begun work on this task.” It is non-aborting, meaning it triggers a parallel thread on the exception flow without disabling the normal flow out of the activity when it completes. It applies naturally to human tasks (user task type), but I can imagine use cases for service and send as well.
Wish item #3 is another non-aborting attached event, ‘user action.’ It means during this activity the performer MAY throw this event, which again triggers a parallel thread on the exception flow.
Wish item #4 is a new event type, ‘Enabled to finish’. Like attached compensation event, it is a special one, i.e. doesn’t follow the normal rules. It has a sequence flow in and no sequence flow out. It means that the activity (task or subprocess) cannot complete until the event occurs. Yes, a workaround is available in BPMN 1.1 by wrapping the activity in a subprocess with a parallel path waiting for a Signal event. I’m proposing a simpler notation.
These items all relate to one of my original wish list topics, semi-structured processes, something BPMN today does not handle well. Even though BPMN is fundamentally about time ordering of activities, it adopts a very limited view of time ordering, just Finish-Start (FS) dependencies: Activity B is enabled to start when Activity A is finished. I’m not the first to notice this. Denis Gagne wrote a long treatise about BPMN’s limited view of time dependencies several months back. (The Temporal Perspective: Expressing Temporal Constraints and Dependencies in Process Models can be found in the 2008 BPM and Workflow Handbook published by WfMC). And as long ago as 2005, on an OMG discussion thread, Derek Miers worried about
…the sorts of dependencies that could exist between the nodes … most people only understand the “hard-start” condition (if this activity has finished, then the next one can start). While that might suit software programmers trying to build code, it doesn’t readily reflect how the real world actually works.
In a semi-structured process, such as described by a tool like Microsoft Project, FS is only one of several dependencies between activities. You also have:
- Start-Start (SS). Activity B is enabled to start when Activity A is started in the normal business sense, i.e. a performer has begun work on it.
- Finish-Finish (FF). Activity B is enabled to finish when Activity A is finished. Note this is not exactly the same as using a gateway to join A and B, since the behavior of an event attached to B would be very different.
- Start-Finish (SF). Activity B is enabled to finish when Activity A is started.
In addition to dependencies on “actual start” vs simply “enabled to start”, the notation can be applied to flows triggered by optional user actions (US)…
… or activities enabled to finish by optional user actions (UF). Note enabled to finish does not mean commanded to finish, which you can do with aborting Signal event. Enabled to finish essentially imposes a join condition on completion of the activity; both completion of the activity in the normal sense and arrival of sequence flow at the enable to finish event must occur before the activity is complete.
Combinations of these dependencies are possible as well. The particular trigger icons used here are not important, but I would love to see these notation semantics in BPMN 2.0.
July 17th, 2008
This is starting to get good. Let’s face it, not many people care about BPM standards, other than wouldn’t it be nice if we could agree on some. I’m really no different, although at this point I would admit to having a vested interest in getting quickly to a version of BPMN that was portable between tools. So I’ve tried to publicize and opine on some of the issues behind the normally secret deliberations over BPMN 2.0, now being hashed out in OMG. There are two competing proposals, one a longstanding OMG project called BPDM, and the other a joint submission from IBM, SAP, and Oracle that looks a lot like current BPMN but with a defined XML schema.
Until recently what commentary existed in the blogs on this topic was from the IBM-SAP-Oracle side, but in the past couple weeks the BPDM supporters have begun to tell their side, beginning with Fred Cummins, Conrad Bock, and now Lombardi’s Phil Gilbert. Of the three, Conrad’s for me is the most persuasive, probably because he concedes the point on what was my biggest objection to the BPDM vision for BPMN, which said that the notation could mean whatever the modeler intends it to mean, as long as the serialization in conjunction with MOF fully describes the semantics. That, for example, was the argument of Antoine Lonjon (BPDM editor) in his BPMN wish list featured white paper on the OMG site. But Conrad concedes that no, even though BPDM provides a ready framework for describing any new diagram behaviors, the notation for such would have to be agreed upon and published in the BPMN spec. (I haven’t figured out how that works if BPDM is just renamed BPMN, but that’s another story).
I have two other reasons for favoring the IBM-SAP-Oracle proposal myself: One, it seems to be the one favored by most other BPMS vendors, who are also the ones making the low-cost (some free) BPMN tools available to me and my training students. I think that’s because it looks so much like the BPMN we have now, not a “brand new language.” If all tool vendors don’t rally behind BPMN 2.0, that would be a bad thing, and I think universal adoption is more likely with the IBM-SAP-Oracle one.
Two, and I admit that I might be alone in this one, it is based on standard XML, and can be mapped with regular XML tools, as opposed to mapping based on MOF and XMI, which to me are foreign languages. Others have expressed their own objections. Oracle’s Vishal Saxena, for instance, advances the “simplicity” argument (compared to BPDM), but I think that he really means more “like today’s BPMN” than “dumbed-down.” SAP’s David Frankel expresses the view that BPMN should have its own schema and metamodel, based on the BPMN spec, and that BPDM is a new abstract language to which BPMN and many other platform-specific languages can be mapped. Maybe that’s just another way to express the simpler/more-familiar argument.
Anyway, now comes Phil’s defense of BPDM, which adds a new twist, suggesting that opponents of BPDM are really vendors out to kill BPM and its notions of business empowerment. It’s true that some of them were not on board with BPMN in the beginning and bet on UML instead, but I wasn’t prepared for this:
It’s only been in the last 12 months or so that some major stack vendors and application vendors have announced support for BPMN…. When OMG approved BPDM, once again their world was challenged. All the sudden, a legitimate, useful, long-term alternative to technology-based diagramming (like UML) was a reality. Business-facing diagramming… with power? Big problem.
Is the IBM-SAP-Oracle proposal BPMN’s Manchurian candidate? Phil continues:
There is no question that the power of BPDM - the explicit aspect of it that you are worried about - was a key contributor to the movement of some of these vendors into a “hey we better beef up BPMN with a simple serialization” mode. Could it be that they recognize that crippling the power of an alternative model to UML might be in their strategic interest?
While Phil’s suggestion seems to me over the top, I welcome it. Because if the other side takes the bait, we should finally have what has been missing for two years - a real public discussion of the issues shaping the next generation of BPM tools.
July 14th, 2008
Conrad Bock of NIST picks up the defense of BPDM where Fred Cummins left off. Since I don’t see much other discussion on the web about this important topic, I’m going to renew the thread here. Here are Conrad’s points:
The calls for a BPMN metamodel started two or three years ago, including OMG reopening the BPDM submitter list to the new BPMI members, and invitations from the BPDM submitters at the time. Only one new vendor chose to participate, not among the major ones. IBM and SAP were in attendance at those meetings, and perhaps Oracle also. It’s unclear why they did not to participate, but there was nothing preventing them, certainly not an “insider” group.
BPDM was conceived to cover common process languages including BPMN, rather than something unrelated or different from BPMN. BPMN and its precursors were widely known in the process modeling world during BPDM development. The calls mentioned above requested the BPDM submitters to include BPMN as a special case, which they did. BPDM includes a notation mapping to BPMN.
Adoption of process modeling tools would increase significantly if they worked with other tools, such as process analytics, monitoring and management, as well as processes defined textually rather than graphically. Simply capturing notation will not achieve this, because these tools are most often concerned with semantics, rather than notation. For example, process monitoring tools are concerned with how the process is expected to be performed or executed, rather than whether it was specified with a particular notation. Process modeling tools needs much more integration with other tools to achieve wider adoption than the occasional use they receive now (see the BPTrends 2008 survey), This is not possible with a purely notational metamodel.
BPMN can only be changed when there is agreement on which changes to make, and they are adopted through the Object Mangement Group process. This is facilitated by extensions developed outside the standard that are shown to be useful in practice. BPDM enables semantic extensions, and with the diagramming capabilities in the upcoming BPMN 2 submission, extensions to notation also. Users and vendors can develop their own additions to BPMN and suggest them to the OMG for adoption. This makes it easier for OMG to respond to user requests for new features.
I did not mean to suggest that the BPDM ‘insiders’ were excluding other voices, but I suspect the IBM-SAP-Oracle contingent’s vigorous disagreement with BPDM on basic principles came as a surprise. At last year’s OMG Think Tank, for instance, the BPDM people simply announced as a fact that BPDM would be renamed BPMN, which would now stand for Business Process Metamodel and Notation.
On the second point, it’s not that the BPDM group was unaware of BPMN, but rather that BPDM was conceived at a more abstract level in order to accommodate other languages as well. This simple fact, upon which both sides agree, is at the heart of the disagreement expressed by David Frankel.
Conrad avoids the undeniable fact that BPMS vendors, with the exception of Lombardi, favor the IBM-SAP-Oracle approach over BPDM, and instead says let’s not forget about the process monitoring vendors. But I don’t get that. For one thing, except for a few tools like ARIS PPM, the process monitoring vendors are the BPMS vendors. Second, what monitoring vendors need is standardization around runtime data, not modeling notation semantics. And OMG tried to get that off the ground, called BPRI. They built it… or started to… and no one came. So I’m sticking with my story that if tool adoption of BPMN is the goal, BPDM is not the right strategy.
On his last point that the BPMN notation is standardized by the BPMN spec, regardless of BPDM’s extensibility, I say Absolutely correct! (Please inform your colleagues.)
There is one final element I would like to add to this discussion, even though I may not have many supporters on this one. The BPMN schema proposed by IBM-SAP-Oracle is just so much cleaner than the one used by BPDM. The element names match BPMN names. The serializations are human readable. You can use regular XSLT tools to map them, to validate them. I realize many - perhaps most - people say there is no need for the XML to be human-readable. But I suspect those people have never had occasion to map XML. In any case, I don’t have the tools to manipulate BPDM serializations, whatever they are (EMF?). I do know how to use standard XML tools
July 11th, 2008
Are you as sick as I am of so-called “architects” swiftboating BPM with phony strawman arguments? Here’s the latest, from blogger Nick Malik:
I like point out really nutty ideas, even when a lot of people have spent a lot of time investing in them…. [BPM] created pretty languages for describing business processes, and we started telling the business that once business processes are described using these languages, then you can push a button and “viola” the process becomes automated. According to the ‘true believers,’ we can give end users one of our pretty languages (BPMN or BPEL) and they will write their own software, and we can fire all the IT developers.
Nick, your post is not so much nutty as scurrilous. It’s plain false, but it fits a recurring pattern in our culture: Repeat a charge long enough and people start to believe it. Please tell me, who in the BPM community is saying these things? I challenge you to do it. And don’t tell me some joker in the next cubicle. A BPM vendor, authoritative consultant or blogger, whatever. Let’s have the links. Put up or shut up.
Let’s hypothesize that Nick has some clue about what BPM is, even though BPMN can not by itself generate implementation (it’s just activity flow modeling) and BPEL is definitely a developer language, not for ‘end users’. (Maybe Nick thinks that only Java programmers are ‘real’ developers?) BPM Suites based on BPMN do provide a more agile implementation style in which business and developers collaborate on process automation. But not all BPM solutions are best implemented by BPM Suites, and not all business solutions are best handled by BPM. No one is saying those things. So stop the swiftboating. Please.
July 5th, 2008
Today Oracle lifted the veil on its plans for BEA. Naturally, Oracle said the acquisition as a whole was not just for market share, but for BEA’s technology, which would all become part of the Fusion middleware platform. There was a lot of material presented, but I’ll focus on the product convergence plan as it relates to BPMS.
To rationalize the product set, Oracle first sorted the BEA product catalog into one of three buckets: 1) strategic, where BEA was considered superior to existing Fusion components or a new capability; 2) continue and converge, where BEA component would be positioned as secondary, maintained but eventually merged into the current Fusion offering; and 3) maintenance, mostly OEM offerings, which it seems Oracle wants to walk away from as soon as they can. The BEA installed base was reassured that all BEA current products would continue to be “supported,” although those that are not “strategic” would not be enhanced.
Oracle JDeveloper continues as the strategic IDE, although Oracle will continue to contribute significantly to Eclipse. In Oracle BPM, JDev is the one that counts. The Oracle and BEA Eclipse pieces will be combined into Oracle Enterprise Eclipse Pack, replacing WebLogic Workbench. All these tools will be free to customers, per Oracle’s current policy.
WebLogic will be the strategic app server, over Oracle’s own, even though the tooling moves over to JDev. One confusing thing is OC4J, which Oracle uses as the container for BPEL processes, has to be ported to the BEA app server. I guess that is not hard to do…
In SOA, AquaLogic ESB trumps Oracle’s own. It will be enhanced with Oracle features like SCA fabric, BAM sensors, and business rules, and will become part of the Oracle SOA Suite. Oracle BPEL Process Manager continues as the strategic process orchestration and human workflow engine. Web services, complex event processing, rules, B2B, and BAM all fall on the Oracle side.
For BPM, Oracle tries to divide the baby. The existing BPA Suite (OEM ARIS) is positioned as the “strategic” modeling tool at the “high end”, but BEA’s AquaLogic BPM (fka Fuego) seems to have found a home as the “agile BPM” tool suitable for implementation by non-IT “domain experts.” I’m not sure that’s how BEA ever positioned ALBPM, but Oracle’s positioning of ALBPM as the agile one (compared to BPA Suite + SOA Suite) is refreshingly honest… perhaps too much so, so we’ll see how long that lasts. Not sure if they have figured out how to do it yet, but the plan seems to be to maintain the ALBPM modeling/design environment - bad news for BPA Suite? - and move the ALBPM runtime over to a single engine that can execute either BPEL or BPMN 2.0, with common auditing and management. Oracle says ALBPM “will be integrated with the BPEL metamodel for round trip design,” and “process documentation” will be available via BPA Suite. How much of that is hobbling ALBPM and how much enhancing BPEL remains to be seen.
All of this means there is finally a product named “Oracle BPM Suite.” It includes:
- Oracle BPM Studio (ALBPM Studio, BPEL Designer)
- Oracle BPEL Process Manager (runtime)
- Oracle Business Rules
- Oracle Business Activity Monitoring
- Restricted use of Oracle WebCenter Suite (for Process Portal)
More confusing to me is the UI side. Oracle ADF is the strategic UI builder. Oracle WebCenter is the strategic portal/collaboration environment, and leads Oracle’s charge into the Enterprise 2.0 space. It takes a wide range of point products, from collaboration to content management, and combines them in an integrated suite architected for “enterprise-class” use.
Oracle WebCenter Services will include a mix of existing OWC and AquaLogic components:
- Oracle WebCenter Framework
- Oracle BPEL Worklist (Human Workflow)
- Oracle UCM Content Adapter (access Content from Stellent)
- Oracle Portlet Bridge & JSR-168 Container
- Oracle Composer (Thin Client Customization)
- Others: Wikis, BLOGS, Tasks, Discussions, Polls, Surveys, …
- Oracle Ensemble (formerly BEA AL-UI Ensemble)
- Oracle WebCenter Analytics (formerly BEA AL-UI Analytics)
- Oracle WebCenter Adapter - Content Integration from external Content Stores into WebCenter
Oracle WebCenter Suite is a bundled offering combining OWC Services with a number of collaboration and portal tools, several of which come from BEA:
- Oracle WebCenter Spaces (Portal Communities)
- Oracle Content Server (restricted Document Repository)
- Oracle Secure Enterprise Search (restricted use)
- Oracle Presence (Restricted to Max of 50K Users)
- Oracle BPEL PM (Restricted to Community & Content Approvals)
- Oracle WebCenter Interaction (BEA AL-UI Interaction)
- Oracle WebCenter Collaboration (BEA AL-UI Collaboration)
- Oracle WebCenter Sharepoint console (BEA AL-UI Sharepoint Console -ability to access Content from Sharepoint into AL-UI)
- Oracle WebCenter .Net Application Accelerator (BEA AL-UI .Net Application Accelerator)
- Other BEA AL-UI Individual Line Items folded in
Only part of OWC Suite is included in the new BPMS.
Finally, Oracle intends to follow IBM’s lead and continue to offer a separate special-purpose BPM product - fka Stellent - for content-centric workflow, including imaging and document capture, rather than orchestrate those content services using the “real” BPMS (either one of them). I don’t think this strategy works for IBM and I don’t think it’s ideal for Oracle, either.
July 1st, 2008
