I am watching a number of comments being placed about a new effort for BPMN 2.0. Vishal Saxena says that the BPMN 2.0 metamodel should maintain this flexibility that BPMN 1.0/1.1 has. No argument there. Sebastian Stein says that BPMN is missing an exchange format, and clearly he does not know about XPDL. He goes on to say that the real problem is a lack of clear execution semantics. He points out that the OMG discusses two approaches: BPMN defines the semantics, and BPDM defines the semantics. Bruce Silver comments that the first approach would be the most value to the BPM community. We seem to agree that BPMN needs more clarity in expression. I suggest that there is a third approach that the OMG should consider.

My concern is that the BPMN committee is heading down a blind alley: One part design-by-committee, and two parts not-invented-here. It might be expressed as something like this: “Products can’t completely agree on the semantics of the drawings, so let’s just make up some new semantics, and everyone can just use that.” As if the problem was that products simply can’t define precisely what they mean, so the standards committee needs to define it for them.

The issue is NOT that existing products have undefined semantics! There are many products on the market, every one with precisely defined semantics of what they want to, and need to, express. The fact that products have inconsistent implementations of BPMN is not because they don’t know what to say. Instead it is because BPMN is not good enough at expressing precisely what that product needs to say.

Let me give you a concise example. In BPMN you can define an activity to have multiple outgoing arrows. Does this mean that all, some, or one arrow will be activated when the activity is completed? There are three cases to consider:

If you leave the tails of the arrows unembellished, it indicates AND split semantics and all arrows will be taken. If you put diamonds on the tails of the arrow, it means Inclusive Or semantics: one or both of the arrows will be taken dependent upon conditions within the diagram logic. The other normal case would be “Exclusive-OR Split” semantics, which means exactly one of the arrows will be taken. There is NO WAY to indicate in BPMN that the outbound arrows from an activity have exclusive-OR split semantics. It is simply missing from the standard.

This is surprising because so many products out there have traditionally made use of exclusive-OR. Traditional “flow chart” modeling uses exclusive-OR predominantly. Of course, there are other ways to draw it: I can make a single arrow go to a gateway, and there is an exclusive-OR gateway, so it is a logically equivalent way to draw it, but it is different drawing, and significantly more cluttered one at that. Not every product needs exclusive-or in this case, but some do, and we all would benefit if there was a standard way to express this.

Products are inventing extensions to BPMN because BPMN does not have the power to express precisely what they need to express. BPMN is the best standard notation we have, but it is not finished, and there are still many limitations. Now that we know there is a “meaning” to be expressed, and no way to express it, the BPMN committee should focus on extending BPMN with a way to express this. Don’t waste time developing a visionary model of a new non-existent product. Instead, the committee should be looking at existing products, and observing how they have used BPMN inconsistently, in order to figure out what gaps exist in BPMN today. Then come up with a clear expression so that when we see the diagram, we know what it means.

Many of the successful products today are based on years of research and customer trials which have directed the products to become very very effective at some particular segment of the market. How naive it is to believe that the difference between products are accidental and inconsequential differences. How arrogant it is to think that any group of experts can simply invent a new approach which is universally better than one that has already been proven successful. But this may be precisely what the committee tries to do.

The purpose of a notation is to clearly and unambiguously express something about the world as it is. It is NOT the purpose of a notation to redefine the world as we would like it to be, regardless of how attractive that idea might be.

If we think for a moment about the “musical notation” analogy (my previous entry) it would be a bit like the committee saying: “now that we have defined the musical notation, let us define instruments that can play such notes. We have a staff that goes from E to G, so I need an instrument that goes exactly from E to G”. The reason this is so laughable is that the sound of a musical instrument is infinitely richer than what is expressed in the notation. Reading the score of Beethoven’s 9th would be meaningless without having a familiarity with the different sounds of the instruments that are playing the various parts. The notation does not define the sound that is made, but it does express exactly what the musician needs to know in order to play along.

The best way to arrive at a more precise definition of the execution semantics of BPMN, is to look at existing successful products today, that already have precisely defined semantics. Examine how well these products are able to use BPMN, and particularly at how BPMN falls short of being able to precisely express what such a product needs. Then extend BPMN so that each product can clearly, and unambiguously, express what it needs to say. In this way, the BPMN standard would gain from all the best ideas which have been developed over the past 20 years.

I attended the keynote by Dennis Wisnosky, CTO of Dept Of Defense, today at the Architecture & Process conference. He is currently on a campaign to get vendors to make truly interoperable implementations of BPM technology. He has been testing implementations of BPMN, and found disparity.

A notation is…

He feels that the most important thing is a standard notation for business processes. What do you get with a standard notation? You can have a document that displays something, and everyone should be able to read it, and agree on what it means. He gave two examples of notations.

First, he showed an electronics schematic. He pointed out the resistor symbol, the capacitor symbol, and the ground symbol, included in a simple filter circuit. You go to any electrical engineer, in any country of the world, and they can read this diagram. It is a standard notation that works.

Second, he showed musical notation. Again, this is a world-wide standard which consists of notes on the staff, as well as a collection of other notation. Again, you can take a piece of music to any musician in the world, and have agreement on what the notation means. It is clear what notes are to be played, when they should be played, and for how long.

He is absolutely right. You should be able to take a BPMN digram from any product, and show it to a person who is trained in BPMN, and there should be an unambiguous interpretation of what the diagram means. That is the goal of BPMN.

But a notation is not…

The analogy with music is a very good one, because it exposes some other properties of a notation that people find non-intuitive. For example, you can write a jumble of notes on a staff, but that does not mean that any given instrument can play it. A tuba player can read the piccolo part, and agree what the notes mean, but that does not mean that the part can be played on a tuba.

