Tag: BPEL

BPM Think Tank Day 1: ebBP (aka BPSS)

I’m in the BPM Think Tank pre-conference workshop on ebXML BPSS (Business Process Specification Schema), relabelled no less cryptically as ebBP (eBusiness Business Process, with the “specification schema” implied), presented by Sally St. Amand of the OASIS ebBP Technical Committee. St. Amand is obviously very knowledgable on the subject matter, but is a less-than-engaging speaker — call it the bureaucratic style of presentation, full of long pauses and paper shuffling.

According to the TC’s site:

The ebBP is a technical business process specification. It defines a standard language so that business systems can be configured to support the execution of business collaborations between partners or collaborating parties rather than the processing accomplished from the perspective of one business partner. The formal designation has been eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS). It is more commonly known as ebBP (after the OASIS ebXML Business Process Technical Committee).

In other words, ebBP is an execution language for business collaboration between peers, like most eBusiness (and EDI) specifications before it, although it also allows for non-first-class participants (such as others in the supply chain) who may wish to observe the state of the process at certain points. In its basic format, it’s very similar to other XML-based eBusiness specifications that I’ve seen, usually from vendors; these vendor-provided specifications will hopefully migrate towards the ebBP standard as V2.0.X is adopted. The benefit of including observer participants became really obvious in a diagram of an eBusiness exchange that includes an observer: the message flow can include messages to the observer at any time, rather than just between the two main participants, although only the first-class participants can initiate the signals.

ebBP specifies the XML format, but does not include any graphical representation or modelling. There is an open source ebBP editor, which I’ve downloaded but haven’t tried out yet.

Working this into the general standards landscapte, ebBP is a choreography language for collaboration between different organizations, whereas BPEL is an orchestration language for processes that are controlled by one organization (although may execute across organizations).

BPEL: just another language

Phil Gilbert’s post last week exposes the Emperor’s clothes for what they are: BPEL is just another implementation language:

It’s simply a new way to write code. It has nothing to do with the management of business processes. I don’t love it or hate it; other than that it is a distraction. BPEL isn’t necessary to achieve the benefits promised by business process management – and therefore it’s an impediment in the market conversations that are occurring with respect to business process management.

Yes, BPEL can make writing code to implement BPM easier, but don’t confuse that with anything to do with managing business, or with anything that allows the control of business processes to be moved into the hands of the business.

BPM Think Tank

I’ve just registered for the OMG‘s BPM Think Tank in Washington DC on May 23-25. The program is mostly about standards, which is a big focus for me right now. It will be a chance to see some people who I’ve met before, such as Phil Gilbert and Derek Miers, and meet a few others for the first time face-to-face, such as Bruce Silver, Keith Swenson (who I heard speak at the Gartner BPM Summit) and John Evdemon (who was referred to me by Harry Pierson when I met him at Mashup Camp).

If you’re going, look me up. If you haven’t signed up yet, discount registration fees for the BPM Think Tank are still available until May 1st.

OMG gets full marks for including bloggers when they’re handing out press passes; my thanks to Dana Morris and Stephanie Covert for their forward-thinking press relations policies. I’ll be blogging more about the event before, during and after.

Integration FUD factor

A good article in DMReview (where normally I find much more about data warehousing and business intelligence than integration) on Fear, Uncertainty and Doubt about integration, especially for small-to-medium sized businesses that don’t have IT budgets that look like the GDP of a small Pacific nation. I just love it when someone cuts through all the crap:

Integration is moving data elements from point A to point B with the necessary translation in between…Tier-one integration vendors have conditioned the market to believe that integration should cost millions of dollars and take years to implement. With today’s offerings, this is simply no longer the case.

Couldn’t have said it better myself.

Through a fog of BPM standards

If you’re still confused about BPM standards, this article by Bruce Silver at BPMInstitute.org may not help much, but it’s a start at understanding both modelling and execution languages including BPMN, UML, XPDL, BPEL and how they all fit together (or don’t fit together, in most cases). I’m not sure of the age of the article since it predates the OMG-BPMI merger that happened a few months ago, but I just saw it referenced on David Ogren’s BPM Blog and it caught my attention. David’s post is worth reading as a summary but may be influenced by his employer’s (Fuego’s) product, especially his negative comments on BPEL.

A second standards-related article of interest appeared on BPTrends last week authored by Paul Harmon. Harmon’s premise is that organizations can’t be process-oriented until managers visualize their business processes as process diagrams — something like not being able to be truly fluent in a spoken language until you think in that language — and that a common process modelling notation (like BPMN) must be widely known in order to foster communication via that notation.

That idea has a lot of merit; he uses the example of a common financial language (such as “balance sheet”), but it made me think about project management notation. I’m the last person in the world to be managing a project (I like to do the creative design and architecture stuff, not the managing of project schedules), but I learned critical path methods and notation — including hand calculations of such — back in university, and those same terms and techniques are now manifested in popular products such as MS-Project. Without these common terms (such as “critical path”) and the visual notation made popular by MS-Project, project management would be in a much bigger mess than it is today.

