Archive for March, 2008
[My April column for BPM Institute. Please add your own nominees in the comments.]
Is there a BPM Hall of Fame? I don’t think so, but there should be, to recognize the true pioneers and innovators in the field. BPM’s core ideas and technologies come from several divergent fields, and my list would include those who first introduced them – ideas about what a business process is, and what managing one really means. Thinking about who should be in a BPM Hall of Fame is a fun exercise, and you might it helpful in framing your own views. My list emphasizes technology, recognizing those who first recognized that improving business processes demanded fundamentally new technology, often enabled by fundamental shifts in the surrounding IT environment.
My nominees would be:
- Ted Smith. Whatever BPM gurus today might say about agility or end-to-end visibility, the biggest ROI from BPM still comes from automating the flow of work, leveraging the network to make business processes run faster, and get more work done with fewer people. As the founder of FileNet, Ted Smith in the 1980s invented the concept of workflow, and even trademarked the word itself. Back then, business processes were mostly paper-based, inherently manual and slow, but the new technologies of computer networking and digital mass storage offered the possibility of a better way. While competitors like Kodak and Wang promoted document imaging as an electronic file cabinet, Ted Smith realized the real benefit of getting paper inside the computer was not storage and retrieval, but making business processes more efficient by automating the flow of work.
- Fernando Flores. Finance Minister under Allende at age 28 and sprung by Amnesty International from political imprisonment six years later, Fernando Flores spent his exile from Chile at Stanford. There, while Ted Smith was inventing workflow, Flores and Terry Winograd conceived of the business process in a very different way – not as a sequence of assigned tasks to be performed as quickly as possible, but as a set of commitments between requesters and performers, including negotiation, promises, and acceptance of satisfactory completion, the humanistic side of work. Leveraging the new technology of PCs, LANs, and email – intra-office, as this was still pre-Internet – Flores’ Speech-Action theory took shape in a software package called The Coordinator, pioneering what was later called groupware. In today’s terms we would call it collaborative process management. His company Action Technologies later refined the ideas and updated them to the web, but their incorporation into mainstream BPM remains a promise largely unfulfilled. Winograd today is best known as adviser to Larry Page, whose research project on web search turned out, we hear, even bigger than BPM.
- Dale Skeen. There is another dimension to BPM beyond managing the efficiency or quality of human work: using processes to integrate the diverse application systems that, in the view of some, are what really run the enterprise. These systems were never designed to talk to each other, but the pressures of globalization and the web meant that they had to anyway. As a co-founder of TIBCO and inventor of distributed publish-subscribe integration, Dale Skeen pioneered enterprise application integration (EAI) technology. But what puts him in the BPM Hall of Fame is not that. Rather, it was his understanding – long before others in EAI – that optimizing integration requires more than automating a single event-triggered action. It means automating the end-to-end business process, and his second company Vitria brought that approach to EAI, with a unified design environment encompassing integration, human workflow, BAM, and exception management, and a similarly unified runtime environment. Skeen is the inventor of what we call today integration-centric BPM, and most of the big middleware companies just getting into BPM are following the path he blazed back in the dotcom days.
- Ismael Ghalimi. While the first three nominees could be said to have pioneered threads of what later became BPM, Ismael Ghalimi is responsible for many of the things that today define what BPM actually is – a technology based on Internet and web services standards, and, more important, a technology that empowers business to take charge of their own processes. His company Intalio was the first to offer a process engine based entirely on web service orchestration, and he founded the BPM Initiative (BPMI) to make that orchestration language, called BPML, a multi-vendor industry standard. Before this, every workflow system, EAI system, or self-styled BPM system was proprietary from head to toe. BPMI grew to 200 member companies, but BPML was soon eclipsed by a rival proposal from IBM and Microsoft called BPEL. In the aftermath, Ghalimi not only moved Intalio to BPEL but made its BPEL engine open source.
While we are just beginning to feel the impact of standards-based and open source BPM runtime, another BPMI effort – the Business Process Modeling Notation (BPMN), now managed by OMG – has already had a huge impact, and promises something even more valuable than inexpensive software: business-empowered implementation. Smith and Fingar’s 2003 book BPM: The Third Wave, heavily influenced by Ghalimi’s efforts, laid out the essential vision, in which BPM solutions would be built and modified by business people working collaboratively with IT in a single tool. In the end, this business-empowered implementation style will be recognized, in my view, as the most important innovation of BPM, and Ismael Ghalimi was its prime mover.
- Phil Gilbert. BPMN’s power comes from the fact that its shapes and symbols are intelligible to business, yet expressive and precise enough to serve as the “abstract” definition of executable process solutions. But lacking support for human tasks, subprocesses, and looping back to previous activities in the flow, BPEL turned out to be an imperfect runtime companion for BPMN. Fulfilling the promise of business-empowered implementation actually required a “BPMN engine,” but no BPMS vendor had one. As CTO (now President) of Lombardi, Phil Gilbert elected to break his own shipping product and build one. That’s either nuts or brilliant, but Lombardi’s Teamworks has emerged as the first and best realization of BPM’s promise of business-empowered implementation based on standards and business-IT collaboration.
Workflow automation, structured collaboration, business integration, standards-based tools, and business-empowered implementation. To me, these are central themes of BPM today, and my Hall of Fame nominees are the ones that gave them to us. I accept that your list might be quite different. You are invited to submit comments and your own nominations on the BPMS Watch blog.
March 22nd, 2008
Tom Baeyens weighs in on my debate with Michael. He mostly sides with Michael, but I think because of a slight understanding of my stance. I’m not saying BPMN is all or nothing. Yes it has parts that are not very useful. And, like Michael, the tool vendors factor into my thinking as well, in particular the BPMS vendors who support BPMN’s model-driven implementation style. So I, too, divide up BPMN constructs into different buckets, but with very different criteria.
I am thinking about the problem of model portability. Yes, I’m on that horse again. I’ve been working with Robert Shapiro and Tom Laverty to define a model portability conformance standard for XPDL 2.1, the new version that supports BPMN 1.1. (Sorry to say, you can’t just download the spec and white paper; WfMC makes you go through an online interview: “First, tell us a little bit about yourself…” Good god…)
XPDL provides a BPMN schema, but just because a BPMN model is XPDL schema-valid doesn’t mean that a) the diagram has been serialized in XPDL properly, or b) another tool can make sense of it. Tom Laverty has developed an XSLT that, when applied to the XPDL instance, generates a list of errors about any improper serialization or internal inconsistencies, and warnings for elements that fall outside of the portability conformance set. It’s very cool.
What portability conformance set? I’m glad you asked! We divide up BPMN into 3 categories, based on the likelihood a BPMN tool supports the constructs.
- The SIMPLE conformance set includes task, collapsed subprocess, gateway (exclusive data-based and parallel), None start and end events, pool, lane, data object, text annotation, sequence flow, and association.
- The STANDARD conformance set includes task (task type User, Service, Send, Receive); collapsed and expanded subprocess, looping or multi-instance activity, gateway (inclusive, exclusive data-based, exclusive event-based, parallel), start events (None, message, timer), catching intermediate events in sequence flow (timer, message), throwing intermediate events in sequence flow (message), attached intermediate events (timer, message, error), end events (None, error, message, terminate), pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association. [Looks like we left out message flow… not sure why.]
- The COMPLETE conformance set includes the full BPMN 1.1 spec.
Because this is intended to validate portability of “models” not executable designs, the only attributes of these objects supported are either ids (to hold the model elements together) and labels or subtypes that print in the diagram. The executable details of these objects are rarely added in BPMN, anyway.
Note that my SIMPLE is similar to Michael’s core + extended. To me it’s pseudo-BPMN, but any tool that claims to be BPMN supports all of it. The STANDARD reflects my view of the important parts of BPMN. Not all event types - mostly timer, message, error, and terminate, as those are the ones you need. Some tools are there today - Lombardi, Appian, Tibco, maybe others. Most are working hard to get there. The COMPLETE level is basically for modeling tools with no runtime… they can do whatever.
In my training we focus on the STANDARD constructs and patterns. True, before the training users don’t know how to use all of it, and afterwards, they do. I think that’s the point.
The way I see it, if we can get tool vendors to buy into the portability standard, the marketplace will decide whether SIMPLE or STANDARD is the sweet spot for tools. And that’s as it should be.
March 11th, 2008
Michael zur Muehlen posts a lengthy response to my post On How Much BPMN Do You Need. He elaborates on his data analysis procedure - their procedure, actually, as Jan Recker was a co-author - and it’s actually kind of interesting, looking at statistical correlations between diagram elements in a sample of BPMN collected in the wild. Sort of an anthropological survey - maybe archeological, given where we are on the adoption curve - of which shards of BPMN are used, correctly or incorrectly, in diagrams today. And if it had been presented that way, it would have been interesting, maybe even mildly useful.
But that’s not how it was presented, and that’s why I still say Michael (and Jan) draw the wrong conclusions from the data. The part of BPMN that is no different than a swimlane diagram is not at all “the BPMN you need to know.” It’s better described as “the BPMN you already know.”
In his new post, Michael says,
The process modeling efforts in most organizations at this stage are simply not advanced or mature enough to start specifying service-enable workflows with exception behavior in BPMN. No, most people use it simply for flowcharting. What we conclude from this observation is that the ecosystem of vendors, consultants and trainers should be aware of this and should plan, manage and employ their efforts (be it tool development, BPMN training or modeling workshops) accordingly.
This is the conclusion I just vigorously disagree with. I would rewrite it as follows:
The process modeling efforts in most organizations still lack the knowledge and methodology required to document and analyze their business processes effectively in BPMN. Today most BPMN models are no more than flowcharts, omitting the exception paths that would be necessary to analyze them for potential improvement, either by simple visual inspection or quantitatively using simulation. And they offer no hope of serving as the business view of an automated implementation of the process in a BPM suite. That’s too bad, because the real value of BPMN - the reason why it is important - is that it empowers business analysts, not just developers and architects, to do all of those things. But that requires training, on both the notation itself and a methodology for using it effectively. The BPMN you really need to know is NOT the BPMN you already think you know.
I am not saying BPMN contains no nearly-useless parts. I’d happily get rid of transaction compensation, complex gateway, conditional (fka rule) event, conditional sequence flow, and multiple event (except in event gateway). I personally have little use as well for Link event, the off-page connector, although I have students who can’t give it up. Even timer start event, signifying a scheduled process - harmless enough, but ok, I could live without it.
Those account for 15 of Michael’s useless 17. It’s the other two that get me: exception flow, which means any attached event; and intermediate error event. (In BPMN 1.0 that could mean either throw the error or an attached event, but in BPMN 1.1 just the attached is allowed.) Without attached events you can’t specify deadline-triggered behavior; you can’t let your process respond to an unsolicited event; you can’t easily propagate exceptions from deeply nested levels of your model to a parent level, which makes hierarchical models very difficult to manage.
Michael, I can see you rolling your eyes: attached events, nested levels, propagating exceptions… Those are IT things, not business analyst things. But I have to tell you, having taught these concepts and practices to hundreds of students in the past 12 months, that that attitude is condescending to business analysts. Not to put too fine a point on it, it really pisses them off. The thing that’s energizing BPMN in the marketplace is that it gives the business folks for the first time a seat at the table with IT, lets them go from documentation to analysis to implementation without changing the notation, just layering on more properties.
Can you do this with the flowcharting you already know? No you can’t. It takes a bit of education and practice. And it takes more than your core set or core + extended. To say subprocesses, intermediate timer and message events, event gateways, and repeating activities (loop and MI) are just for “specialists” sets the bar too low. Way too low.
The vendor side of the equation is off target also. Given that no BPMS supports all of the BPMN spec, Michael says:
So which constructs can a vendor neglect initially and which need to be supported? We would argue that it is of best interest to vendors to focus on those constructs heavily used in practice.
Beating a dead horse though, since I doubt I could name one BPMS that claims to support BPMN but doesn’t support all of Michael’s core + extended core set already. The area of interest is what Michael calls the BPMN Specialist Set. These are the constructs at the heart of BPMN-ness, bridging the business-IT divide. To be so dismissive of them is just wrong. And is he saying users should be familiar with them before they are available in the tools? I don’t get it.
Michael ends his piece by asserting that the real BPMN is not what vendors, consultants, and trainers like me say it is, but the way untrained practitioners are using it today. The core set diagrams - start, end, task, gateway - from his sample give a truer view, he says, of the “problems real users face. Instead of the problems we think exist in practice.”
March 10th, 2008
Michael zur Muehlen posts a strange bit of analysis called How Much BPMN Do You Need? The method of research consisted of collecting 126 BPMN 1.0 diagrams from “consultants, seminar participants, and online sources,” and counting the frequency of various diagram objects in them. His conclusion is that the BPMN that you “really need” consists of task, start and end event, sequence flow (he calls it “normal flow”), exclusive gateway, and pool. It’s a bit like saying e, t, a, o, i, and n are the letters you “really need” to communicate in English.
The methodology is not detailed in the post, but several things Michael does say suggest that the analysis focuses purely on the diagram, not the semantics. For example, the spec says a pool is implied even if not drawn, but Michael seems to just count it if drawn. (He also says the spec requires the pool to be drawn if lanes are used; I don’t agree.) Also, exclusive (XOR) gateway. The spec says this gateway may be drawn either with an X inside or with no icon inside; there is no semantic distinction. Michael counts them as different flow objects and says one is core and the other not.
The data presented suggests that Michael is not looking at semantics, just counting shapes and symbols. The parallel split gateway falls into the “extended core” set, but in BPMN two sequence flows out of an activity has the same semantics as a parallel split. Many older notations use multiple connectors out of an activity to mean alternatives, not parallel paths, and students beginning my training incorrectly think that applies to BPMN. I’ll bet those errors are in the 126 diagrams, but it’s not clear how they were counted.
The tables do not distinguish between intermediate events used in sequence flow, which pause the process to wait for an event, and intermediate events attached to activities, which abort the activity and redirect processing on an exception flow. However, the data suggests very few attached events, since exception flow - the required sequence flow out of any attached event - is so infrequent that Michael consigns it to the lowest category, “BPMN Overhead,” which is clearly meant to mean “useless appendages.”
Stepping back, what he calls the core set of BPMN has, to me, absolutely zero BPMN-ness to it. It’s just flowcharting. In fact, except for message start event, his core plus extended core set is still just swimlane diagrams that have been around for decades. My conclusion from this study is not that this is all the BPMN you need, but that understanding of BPMN, even among consultants, seminar participants, and publishers of online sources, is pretty poor. (If you remember my What’s Wrong With This Picture? posts a while back, BPMN blunders by tool vendors and online tutorial authors alike were more the rule than the exception.)
Michael draws different conclusions, and since he is a respected academic, I find them really troubling:
- “Practitioners” should start learning BPMN using the core set - start, task, gateway, end, that’s it - and leave the other “more specialized” constructs to those who need special training. (In my BPMN classes, business people are totally offended by the suggestion that they can’t understand events and other “specialized” constructs.)
- Tool vendors who don’t support all of BPMN today should use his frequency chart as a measure of importance. (Let’s see, that would mean no event gateways, no attached events - attached error event had a frequency of 0% in his sample! Really! - and no multi-instance activities. That’s absurd.)
- “Standards makers” - read OMG - should reconsider whether putting things like the above-mentioned constructs in the standard was useful since they make BPMN more complex than traditional swimlane diagrams. “How much time,” he asks, ”was spent on defining those seventeen symbols that we found are hardly used?” Those 17 include exception flow (needed for attached event of any kind), error intermediate event, timer start event, and off-page connector (Link event). (Oh, man…)
March 9th, 2008
Last fall I wrote a column and subsequent blog post called My BPMN Wish List, discussing some useful semantic patterns that were hard to diagram in BPMN. I didn’t get much comment on it, so I was a bit surprised to find recently on the OMG site a featured white paper by Antoine Lonjon, better known as the author of the BPDM spec, entitled The BPMN Wish List Revisited. It might seem flattering that my wish list turned into the wish list, but the opener dissed that idea:
In recent articles, people have expressed some desires and concerns regarding BPMN. Some of them are actually already addressed by the latest version of the specification, while others could be reformulated for consistency.
Ouch. No mention of my column, blog, or name even, and I didn’t even know about it until I stumbled upon it, but I think it’s worth revisiting Antoine’s revisitation because it points out where I think BPDM is going wrong.
One of my wish list items was called Multiple Start. It’s where you have multiple entry points to a process, typically (although not necessarily) based on the channel of request. For example, a customer service request could come via the call center, email, or the web. Downstream the process is the same, but the initial steps are frequently channel-dependent. This is a fairly common scenario.
What I didn’t realize last fall was that BPMN 1.1 solves this use case explicitly, using event gateway to “bootstrap” the process. Like this:
That’s cool. Not especially consistent with how intermediate events work normally (they normally wait for events), but who cares? So what Antoine should have said is, hey Bruce, read the spec. It’s in there, now. But instead he said that since the channel of contact is external to the process, the channel-specific initial activities should be in separate pools. Here’s Antoine’s corrected solution:
Now that’s just silly. There are reasons to use multiple pools in a process, but since they add complexity the reason should be a good one, and this one is not. Here’s a situation where the BPMN spec added a new diagram pattern to solve this common use case, and the author of BPDM - supposedly the formalization of BPMN - says it’s unnecessary. Does that make sense to you?
OK, next wish, the nonaborting unsolicited event. This comes up all the time. An intermediate event attached to an activity, such as message or timer, aborts the activity if event trigger occurs while the activity is running, and redirects processing to the exception flow out of the event. Extremely handy construct, since the activity can be a subprocess inserted for the express purpose of defining the scope of the event. But in addition to the aborting event, wouldn’t it be nice to have similar scoping behavior but allow the event signal to trigger an exception flow without aborting the activity? Of course, it’s another real-world processing pattern that deserves a place on the wish list. I described how to do it in a workaround, and subsequently I have developed a better more general one.
For example, consider event E attached to activity A. If E occurs while A is running, A is aborted and the exception flow is executed. The non-aborting variant is this: if E occurs while A is running, A (and the normal flow subsequent) continues, but a parallel exception process is triggered. How do you model it? Here it is:
You need to wrap A in a subprocess, with a parallel path containing E as a “wait-for” message event. If E occurs, a message end event triggers the exception process in a separate pool. (There are special cases, such as simply issuing a reminder, where you don’t need the complication of a separate pool, but the general case is more easily modeled this way.) The end event following A inside the subprocess is a Terminate event. That means if A completes before E occurs, the path waiting for E is killed. Otherwise the subprocess could never complete.
So this works, and I teach the pattern in my BPMN training, but I call it a workaround because it adds complexity for a very common situation. What would a non-workaround - my wish list item - look like? It would be some graphical variant of the attached event that the BPMN spec says means non-aborting. For example, the double circle for the event might be dashed instead of solid. Or, if you don’t want to add a new shape to the graphics library, borrow the start event (single circle) shape for E attached to A. I don’t care what shape they decide on, as long as the spec says this shape used in this way means non-aborting scoped event.
But again, Antoine is having none of it. And what he says is kind of shocking, which is that the non-aborting attached event “is already supported in the OMG BPM specification.” Really? And what is “the OMG BPM specification”? Is that a typo? Does he mean BPMN specification or BPDM specification? And is there a difference? He goes on:
The good thing with the OMG BPMN specification is that new kinds of behavior can be defined for this “attached to the boundary” relationship. An example of new behavior can be exactly the one described [i.e. non-aborting]…. This is made possible because the OMG BPMN specification is underpinned with a consistent and extensible “behavior model” that defines the rules for starting, ending, aborting, etc. The default behaviors are the ones most commonly used by process modelers…. Therefore, process modelers don’t even have to think about them. But whenever required, this behavior model can be accessed and even extended.
Now we get to the heart of the matter. This is a serviceable description of OMG’s metamodel initiative, BPDM, which is not out yet. But that’s not BPMN. The metamodel has the goal of formalizing behaviors and tying them back to the Meta Object Facility (MOF) so that modelers can define their own behaviors, serialize that model in XML, and the code generation will be (supposedly) unambiguous. That’s not of any particular interest to me, but it seems to be something that MDA people want. OK, no problem with that.
But I say it again, that’s not BPMN. BPMN isn’t about user-defined behaviors. It’s about particular shapes and symbols, drawn in the diagram in a certain relationship to other shapes and symbols, having specific semantics that are standardized and clearly expressed from the diagram itself. At least that’s my opinion what BPMN is about. And I think that view is consistent with the passage on extensibility in the BPMN 1.1 spec (section 7.1.3):
BPMN is intended to be extensible by modelers and modeling tools. This extensibility allows modelers to add nonstandard elements or Artifacts to satisfy a specific need, such as the unique requirements of a vertical domain. While extensible, BPMN Diagrams should still have the basic look-and-feel so that a Diagram by any modeler should be easily understood by any viewer of the Diagram. Thus the footprint of the basic flow elements (Events, activities, and Gateways) should not be altered. Nor should any new flow elements be added to a BPD, since there is no specification as to how Sequence and Message Flow will connect to any new Flow Object.
Note this doesn’t say that modelers can redefine the semantics of standard flow objects, and it does say they can’t add new ones. The can only add other “elements or artifacts” - which cannot have sequence flows attached. That’s why my wish list is a wish list, because it’s the BPMN 1.x or 2.0 spec that would have to add the new flow objects or new behaviors for existing ones.
Here’s my main point. The BPDM people in OMG like to say BPMN is vague and needs a formal metamodel. It is vague in a few places, but mostly BPMN is quite specific about the semantics of flow objects. It is BPDM that adds countless new states and behaviors not described by BPMN. That’s fine for BPDM, because BPDM is not really about BPMN, but is a general framework for all modeling notations and languages. Why can’t they just come out and say that, instead of these back-door attempts to redefine BPMN. even when the BPMN spec — which just came out in January — says something different?
The real value of BPMN is that the notation - i.e. the diagram - is not only expressive but standardized. A particular shape means a particular thing, apparent right from the diagram. That’s one of BPMN’s essential differences from a tool like ARIS, where an arrow just signifies that a relationship exists, definable by the modeler, between the thing at the tail and the thing at the head. In BPMN, a sequence flow means one thing and one only, so you don’t have to consult the repository (and maybe the modeler) to understand what the diagram means. It’s obvious right from the printed page.
My wish of all wishes is that tool vendors would all serialize BPMN the same way, so that not only would a printout of the diagram mean the same thing across tools but the XML would as well. BPDM claims it offers that. But how can it, when it won’t admit that BPMN is not about user-defined semantics, but about connecting spec-defined semantics to standardized shapes and symbols?
March 8th, 2008
BPMN training v3.0, that is. Here’s a link to the overview on BPMessentials.com. Sorry for repeatedly blathering about this, but if you’ve ever tried to produce 6 hours of Flash video material you know the level of pain involved.
March 6th, 2008
My latest column on BPM Institute covers the issue of end-to-end process models which involve multiple pools and deeply nested hierarchies. It was motivated by painful experience grading certification exercises in my BPMN training. That experience was critical to my ultimate decision to include this in version 3.0 of my BPMN training, overcoming an initial concern about scaring off would-be process modelers. But the difference between the simple exercises modeled inline in the training and the post-training mail-in certification exercises representing real-world processes was simply too great to ignore. I’m not going to summarize the column here, but I recommend it to anyone interested in BPMN modeling.
For the blog I just want to add that topics like this are emblematic of the evolution of my approach to teaching BPMN from my initial efforts a year ago to version 3.0, which launches tonight on bpmessentials.com. When I started, my goal was to teach the semantics of the shapes and symbols as defined by the spec, especially where the spec does a particularly poor job of it (plenty of opportunities there!). But the experience of interacting with students showed me there is a hunger out there for a methodology, not an analytical framework like Lean (although that exists, too) but more of a cookbook approach representing best practice for BPMN. The spec doesn’t give you that. As a vendor-independent standard, BPMN has no built-in methodology, and BPMN tools vary in their ability to model complex end-to-end processes in the top-down hierarchical fashion that I think is vital. Naturally, the tool we use in the training, Process Modeler for Visio from ITP Commerce, does that part very well, but it still demands a cookbook methodology for organizing models stretching over many many sheets in Visio, so that they not only are easily traceable visually but hang together as a single end-to-end model for simulation and ultimately execution.
March 6th, 2008
On April 9 I’ll be speaking at Impact, IBM’s annual WebSphere mega-event in Las Vegas, on the topic of “Leveraging Enterprise Content in BPM and SOA”. I was quite surprised they invited me, as I have been critical of their previous positioning of FileNet vs WebSphere in the BPMS space (”content-centric” vs “process-centric”? are you kidding?) But given the new SOA spin on enterprise content (both FileNet and DB2 CM), sounds like IBM may be loosening up. In any case, I don’t have to talk about IBM product strategy, just why SOA and BPM folks need to include managed content in their solutions, and how to do it.
March 6th, 2008
I’ve just finished version 3.0 of my Process Modeling with BPMN course - it should go live on BPMessentials tomorrow. A 2-day classroom version will be held in Chicago on April 16-17, hosted by the BPM Institute. Same material, same hands-on exercises with Process Modeler for Visio, same certification procedures as the online. Once the online goes live, I’ll write more about v3.0. I’m really happy with it. Pricing for the class in Chicago is set by BPM Institute. The earlier you register, the lower the price, that’s the basic formula. So sign up soon.
March 5th, 2008
Over the past several months I’ve been doing a lot of work with SAP to beef up the modeling-related content on their BPX community site. BPX stands for Business Process Expert, a term intended to describe a new role in the organization, straddling the line between business and IT. I see BPMN as a critical enabler of this role, because it for the first time allows process modeling, a business function, to be directly integrated with process implementation design… throughout the process lifecycle. Traditional modeling notations assumed the model was standalone, used for documentation, analysis, and generation of “business requirements” handed off to IT, who would start over in a new design tool with a different metamodel, different data model, and different programming model. Agile? I don’t think so.
BPMN enables a new iterative implementation style in which business collaborates directly with IT throughout the cycle, rather than a one-time handoff. That’s because the BPMN model has the expressiveness and semantic precision to underpin an executable design. The BPM Suites that do it right — and those that don’t are trying to move that way — don’t start over in a separate design tool but layer implementation properties on top of the BPMN model objects - activities, gateways, and events. So the model, i.e. the BPMN diagram, remains an abstract business view of the implementation throughout the development and maintenance cycle.
Achieving this demands a new role, the BPX, who can translate process knowledge and business requirements into the BPMN model and work with IT in that iterative/collaborative fashion. The BPX community site on SAP Developer Network (SDN) is trying to facilitate the growth of this role, with free resources of all sorts, including a series of articles and Flash tutorials on BPMN modeling which I authored.
The BPX site tries to remain free of any SAP marketing, although I’ve never understood why. It may seem odd that SAP is pushing this line of thinking — sounds more like Lombardi or Appian, you might say. But SAP has been peeling back the veil from their new Project Galaxy, a BPMN-based BPMS (they call it a “business process platform”) based on Netweaver. In the continuum of BPMS design environments, it’s clearly on the Lombardi-Appian end rather than the IBM-Oracle end. I made the screenshots in my Flash mini-training on BPX from an early beta of the tool… it’s pretty nice.
Marco ten Vaanholt, head of the BPX community, and I did a webcast recently on ebizQ. If you’re interested in this topic, I recommend it, along with my BPMN articles and free training on the BPX site.
March 5th, 2008
Previous Posts