A standard notation does not imply that all legal notation can be played. Each instrument has allowable parameters around what you can and can not play, limited certainly by range, but also other factors: a piano can play chords while a wind instrument can not. (Please, no smart comments about bag pipes, OK?) A composer does not write a piece of music as an “abstract” composition of notes. A composer considers each instrument, and writes music that that instrument can play. This is expressed as standard notation, which anyone can read, but there is a lot more composition than simply creating the notation.

It is really important to keep this in mind for BPMN. When a process analyst creates a process diagram, that analyst must keep in mind the capabilities of the process engine that will be executing the process. The process should be designed specifically to run on that engine. But then the process can be expressed in a standard notation that we all can read and agree on the meaning of.

Conversely, this means that when an engine imports an XPDL file containing a BPMN diagram, the BPMN and XPDL standards do not, by themselves, guarantee that the engine will be able to execute it. The best we can hope for is that the engine tells you when there is something “out of its range” and can not perform.

Don’t confuse notation with universal language…

Imagine a universal instrument that could play any combination of notes for any duration, but there are other considerations beyond simply being able to throw any notation at an instrument. A trumpet and an oboe may play the same notes, but they are qualitatively different instruments in a way that transcends the notation. The notation communicates certain important things, but it is not the full embodiment of the music.

Some people jump to the conclusion that all process engines should have a “complete” implementation of BPMN — whatever that means. Having all process engines with exactly the same capability would mean stopping all innovation on support for business process, and limiting all engines to a least-common-denominator approach. It has been my experience that each engine offers new and unique difference that are good for supporting particular kinds of processes. Stifling innovation for the sake of universality is a short sighted goal. The fact that the engines are different is not a bad thing. Yet we still can expect, and must demand, that the notation be consistent.

Dennis Wisnosky represents a very large and powerful customer of process technology, with influence across the industry. Watch what he does, because I think he is in a position to have a profound effect on the BPM marketplace this coming year — and he is on the right track.

I just want to highlight an excellent post by William Vambenepe on the subject of BPMN to BPEL: going to battle with one hand tied? He does a very simple experiment: draw a meaningful diagram in BPMN, in this case a fairly simple one involving an Inclusive-OR branch, and then attempt to convert this to BPEL. He does this conversion and presents the results is quite obviously a diagram that fails in fact to capture the exact meaning. He says he has no solution to this problem.

William, I have your answer, but it is kind of cheating: “WYDIWYE” The solution is to NOT convert to BPEL at all. Why can’t the engine take the BPMN diagram directly? Why does it have to be converted at all?

Think about it: if you can draw a diagram that is unambiguous and the rules are clear, why not simply transfer that entire diagram to the engine, and let the engine execute it exactly? A conversion always involves loss of information, or at best, retaining the same information, and the problems of “round-tripping” conversions are widely discussed. What would be the advantage in converting the diagram to BPEL?

Internally, the engine can convert to anything it wants. If it is internally a BPEL engine, then it can convert to its own brand of BPEL. If it is Ruby based, it can convert to Ruby. As users, why should we care what it converts to for execution?

There are a number of engines that interpret the diagram directly without needing translation. WYDIWYE: What You Draw Is What You Execute. This is exactly what Interstage BPM does, but Fujitsu is not the only BPM vendor out there that does this. (Others can chime in, please.) I often get asked: “do you convert this diagram to BPEL?” My response is “Why should we want to do that?” We send the entire diagram, unconverted, to the engine, where it is executed directly. There is no benefit I can see to stripping the process down to the executable part for giving it to an engine.

There are several clear advantages of WYDIWYE:

• The additional non-executable information (graphics, etc) as useful in order to display the running process to a user.
• If you offer on-the-fly modification, then you have the entire process to start modifying. Not possible if you have only a BPEL extraction.
• If it fails to execute the BPMN diagram that I drew, then the engine can explain to me on that diagram what is wrong. It is difficult to communicate problems back to the user if the form is changed from the original.
• You can always convert it later to BPEL if you wish, given that you have the complete diagram.

Seriously: what do you gain by converting to BPEL before giving it to the engine? BPEL strips out non-executable aspects of the BPMN diagram. Even those that claim all is preserved do not deny that often the form is changed to be unrecognizable. Also, consider that the Diagram is the Meaning in many cases.

WYDIWYE: What You Draw Is What You Execute. Why does the diagram have to be stripped down to the executable part before giving it to the engine?

It has been a while since I given an update on the work of the WfMC Technical Committee. The last couple of months has been busy, and this is all building toward two standards tutorial events: one in DC and one in London. Before we get to that, it has been a busy couple of months:

XPDL 2.1 - A new update to this specificatio due to the hard work of a number of people contributing and painstakingly edited and assembled by Robert Shapiro. TheWfMC working group 1 met in Nashville and voted for adoption of the 2.1 spec as it is. The new version contains extensions to support BPMN 1.1 (also just released) and include a new section on conformance testing. This is an important step because it allows us to specify several levels of conformance, and a way to measure which level you are at. Bruce Silver contributed significantly to this approach. Tom Laverty from Global 360 developed an XSLT script for performing the test. All in all, it is another step forward in the WfMC effort to allow for a process design ecosystem.

BPAF - A new acronym is born. The Workflow Reference Model describes interface 5 which is a way for events and other historical information to be passed to an analytical tool for processing and mining. At the Nashville meeting a decision was made to call this “Business Process Analytics Format”. This is a standard XML structure which a BPMS can generate, and Process Intelligence product can consume in order to product high quality analytics. Of course many such tools can be programmers to take a stream of event in any format, but a standardized format will allow us to fine tune the precise semantic meaning of each attribute of the event, and make it far easier to hook various types of process engines together without programming. There is a working group led by Michael zur Muehlen and Shane Gabie.

