Friday, September 25, 2009

Demystifying SAEAF...maybe (SAIF)

The HL7 ARB and its CIO have mandated that we will use the (Services Aware) Enterprise Architecture Framework within HL7 to improve processes within the organization and to make our specifications the widest the industry.  As a Cochair of the HL7 Structured Documents TC, it was pretty clear to me in Kyoto that we (SDWG in HL7) would need to make the next release of the HL7 Clinical Document Architecture project one of the Alpha projects for this new framework.  Nobody yet knows what this entails, but Austin Kreisler and I dug into this last night over dinner.  As I read through one of the presentations made by the ARB to several workgroups in HL7, I began to understand what it is.  We prepared a presentation based on that understanding for HL7 Structured Documents that was presented this morning, and spend a good bit of time talking about the SAEAF goals for CDAR3

I am now sharing some of my understanding here.  My sole purpose in leading the charge for this in HL7 is that I know that the blow was coming, and it is far easier to deflect it or redirect it if I lead into it.  Having worked through the example, I think one of the key problems that we've had in understanding this is a problem in how the information has been communicating.  I'm hoping to address some of those issues here.
Here's what I've learned thus far:

The key to implementing SAEAF in HL7 is in understaning the matrix which describes the different content that needs to appear (or not appear) within an HL7 standard.  The matrix appears below:
Now of course, it has to show up using all of these terms that only Enterprise Architects understand, and I don't have twenty years of enterprise architectural experience to understand it, and neither does most of the existing audience in HL7, never mind the audience we left behind.

However, after about an hour of reading (a lost art in this world of powerpoint), I began to understand what they (the ARB) were getting at.  It doesn't require an understanding of RM-ODP (although it helps), enterprise architecture, or all the current buzzwords around Service Oriented Architectures, or Architectural Frameworks.

What it does require is to answer twelve key questions about what you are developing as a specification.  Those twelve (3 x 4) key questions revolve around what I call the dot product of seven key concepts (3 + 4).  Ed Note: The dot product of two vectors (column and row heads) is the sum of the products of all terms in each vector.

