Thursday morning, and it seems like a few of us survived last night's baseball game (and the after-parties) to make it here for the first session of the day. This will be my last session of the conference, since I have a noon flight in order to get back to Toronto tonight.

Tim Stephenson and Mark Elder from TIBCO talked about Business Studio, carrying on from Tim's somewhat shortened bit on Business Studio on Tuesday when I took up too much of our joint presentation time. The vision for the new release coming this quarter is that one tool can be used by business analysts, graphical tools developers and operational administrators by allowing for different perspectives, or personas. There's 9 key functions from business process analysis and modelling to WYSIWYG forms design to service implementation.

The idea of the personas within the product are similar to what I've seen in the modelling tool of other BPMS vendors: each has a different set of functions available and has some different views onto the process being modelled. Tim gave some great insight into how they considered the motivations and requirements of each of the types of people that might use the product in order to develop the personas, and showed how they mapped out the user experience flow with the personas overlaid to show the interfaces and overlaps in functionality. This shows very clearly the overlap between the business analyst and developer functionality, which is intentional: who does what in the overlap depends on the skills of the particular people involved.

As we heard in prior sessions, Business Studio provides process modelling using BPMN, plus concept modelling (business domain data modelling) using UML to complement the process model. There's a strong focus on how BPM can consume web services and BusinessWorks services, because much of the audience is likely developers who use TIBCO's other products like BusinessWorks to create service wrappers around legacy applications. At one point between sessions yesterday, I had an attendee approach me and thank me for the point that I made in my presentation on Tuesday about how BPM is the killer app for SOA (a point that I stole outright from Ismael Ghalimi -- thanks, Ismael!), because it helped him to understand how BPM creates the ROI for SOA: without a consumer of services, the services themselves are difficult to justify.

We saw a (canned) demo of how to create a simple process flow that called a number of services that included a human-facing step, a database call to a stored procedure, a web service call based on introspecting the WSDL and performing some data mapping/transformation, a script task that uses JavaScript to perform some parameter manipulation, and an email task that allows the runtime process instance parameters to be mapped to the email fields. Then, the process definition is exported to XPDL, and imported into the iProcess Modeler in order to get it into the repository that's shared with the execution engine. Once that's done, the process is executable: it can be started using the standard interface (which is built in General Interface), and the human-facing steps have a basic form UI auto-generated.

It is possible to generate an HTML document that describes a process definition, including a graphical view of the process map and tabular representations of the process description.

As I mentioned in other posts, and in many posts that I've made about BPA tools, is that there's no shared model between the process modeller, which is a serious issue for process agility and round-tripping unless you do absolutely nothing to the process in the iProcess Modeler except to use it as a portal to the execution repository. TIBCO has brought a lot (although not all) of the functionality of the Modeler into Studio, and are working towards a shared model between analysts and developers; they believe that they can remove the need for Modeler altogether over time. There's no support at this time, however, to being able to deploy directly from Studio, that is, Studio won't plug directly into the execution engine environment. Other vendors who have gone the route of a downloadable disconnected process modeller or a separate process discovery tool are dealing with the same issue; ultimately, they all need to make this new generation of modelling tools have the capability to be as integrated with the execution environment as those that they're replacing in order to eliminate the requirement for round-tripping.

Posted by Sandy Kemsley at 12:59 PM in BPM • BPM standards • SOA • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

At this point, it makes more sense to start labelling the posts by session title rather than presenter, since we're getting into some pretty detailed breakout topics. This one was presented by Roger King, Director of BPM Product Strategy & Management at TIBCO, and Justin Brunt, product manager for iProcess.

Most of the technical people working TIBCO's BPM group seem to be vestiges of the Staffware acquisition; many of them are still based in the UK, where the development is still done.

They started out with a review of what's happened in the products in the past 12 months:

• Business Studio 1.x, a standalone modelling and simulation product aimed at business analysts; the free downloadable version released in November already has more than 10,000 downloads. Modelling is done in BPMN, and XPDL is supported for import and export -- necessary for even getting the models into the iProcess Suite for execution, since there is no shared model with the process execution environment. It also supports imports from Visio and ARIS. There's some more advanced features as well: a hierarchical organization of business processes and associated assets; and process simulation with SLA indicators and reports.
• iProcess Suite 10.5, with improved work queue performance and scalability to support more concurrent users, better performance for sorting and filtering (always slow with most BPM products) and faster startup time. It also included an enhanced web client based on General Interface, with GI or custom forms support and a number of other new functions.
• iProcess Insight 2.0, the BAM product, which I reviewed in a post yesterday.

What's coming in the near future:

• Business Studio 2.0, with support for the full BPMN 1.0 specification and XPDL 2.0. I keep meaning to download Business Studio and do some comparative analysis with some of the other downloadable modelling products, but I may wait until version 2.0. I wrote about a few of the new features from Tim Stephenson talk yesterday, but here's a recap. In the process analyst perspective: design patterns/fragments to speed design, refactoring, concept modelling with UML support, import/export of EPC/FAD from ARIS, and custom XSLT translations to XPDL. In the process architect perspective: service registry, native services such as email and database connectors, direct server deployment and version control
• iProcess Suite core component support for some new platforms, including 64-bit Windows Server and Red Hat Linux; direct deployment from Studio to Engine (although it's not clear if this is via a shared model or just automates the import/export process); and new audit trail entries. They've also simplified installation.
• Web services capability, with support for WS security at the transport and SOAP layer, and support for withdraw actions and delayed release.

They went on to discuss a number of key themes in product development for this year and beyond.

They're gradually migrating to a single modelling/design environment -- Business Studio -- although they're still not quite there yet; this will provide a more consistent experience for both business and IT users of the design tools. This supports the move to full model-driven development by allowing for the easy integration of forms design into the Eclipse-based environment, which can in turn generate GI, JSP or other runtime forms for the updated iProcess web client. Business rules definition will be in the Eclipse-based design environment, although it's not clear if they're using a third-party BRE or have their own rules technology. The old modelling environment, Business Modeler, isn't going away any time soon, but new feature development will focus on Business Studio so will encourage migration. Like most vendors using this tactic to get existing customers off an old product, I expect that they'll hear grumbling about this for years.

The out-of-the-box web client will be simplified and made to look more like the familiar Outlook client, with improved performance. The UI will also be exposed as components and services to allow them to be included in custom applications or portals, and they'll ship an out-of-the-box BPM portal using TIBCO's portal platform to show how this can be used. There will be better MS-Office integration and an Eclipse-based desktop application.

They're also going to provide a project collaboration portal for BPM projects, to allow people developing TIBCO BPM applications to collaborate. They're also adding in some governance capabilities to help handle the lifecycle of BPM projects and assets.

King mentioned my presentation from yesterday directly, and commented that they're going to be supporting more of the BPA tools for import soon, including Proforma. They've obviously identified that it's important to be extremely open from both a standards and BPA support standpoint.

Next on the list is goal-driven BPM, or virtual processes, where there may be too many process alternatives to model explicitly and the optimal runtime process has to be generated based on process parameters and environmental factors. This sounds like fuzzy future stuff, but would be great if they can pull it off.

They're also developing workforce management and more complex resource modelling for the purposes of business optimization.

There was a brief point at the end about preparing for the next generation of SOA, although no time to talk about what this means; I would have loved if this session had been a bit longer.

Posted by Sandy Kemsley at 04:08 PM in BPM • BPM standards • BRE • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

There's an awful lot of keynotes in this conference: a couple of overall sessions this morning, now "track keynotes" for each of the four tracks within the BPM conference. I'm in Bruce Silver's New Directions in BPM Tools and Technology session, where he started by taking a gentle poke at Gartner, saying that BPM is more than a management discipline (Gartner's most recent definition of BPM).