Wf-XML - Main focus on creating a new RESTful version of this specification in cooperation with Open Geospatial Consortium. Find out more about this at GeoBlicki.

Events - there have been a number of successful BPM tutorial events:

• Las Vegas, Feb 2008, BPM In Practice at Gartner BPM Summit drew a full room of 60+ people for this three hour tutorial by Keith Swenson and Robert Shapiro
• Nashville, Feb 2008, BPM In Practice at the BPM Tech Show was a repeat success with the three hour tutorial. This one was recorded and is being turned into a book!

Future Events - please mark your calendars, the followin:

• Washington DC, April 21, 2008, at Architecture & Process 2008
  A full day BPM Standards Tutorial given by the entire team of WfMC BPM experts. This is also the location of the next WfMC Member Meeting April 22-24.
• London England, May 1, 2008, BPM In Practice Special Event
  First time in England for this venerable tutorial series, and timed to be the day after the Gartner BPM Summit in downtown London. A full day session to catch up on the most important standards for BPM Technology today. Get your reservations early.

After a few months without much BPM discussion, then I blinked and found that I have been missing the Great BPMN Debate. To bring you up to speed: Michael zur Muehlen and Jan Recker have been studying how people actually use BPMN to draw business processes, and have counted the occurrance of rate of various elements. He summarized this in a blog post,which came to the conclusion that practitioners could focus on learning and using a small subset of a dozen BPMN elements, that vendors could prioritize implementations to get the more common elements first, and that some elements were used so rarely that the value of their existence was questioned.

To me this intuitively makes sense if you consider the way that such standards get developed. A group of people get together bringing with them different ideas of how to draw a meaningful diagram. Common ground has to be found between all of the different approaches by taking the specifics of several different approaches and abstracting to a higher level concepts and groupings. Compromises have to be forged in order to include all of the most important parts, and to exclude ideosyncracies of a given approach. The committee aims for a suitable level of completeness. Given that each committee member is coming from a slightly different background and with a slightly different concept of how the various elements might be used, there are clearly differing priorities. Committees will tend to err on the side of including too much because it is easy to argue that a capability is needed, and give an example that requires it, than it is to argue that that example is not common enough to warrant inclusion. It is only natural that the core of a few items will represent the bulk of the usefulness, while there will be some elements that are not useful at all. It is the nature of standards, as it is for high tech products, that the exact way it will be used can not be fully determined until they are actually in use.

Bruce Silver responded with a spirited post raising questions about the method and conclusions. Bruce certainly must be counted among the handful of top BPMN experts that exist today. Bruce has a point: the study was done from existing BPMN diagrams. Who can say for sure that the elements were missing because they were not needed, or because simply the modeler did not understand how to use them? Who can say whether they were missing from the diagrams because the modeling tool vendor did not implement them, or did not implement them correctly. The diagrams themselves may not actually comply to the BPMN syntax. The model might comply to BPMN syntax, but the the modeler might have intended to represent something else. Given the likelihood of these diagram flaws, how can you then conclude that something is not needed simply because it is not used? This is beginning to sound a bit like an argument that designers often use: “They would be useful if the standard had been implemented correctly in line with the original vision of the standard.”

Michael responded with a thorough post which can be brutally reduced to: “Like it or not this is actually how BPMN is used today.” His intent was not to criticize the standard (quite the opposite) but to provide helpful empirical data to guide practitioners, vendors, and even the standards committee to the most important aspects of the standard. Implicit in this is the implication that a subset of the entire standard is acceptable. Bruce responded by admitting that there were superfluous elements of BPMN, but that we should be a bit more careful on how we select the most important set. Tom Bayens weighed in with another well considered perspective. Sandy Kemsley’s summary of this debate is far better than mine, so I will stick to a few comments.

As I have said many times, I consider BPMN to be a dictionary of symbols which can be used to represent concepts. Just as a writer will write a novel without using every word in the English dictionary, so it is suitable to pick and choose a subset of these symbols for use in modeling processes. I have never quite understood those who argue that a modeling tool is useless unless 100% of the specifications are supported (which is arguably not possible given ambiguities and redundancies that exist in such standards.) It goes without saying that your expressibility is limited the more you limit the available symbols. Yet Michael’s main point is that you can say quite a bit with a surprisingly small subset of the BPMN language. I do hope the BPMN group will take to heart as they consider extensions to the existing set, because it is important to step away from the theory of how you would like a standard to be used, and be guided by the more pragmatic knowledge of how it is being used in practice.

That being said, for models to be portable, there must be a broadly agreed upon subset which is sufficiently expressive to handle all the cases you are likely to encounter. If tools choose too narrow a subset, then they will not be able to understand diagrams from another tool with a different subset. Thus Bruce argues quite effectively that the process design ecosystem is best served by encouraging implementation of as much of the specification as possible, well beyond a minimal subset. So I can identify with the concern that a narrow approved subset might encourage vendor to stop short of a useful implementation.

Let me conclude this post with a quick acknowledgment of the tremendous work which Bruce has been doing recently on the XPDL 2.1 specification which has been approved for release by the working group last month. He drove the development of a model portability conformance guideline which he touches on in his most recent post. This ground breaking work will allow us finally to measure the extent to which a tool supports BPMN, and to assure that there is a certain minimum level of consistency, without requiring 100%-or-nothing. Thanks Bruce.

Will you be forced to pay royalties in order to watch your child’s performance on your TV at home? That videotape of your child’s band concert might be illegal, due to overzealous enforcement of copyright laws by the music industry. Motivated by greed, the music industry has simply gone too far.

Consider the case of Mike. He has two kids playing in the high school band: Tom and Nicole. Mike is a typical band booster: he volunteers on the music association board, he helps load and unload all the equipment at events, sometimes he even drives the truck. The kids love the band. They hang out with a group of students who are motivated to cooperate to collectively put on a show. Band students tend to do well in school, and they learn important skills in being able to work with others.

