Strategy and Tactics in Standards Development

I like to play chess.  Over the past couple of years though, instead of playing chess, what I've been doing is solving chess problems.  My wife this morning asked me how I solve the problems ... can I see the answer to the problem in my head, or do I do something else first.  It depends actually.  Some problems the answer is fairly obvious, I see a particular weakness or pattern on the board, and the solution is pretty obvious, even if a few moves deep (three or four at most).  In other cases, while I can identify a weakness I want to exploit, I cannot see the full solution immediately.  But I can often find the first move, and as the board unfolds, the remaining moves become more obvious.  When I struggle, I fall back on trial and error.  I make a move, and either it is the right one, or it isn't.  Eventually, I solve the problem, but this is perhaps the most frustrating and least satisfying way to solve the problem.

In developing standards, the same thing is true.  Sometimes you can identify the solution pretty quickly, the strategic objective is obvious, and the tactics just fall into place.  At other times, the strategy is identified, and the tactics unfold as you start to head in a particular direction.
The results depend on the two components: Whether you chose the right strategic objective, and whether your tactics addressed those objectives.  Let's look at a couple of cases:

The Direct Project

The strategic objective of the Direct project was identified as creating an "on-ramp" to health information exchange.  SOAP-based exchanges were rejected because they were too complex to solve the problem.  The tactics shifted towards SMTP, and we now have an e-mail based on-ramp for health information exchange through Direct.  In this particular case, we have a tactical success, but most would probably agree that Direct strategically was a failure.  The original desire of some of the project initiators was actually a RESTful health information exchange API, but as a strategic goal, that couldn't happen because the necessary infrastructure to support the tactics associated with that didn't exist at the time Direct was created.  Subsequent initiatives, such as FHIR and IHE's Mobile Access to Health documents profile better addressed the "simple on-ramp" requirements, and are being evolved through the Data Access Framework project to achieve a better on-ramp.

Mobile Access to Health Documents

IHE's Mobile Access to Health Documents profile was looking at addressing how to simplify edge connections from mobile devices to better support information exchange.  Tactically it was in a better environment.  The infrastructure to support the necessary tactics for this profile were under development in FHIR, and what IHE had to do was simply execute on profiling the right components of FHIR.  We had to wait a little bit for FHIR to be more complete, and so the tactics weren't clear from start to finish until later in the profile development.  Again though, I think few would argue, that given the environment that we are in today, the tactics, given the identified strategy are fairly clear.

BPMN Whitepaper

The BPMN white paper (was previously an appendix, but we've changed scope a little bit) identified a fairly clear strategy: Enable automated development, implementation and testing of IHE workflow profiles.  Tactically, BPMN is the right solution space for this work, but the evolution of our implementation is a bit challenging.  I'm bogged down a little bit in the tactical details right now. There are a number of issues that I need to address, and unfortunately, there are at least two and possibly more different ways that those could be resolved, some of which are supported by existing tools, and others which are not.  So, trial and error needs to come into play.

In war and chess games, strategy and tactics problems are unforgiving.  If you miss the strategy or the tactics, you wind up with a loss.  In standards development, it's not quite the same situation.  We can learn from our mistakes, and while past failures may be disappointing, they aren't all or nothing losses or successes.  There are always opportunities for do-overs and refinement.