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 implemented.in 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).

   Keith