Mike, like most parents, is very proud of his kids’ accomplishments. He wants to capture videotape of every moment of their performance on the field. He wants to show Tom’s and Nicole’s grandparents who live across the country. Never mind the amateur style of photography, there is nothing more delightful than seeing your child or grandchild actually taking part in an successful performance. You and I might not want to watch these recordings, but Mike and his wife would treasure these memories for many years. But Mike is banned from using his video camera at events.

Increasingly, band events are outlawing the use of video cameras to film the kids. The problem: music is being recorded “synchronized” with images of marching - this incurs special synchronization royalties. The organizations that put on such events are truly heroic in giving young student the opportunity to perform, but clearly they are struggling to comply with the legal issues: “Over the past several years, compliance with copyright law has become a matter for close scrutiny by the copyright owners and publishers of copyrighted music. “

That video recording of your child’s birthday party with the kids singing “Happy Birthday”? — you owe royalties for performance, mechanical reproduction, and synchronization. You probably thinking that this is not possible, because these home recordings are “non-commercial” and therefor not subject to payment of royalty. This is a commonly held misunderstanding about copyrights: you don’t have to charge money to be liable for royalty. There is a standard royalty rate for mechanical reproduction (1.75 cents/minute = $1.05/hour) for every copy. You don’t even have to have any public presentations of the video.

You might be thinking: “but they will never catch me.” Cameras are so small now, there is no way such an event could be policed. Which is why event organizers are turning to blanket bans on the equipment. Mike and his wife are made to feel like they are breaking the law just to get a few shots of the kids in a key accomplishment. Mike always complies with the rule; it can still be very uncomfortable sitting next to another parent who is flagrantly taping the entire show. Do you tell them to stop? Why does the event even have to put you into this situation? Why can’t we be allowed to videotape our own kids?

I am a lot like Mike: my kids play in the school band. (But, to be honest, I don’t carry a video camera, see my posts on HDR for my particular obsession.) I went along with the high school band on their final performance at a band competition in East Los Angeles in November of 2007. I was shocked to see signs posted all over the arena saying “No Videotaping Allowed in Respect for the Copyright Owners of the Music”. The reason given for banning all camcorders was that there was no permission for “mechanical reproduction” of the songs being played. The music industry feels the need to prevent the parents from recording their own kids, because this might cut into their profits.

Let me remind the reader: we are talking about high school bands in a marching band competition. This is not going to steal audience from any pop-star concert. The audience consists exclusively of adoring parents, musical teachers, and assistants. Nobody is going to get rich stealing footage from these concerts. Do those music industry executive seriously think that people are going to sell these recordings? Is it going to hurt them in any realistic way? Yet for Mike, this is a serious affront. His kids have been working all season long on this show. They have attended half a dozen competitions, each time getting a little better, a little more in sync, a little more polished. This final concert is the ultimate conclusion of a season’s work. Those kids have never played better, but I can’t actually show you. “No Video Cameras Allowed!”

The law is on the side of the music industry: copyright owners have been given by the government exclusive right to control performance, mechanical reproduction, and synchronization of music. Fifty years ago mechanical reproduction and synchronization was something that only the most accomplished musicians had access to. But today the typical child carries such capabilities in their pocket cell phone and the law is an anachronism which is abused. Such a recording might be considered fair use, but the burden of proof is on the defendant, and the resulting chilling effect is the banning of video cameras at high school band events.

The irony is that Mike is not making a video tape because he wants a copy of the music. The Band might be playing Beethoven; it is not his objective to get a copy of the Beethoven piece. Instead, his objective is to capture the experience of the band performance, the actions of the kids. This experience belongs to the audience. The music is, in some sense, incidental. Like the video of the birthday party: the purpose is to capture the event, and not to steal another recording of “Happy Birthday”. The current law make no distinction as to the purpose of the recording.

A typical high school band will spend thousand of dollars licensing music for the kids to play. This is valuable and legitimate so children can learn to play. But the terms of this license border on the bizarre. Music licensed to high school bands is not automatically licensed for “mechanical reproduction”! What are these people thinking? When you license music to a senior or junior high school band, you can be sure that parents want to videotape their own children.  Getting a mechanical reproduction license requires significant additional trouble of estimating how many minutes of video tape are going to be recorded, and license at a a few cents per minute of recording! Few schools, already strapped for money and volunteers, can afford this or have the manpower to follow up on this. They are forced into the only alternative: ban camcorders at the concerts.

Clearly professional bands performing for a fee owe a portion of what they make to the writers of the music. High school bands are not professional. These are music students, and the performance is essentially a final exam. But don’t let Mom or Dad make a recording of this, because that might be stealing profits from ASCAP or BMI.

The Music industry has simply gone too far, and bans the use of certain songs at events. Reading the band competition site is sad and poignant: “In some cases, the [banned] songs listed above were included because the copyright owner has already advised Bands of America that they are not willing to grant video synchronization rights for marching band videos” Apparently “God Bless America” is not allowed by the owners to to be used in a band concert. Walt Disney will not allow any music from a current release. Don’t even think of playing a James Bond theme. There are many more specific publishing companies that refuse to let school bands play their music, but I don’t want to give them free publicity here. Makes me wonder: what are they afraid of? “They’re protecting an archaic industry,” said the Grateful Dead’s Bob Weir.

The local high school band does not have much money, but still diligently licenses all music. That is why they are concerned when they are told they can not make a “mechanical recording” of their legitimately licensed music. When the company sells music to a school band with 150 students, you have to expect that there will be between 150 and 300 parents in the audience wanting to video tape it. This is just common sense. Allowance for this should be part of the deal.