He started out discussing process modelling, and how it's inherently a business activity, not an IT activity, which speaks directly to the issue of the tools used for modelling: is there a handoff from a modelling-only tool to an execution environment at the point of business to IT handoff, or is the model actually just a business view of the actual implementation? With all of the vendor demos that I've done lately (I know, I have yet to document many of there here, but I'm getting to it), I've had quite a focus on the distinction between having a model shared between business and IT, and having a separate BPA tool that models much more than just the processes that will be implemented in a BPMS. Bruce positions this as "BPA versus BPMN" views towards describing process modelling, and doesn't see them in conflict; in fact, he thinks that they're ignoring each other, a viewpoint that I'd have to agree with given that BPA initiatives rarely result in any processes being transferred to some sort of execution engine.

Bruce, who often accuses me of being too nice, takes a stab a the vendors in a couple of areas. First is with their BPMN implementations, specifically that of events: he states that many of the execution engines just don't support intermediate events, so that the vendors conveniently forget to include those events in their BPMN modelling tool. Second is with simulation, and looking at whether a vendor's implementation is actually a useful tool, or a "fake" feature that's there to enable it to be checked off on an RFP, but not functional enough to make it worth using.

He has a nice way of categorizing BPMS products: by vendor speciality (e.g., integration, human-centric), by process type/use case (e.g., production workflow) and by business/IT interaction method (collaborative shared model versus handoff). This was interesting, because I wrote almost identical words two days ago in my presentation for the Shared Insights Portals and Collaboration conference that I'll be speaking at next month; great minds must think alike. :)  His point, like the one that I was making in my presentation, is that most BPM products have some strengths and some weaknesses that can make or break some process automation; for example, a product focussed on human-centric workflow probably doesn't do some nice integration tricks like mapping and transformation, or complex data objects.

He also makes a good distinction between business rules (implemented in a BRE) and routing rules (implemented in a BPMS): business rules represent corporate or departmental policies that may need to be shared across business processes, whereas routing rules are the internal logic within a process that's just required to get through the process but don't represent policy in any way.

Bruce thinks that BPM and SOA together is still vapour-ware for the most part: it's what the vendors are selling but not typically what they're delivering. In particular, he thinks that if the BPMS and the ESB are not from the same vendor, then "all bets are off" in terms of whether a BPMS will work with any particular ESB or other services environment.

The session turned out to be too short and Bruce couldn't even finish his materials, much less take questions: it was only 45 minutes to begin with, and shortened at the beginning while Bruce waited for stragglers for the previous session to make their way upstairs.

Posted by Sandy Kemsley at 01:20 PM in BPM • BPM standards • BRE • BrainStorm2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

I just listened in on To BPEL or Not To BPEL, the title of which I believe resolves the pronunciation issue once and for all: although the presenter (Danny van der Rijn, principal architect at TIBCO) said "BEH-pull", clearly it must be "BEE-pull" to make the title work. :)

Intended for those with a technical interest in BPEL, van der Rijn went through the history of BPEL from its origins as a melding of IBM's WSFL and Microsoft's XLANG, through the BPEL4WS 1.0 specification in 2002, 1.1 in 2003 and the soon-to-be-approved WS-BPEL 2.0. More importantly, he looked at why BPEL emerged: basically, the web services stack didn't do enough to allow the orchestration of processes.

He then talked about what you're not going to do with BPEL -- it's not a process modelling notation, it's not for service creation -- and stated that it's not for portability: he mentions XPDL as a solution in that area (with no mention of BPDM). What I'm seeing, however, is that although BPEL may not have been intended as an interchange format, that's exactly what it's being used for in many cases. For many BPM engines, the "E" in BPEL is apocryphal: BPEL is a format that's used to import process models from other applications, but it's then converted to an internal (proprietary) format for the actual execution.

He covers off all the changes in 2.0: data, scoping model, message handling, activities and more, and walks through the basic BPEL components in some amount of detail. Overall, a good technical introduction to BPEL.

Unfortunately, about 40 minutes into the presentation, I received an "Invalid Flash Player Version" stating that I needed Flash Player version 8 to view the current content, and I lost all audio and video of the presentation. Flash? I was supposed to be using the Windows Media Player version of the presentation! On24.com really needs to get their act together: changing system requirements mid-presentation is not cool. Even when I installed the new Flash version and did a successful test, I wasn't able to get back in. Guess that I'll have to see the last bit in reruns.

Posted by Sandy Kemsley at 12:58 PM in BPEL • BPM standards | Permalink | Comments (9) | TrackBacks (0) | Add to del.icio.us

An interesting bit on the WfMC site comparing XPDL and BPEL that was highlighted in a WfMC mailing this week:

BPEL and XPDL are entirely different yet complimentary standards.  BPEL is an "execution language" designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-a-vis application integration.  The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to "run" the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is not an executable programming language like BPEL, but specifically a process design format that literally represents the "drawing" of the process definition. To wit, it has ‘XY' or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPMN process diagram. For this reason, XPDL is effectively the file format or "serialization" of BPMN, as well as any non-BPMN design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)

A good distinction between the best uses of BPEL and XPDL, except for one point: very few vendors are using BPEL as an execution language; they're using it as an interchange format, which is causing a lot of confusion about what format to use (XPDL or BPEL) to move process maps between a modelling and execution environment. As the above paragraph points out, XPDL maintains the graphical drawing information as well as the execution-specific information; it also supports everything that can be modelled in BPMN (which BPEL currently can't).