The related effect in the world of BPM is that the sooner we all start speaking the same language (BPMN), the sooner we start being able to model our processes in a consistent fashion that’s understood by all, and therefore the sooner that we all starting thinking in BPMN instead of some ad hoc graphical notation (or even worse, a purely text description of our processes). There’s a number of modelling tools, as well as the designer modules within various BPMS, that allow you to model in BPMN these days; there’s even templates that you can find online for Visio to allow you to model in BPMN in that environment if you’re not ready for a full repository-based modeling environment. No more excuses.

One last session

I’m cutting out early for my flight home, so I’m finishing the FileNet user conference with another BPM technical session, this one on process orchestration. This is a relatively new area for FileNet in terms of out-of-the-box functionality, and a bit behind the competitive curve but they appear to be charging into the fray with strong functionality. Mike Marin, BPM product architect extraordinaire, walked us through the current state: the ability of a process to consume web services, and the ability to launch and control a process as a web service. Mike sits on a couple of standards boards and is pretty up-to-date on what’s happening with the competition and future directions. Nothing here that I wasn’t already aware of, although he provided some good technical insights into how it all works under the covers as well as an excellent distinction between choreography and orchestration. He also talked about using web services as a method for federating process engine services, that is, allowing a process to span servers, which I think is absolutely brilliant. The same thing holds for invoking and being invoked by a process on a BPEL engine (like Oracle’s), because it’s just a web service interface.

Time to grab some lunch and head for the airport. Regular (non-UserNet) blogging resumes later this week.

BPM SIG

I’m in the BPM special interest group session, which is much more sparsely attended than I expected, but it’s just after lunch and people are still trickling in. The conversation is starting out a bit granular, questions about some very specific functionality although I suppose that’s part of the goal.

Chris Preston just made a statement that the clear direction for interoperability is BPEL, which is definitely the right answer although there’s still a lot of issues around handling the human-facing steps in a process. Unfortunately, in the absence of any questions from the audience, he’s off on a long rant about “re-engineering” using FileNet tools for process modelling, execution, analysis and simulation, which is a little too sales-y althoguh he’s doing his best to be consultative. He needs to encourage much more give-and-take with the audience rather than going into full oratory mode.

Minutes go by, and I’m really starting to wish that I sat closer to an escape route…

BPM: a moving target

I’m prepping for the 2-day Making BPM Mean Business course that I’ll be delivering this weekend in Las Vegas, and it’s giving me a chance for a complete end-to-end review of a lot of material that I’ve been gathering, thinking about, presenting and rewriting over the past several months. One thing that immediately strikes me is the constant state of change: since I sent these materials for printing three weeks ago, there’s new things that I just have to include. The BPEL for People initiative (IBM-SAP white paper here), for example, which is a critical step to having BPMS products use BPEL more extensively. The ongoing effects of the OMG-BPMI merger. New versions of Enterprise Architecture modelling tools such as ProVision, since I position BPM in an EA context in this course.

There’s also a lot of wisdom that I’ve gathered over time that it will be fun to discuss with the course participants: how to do a business walkthrough, analyzing and designing business processes, and ROI calculations for BPM.

I spent this morning sitting in a local café (a good place to get away from all distractions except the Crackberry, which I am unable to detach from my psyche), putting the final touches on the workshop exercises that I’ll be having the participants do during the course. It’s a small class which should result in a lot of interaction amongst the attendees, and since they’re all from different companies, I’ve decided to do individual projects rather than group projects so that they actually have something usable to take home about their own business processes at the end of the two days. It’s sort of like speed-consulting for me, which should be fun all around.

I’m all a-quiver with anticipation.

Visio for BPMN

Another article by Bruce Silver on the value of using Visio for process modelling. His argument is that it’s already a de facto standard, with two-thirds of the world’s existing process models done in Visio, so why not find ways to just make it ready to play in the big leagues?

One way is to allow import of Visio models into enterprise architecture modelling tools such as Popkin, where they would then be “finished” by developers, but I don’t like that method because it takes control of the modelling — includuing ongoing maintenance for the models — out of the hands of non-technical process designers.

The other is to use add-ons to Visio that allow a process designer to create BPMN-compliant process models in place, then generate BPEL or XPDL. ITP-commerce, for one, has a tool to do this, and I think it could be a better solution in many cases, since it allows the process designers to use a familiar tool and easily work from their existing library of models.

What’s in a name?

Just discovered mwd blog through their post about BPEL; they believe that the “business process” part of BPEL is a bit of a misnomer, and that “at the very best what vendors are really representing are definitions of integration processing.” I knew that I was in tune with these guys when I read their earlier post on ESB, which tears a strip off technical marketing types that invent new terms for existing concepts in order to attempt to achieve some sort of marketing advantage.

Their BPEL post also includes a link to a Bruce Silver article about BPM standards that’s definitely worth reading.