I have no sympathy for fat-cat music executives who sell music to a high school band, and then turn around and invoke a special clause that prevent parents from videotaping their children in the final concert. How sad it is that the music industry is so money grubbing that it feels that your home videos of little Tom and Nicole are a threat to it. As Americans we should change this anachronistic law. As long as we are not selling the recording for profit, we should fight for the right to record, photo, videotape any public performance by family members, friends, and community members. These recordings capture our experiences to which the music is just a backdrop. Our memories should not be copyrighted.

• Bands of America - Copyright Guide
• Mechanical Reproduction Rights Primer
• BOA Participant Requirements
• RIAA vs. The People
• The Promise of a Post-Copyright World
• Stanford Fair-Use Center

What can you do? Write your congressman. Promote a law that allows music performed by a student group to be recorded and used for any non-commercial use. Call it the “Freedom to Videotape” law. Or perhaps it should be an amendment to the constitution to give us the “Right to Royalty-Free Memories”.

Yup, we never stop inventing new stuff here, and to prove it, check out the latest new product: Fujitsu Unveils Laptop Made of Corn. What will we think of next?

Also seen on inhabitat.com.

If you don’t have an HD TV yet, you are sure to have one soon. Somewhere I read 50% of households have a digital TV, and I suppose some large fraction of that will be HD. But here is the scam: eventually you are going to need an HDMI cable, and the electronics store knows that you are not going to think ahead. Funny thing: all the cables are so very expensive. Not anything like the TV, but often between $100 and $150 for a 3 to 6 foot piece of wire. If you are lucky, they may have a “discounted cable” for $85.

Why are they so expensive? There is no real reason. HDMI is a digital connection, and there is a certification standard. As long as the cable meets the standard, the picture should be exactly equivalent. If you look around, you can find an HDMI cable on the web for $6 to $8 with gold plated connectors and fully certified. These places have HDMI cables for “normal” prices:

• http://www.mycablemart.com/store/cart.php?m=product_detail&p=813
• http://www.eforcity.com/hdmi-hdmi-cable.html
• http://www.dcables.net/index.asp?PageAction=VIEWCATS&Category=112
• http://www.optimization-world.com/products/catid/2.html

What is going on? Simple psychology. Most consumers will forget to buy the cable, until they discover they need one, and it is 30 minutes to the opening kickoff of the superbowl. They know you are are going to focus on the main purchase: the 50 or so inches of gleaming glass and glow where you will shell out between $2K to $5K or more. “Would you like a cable with that?” they will say. What difference does $100 make in a purchase of this size? Who wants to take home a brand new TV, and not be able to turn it on to watch? Who wants to take home a brand new PlayStation or other high def DVD player, and then have to wait a week or more to be able to enjoy the full resolution? You are going to want the cable right then. The markup on these cable is in the 10x range if you buy from an electronics retailer.

I went (of course) to Fry’s to search for a better deal. In the TV department, they had the standard $85 cable on display. I looked they guy in the eye and pointed out that Fry’s is a discount store, and he said I could find a better deal in the electronic parts department. Over on the other side of the store, I found the rack where HDMI cables hang empty. After rummaging around on top of the overhead shelf, I found a package with a 6 foot cable for $25 that someone had probably stashed up there for possible recovery later. That was clearly the best deal I was going to get three days before Christmas.

The retailers know that they “have you” over the cable and that is why the prices are uniformly high. And, to be fair, none of them are going to sell more TV’s by lowering the prices of the cable. But it just plain bugs me that the price is so inflated.

Here is my recommendation: click on one of the links now (do it right now) and purchase an $8 cable and have it shipped to you the slowest, cheapest way. Eventually, probably in the next year, this is going to save you money. It might save you anywhere from $20 to $50. Either way, a $10 investment with a 2x to 5x return within a year is a good investment in anyone’s book. But the satisfaction of telling the saleman you don’t need the cable is priceless. Even if you don’t have an HD TV, and are not planning to get one in the next year. A you might be the guy (or gal) with a spare HDMI cable, 30 minutes before the superbowl game.

Links to similar articles: arstechnica, gizmodo, macrumors, searchwarp, cnet, playstation.

The BPMN specification includes a sample process to use as an example of how you would use BPMN to draw the process and how it would then be converted to BPEL. Bruce Silver has suggested that this be used as an example process to test interoperability between different process diagramming tools. One point in favor of this is that it is fairly well fleshed out and documented. Also, it is a real process that would be reasonable to use in real life.

As I set out to implement this process, it struck me how dramatically different the process would be drawn if you had an implementation engine that supported human activities directly. Many of the things which are broken out into seprate activities would be combined into a single activity. Even at the basic level, the model would be different, because you would be modeling the human activities, instead of the flow of data back and forth. The process as it is diagrammed was designed from the beginning with the idea of being implemented on a BPEL engine. The process model as it is drawn approached everything from the point of view of what would be possible with a BPEL engine.

The best way to explain this is to show what the process would look like if you were to implement it using a human facilitation style BPM engine, and that is what I will do below by applying the Methodology for Human Processes to the email voting scenario.

The first step is get a list of the actual human activities that appear in the process. To do this we fly up to the 40,000 foot level and look down, ignoring as much as possible the details that came into the process due to the orientation to be able to executed on BPEL. We start with the activities that have to be done by people, because they require human intelligence, and really can not be automated.

1. Choose the issues for this week. The scenario assumes that there is an open ended list of possible issues which are being continually added to. It is not possible to talk about all issues every week, so someone must pick the most important issues. It is not possible to automate the determination of what the most “important” issues are, so this task of picking 1 to 5 issues for discussion and voting this week must be done by a person. There may not be enough issues this week, or it may be a holiday week, or any number of other possible reasons not to discuss issues this week, so the issue manager must choose whether there are “Issues” or “No Issues” this week.