There's also an article by Jon Pyke of WfMC in Computer Business Review Online where he smacks them down for calling XPDL a failure in a previous article, and states that XPDL is "often incorrectly perceived to be competitive with the business process execution language, BPEL, standard". XPDL and BPEL aren't competing in the sense that someone would elect to use one over the other, but they are competitive in that they're both used as interchange formats, just for different types of processes or in different tools. Unless your BPM engine actually uses BPEL as an execution language (which few do), you're not going to go from BPMN to XPDL to BPEL and then on to your BPM engine's proprietary execution language, because there's no value added from an additional data transformation: you'd do BPMN=>BPEL=>[BPM engine execution language] (obviously skipping the last transformation if the native execution language is BPEL) for web services orchestration-type processes that can be described completely using BPEL, or you'd use BPMN=>XPDL=>[BPM engine execution language] (where the latter may or may not be BPEL) for the larger set of functions supported by XPDL, like human-facing steps. In many cases, the choice of XPDL or BPEL is dictated by what's supported by the tools that you use for processes modelling; those tools intended to model processes of web services orchestrations are more likely to support BPEL, whereas those targetted at the "BPM suites" market are more likely to use XPDL.

Posted by Sandy Kemsley at 11:21 AM in BPEL • BPM standards | Permalink | TrackBacks (0) | Add to del.icio.us

