Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, August 12, 2008

The making of sausages and standards

Laws are like sausages, it is better not to see them being made. -- Otto von Bismarck.

I sometimes feel the same way about standards. My best friend and I have been in software for more than 25 years. For more than half of that time, we've been working together, at four separate companies (and not just name changes or purchases, counting those, it would have to be 7 or 8). He's always been the one too see two sides of any argument, to drive consensus, and adeptly manage people (including me). I've always been, well, as he describes it "A Cowboy", or as I do, a tilter at windmills. I can tell you that I've knocked down a windmill or two, but that many others have won. Today, my friend is writing code for his own company for too many hours a day at his kitchen table, and I'm deeply involved in standards, and much to both our amazement, "Politics" (the word is often said from one side of the mouth, and then you have to spit afterwards).

Those who understand the strategic importance of standards to their organizations have involved their best leaders in these activities. That sometimes make standards development and selection a political process, and it has more than occasional skirmishes. I can think of about 4 or 5 offhand going on right now, without even blinking. Some of these are fairly mild, and others are real battles, and at least one is on the verge of war. Often these battles are held in areas populated by a number of rather innocent, and sometimes even, totally unaware bystanders.

Slightly more than a decade ago, I participated in my "first" standards activity. I was a member of the interest group for the W3C DOM2 (Document Object Model). The company I worked for had many people involved in W3C activities, include the product manager for the product team I led. She used to regale me with stories of the battles between two of the major players on how DOM2 would go, and which of their implementation feature sets would become part of the new standard. When two 500 pound gorillas have a dominance fight, everyone better clear some space. Her descriptions of the (dare I call them) discussions were reminiscent of scenes from Bloodsport, although not at all physical.

There are three ways of dealing with difference: domination, compromise, and integration. By domination only one side gets what it wants; by compromise neither side gets what it wants; by integration we find a way by which both sides may get what they wish. -- Mary Parker Follet

Often, one way to resolve these sorts of disputes is to make sure that neither of the gorillas win. Both are often willing to agree to a "draw", as neither gains any advantage from the outcome of the battle. But what about those not directly in conflict? Like most bystanders, they more than likely lose, at the very least valuable time, and in some cases, a chance to make a truly good choice.

Another way to resolve these sorts of disputes is to look very clearly at both sides of the issue, and try to craft a solution using the best aspects from both sides. When this does occur, the collaborative process really shines. This synthesis produces something advantageous to all, and we are no longer playing a zero-sum game.

What I learned from those days was that standards discussions that are motivated by financial incentive and not based on technical merit are to be avoided at best. If they cannot be avoided, then at the very least, financial motives should be very clearly laid on the table. In many organizations, there is a taboo on discussing practical realities such as cost. However, these considerations have a significant impact on the utility and uptake of the standard. We need to find ways to discuss the topic of implementation costs openly, and not hide debates related to that topic in some other guise.

Some questions I use to tackle this topic follow:

  • Can it be implemented with open source tools?
  • Can it be implemented with commercially available tools?
  • Is implementation of this a senior project, a doctoral thesis, or a massively funded effort?
  • Can I hire software engineers from any field to build it, or do they need to be specially trained?
  • Can I buy a book on it?
  • Can I take a class on it?
  • Does it work with existing infrastructures, or will I have to rip and replace?

Later in my career, I entered healthcare and the realm healthcare standards. I found myself unwittingly not just in the middle of another battle, but as the field general in a war. This was a highly political disagreement between a pair standards organizations that I was a member of. Tactically, I believe that battle to have been concluded successfully, and the peace treaty seems to be holding. Strategically, I think it's still being fought, but as a rather meager guerrilla action. I know I'm not paying much attention to it these days. I learned a great deal from that war.

  • Pick your battles.
  • Stick to your principals.
  • Respect the opposition.
  • Religious battles are never won through logic.
  • Persistence Pays

Pick your Battles

The technical work of standards development is time consuming enough, as anyone participating in it well knows. Fighting political battles takes time away from those activities at the very least, and often you wind up with nothing to show for it. In a world where you see the same people involved in many places, making an enemy in one place is something that can follow you around to many others. You don't become a target alone, but so does anyone else associated with you.

Stick to your Principals

Make sure that your issues are openly aired and debated. If there is something that you are unwilling to talk about, consider your motives. You never want to be put into a position of being embarrased by having your motives either questioned or exposed. If you cannot be shamed by that, then you can never lose from embarrasment.

Secondly, fight clean. Stick to technical merits. Avoid falacious arguments, ad hominem attacks and other dirty tactics. Standards development is a long process. What you lose from fighting dirty (even if you win) will stick with you for a long time, and can make future debates even more difficult.

Respect your Opponent