2. Discuss Issues. There is a period time within which people are allowed to discuss the issue, and that means having access to the issue descriptions, access to comments that others have made, and the ability to make comments on the issues. This is performed simultaneously by a large number of committee members.
3. Determine is Discussion is Over. The issue list manager is asked in this process to take a look at the results of the current discussion, and decide whether the discussion needs to continue or not. Since this is a decision that is not automatable, we have to have the issue manager do it. There are two choices: “Continue the Discussion” or “Finish the Discussion”.

4. Vote on the Resolutions to the Issues. Mainly just recording the results of the activity. In this step, we can make use of a parallel activity called a “Voting Node” to allow everyone to be informed about the vote, to collect their responses in a convenient way.

5. Remedy Voting. This is a human activity in the case that voting “fails”. Voting can fail when not enough people vote. The original BPEL oriented process had a number of steps, most automated, to handle this situation. When considering the human tasks, an analysis of the process leads to the conclusion that a large number of the possible paths are automated, but a few of the paths require a person to address the situation by either reducing the number of voters or reducing the number of options being voted on. The key here is that in those situations that a human must be brought in, what is important is that the person be notified that the voting has not worked, and be given a couple of options to remedy the situation. So for the purpose of modeling the human process and for making the decision of how to proceed, I have collapsed this to a single activity node for a person to perform. The automated aspects are ignored at this point.

Then we have human activities that are necessary because the technology is somewhat limited, and not completely automated, and so there are some tasks which people do manage and maintain the systems

6. Moderate the online discussion. Unfortunately, the discussion is not completely self moderating, and so someone must have special access to possibly delete spam and inappropriate messages, and to help people to keep the discussions going.

7. Hold or attend conference call. The discussion on the issues is not completely on-line discussion, but also conference calls are a way that people come to a common understanding of the issues and resolutions. Someone needs to set for the conference call and moderate while it is happening.

The above seven activities account for everything that is done by people in the process (if I considered everything correctly). There are only two roles in this process. The Issue Mgr is the person who is managing the issue process. This could be multiple people, but only one of them would act at a time. The other role is the Committee which is everyone who is involved in discussing and voting on issues. The committee members are responsible for Discussing Issues and Voting, while the Issue Mgr is responsible for all other activities in the process.

The email voting process actually consists of two processes: a singleton starter process which loops and starts an instance of the actual issue voting process every week. The issue voting process then has two subprocesses. Because we have only seven human activities, I decided to keep it simpler and not use the subprocesses, and to do everything in the two main processes, though this would have been a choice if you wanted to you could use subprocesses to group things differently.

In doing the analysis I became aware of a strange behavior of the original process as written. You could very easily be in the position of being asked to run multiple conference calls at the same time. Remember that issue handling process is started every week, which drops into a subprocess for decision handling and another for voting. Each of those subprocesses have logic for determining if there will be a conference call during that time period, and to trigger an activity for handling the conference call. The discussion subprocess may loop, potentially for multiple weeks. It is possible that you will have multiple instances running at a time, and if this is the case, each instance will prompt for a conference call. The issue manager might manually avoid having multiple instances running at the same time, by deciding not to discuss anything in the new process instance as it is started, but this rather begs the whole question of why there are the possibility of multiple issue resolutions processes in the first place; why not simply have the singleton starter process do all the work? Finally I settled on the idea that issues are grouped, and it makes sense to have the possibility of multiple issue groups being discussed and/or voted at the same time. The conference call on the other hand is scheduled every Thursday, and takes place regardless of the number of issue groups currently, and therefor should be associated with the singleton starter process, and not the instances of the issue voting process.

The starter process

There is a single instance of this process, which loops every week. There are timer delay nodes that cause things to happen at specified times. At 9am Monday morning, an instance of the issue list process is started. This is done with an “asynchronous” subprocess node; this is a node that starts a subprocess, but continues without waiting for that process to finish. The ability to start a subprocess and not wait for it is commonly available on human process engines, and is a standard part of the XPDL file format. This is one clear area where the capabilities of the engine will certainly effect how you draw the process. If you think about it, the purpose of this starter process is to create instances every week of the email voting process, but because in BPEL there is no operation for expressing this, the original process would “send the issue list” and the “receipt of the issue list” would cause the creation of the process. This is quite strange when you consider that the issue list itself is probably on a server that is already accessible by everyone, and does not need actually to be “sent” anywhere! The sending and receiving of the issue list is an artifact created just to get around the problem that BPEL does not have an operation to create a subprocess! This is also partially because BPEL is not modeling the work that people do, but only modeling the sending and receiving of data. OF course, it is possible to model the whole world in terms of sending and receiving bytes, but it is far clearer and easier to read a process diagram with a node that creates the subprocess directly.

Then, on Thursday at 9am there is an activity to hold a conference call. This is assigned to the Issue Manager. I embellished the process a little bit to also give that manager a choice of whether to conclude the working group or not. The original process had a branch node that checked something to see if working group was still active, but then someone would have had to have taken some action somewhere to indicate that the working group is completed. Drawing it this way ties both the human indication that the working group is finished together with the completion of the process. Every week, the conference call task will be concluded with the choice “Continue Working Group” which is no additional effort over simply saying that the conference call is done. But, when the time comes that the working group is no longer active, and there is no need to ever have another conference call or another issue vote, then simply choosing “Conclude Working Group” provides an easy to complete the process without using the administrator’s console.

The Issue Email Voting Process

This process starts two activities from the start. “Moderate Discussion” is designed to remain active the entire time the process is running. Most of the time the process will be in the Discuss Issues step or the Vote step, and so really this step allows a place where the issue manager can moderate both discussion and voting. I embellished it a little bit to add a “Terminate” option that would shut down the process before discussion or voting was finished.