It's not often that you get free advice from an analyst/consultant, but I gave this one away already today in a conversation with a vendor: don't ignore BPDM. The fact that Lombardi has already announced support for it as the interchange format between Blueprint and TeamWorks (not a coincidence that Lombardi's CTO sits on OMG standards committees) even though the standard is not yet released means that it's likely to be presented to customers as a competitive differentiator by the BPM vendors who implement it very early on in the game. Assuming that it catches on, you'll still need to support both BPDM and XPDL for a period of 2-5 years.

Posted by Sandy Kemsley at 03:57 PM in BPM standards | Permalink | TrackBacks (0) | Add to del.icio.us

I skipped the last breakout session of the day for a discussion with Trevor Naidoo, IDS Scheer's Director of ARIS Solution Engineering. He's responsible for the pre-sales technical activities, and used to be an ARIS customer, so is very familiar with how customers use the product and how they want to use it.

We spoke first about integration between ARIS and the BPMS products that automate processes, which included some discussion about standards. He pointed out that integration using pure standards tends to degrade to the least common denominator -- a point that I'm not sure that I agree with for all standards, although it makes sense if you picked BPEL as your standard -- which led them to take a different approach with their most tightly integrated partners, SAP and Oracle: that of "standards-based" integration, where they extend BPEL (I believe) in order to provide increased functionality. I'm not sure at what point a "standards-based" approach becomes "proprietary", although I can see the value of going this way. In any case, they're using different approaches for different vendors: "standards-based" for SAP and Oracle, BPEL for Lombardi, and XPDL for Fujitsu.

This really came around to the issue of how to get those process models into an execution engine, or if anyone is really doing it at all. Naidoo said that what was moving from ARIS to the execution engine was a "process outline", which then required some amount of work to hook it up to the BPMS engine (as expected), and that the main value is not in the transfer itself -- which could be readily recreated in the BPMS designer directly -- but in engaging the  business in the entire process design cycle. This, then, is what I suspected: that most people really are redrawing the process models in the BPMS designer, adding who knows how many translation errors along the way, because there is insufficient value to bother with the direct integration. This is not unique to ARIS; I saw the same thing at the Proforma user conference last year.

We moved on to talk about the technology. I hadn't done my homework in this area, and was really unaware of ARIS' support for browser-based design (yes, I'm on my usual rant about browser-based process modelling); they have a Java applet client for design in a browser environment, which is a pretty heavy footprint by today's AJAX standards. I'd love to hear more about their plans to put that client on a diet, which will greatly facilitate design collaboration with occasional users, both inside and outside the corporate firewall.

We finished with a discussion of how to move the process modelling story from what is usually a departmental beginning within a company up to the executive level and therefore out across the entire organization: internal evangelism, if you will, to leverage that initial 10-person ARIS project into making ARIS an enterprise-wide process modelling tool. This is addressed to some degree by one of their new "solutions" (which appear to be specific packaging and bundling of products and services), the Enterprise BPM solution which (based on information from their website) includes the ARIS Business Architect, ARIS Business Optimizer, ARIS Business Simulator and ARIS Business Publisher as the basis for implementing a company-wide BPM infrastructure. I still think that there's a fundamental disconnect in language between the players: the average business analyst or architect is likely too mired in detail to be able to present a high-level plan to the executives of their organization on why to super-size their ARIS installation, but I'm sure that the IDS Scheer sales team would be happy to help out. With Trevor's able assistance, of course.

Posted by Sandy Kemsley at 06:08 PM in ARISProcessWorld2007 • BPM • BPM standards • Web2.0 | Permalink | TrackBacks (1) | Add to del.icio.us

The opening keynote this morning was by Prof. August-Wilhelm Scheer, the founder and serious brain-trust behind IDS Scheer. You have to love this guy: not only is he brilliant and able to describe his ideas clearly, he opened and closed his session by playing sax in a jazz trio on stage.

He covered a lot of material in his talk, and I can't begin to do it justice but will try to hit a few of the high points.

The goal of a modelling tool like ARIS is to support business processes from strategy to model to detailed description to implementation, including changes to any part of that chain and how the changes ripple through the other layers. The design-implementation-control life cycle of business processes, with a current strong focus on the optimization end of things, serves to bring together process modelling and execution like never before.

The business model at the top of any business process is the key competitive differentiator for an organization, requiring identification of the value proposition, supply chain, and target customer. This places the business model, and the surrounding business architecture, as part of an overall enterprise architecture. Looking at the business process architecture stack (think Zachman column 2), the business model leads to the business process, which requires/populates the business process repository. This, in turn, populates the IT-business process repository for the subset of the processes to be automated, through standardized modelling formats like BPMN and serialization formats like BPEL, which in turn connect to the enterprise service repository that documents the underlying services. Surrounding all this is the business process platform for service assembly/orchestration, portals, B2B, WFMS (wow, haven't heard that term for a while: workflow management systems, for the youngsters in the crowd) and EAI.

IDS Scheer is involved with (or at least concerned with) a number of process-related standards, including ones such as BPMN and IDEF at the business process modelling level. I'm interested to see if they're involved in the BPM Think Tank that OMG runs, such as the one coming up in July in San Francisco -- an email exchange with someone from OMG a few minutes ago indicate that they're not heavily involved in OMG standards. ARIS' business model metamodel and their generally high level of innovation could almost certainly contribute to OMG standards development, if they're not already.

One interesting point that Prof. Scheer finished with (well, before he started playing sax again) was that BPMS (i.e., process execution) vendor platforms will continue to be proprietary in spite of their "commitment" to standards (my quotation marks, since I agree with this thought), so products like ARIS are necessary in order to help facilitate the movement of models between execution systems. The business view needs to be open, while the implementation layer will remain proprietary.

Posted by Sandy Kemsley at 12:21 PM in ARISProcessWorld2007 • BPA • BPEL • BPM • BPM standards • BPMN | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

Right after I dissed the new for-pay incarnation of Business Integration Journal Business Transformation and Innovation, it turns out that I'm mentioned in an article in the November/December issue.

For the past 12 to 18 months, there has been growing interest and discussion surrounding BPMN, XPDL and BPEL. What has begun to take form is the recognition of the BPMN-XPDL-BPEL Value Chain, a concept first credited to analyst Sandy Kemsley by XPDL expert Keith Swenson.

I normally don't read this publication cover to cover, but I was checking my email subscriptions folder and saw a message with the title "The BPMN-XPDL-BPEL Value Chain". Having coined the phrase "BPMN-XPDL-BPEL value chain" in a blog post covering the BPM Think Tank last May, I tend to notice when it crops up elsewhere :)

The BIJ article, written by Nathaniel Palmer of WfMC, discusses the three process standards and their interrelationship, particularly around how XPDL and BPEL are complementary, not competitive. Nothing here that I haven't written before, but it's a good overview/summary article on the subject.

Of course, being from WfMC, which authors the XPDL standard, he doesn't mention OMG's BPDM, which could prove eventually to be XPDL's nemesis.

Posted by Sandy Kemsley at 06:14 PM in BPM standards • BPMN | Permalink | Comments (4) | TrackBacks (0) | Add to del.icio.us

I'm in the online OMG tutorial on the Business Process Maturity Model (BPMM), which is a bit awkward because they've gone the really cheap route and done this with a conference call line with poor controls (everyone is in talk mode by default when they dial in, and a lot of people don't realize that it's good conference call etiquette to find the mute button on their phone so we heard a lot of background noise, beeps, coughing, breathing, etc.), and everyone needs to download the slides and follow along on their own. C'mon guys, GoToWebinar is pretty cheap, you could have sprung for that. :)

The BPMM acronym is problematic right from the beginning (aside from my gaffe last week when announcing the tutorial), when someone chimes in and says "but BPMN is in many shipping products now..."

Bill Curtis started with a history of maturity models; he and his partner have had a consulting practice around CMMI for a number of years, and obviously have a great deal of knowledge about maturity models in general. Apparently, one of their banking customers that had huge success with CMMI asked them for a business process maturity model a few years back, and so began BPMM.

Like CMMI, BPMM has five maturity models: initial, managed, standardized, predictable and optimizing (since the slides are marked as copyright of Capability Measurement, the consulting company that the two presenters run, I won't reproduce the graphics here but you can download the full presentation here). At the initial level of process maturity, organizations tend to be undisciplined, individualistic and inconsistent, which makes them inefficient and stagnant. Funny, this put me in mind of Jon Pyke's article yesterday where he spoke about how workflow systems "suck" because they don't allow people to do their own thing in order to get things done; Pyke seems to be dissing workflow systems because they enforce repeatable processes.

Levels 2 and 3 of BPMM show the benefits of putting some business process maturity in place: managed, repeatable processes, integrated across the organization and adaptable to different circumstances. Roughly speaking, Level 2 involves putting some process automation and management in place for localized process improvement, and Level 3 involves organizational-level process improvement and reengineering by standardizing processes across the organization. My feeling, and that of the speakers, is that most organizations are at Level 1 in their process maturity, with some approaching Level 2 where organizations have implemented some process improvement initiatives, particularly those including a BPMS implementation.

Level 4 is taking a more statistical look at processes, reminiscent of Six Sigma: making processes less variable and more predictable, and gets into more performance management. BPMM is a roadmap, whereas Six Sigma is a set of tools that can be applied -- probably starting around Level 3 or 4 -- therefore can work together.

Level 5 is taking it to a proactive level, where an organization can recognize the difference between where they are and where they should be, and quickly take steps to achieve that. This is the level of continuous process improvement, where change management becomes just another standardized business process, focused on defect reduction and prevention.

There was a slide at the end about cultural transformation that I particularly liked: moving between Levels 1, 2 and 3 is about discipline, while moving to Levels 4 and 5 is about trust.

Although I can't find the BPMM documents on the OMG site (which has the annoying habit of restricting access to standards in development), there is a BPMM information day in Washington DC next week where you can get more information.

On a related note, yesterday I attended the inaugural meeting of the Toronto BPMG chapter (more on that later), where Jim Baird talked about BPMG's business process maturity model. Although I'm not familiar with it, I have to wonder if there's room in the market for two business process maturity models.

Posted by Sandy Kemsley at 01:29 PM in BPM standards • BPMM | Permalink | TrackBacks (0) | Add to del.icio.us

Major correction: this tutorial is on BPMM (business process maturity model), not BPMN. Thanks to Phil Gilbert for emailing me a prompt correction.

If you're interested in learning more about the business process maturity model (BPMM), tune in to a tutorial that OMG is running on November 30th at noon Eastern time. From their description:

Today, management has no standards-based framework by which to assess the maturity of business processes. As a result, managers have no method to assess the risk that immature processes pose to enterprise IT projects, or to identify the causes of weaknesses in their process workflows that, if addressed, could reduce cost and increase operating efficiency. The Business Process Maturity Model (BPMM) is a proposed standard for evaluating the capability and maturity of business processes. The intent of this model, if adopted by the OMG, would be to provide an open, standard roadmap for assessing process maturity and guiding business process improvement.

Presented by Bill Curtis and John Alden, this tutorial will introduce the concept of a Maturity Model and provide insight into its origin, market requirements and benefits. The tutorial will discuss why projects fail, leading to billions of dollars in reworking costs. Case studies, examples and a detailed overview of the structure of BPMM will also be covered. We invite all OMG members to listen in.

It's not an online webinar, but more of a conference call with backup material: you download the slides in PowerPoint or PDF formation from their site, then dial in to listen to the live audio.

Now unrelated to this tutorial: If you want more in-depth information on BPMN (business process modeling notation), you can see the full version 1.0 specification on the OMG site, and check out some of the BPMN-related material on the Tyner Blain blog, which I've linked to in the past. I can't find the BPMN 2.0 spec on the OMG site, although I thought that it was in public release by now.

Posted by Sandy Kemsley at 01:43 PM in BPM • BPM standards • BPMM | Permalink | TrackBacks (0) | Add to del.icio.us

The OMG's fall newsletter is out (although as my Aussie friends remind me, it's spring down there), including notice of their technical meeting in DC on December 4-8. This will include a session by OMG BPMI on "Improving Business Process Management using a Maturity Model Framework":

"The OMG BPMI Steering Committee has been developing a plan for a Maturity Model for business process improvement, called the Business Process Maturity Model (BPMM). This program will discuss how such a BPMM would guide organizational change, relate to existing OMG standards, and how it could be made available for widespread use and adoption through the OMG standards development process. The BPMM authors include Dr. Bill Curtis and Charlie Weber, who were lead authors for the CMM/CMMI. Dr. Curtis also authored the PCMM (SEI’s People Capability Maturity Model). Topics covered will include introduction and discussion of the BPMM draft, and how it can be used by business, government and vendor communities. Specific attention will be paid to how BPMM could elevate success rates for SOA initiatives."

There's also an interview with Phil Gilbert of Lombardi, who is now the BPMI steering committee chair within OMG. I realize that vendors on standards committees make valuable contributions, I'm just not sure that having one run the whole show is a good idea. Are other vendors worried that the standards produced by BPMI will favour Lombardi? Or is this just a great way of forcing all the vendors to participate in the process, since they'll be afraid of what might happen when they're out of the room?

Posted by Sandy Kemsley at 09:50 AM in BPM standards • BPMN | Permalink | Comments (3) | TrackBacks (1) | Add to del.icio.us

If you're not using a BPM modelling product that outputs to XPDL and want to get an idea of what it actually looks like, some of the vendors are posting samples of their BPMN/XPDL for interoperability testing on the WfMC forum (you may need to be a member to see the posts, but it's free). For example, here's the sample from Global 360.

Posted by Sandy Kemsley at 10:57 AM in BPM standards • BPMN | Permalink | TrackBacks (0) | Add to del.icio.us

Although labelled "The business value of BPM", this is really a webinar on BPM standards as a wrap-up of the recent OMG BPM Think Tank, which I blogged extensively about.

Since I was at the Think Tank and have a lot of opinions on the subject of BPM standards, I'll be presenting at this webinar (as opposed to my previous role as moderator) along with Connie Moore from Forrester and Jeanne Baker from OMG and Sterling Commerce. Connie will be covering the business value of standards, Jeanne will be doing a wrapup of the Think Tank, and I'll be doing an interactive discussion between the three of us on the future of BPM standards.

Being a presenter on this webinar prompted me to finally update my bio on the ebizQ site; a few people who I've met lately assume that I work for ebizQ, which I don't, so this should clear it up.

The webinar is on August 9th at noon Eastern, and you can sign up here.

Posted by Sandy Kemsley at 05:18 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (0) | Add to del.icio.us

Since I only finished posting about yesterday's sessions at the end of this morning, I decided to just do a final conference wrapup instead of separate wrapups for yesterday and today.

In general, the BPM Think Tank was great, and I'll definitely attend again in the future. I learned a lot about some of the standards that I didn't know much about before (like BPDM), and met some really smart people with lots of opinions on the topic of standards. It's been so long since I was involved in any sort of standards work (AIIM in the early 90's, and topographic data interchange formats for the Canadian Council of Surveying and Mapping back in the late 80's), and I had forgotten about both the frustrations of dealing with standards committees and the excitement of being able to contribute to a little bit of computing history that will make things work better for a lot of people.

I'm still mulling over the XPDL/BPDM conundrum (and, to a lesser extent, BPEL), but the fact that different standards bodies are all here participating is a good indicator that there is the collective will to head off problems like this. At last year’s Think Tank, discussions between BPMI and OMG around the competing graphical process models of BPMN and UML activity diagrams helped lead to the absorption of BPMI into OMG, and the championing of a single standard, BPMN, being put forward by the merged organization. We can only hope that something similar will happen with XPDL and BPDM in order to avoid future problems in the BPMN serialization domain.

I had the chance to meet several people who I had connected with online but never met face-to-face: Dana Morris of OMG, Bruce Silver, John Evdemon (who I'll be having ongoing discussions with about BPM and Web 2.0) and others. Jeanne Baker, who did such a great job at keeping things moving along during the sessions, even remembered one of my posts from last year about a webinar that she gave on standards -- she turned to me at lunch yesterday and asked "Did you write that blog post called 'Alphabet soup for lunch'?" -- proof that people will remember if you mention them in print. I missed other people completely in the crowd (Phil, where were you?).

There were a few logistical problems (conference rooms way too cold, no free wifi, not enough herbal tea, and no free t-shirts with vendor logos, about which I heard a lot of whining when I got home), but these were only minor annoyances in an otherwise well-executed conference with excellent content.

Posted by Sandy Kemsley at 10:33 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | Comments (3) | TrackBacks (1) | Add to del.icio.us

The last of the four roundtables that I attended was on BPDM, led by Fred Cummins. I started with my (by now) usual question about the distinctions and overlap between XPDL and BPDM: his response was that XPDL is an XML specification, and BPDM is a metamodel that can be exported to XML via XMI. He seemed to imply that they could coexist, but given that BPDM will include a serialization specification for BPMN (in addition to other models that can be represented in BPDM), I'm not sure I see the need for both in the standards world. He later stated that there is an expectation that people will model in BPDM (as visualized by BPMN or other visualizations as appropriate) and transform to an execution language such as BPEL, rather than BPDM being an interchange format; this seems to leave no room in the landscape for XPDL if you adopt BPDM, unless you need it as a legacy interchange format.

Moving on to other points about BPDM, it will include both orchestration and choreography (process flow, messages and collaboration), and will include more concepts than can be represented in BPMN, hence will support other views, e.g., process dependency diagrams, roles/organization view, choreography. A draft submission of the standard is due on June 5th, with a rough plan to finalize the underpinnings to provide BPMN support within 3-4 months, although there is no plan to issue a version with just the serialization as a preliminary release. In order to complete the release, they will likely do BPEL export from BPDM and a UML mapping to BPDM in order to demonstrate usability of the standard on a broad enough basis to initiate its acceptance.

When Cummins provided a summary of all of his roundtables at the end of the conference, he pointed out a couple of questions that had arisen during the discussions:

• Is there a potential for executable BPDM? [I say that if there can be abstract BPEL then why not executable BPDM?]
• Is there a way to achieve compatibility between XPDL and BPDM? [I think that there better be]

Posted by Sandy Kemsley at 10:26 PM in BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (0) | Add to del.icio.us

This afternoon, I attended technology roundtable on XPDL led by Keith Swenson.

Keith went around the table and asked how we (or our customers) are modelling processes now. The biggest faction by far use Visio, but PowerPoint (!), UML activity diagrams (using the IBM/Rational tools) and proprietary/internal tools specific to an industry were also mentioned. For the most part, people are concerned with sharing processes between tools, not between organizations, since most organizations are very protective of their processes. A major issue with most of these tools is round-tripping and process lifecycle issues, since in many cases it's a one-way trip from the modelling tool to the execution engine. We talked about Byzio, the Zynium add-on to Visio that allows BPMN to be modelled in Visio, and a mapping from either a BPMN template or any other Visio set of shapes to XPDL. I reviewed Byzio several weeks back, and Keith is quite familiar with the product too.

We discussed how XPDL could be used to aggregate process models from disparate BPMS' that might be in use within the same organzization.

In discussing BPEL, Keith felt that XPDL provides all of the support for everything that BPEL can do with respect to the interface to web services; this further pushes the issue that BPEL is not really required if it's not being used as an execution language and if there is a transformation from XPDL to the specific engine's execution environment (which implies that the BPMS vendor's design tool can import the XPDL file).

XPDL provides support for extensions modelled in a BPMS vendor's design tool that are specific to that engine; these are preserved in XPDL and should not be affected if the XPDL is manipulated by another process design tool. This is critical for supporting round-tripping from a design tool to the BPMS vendor's engine (via their design tool) and back again, since the design tools should preserve the extensions even if they don't interpret it. An example of such an extension is assigning colour to swimlanes (which Fujitsu allows in its design tool): the file can be read into a tool that doesn't interpret the colour information, but when it is saved and read back into the design environment that does support colour, the colour's there. Vendor extensions such as this may be brought forward at XPDL TC meetings for inclusion in future versions of the standard.

The most recent set of major changes to XPDL were BPMN-related enhancements including X-Y coordinates of lines, topology, etc.; however, they forgot to include scale, since some measures are in real-world units (inches/cm) and some are in pixels. This caused further discussion on the separation of presentation and logic data, since both are included and intermingled in XPDL when it’s used to serialize BPMN, and if logic and presentation be versioned separately, since some purely cosmetic changes can be made to presentation without affecting logic. Other presentation-related information includes a "page" indicator, since a process may span multiple pages when visualized.

We had a lengthy discussion on additional versioning information that could be included in XPDL, and how this ties in with SOA governance initiatives for maintaining the integrity of interfaces and functionality.

I repeated what I said in an earlier post about blaming the large analysts for forcing (sometimes inappropriate) standards by creating RFP checklists that are used (somewhat blindly) by customers -- Keith agreed with this view.

We ended up with a bunch of ideas that deserve more thought: Should Java be extended to subsume BPEL functionality? XPDL is graph oriented, and BPEL is block structured; BPEL4people implies that you can extend a block-structured language to represent human-facing process flows which are inherently graph-oriented. Should BPDM be the metamodel behind XPDL? (This is not a viewpoint endorsed by OMG since XPDL uses some notation not recommended by OMG, and BPDM has a broader scope that inclues BPMN serialization.) If XPDL were made MOF-compliant, could it replace the need for BPDM?

Posted by Sandy Kemsley at 10:21 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (1) | Add to del.icio.us

I finished yesterday afternoon by attending a technology roundable on BPEL led by John Evdemon. There was a lot of ground covered there that I had heard in his workshop on Day 1 and the panel earlier yesterday that I won't repeat here, so just a few brief notes.

There are some things that can be described in BPEL that can't be modelled in BPMN, which I didn't realize. The example that Evdemon gave was an online order for a book, then a follow-on process kicked off the next day when the customer cancels the order. Although both of the processes can be modelled in BPMN, I think that his point is that the interaction between the processes can't be modelled there. There are apparently a few use cases like this that are being considered for inclusion in BPMN (if I understood correctly), but I didn't hear anything about this in the earlier BPMN roundtable. Stephen White's mappings of BPMN (available on the old BPMI.org site, so I imagine all still available on OMG's site) has many peole thinking that BPMN models a superset of BPEL, which is not strictly true.

Like the BPMN roundtable and some hallway discussions, there were a lot of comments about the linkage between process standards and enterprise architecture.

The issues that we discussed, and the notes that I made from the discussion:

• BPEL doesn't provide all the functionality that can be modelled in BPMN.
• If BPEL isn't used as an execution language, but just as an import/export language as is done by Microsoft, IBM and others, what value does it add over XPDL (or eventually, BPDM)?
• Are we eventually going to end up with just BPMN, BPDM (or XPDL, if you believe Bruce), and a vendor-specific execution language in the process chain?

I have some additional research to do, some of which will start in this afternoon's roundtables on XPDL and BPDM, about whether BPEL does add value over these standards by providing more specific web services information such as endpoints or ports. You can definitely use BPEL as an import/export and exchange format, or to store the representation of a process for future rehydration, but it appears that you could also use XPDL or eventually BPDM to do the same thing and provide a richer interpretation of models created using BPMN.

At the end of the day, when we all reconvened as a group, Evdemon gave a summary of what we discussed:

• What is the value of BPEL if XPDL is a direct serialization of BPMN? BPEL had a lot of press because of who's backing it, not necessarily because of its capabilities. (A direct quote from him during the roundtable itself on this subject: "Unless you're going cross-platform, you may not need BPEL.")
• Use BPEL to store current processes to be rehydrated later if needed for audit or other legal and compliance requirements. BPEL is also being used by other standards such as RosettaNet to provide process-related templates for those standards.
• Process formats may just become different serialization formats with different capabilities, accessible from many tools just like all the document formats that are available if you select File...Save As within Word.

Posted by Sandy Kemsley at 10:44 AM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (0) | Add to del.icio.us

Since I'm here in part to firm up my knowledge about BPM standards, I chose to attend four technology roundtables and none of the executive (business focussed) ones. The first one that I attended was on BPMN, led by Petko Chobantonov of Lombardi. Petko's involved with the development of the BPMN standard and was really pushing us to find out what else should be added to the standard in the future. I was the scribe for that session so have a ton of notes, my problem is trimming them down and making them understandable in this post.

First of all, Petko made the statement that OMG is not recommending XPDL for serialization of BPMN (i.e., a file format in which to save BPMN), but recommends the use of BPDM (which isn't released yet, although a very early draft is due next month). This sets up for an interesting showdown between XPDL, which is already in use by 30+ modelling and BPM vendors, and BPDM when it finally is released this year or next.

For the first time, I heard about BPRI, Busines Process Runtime Interface, which incorporates information gathered at runtime such as metrics and statistics about a process (I think). Petko has a bit more on his blog about it here, and I'll be looking at this in more detail since I think that this is a necessary standard as well.

One of the participants from an end-user organization said that they have extended BPMN with 3-4 custom types in their internal use, one for applications and one for data elements. He also said that they have difficulties in publishing and communicating BPMN diagrams because of the complexity, and that there needs to be some easier ways to abstract a flow in order to present it to someone who is not intimately involved with the process, such as executive management. Although using just a linear set of milestones was suggested as an abstraction model, removing all of the split/merge and other flow information, I think that some of the flow information should be left in place even in a high-level diagram in order to provide sufficient value.

This was also one of the times during the day when I heard about the crossover between BPMN and enterprise architecture. We discussed different perspectives (similar to the perspectives in a Zachman diagram), and although Petko felt that the standard could be extended to become effectively a higher-level diagram from which you could invoke other EA perspectives, like organizational and motivational models, I think that BPMN holds a place as a standard for creating artifacts in one or two of the Zachman cells in column 2 (process), not as an overarching EA model.

We had a discussion about the standard organizational tree-type chart, and how the boxes in that correspond to swimlanes in a BPMN diagram. From that, we talked about how to represent information in the org chart based on which processes that a particular role participates in, and also discussed the stickier subject of assigning roles a bit more dynamically based on a collection of capabilities rather than a pre-determined role. That got me thinking about whether we're asking the question the wrong way around: instead of the asking what capabilities exist in a role or person, should we be creating the roles or services based on what combinations of capabilities exist? Something to think about later.

We talked about a dependency diagram for subprocesses used in multiple processes, and whether this should be a standard view defined in BPMN, or if it's informational rather than notational. If the audience for this information is primarily the business analysts who use BPMN, then perhaps a graphical standard is appropriate, although it's a "report" of sorts, not a working model.

Petko finished up with some ideas about defining aspects of a process, such as security, escalation and exception handling, in order to simplify the primary representation. The aspects would be invoked whenever an activity is executed, but represented on separate diagrams. In that way, an aspect would effectively be a template for activities that could be overlaid on any of the activities in the main diagram and extend the meaning of the main diagram. Each activity in the main diagram would need a mechanism for passing some number of parameters to the instance of each aspect that may execute for that activity, for example, some measure of the time-criticality of an activity in order to trigger an escalation at the approriate time.

Tons of ideas came out here, as they did at the later roundtable that I attended on BPEL, and I'm looking forward to the roundtables today.

Time to head off to the conference (I'm already 5 minutes late and still have to finish packing and check out); more throughout the day as I get a chance.

Posted by Sandy Kemsley at 09:05 AM in BPM standards • BPMN • BPMThinkTank • EnterpriseArchitecture | Permalink | TrackBacks (1) | Add to del.icio.us

We finished Wednesday morning with a panel on the business value of process standards, moderated by Connie Moore of Forrester, with panelists Richard Soley of OMG, Keith Swenson of Fujitsu and John Evdemon of Microsoft representing the BPMN-XPDL-BPEL value chain.

I'm now on the search for the Holy Grail of BPM standards: what's going to survive the coming shake-out, and how exactly do XPDL, BPDM and BPEL overlap, compete and complement each other? Swenson started his intro with a statement about BPDM and XPDL: basically, there's some great work happening on BPDM, but XPDL is here now and can be used in the interim. Was this an admission that XPDL is going to go away and be replaced by BPDM? I had a side conversation with Fred Cummins (who gave the BPDM workshop yesterday) before the panel, and he sees BPDM as providing a superset of functionality such that transforming to XPDL or BPEL doesn't add any value unless the particular BPM execution engine requires the transformation. BPMN has clearly won the graphical representation skirmish; can BPDM take the rest of the field? [Note to Phil Gilbert, who dissed me yesterday for asking why use BPDM if you have XPDL: this is live blogging so pretty much stream of consciousness, I'm just blogging what I hear and think during the session and haven't had time to formulate any real opinions or analysis of all this. So back off, buddy. :-) ]

Evdemon said that in his personal opinion, BPEL has a 3-out-of-5 importance rating for most organizations, mostly for checking off boxes on an RFP (in his position on the TC of the OASIS BPEL group, he said that it's a 5/5, which makes me wonder why OASIS would choose to use him as a public speaker on the standard when his corporate affiliation and personal opinions aren't really in line with the goals of the standards committee). He feels that BPEL got a lot of press unfairly, and that when he found out yesterday that XPDL can save a complete representation of all BPMN objects, he seemed to think that BPEL could become even less important and possibly even subsumed -- recall from my post yesterday on his workshop that he sees BPEL as more useful as an abstract (modelling or exchange) language rather than an execution language.

Swenson came back to the issue of XPDL versus BPEL, which he doesn't see as competing. XPDL is about process design, about serializing and saving what you drew in BPMN, and not so much about execution. He sees XPDL as a way of moving a process from one design/simulation/analysis tool to another (about 30 tools support it today), whereas BPEL is about the nuts and bolts of sending messages from one location/service/system to another. As Evdemon said, XPDL is like XMI for business processes. Swenson states that XPDL will continue to track and adjust to any changes to BPMN.

Interesting that the BPEL proponent thinks that BPEL is less important in the face of XPDL's current functionality, whereas the XPDL proponent thinks that BPEL and XPDL should coexist.

Even more interesting is that the panel did not directly address the issue of the business value of standards, only the standards themselves. It would have been good to hear a bit more about how to promote the idea of BPM standards within an organization, although given the current somewhat confusing state of overlapping standards, it's hard to know exactly what to recommend.

A last question was posed about BPDM that Soley addressed, namely, what is it and how does it compete/overlap with the others that we're talking about here. He claims that it's not intended to compete with any of these other standards, although that's still not clear to me.

A really valuable and lively session, I just wish that I had recorded it since the opinions and comments were flying by and I'm sure that I've missed some key points. Hopefully, I'll be able to explore these further in the roundtables this afternoon and tomorrow.

Posted by Sandy Kemsley at 12:33 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | Comments (3) | TrackBacks (3) | Add to del.icio.us

I'm now in the final session of the day, with John Evdemon talking about BPEL. He's dealing with a number of interesting points, such as name (WS-BPEL versus BPEL versus BPEL4WS), pronunciation (he doesn't care, as long as you use it), the lack of graphical notation, and orchestration versus choreography. I particularly like his description of orchestration versus choreography, which is crystal clear: orchestration has the concept of a controlling party, even if other external organizations are involved in a process, and is concerned with the process from the viewpoint of that party includes its internal activities; choreography is at a higher level and looks at a process as message-passing between peers, without delving into the processes internal to any of the participants. BPEL is an orchestration language, and you can think of choreographing between the BPELs at each organization (sort of).

The motivation behind BPEL was application integration both within and between organizations -- EAI and B2B -- where everything is described as a service. It covers both non-programmers implementing flows by assembling components with flow logic, and programmers implementing the granular services using function logic that will make up those processes. There's also the idea of being able to model both executable processes and abstract processes using BPEL, although most of the excitement around BPEL has been due to the platform-independent nature of it as an execution language, that is, the logic for how messages actually get processed. Abstract BPEL, on the other hand, can be used to describe an organization's services at a deeper level than can be done via WSDL, without concern for execution.

Evdemon showed a diagram of how BPEL fits together with the rest of the WS-* stack, and shows how business process models and choreography models need to still be layered on top of BPEL to provide full capabilities.

Something that I didn't really think about before, but which came up in response to the questions "where does BPEL live?" is that Microsoft doesn't run BPEL directly, but translates it into BizTalk (unlike a product like Oracle BPEL Process Manager, which executes BPEL directly).

BPEL 2.0 is scheduled to go out for public review next month. New since v1.1:

• New activity types (if-then-else, repeatUntil, validate, forEach, extensionActivity)
• Completion condition in forEach activity
• Variable initialization
• XSLT for variable transformations (new XPath extension function)
• XPath access to variable data (XPath variable syntax)
• XML schema variables in web service activities (usability enhancements for WS-I compliant doc/lit-style WS interactions)
• Locally declared messageExchange
• Abstract processes (common base/syntax and profiles/semantics)

Evdemon's recommendation and predictions about BPEL shocked me: it's still under development, so don't use it yet in production and the portability of executable BPEL will be low to non-existent. He sees that many organizations implementing BPEL are using it like a programming language, which he implies is an inappropriate usage since it's missing some core capabilities, but that it's more of an orchestration modelling language. If that's the case, and the vendors are going to just translate it into their own proprietary execution language, then there seems to be little advantage to adopting BPEL over something like XPDL that can capture everything that BPMN can model, except possibly for better WS handling.

Posted by Sandy Kemsley at 05:41 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (2) | Add to del.icio.us

I'm in Fred Cummins' BPDM workshop, where his stated goal is to provide a general understanding of BPDM, engage us in a discussion of the requirements, and discuss the implications of BPDM to enterprise agility. Fred's an EDS fellow who writes occasionally on the EDS Next Big Thing blog.

BPMN and BPDM are both standards that are designed for use by business people, with the inclusion of non-automated as well as automated business processes, and they are both business models as opposed to execution models (like BPEL, WS-CDL or proprietary vendor execution models). BPMN is a standard for the graphical representation of a business process, whereas BPDM is the XML file format in which such a representation can be stored: hence, a tool might display a business process as BPMN and save it as BPDM (which makes BPDM competitive with XPDL from WfMC, which I previously discussed as a file format for BPMN, although Cummins later stated that the scope and goals of BPDM exceed those of XPDL).

We had a lengthy discussion about the relationship between choreography (a collaboration between multiple participants) and a business process/orchestration (how one of the participants manages their view of the interaction): the roles typically map directly between processes and choreography, whereas only the steps in a process that involve interaction with another one of the participants will appear in the choreography. BPDM is intended to capture both orchestration and choreography information, although there was some discussion about whether BPMN has all the graphical representation for everything needed for choreography. It does include the concept of pools (like swimlanes, but representing different organizations, not different functions within an organization) and can collapse a pool so that it is effectively a black box, so I think that it has most or all of what's required for representing inter-organization choreography. An organization only needs to map the other parties in a choreography as a black box (i.e., a collapsed pool), whereas it will map it's own internal activities fully within swimlanes in its own pool.

Cummins then moved on to the hot topic of BPM and SOA, with the following definitions/relations:

• BPM: Business processes are the orderly execution of activities that achieve defined objectives.
• SOA: Services offer capabilities that can be used in a variety of contexts.
• Business processes may use services to achieve their objectives.
• Services implemented with explicit business processes can be more quickly adapted to business changes.

Personally, I find that list a bit circular, and I think that his "definition" of SOA is actually a definition of services -- maybe a bit of a fine point. He made a vague point about how processes and services provide different levels of granularity of agility, then came back to make two statements about agility:

• Primary impact of business changes is on the business processes and organizational structure.
• The actual work (concrete services) and data of the business tend to stay the same.

There's a lengthy discussion going on now about the difference between defining a meta-process and defining a paradigm, which is getting just a bit too esoteric for my taste (the accusation "you're being too rigorous!" was just flung around the room), but does remind me that OMG is a standards organization and this is exactly why I prefer implementation to theory, in general... (several minutes elapse)

Cummins finished up with some things that are being considered for BPDM but are still unresolved, such as the integration of business rules (and presumably a BRE) into a business process model, and the integration with strategic planning that's necessary to make business process modelling a fully participating activity in enterprise architecture.

At the end of it all, this workshop had a lot less to do with BPDM than I wished that it had, and a lot more about some particular views on SOA and business agility that didn't really have anything to do with BPDM. I understand that BPDM is still a work in progress, but it would have been nice if the artists had unveiled the canvas for us to take a preliminary peek.

Jeanne Baker, who sat in on the session, pointed out that this think tank is for all standards groups, and that last year's think tank resulted in the merging of BPMI into OMG due to the overlapping scope of BPMN and UML activity diagrams. Maybe the next move is to bring together XPDL and BPDM instead of indulging in an unwanted standards war for business process metamodels.

Posted by Sandy Kemsley at 03:30 PM in BPEL • BPM • BPM standards • BPMN • BPMThinkTank • BRE • SOA | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

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).

Posted by Sandy Kemsley at 10:39 AM in BPEL • BPM standards • BPMThinkTank | Permalink | TrackBacks (1) | Add to del.icio.us