Archive for June, 2008
Having long held the inside track, the BPDM camp has felt little need to advocate publicly for its vision for BPMN 2.0. However, with united opposition from IBM, SAP, and Oracle, EDS’s Fred Cummins, co-chair of the BMI task force in OMG (responsible for BPMN and other BPM standards), has begun something of a public defense. His first post addresses the concern that BPDM is “too complex.” He begins by acknowledging that BPMN and BPDM sprang from different goals:
BPMN focused on defining a graphical notation that was consistent with the way business people think about business processes. BPDM was intended to provide a common modeling representation to resolve differences between existing standards and proprietary languages, independent of the implementation technology.
The admission that BPDM was never conceived as BPMN but a way to map BPMN to other things is something all sides can apparently agree on.
While the success of BPMN’s adoption by such a wide variety of tool vendors has been greatly aided by its light weight - it doesn’t try to do too much - Fred notes that BPDM is not intended to stand alone, but to serve as the process component of a “suite of business modeling languages being developed by OMG,” including SBVR (business rules) and BMM (strategic motivation model). Moreover, the reason for BPDM’s complexity - what Fred calls “robust abstract metamodel” - is that it has to define…
…basic concepts, many of which will occur in other business models, but in different contexts [in order to] establish consistency of concepts between the different modeling languages. Within BPDM these concepts provide a consistent foundation so that the meanings of the concrete elements that occur in different graphical expressions of BPMN will be consistent with each other and will be interpreted in the same way when used in different modeling tools.
I personally doubt this is a winning argument, if adoption by process modeling tools is the measure.
But I have to say that complexity of the metamodel would not rank at the top of my list of complaints about BPDM. More serious is the view that the notation is secondary to the metamodel, and that user-defined semantics are OK as long as the underlying metamodel can describe them. This is the essence, for example, of Antoine Lonjon’s contention that an attached event in BPMN does not necessarily abort an unfinished activity. Non-aborting attached events would be a great idea, I agree, but step one is to define a notation for it and put it into the BPMN spec.
I have no problem with BPDM as an abstract metamodel, but simply renaming it BPMN 2.0 puts at risk the success BPMN has enjoyed to this point (even without an interchange format). But I’m glad Fred is engaging in the public debate.
June 23rd, 2008
The most interesting keynote at the Intalio User Conference was by Greg Olson, founder of Coghead, a BPM-in-the-cloud service that uses Intalio as the process engine under the covers. Coghead bills itself as a next-generation platform for situational apps, such as built today on Excel, Access, or FileMaker. Instead of professional developers, Coghead targets independent web developers and power users. The platform is 100% web based, a multi-tenant service hosted on the Amazon cloud infrastructure, with simple subscription-based pricing (free for single user). You can define data, forms, and perform the usual set of database operations, so it’s really easy to build a database app in the cloud.
So where is the BPM part? You can customize an insert, update, or delete by defining it as a process flow, as shown here.
The diagram isn’t full BPMN, but you can have conditional branches, loops, do lookups, set values, send email alerts, or perform custom actions. The flow becomes BPEL under the covers, executed on Coghead’s Intalio engine. Instead of process being the centerpiece, mini-processes are used to replace simple database operations. The entire app is Web 2.0, accessible through Google Gadgets or iframe. It’s pretty cool.
All of the data lives in Coghead, so you probably are asking how to integrate this with your real data sources behind the firewall. Coghead provides a “linked application” feature in which a facade on Coghead communicates with a RESTful API on your app behind the firewall, which I believe is based on the Atom Publishing Protocol (APP). Much as we have WSDL-based adapters to business systems today, it is expected that application systems will increasingly offer APP “adapters” for this type of integration, either from the app vendors themselves, middleware providers, or built by individual developers.
June 18th, 2008
Did you know Adobe had a BPMS? Most people don’t, even though with over 5000 customers they could be considered a major player. One reason people don’t know about Adobe and BPM is that the company doesn’t talk about it in the usual way. In fact, it treats the normal catalog of BPMS features and functions, like workflow and integration adapters, as commodities. For example, Adobe includes process modeling and a workflow engine inside every copy of LiveCycle Enterprise Suite, although to get full human task support you need to get the Process Management ES component as well.
Instead, Adobe’s positioning emphasizes user “engagement,” which is Adobe’s code for an effective user interface, since ordinary HTML user interfaces, such as found in most customer-facing web applications and human workflow tasks, cannot - in Adobe’s view - fully meet user needs. Thus while most BPMS vendors make orchestration the centerpiece and UI an afterthought, Adobe takes the reverse approach.
The ace up their sleeve is that the players for Adobe’s rich Internet application formats - PDF and Flash - are already ubiquitous. Do you know of any desktop that doesn’t have them installed? You might say, so what? Lots of products support PDF and Flash. And Adobe would answer, not the way LiveCycle does. LiveCycle provides a wealth of special server-controlled features that lets you use the free Adobe Reader to fill out forms, digitally sign forms and documents, apply security and digital rights management, encode user data into scannable barcodes, and all kinds of other crazy things. And Adobe’s tools let you render XML process data in Ajax web formats (Flex), multimedia Flash, or PDF, and pop back and forth between the formats. While most BPMS vendors are preaching agility and ease of use to Java developers, Adobe is going after the larger population of Flex and Flash web developers and introducing them to BPM.
OK, that part of the story is about a year old, not new. What’s new from Adobe, in the unglamorously named “Update 1″ version of LiveCycle Enterprise Services, is content management. This is an OEM version of Alfresco’s open source ECM offering, tightly integrated with the LiveCycle development environment. Besides the basics of foldering and search, versioning and access control, it provides automatic content classification, retention management, and team collaboration. Integrated with LiveCycle’s BPM, it provides built-in support for content events, where a new or updated document in the repository can trigger a new process or complete a waiting process activity, based on automated policies and rules.
Previously, to get this kind of “active content” behavior, you had to go to EMC Documentum or IBM FileNet… at a considerably higher pricetag. And if you already have Documentum or FileNet, Adobe also has a LiveCycle BPM adapter for those, too. Real ones, documented and supported, not something a PSG guy hacked together one weekend for a customer. So I think Update 1 could make Adobe a player in the content-enabled BPM category.
Adobe tends to lump content management in the “engagement” bag, but I suspect it’s a different market, and at least as big. Any human-centric process has document attachments, and in most BPMSs they are completely unmanaged. They are stored in a filesystem with no metadata other than the process instance, no access control, search, or - most important - retention management. The lifecycle of these attachments is often independent of the process instance, and stretches over a longer period. The ECM world has been successful over the past few years raising awareness of compliance and retention issues, and I have no doubt a similar thing could happen in BPM, but most users don’t want to spend a lot of money on it. Now with LiveCycle ES, they won’t have to.
June 17th, 2008
A lot of speculation about the fate of BPM and other BEA goodies after what Sandy calls “the Borg” has its way with them. Oracle will reveal all in a public webcast on July 1 at 9am PT/noon ET. To the analysts they wrote:
On July 1st at Noon EDT/9:00 am PDT/5:00 pm in London, as part of the “Welcome BEA and Middleware Strategy Briefing” webcast, Charles Phillips and Thomas Kurian will explain how the addition of BEA products to Oracle Fusion Middleware will create a best-in-class combination. Public registration is open here. You can register for yourself and invite your clients to do so too. The webcast will also be available on demand after the event.
Given all the snark to date, I think it’s smart for Oracle to let the people hear it direct from the Borg itself. And my AR friend Avi there promises that, contrary to my speculation, they do know how to spell BPM.
Glad to hear it!
June 12th, 2008
Next week I’m stirring the pot again on one of my favorite topics - BPMN and Business-Empowered Implementation. Not once but twice.
On June 17 I’ll be moderating a panel at the Intalio User Conference in San Francisco. I’m hoping for users who have been-there-done-that with Intalio’s BPMN modeler. What is the business-IT interaction really like? What skills are required? What are the hard parts? The parts that went better than expected? I’m interested to find out myself!
On June 18 I’m doing a webcast on ebizQ: Business-Empowered Process Implementation… Good for Business and IT. Here’s the registration link. It bugs me that some people continue to repeat the old canard about business folks tweaking production apps with no IT involvement. This is a short one that describes what business-empowered implementation - such as possible with BPMN-based BPM Suites - is really all about.
June 11th, 2008
One of BPMN’s most important elements is unfortunately also the most misunderstood. It’s called a pool, a rectangular shape that serves as a container for a process. So in that sense a pool is synonymous with a process, and that’s as basic as you can get. The confusion sets in when you understand that a business process diagram (BPD) - the top-level object in BPMN, describing a single end-to-end business process - frequently contains multiple pools. Usually only one of the pools describes your process; the others typically stand for external participants: requesters of your process, service providers to your process, or possibly sources of unsolicited events that affect your process. Often such external pools are represented as abstract processes, defined only by their interfaces, i.e. their communications with your pool in the form of messages (called message flows in BPMN). They are drawn with no activities inside, just opaque rectangles or “black box” pools.
This is sometimes quite baffling to business users learning BPMN. But you must remember that BPMN originated as a graphical design notation for BPML, a web service orchestration language quite similar to BPEL. In BPEL/BPML, a process is also a service, and in SOA the service requester and service provider are distinct and separate parties. In other words, the requester is not part of the process, but external to it. You might say this is about executable implementation and has nothing to do with process modeling. And I couldn’t really argue with that, except to say that such SOA concepts are deeply baked into BPMN, and if you ignore them you will wind up unable to avoid validation errors in your diagrams. So in my BPMN training, I try to teach this mindset to business users, even if they have no intention of moving to process implementation. Those with no prior experience in process modeling have no trouble with it, but to some experienced practitioners it is a struggle.
One of the first exercises we do in class is a simple time off request process. The diagram above is how a lot of business analysts with prior modeling experience would draw it. The pool is labeled Time Off Request, the name of the process. Lanes representing participants in the process subdivide the pool.
This is not technically incorrect, but I try to teach it a different way, like the diagram below:
Now employee, the requester, is external to the process, not part of it. In a sense this redefines the process as the servicing of a request, and excludes the preparation of the request, which is admittedly an ITish, SOA-conditioned view. The process starts upon receipt of the time off request. If the employee begins to fill out the request, has second thoughts, and never sends it off, no instance of this process is created. To me that makes sense. To some people it does not.
The employee’s own process is opaque, so we show it as a black box pool. As the service provider, we don’t really care what it is. We just want to show how we interact with it, in the form of a request message (time off request) and a choice of response messages.
One of the confusing things to business analysts who find the time to read the BPMN spec is that the spec says pools are used to distinguish process “participants.” But the spec means participants in the SOA sense, i.e. requester or provider, not in the sense of roles within the orchestration, like Manager and HR. Those are depicted as lanes within the internal process pool.
Many experienced practitioners who use process modeling for analysis and process improvement with no thought of automated implementation find my approach annoying, perhaps counter-productive, and would claim that their clients could never understand it. However, I find that business people can understand it easily; it’s the practitioners who may have to adapt their methodology.
Why would they? The answer is that BPMN is an industry standard, supported by a wide variety of inexpensive tools, and provides a common visual language that can be shared by business and IT. Those factors are creating the demand, by business, to adopt that standard, whether it fits their consultant’s pre-existing methodology or not. BPMN offers business the possibility of playing a more active role in defining the to-be process, using a common model shared with IT. But that new role and new common model demands thinking about the process in a new way - when it starts, when it ends, who’s in it and who’s external to it. And that all starts with pools.
June 11th, 2008
CMP’s TechWeb syndicates my blog, and someone posted a question re my recent post about The Future of BPM at BEA/Oracle. When I tried to reply, the CMP site rejected it for sexual innuendo or something. You be the judge.
The comment:
I did not see any speific remarks about Aqualogic in your article and pose this question to you:
Given the current apabilities of Aqualogic and Oracle’s existing ‘positioning’ of its (OEMd) BPA suite, would not Oracle be able to deliver its BPMS offering that way (I think that’s what you are saying) BUT also support the business apps (BPM+SOA) using the same ‘tools’ (thereby eliminating the requirement & assoiated additional EBITDA impact of having to use the OEM ARIS offering)?
My attempted response:
ALBPM stands for AquaLogic BPM, so I believe it was specifically referenced in the post. BPA Suite (ARIS) is at heart a repository for architectural artifacts related to BPM. The role it plays in Oracle’s BPMS, as a BPMN modeling tool that generates BPEL, is a tiny fraction of what you pay for in that offering. If you don’t care about the architectural repository, I am saying yes ALBPM used as a unified modeling/design/runtime for process is simpler than gluing ARIS BPMN to BPEL via a mapping that sort of works. But ARIS has specific features related to Oracle apps that make ditching it hard to do.
Intercession by CMP’s sex police:
Your message has been blocked due to the following words: hard on. Try omitting the word(s) cited, and reposting your message.
No additional comment necessary.
June 6th, 2008
I see my friend Jesper is moving on from BEA, so the reality of the Oracle acquisition is finally sinking in. When I hear people say that Oracle bought BEA for their BPM, I have to laugh. I’m fairly confident the Oracle crew that went after BEA could not even spell BPM. But no doubt the two BPMSs will have to be merged or rationalized somehow into a single primary offering (although IBM/FileNet provides an example of how that can be dragged out for years). I don’t actually know what Oracle’s plans are, and they haven’t solicited my opinion - you can be sure that if they had, I would not be writing about it. But I have thought a bit about what they ought to do.
Since TIBCO-Staffware and BEA-Fuego, both of which seemed crazy to me at the time, I’ve had a change of heart about consolidation in the BPMS business. At the time of those acquisitions, integration middleware vendors had one view of what BPM is - essentially a business wrapper around SOA - and workflow vendors plus the BPM pureplays had different one, focused on improving “work” and optimizing business performance. And it was not clear which vision would prevail. The middleware vendors were certainly bigger companies with more cash and resources, and in the software industry bigger usually wins.
But TIBCO and BEA, confounding my own expectations, did not embed their acquisitions as a human workflow subcomponent underneath their existing integration-oriented suite, but instead made the acquired company the centerpiece of their BPM offering. In fact SOA, the bigger business at both TIBCO and BEA, became the sub-component, with BPM at the top.
And that was smart, smarter than I was at the time for sure, because the energy in the BPM market has proved to be definitely on the human-centric side, with an emphasis on improving human work in the organization and empowering business to play a more direct role in the implementation. The way the acquisitions were handled allowed both TIBCO and BEA to understand that BPM and SOA are not just different brochures for the same product offering, but different things entirely, and require explicit links between them. It’s taken a while to build those links - in fact, they are just rolling out for real this year for the first time in both TIBCO iProcess and BEA ALBPM. In contrast, IBM and Oracle, who continue to embed human workflow as a subcomponent of an overall integration-centric offering, still struggle with the boundary between BPM and SOA.
So what does this say about what should happen now with Oracle-BEA?
First, a couple points about the two existing BPMS offerings. Oracle uses BPMN modeling in an OEM version of IDS Scheer ARIS (extended with some Oracle-specific configuration dialogs for human tasks, business rules, and notifications) to generate skeleton BPEL that is fleshed out in the SOA Suite design tool. There is a simplified BPEL outline called Blueprint intended to serve as a diagram shared by business and IT to eliminate the roundtripping problem, but it’s not as clean as a true BPMN-based design. ALBPM uses a common graphical notation for the process model and the implementation design. In version 6.1, that notation has been made (mostly) BPMN-compliant. I think this is the right way to do it, so on this point score one for ALBPM.
Oracle follows the BPEL paradigm in which the process does not actually perform activities itself but instead invokes services that perform the activities, and those services are defined outside of BPM, e.g. coded in Java and exposed as services in the SOA registry/repository. Or, in the case of human tasks, defined in the BPM environment, but deployed and managed as separate objects independent of the processes that use them. ALBPM follows the more normal BPM pattern in which activity implementations are defined and used within the BPM environment itself. If services are created in SOA and exposed in the registry/repository, ALBPM can bind to those, but it’s not the only way to do it. In a SOA-based production environment, both BPMSs get you to the same place, but it’s easier to do rapid iterative BPM development and deployment the ALBPM way.
So, if Oracle’s goal is to maximize success in the “straight” BPM market, making ALBPM the environment for both modeling (replacing ARIS) and end-to-end implementation makes the most sense, moving SOA Suite (BPEL) down to the SOA layer and replacing the links to AquaLogic SOA components with links to their Oracle Fusion counterparts.
But it’s not at all clear that the straight BPM market is Oracle’s objective. Like SAP, Oracle tends to view BPM primarily as a platform for transforming their enterprise applications from old-style monoliths to composable services. The BPMS developers, I’m sure, would like to make their product a good fit for both the straight BPM market and their own apps business, but that is hard to do. For example, one reason for separating human tasks from BPM is to support the apps business. Also, a reason for hanging on to ARIS, despite the clumsy integration with implementation, is that it provides prebuilt reference models for the apps.
It is possible that Oracle could adopt an IBM-like strategy and keep both threads alive until things sort out, using ALBPM on top of Fusion as the straight BPMS offering, and the current ARIS+SOA Suite to support the apps business. In some ways that’s the path of least resistance, anyway, so I suspect that’s what will happen.
June 4th, 2008