Act as if your opponent in any debate has good reasons for their position. Try to see those reasons. Remember what I said about trying to make sure that you aren't playing a zero-sum game. Learn how to agree to disagree, and then go eat sushi (or have a beer). Standards work is best done with people that can respect others with differing opinions. Mutual respect often allows all parties to find win-win solutions, and we can all benefit from that result.

Religious battles are never won through logic

Never try to teach a pig to sing; it wastes your time and it annoys the pig.
-- Robert Heinlein

Just about everyone I know who is involved in healthcare standards has a deep passion for their work. When that passion overrides intellect, useful discussion often ceases. Be aware, and don't engage yourself in the same mistake. If you find yourself trying to preach to the unconverted, and aren't succeeding, stop. You might very well be wasting the time of both parties, and worse yet everyone else around you.

In this particular field, everyone I run into is an expert, with credentials out the ying-yang. I've discovered that's really meaningless. Don't trust your gut. Try it out. What really counts is what happens when the paper hits the code. In your own arguments, stick to technical merits, and not your opinions, others can usually discern fact from opinion.

Failing that, if you have encounter a religious debate, there are at least two useful strategems:

  • Identify the topic as being one that is "unresolvable" and work on other aspects (agree to disagree).
  • Identify the topic as a pre-established "religious" debate that experts have been arguing about for X or more years, without any resolution. This tactic works only if your opponent is unwilling to move at all, but you are.

You can usually identify a religious debate by noting two polarities (x vs. y or black vs. white), where neither has yet dominated, and where expert opinion may still be divided on the topic. In these issues, the beliefs of both sides are often well documented. The document vs. message debate in computing has existed long before HL7 ever showed up on the scene. The element vs. attribute debate in markup languages has been in existence for 20 or more years. No solution to either of these debates has yet proposed itself. Most experts these days agree that there are places for each. Putting yourself in a position of espousing "one true way", when in fact there are many, is simply asking for failure. Who after all, wants to be associated with a radical?

Persistence Pays

In the end, being persistent counts.

One man scorned and covered with scars still strove with his last ounce of courage to reach the unreachable stars; and the world was better for this.

-- Don Quixote

P.S. I'll return to the topic of Genomics and Structured Family Histories soon.


  1. Keith, as I listen to your voice on the HITSP Leadership call, I'm extremely conscious of the fact that you've come by this knowledge in the best and rarest way -- by fighting your way to becoming a strong, communicative leader.

    Everything you've posted here is correct, acessible and extremely important and I profoundly hope that an awful lot of people read it and understand just how true it is.

    I have an arsenal of key terms and tools that might enhance the message, but I don't know that they're necessary.

    For example: When you talk of the three ways to deal with difference, I'd suggest that there are in fact six and that they exist in four quadrants along the X-axis of "how many people win" and Y-axis of "directive vs collaborative"-- and here are the alternate words for them:

    1. Lose-lose, but situation is resolved collaboratively: Compromise (everyone loses something and no one gets what they really want)
    2. Lose-lose, but situation is resolved non-collaboratively: Failure. Funding is pulled and project is restarted with a different set of premises.
    3. Win-lose, non-collaborative: "Direction" Someone with authority decides what the best path going forward is. Some people win, others lose, and the battle will rage again next time the topic is breached, but at least the project can be finished.
    4. Win-lose, collaborative: "Picking your battles" - Some people give up what they want so that other people can win, and hopefully their sacrifice is recognized and other people later on are willing to give things up in turn.
    5. Win-lose, semi-collaborative:
    "Bulldogging" Some really persistent people carry on the battle until they win. We both know quite a number of people who use this tactic and it IS effective in the short term -- but damaging in the long-term and requires a great deal of emotional and communication maturity to pull off without adversely affecting collaboration.
    6. Win-win, collaborative: Consensus. All parties set aside their differences and work together to find an entirely new solution that meets needs creatively.

    That last one is generally considered an ideal in that it is rare enough that few people believe it is possible, but also so completely effective in the short AND long term that it is worth working towards.

    Personally, I know that consensus is possible and frankly I believe that you have the raw skills necessary to drive consensus. The techniques required are easy to learn and frankly you've outlined the basic and intermediate knowledge required in your post.

    If you ever want some detail on the advanced ones -- let me know and I can bring you some of my toys when I see you next. It's not rocket science, it just takes the sincere dedication to collaboration.

  2. What I find interesting is mapping these six variations into different kinds of games described in game theory. Win-lose games (called zero-sum games), have a number of different strategies which can be applied, based on what you know or don't know about the choices of other game players. Win-win solutions don't exist in a zero-sum game, you have to look to different kinds of game play. What makes this interesting is that HITSP chooses standards, and so it would appear to be the case, almost always, that you have to play a zero-sum game. But its real role is to harmonize standards, and thats where we need to figure out how to change the game that is being played.

  3. I bet between the two of us an a few other usual suspects we could figure it out. Maybe over beer in Chicago next month...