The main process is the lower 5 activites. First the issue manager decides the issues to be discussed. Second, the issues are discussed by the committee. Then the issue manager decides if the issues have been discussed enough and completes that by either “Restart Discussion” or “Call for Vote”. If it is the latter, the committee is asked to vote. If the vote is not conclusive, then issue manager must Remedy Vote and where he will be able to reduce the number of voters or the number of resolutions to vote on, and to choose either to Terminate the process, go back to Discussion, or go back to Vote.

How does the “Vote” work? Here we cheat a little bit by using a capability of the engine that present the vote options to a number of people simultaneously. It gives the options of “Yes”, and “No” to all committee members. People choose one, and the process engine tallys the results. On the outbound arrows, you can specify how many votes, or what percentage of the votes, are necessary to consider the an option successful or not. As soon as the success criteria is met, the voting activity is concluded. There is also a built in timeout so that if a vote is not concluded in a period of time, then the activity can be concluded down a third arrow which leads to the Remedy Vote activity. I know this seems like cheating to pull something like this out of the hat, but I did not make up this process, voting steps are relatively common in the worplace, this is a real node type available in a number of human process engines. As much as anything else, this should make it obvious that the way you draw a process in BPMN is highly dependent upon the underlying technology that you are going to use to implement it. For the discussion node we also use a voting node, even though we are not voting, and again it ends with the built-in timeout mechanism.

How are people notified about what to discuss? How are they told what to vote on? When you assign a human level activity to a person or group of people, that activity automatically includes a notification mechanism that tells them what they are to do, and includes information about the specific case. Simply assigning the “Discussion” node to the Committee means that everyone in the committee is automatically told what it is they are to discuss at the time that the discussion is to start. Simply assigning the vote node to the Committe means that they will be notified what the voting options are at the time they are to vote, and their votes are automatically collected and tallied.

What about the nodes to send reminders? Again, this does not need to be explicitly modeled because every human activity automatically includes (a) notification, (b) information, (c) conclusion, (d) deadline, and (e) reminders. We just set up the discussion activity to have a reminder after 6 days. Similarly on the voting node, we have a reminder after 6 days. That reminder on the voting node can be considered a “warning” since if the vote has been concluded, then the reminder will not be set. The BPEL oriented process had to stop the voting, and then go back and restart the voting after the warning, but that is not necessary when the voting node can send reminders without stopping. Even the nodes for the issue manager can have warnings and reminders if the issue manager goes for a time without taking care of the task.

What is this Human Process good for? By showing the process, you see what everyone is expected to do. At each step in the process, a person is told that something must be accomplished, and given a set of choices. The diagram is oriented around what it is that people do, not what bytes are sent and receive. As such it is useful for explaining what will happen next in the process depending upon which choices are made. This is useful for training people, and it is useful to display the current running status of the process instance to people. But some will point out that it is not complete; it does not contain a representation of all the automated actions. This is true, but no process map is entirely complete. For example, the process variables are not displayed in either the BPEL oriented process, or the human oriented diagram.

What Does All This Mean?

The key point I am trying to make is:

above is a specific process modeled in BPMN, but the way that you model in BPMN depends upon the methodology you use, and the underlying technology that will support the process

There was a desire for BPMN to represent the Universal Lingua Franca of business processes. If you want a particular process, then just draw the diagram in the one true univeral BPMN way, and you will will be able to run that on any engine. But that only works if the engine you are using matches the capabilities you had in mind when you designed the process. A BPEL engine, for example, allows you to send and receive data, and so your model is always around sending and receiving of data, which is useful if that is what you want to do. But many people want to model what humans do in an organization, and modeling humans as sending and receiving data is quite uncomfortable.

BPMN is a great notation standard. Still, implicit in that BPMN diagram is a set of assumptions about the underlying engine that the process will run on. Perhaps more importantly, the diagram is designed to communicate a particular thing to a particular audience. If you want to communicate to people, you will draw the diagram one way, if youwant to communicate to software developers, you may find the need to draw the diagram a different way. BPMN was designed to be used in both these domains, and still offers a great service that at least we have a set of symbol which if used consistently will be readable by everyone.

With all the talk about “Human Facilitator Processes“; what actually does a real one look like? The best documented example of a human process is provided by the OMG known as the “Trouble Ticket” scenario. You will find at the following OMG site address:

http://www.omg.org/docs/bom/98-02-09.pdf

This is a process to allow a software company to handle a customer support issue. This issue might be handled by the customer support team directly. If not, it is forwarded to the QA team for validation/verification and possibly handling the issue there.  If it is a real problem in the product, it is referred to the development team for a fix. Before the process is complete, there are steps to assure that the customer who reported the problem gets the final resolution.

This is not a toy process like most of the example processes used in the various specifications. It is a real process that provides a complete important business function. While it is a simple process performed by people, it is important to support this with a process system because a business can not afford to lose track of customer issues.

If we follow the methodology for a human process, we start by identifying all the of the activities that are performed at points in the process. Please use the above specification for a detailed description of the process, but let me include below a summary of the activities involved:

Activity 1: Recording the Problem. Someone takes responsibility for making sure that no matter how the customer reports the problem (telephone, email, tin-can-and-string) the problem gets entered into the system.

Activity 2: Reproduce the Problem. A second person takes the description given and makes sure that the description is complete.

Activity 3: Correcting the Report. If the description was not complete, it goes back to the person who entered it to fill in the missing details. This is a sort of quality-loop on the report itself.

Activity 4: Identifying the Problem and Resolution. Development gets involved here to clarify what is happening, why it is happening, if it is a bug or not. If a fix is needed, then a new build may have to be produced.

Activity 5: Verifying the Resolution. QA gets involved again to second check that that the described problems was actually fixed.

Activity 6: Communicate Results. Regardless of how the issue was resolved, it needs to be communicated back to the customer in a way comfortable to them.