The first three concepts deal with levels of abstraction:  Conceptual (20,000 feet), platform independent (conceptual after the first level of analysis), and platform dependent (realization of the analysis).  The next four concepts look at different viewpoints (areas of concern or perspectives).  These are the business perspective (which should need no further explaination), the information or semantic viewpoint (the specialist perspective, in this case, healthcare), the computational viewpoint (in this case, what we used to call the systems analysis perspective), and the engineering viewpoint (or programmer's perspective).  I may be somewhat off-base in my own analysis of what these particular viewpoints are, but that is because I'm not someone whose up on all the latest terminology here, however, this is close enough to start with.

So, an HL7 specification needs to indicate what it provides (or doesn't provide) for this dot product of the abstraction levels and the perspectives.  This needs to be explicit for each product of HL7, so that we are clear upon the product boundaries.  Asking the question is important, even if the answer is "no, we provide nothing here".  It gets the workgroup to think about that component, to see if there is something we should provide, and if not, who might actually be providing it for us (for example, one workgroup might not have an implementation if all they are providing is a functional model and requirements, whereas another workgroup might implement functional models produced by the first).

The next step is to ensure that the specification clearly has done the appropriate analysis to define the scope of work to be peformed.  This then needs to be reviewed (e.g., by a review board that checks that the results make sense architecturally) and verified.  The next step is to start developing the various artifacts.  Now, the results of each of these tasks is going to be targeted at individuals with specific skill sets.  The conceptual business level artifacts are going to be targeted at project sponsors, those responsible for understanding high level requirements and making funding decisions (C-levels, product managers, et cetera), whereas the engineering and implementation level artifacts are going to be targeted at application developers.

This results in a second matrix, which I show below.  I think this matrix will be much more comprehensible for many,  because it is buzzword free, and uses terms that should be comprehensible to most of the HL7 audience.  If I didn't get it right, please let me know.  The basic concept of this diagram is to identify the target audience for each of the different components of the dot product.  The importance of understanding who the target audience for each of these components is that it helps us establish whether we've hit or missed the mark with the different parts of an HL7 specification when it is evaluated.

Now, I'll provide a caveat.  I have no clue how close I've hit the mark with my own analysis of the SAEAF matrix that the HL7 ARB has produced.  I'm more than happy to hear your feedback.

Another realization that I had two nights ago while discussing SAEAF with some ARB members is that we need some way to measure our success or lack thereof with this work.  I think it would be very helpful for the ARB to pick a few key past projects from HL7 and, using the project scope statements, identify the architectural artifacts that they expected the project to produce, and THEN evaluate the results of the project.  It might be useful to look at three together as a group initially to identify objective criteria that could be used in a real evaluation.  Then the reviews should be undertaken by people (more than one) unfamiliar with the projects doing the first and second evaluations (it might be interesting to see how those who are familiar with the projects do compared against those that aren't).



  1. It seems like a good summary of the HL7 EAF - there is a lot of value in the EAF - and it is being rewritten to be understandable by mere mortals. See also where I discuss some other issues related to Interoperability paradigms that may be resolved by the EAF.

  2. Thank you for this article.

    I wonder how SAEAF differs from frameworks used in other industries and how a specific one for HL7, and healthcare in general, is helpful. What can we learn from other industries' sucesses and failures?

    The boundary between what is and isn't healthcare is fuzzy, especially from a consumer's viewpoint. So I wonder how the business viewpoint in SAEAF incorporates consumers' various information interaction needs.

    Your point about baseline measurements is well-taken. It is hard to assess improvements without it.

  3. This comment has been removed by the author.

  4. You’ve come up with a concise, comprehensible overview of SAEAF—I’ll be referencing it.

    A few comments:

    - "business perspective (which should need no further explanation)"-- the term "enterprise/business viewpoint" is defined in RM-ODP as being "concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part." Depending on the topic/domain, I think that specifying the roles played by the system in its organizational environment at the right level of abstraction can be challenging and non-obvious.

    - a NASA and JPL team using RM-ODP to design a Space System Architecture chose to rename the "Computational Viewpoint" to the "Functional Viewpoint". As Keith implied, "computational" is used as a "term of art" that is likely to be misunderstood by much of the audience. I would like to see SAEAF use "Functional Viewpoint" instead.

    - I liked the concept of the second matrix a lot. I would suggest using row headings of Business Viewpoint, Information, Functional and Engineering. The Analyst heading made me think of a target audience role (which is captured in the column cells under the heading), rather than a viewpoint of that target audience "which defines distribution through functional decomposition on the system into objects which interact at interfaces".

  5. For reference, the multi-perspective / multi-view approach (where "view" and "perspective" are orthogonal, not synonymous!) derives from the Zachman Framework (good overview article in Wikipedia with links to efforts in other domains, such as the US Treasury Enterprise Architecture Framework, and the DoD Enterprise Architecture Framework).

  6. It is good news that HL7 is finally starting to organize around the analysis processes needed to support real organizations. The first difficulty for HL7 applying this model is to pick the "Enterprise" that HL7 needs to support (which includes specific governance policies, finanical business models, etc.

    Just some background information...
    1) This whole model was popularized along with OO Analysis in the 1994 by Ivar Jacobson, "The Object Advantage: Business Process Reengineering..."

    2) Skill sets required: Today, one must understand OO Analysis of organizations in addition to OO software analysis in order to be an enterprise architect. Few people have enough familiarity with both sides of that skill set to effectively write specifications based on enterprise architecture "perspectives" using the IEEE Std 1471 and the supporting ISO 10746 (RM-ODP) specification standard.

    So, the challenge for HL7 in using enterprise analysis modeling standards is picking the "enterprise" that HL7 wants to model. In healthcare, will the "Enterprise" be the NHS, the NHIN, the Canadian provinical government, or some other abstract "merged model" enterprise that attempts to represent some aggregate of what happens internationally?

    In any case, it is good to see HL7 engaging more fully in standards-based efforts occuring outside of HL7!