Activity 7: Audit and Record. This is a summary step in the process that allows the company to keep track of how things are going and possibly identify troublesome trends.  (It is true that many good products today automatically capture this, but this process was created 10 years ago, and I prefer to keep to that documented process, than to deviate and have to document the process again.)  Activity 6 and 7 are started in parallel because it does not matter which order they are performed in.

There are three main roles:

Customer Support: most likely a person who answers the phone when the customer calls, but they receive the communications by email or other means. In some cases there will be a specific support person assigned to each customer. Customer support performes activities 1, 3, and 6.

QA: The Quality Assurance team is providing two functions. Being relatively expert in the particular product, they are acting to resolve issues quickly without involving development when the problem is a known problem. If a fix is required, then the fixed version is tested to assure that it solves the exact problem that the customer reported. QA performs activities 2, 5 and 7.

Development: The people involved in the design and maintenance of the product, and the most expert on the product itself. While Customer Support and QA try to shield the developers from customer issues, ultimately the issues will come to development if not solved otherwise. Developers perform activity 4.

We can draw up the process and all the dependencies between activities in a BPM diagram using swimlanes to organize the activities for a particular role:

Click on the diagram to see a bigger version. The colors and shading is not strictly standard BPMN, so some of you may be interested in the BPMN classic view of the same process:

The first thing you might notice is that there are lots of branches, but very few branch gateway nodes. Instead, the activity is provided with multiple outbound arrows. Each arrow corresponds to a way that the activity can be concluded. This is, quite literally, the choice of the person performing the activity. Take a look at “Reproduce Problem”. You can see quite clearly that the performer of this activity must identify one of four significant conclusions: “Reproduced”, “Cannot Reproduce”, “Known Solution”, or “Duplicate”. It is very easy to see where the process goes depending upon which choice is made. The process designer can draw this directly on the process, without having to write scripts and conditional statements that test variables and branch depending upon values that have been stored in the variables. I have more on this in the “Multiple Conclusion Controversy” below.

Second, you might noice that there are a lot of implied loops. The “Reproduce Problem” step may determine that the problem is not reproducible, so the activity for “Correct Report” is activiated. The customer support person will add additional details and then send it back to QA to “Reproduce Problem” again. If QA still can not reproduce the problem they might again send it to the “Correct Report” problem. It could be passed back and forth between these people any number of times. In reality of course these are people performing the activities, so if it goes too many times they are likely to take steps to find out why it is taking so many step, or possibly to escalate to management. A similar loop exists between QA and Development when they don’t actually fix the right problem. Each of these loops represent a kind of “Quality Circle” where people are performing checks, and sending it back if not found acceptable. It is an easy way to model this fairly natural interaction between people.

Every activity is a facilitated human activity. This diagram is useful to explain to a customer support person, what other people will be doing in response to a customer issue. This diagram help people understand who else will be involved in response to particular decisions, such as whether the problem is reproducible or not. We can assume that there are also other automated computations, calculations, service requests, etc. involved in the process, but displaying them on this chart would make it more cluttered and harder to read, and therefor less useful for training people for how they are going to interact. Some people, though, will point out that this process is not “complete” because it does not include all the automated activities.

Multiple Conclusion Controversy

Let me address a comment that I often hear from people about BPMN processes who feel that “If a process has a branch, it should use an XOR gateway. It should not use two arrows coming out of an activity to branch.” This argument is based on the idea that activity nodes should be exclusively about performing actions, and gateways should be exclusively about the flow through a process.

The above Trouble Ticket process can be redrawn to use only XOR condition nodes to branch the process. It would look like this:

Compare this one (full size) with the original. There are three reasons why this is less satisfactory.

1. The diagram is more cluttered. Remember this is a simple process with only seven human activities. There are many business processes with many times this amount. The more nodes on the screen, the more visually cluttered it is, the harder to glance at and discern the meaning. The real question though is whether the addition of the XOR gateways actually makes the diagram more meaningful. Or the converse, if I remove the XOR gatways, how is the diagram less meaningful? The addition of the node (in my opinion) adds no extra value to the diagram

2. With the branch separated from the activity, it is far less clear why the process branches at this point. It could be because the human choice, or it could be anything else. You won’t know until you inspect the hidden metadata about the branch. Some branch nodes will the “data based” and some branch nodes will be “choice based” but that is not clear from the diagram. The “data based” branches must remain XOR gateways, but making the lines come straight from the activity make it entirely clear that the branch is because of the choice of the person performing the activity.

3. Part of the activity is to classify the result of the activity into a distinct number of “conclusions”. With the branch separated from the activity, it is less clear what choices the person has at that activity. You would be required to follow the lines out a ways. Consider the “Reproduce Problem” activity. If the lines instead come directly from the activity, it is clear that there that activity involves exactly four choices.

In conclusion, a simple rule that all process branching should occur at gateway nodes, causes diagrams that are lower quality and harder to read when it comes to human processes. When someone is trying to “automate” a process, the actions tend to be separate from the branches, but when someone is trying to “facilitate” a human process, it is more natural to remember that people often both do an activity and make a decision at the same time. For human processes, there is a huge advantage to incorporating the decision (choice) directly into the activity beacuse the process designer can simply draw the choice, and let the system deal with the details of capturing this choice from the user. This is again another difference between process automators and human process facilitators.

Conclusion

Find more on the trouble ticket process at:

http://www.kswenson.com/wiki/Wiki.jsp?page=TroubleTicketScenario

We need to start using a real human process fo revaluation of whether the existing BPM standards make sense. This standard process is documented and published. The diagram that I used in this article was created in TIBCO’s studio process designer, exported to XPDL, and then imported into Fujitsu’sInterstage BPM process designer, and an example of the kind of interoperability that you can expect today. The XPDL is linked to the page above, if you are interested.