ServiceTechMag.com > Archive > Issue LVIII, January 2012 > The Service-Aware Interoperability Framework: Making Cross-Boundary Interoperability a First-Class Citizen
Charles N. Mead

Charles N. Mead

Biography

Dr. Mead has over 35 years of experience in digital signal processing and algorithm development, complex software systems and architectures, and healthcare and life sciences informatics. Dr. Mead has experience in clinical trials methodologies and data management systems, application of the Unified Process, and fundamental healthcare and life sciences informatics issues including terminology management, application of the Health Level Seven (HL7) Reference Information Model (RIM), use of Clinical Data Interchange Standards Consortium (CDISC) standards such as SDTM and ODM, the JANUS data model, and Oracle's HTB development framework. Dr. Mead currently is Chair of the HL7 Architecture Board, past-Chair of the Open Health Tools Architecture Project Team, and a member of the CDISC Board of Directors.

Contributions

rss  subscribe to this author

Bookmarks



The Service-Aware Interoperability Framework:
Making Cross-Boundary Interoperability a First-Class Citizen

Published: January 19, 2012 • Service Technology Magazine Issue LVIII PDF
 

Abstract: The HL7 Architecture Board (HL7 ArB) has just released the specification of the Canonical Definition of the Service-Aware Interoperability Framework (SAIF CD). The document defines a set of languages that enable component developers working in any one of the established enterprise architecture frameworks – TOGAF, Zachman, RM-DOP, etc. – to more consistently and explicitly define appropriate details of a given component (a service, a message, a document, etc.) that is involved in one or more "cross-boundary" (intra- or inter-enterprise) interoperability scenarios. Specifically, the SAIF CD defines a set of languages for describing Informational (static) and Behavioral (dynamic) semantics from the perspective of interoperability. The various languages are ultimately instantiated in organization-specific SAIF Implementation Guides (IGs). As such, the SAIF CD and its derivative IGs are not meant to be replacements, but rather adjuncts, for existing architecture frameworks. In addition to the Informational and Behavioral languages, the SAIF CD provides a framework for collecting various artifacts based on applying its languages across multiple Dimensions viewed from several Role-based Perspectives. At its core, the SAIF CD draws heavily on a number of the SOA Design Principles and the SOA Benefits and Goals of Thomas Erl's previous publications. Finally, it provides a Governance Language that is based on the SOA Governance Framework defined in Erl's recent book on SOA Governance [REF-1].


The video presentation that accompanies this transcript can be found at the Arcitura YouTube channel (www.youtube.com/arcitura) as follows:

Video Part 1, Video Part 2, Video Part 3, Video Part 4

The following is a complete transcription of these video recordings.



Introduction

So hello to everyone, my name is Charlie Mead. I am the chair of the HL7 or Health Level Seven Architecture Board [REF-2], and I’m here to talk a little bit today about the Service Aware Interoperability Framework – or as we call it SAIF – and, in particular, what I’m going to be talking about today as we move forward is the Canonical Definition of what SAIF really is and about what happens to that Canonical Definition as it is instantiated in particular organizations.

First, I probably need to give a little bit of background. HL7 is an international Standards Development Organization (SDO) that you can probably tell from the name, has to do with health care interoperability. But SAIF actually has nothing to do with health care; it has to do with interoperability.

In particular, SAIF is a framework for talking about interoperability across enterprises, so not only intra-enterprise, but also inter-enterprise. The whole motivation for SAIF was the notion that enterprise architecture framework per se – so Zachman, TOGAF or RM-ODP, or other enterprise architectural framework – don’t a priori make interoperability (in particular cross-enterprise interoperability) a first-class citizen. The fact that this work came out of HL7 is really simply because health care interoperability is a very very big and important issue for HL7 members and their stakeholders.

However, there are two URLs which I hope will be supplied by this discussion, and those two URLs are interesting in the sense that they point to two organizations, HL7 Architecture Board being one, the Oasis [REF-3] Service-Oriented Architecture Group being the other. As it turns out, they were working in parallel on very similar aspects of interoperability and though our – HL7’s Service-Aware Interoperability Framework (SAIF) Canonical Definition [REF-4] (which is what I’m talking about today) – is certainly not identical to their Reference Architecture Foundation for Service-Oriented Architecture, there are striking similarities. We are now co-referencing our documents because we both believe that when two organizations come to pretty much similar conclusions independently, that’s worth noting.

So with that in mind, we will start to go through the slides. There are a fair number of slides, so I will go through some very quickly and some other ones I will spend a little bit more time on assuming that you will have access to the slides for examination at your leisure should you so desire.


Why Interoperability is Hard

So, first let’s talk about why interoperability is hard. I’m sure everyone listening to this or at least most people listening to this have had experience with integrating systems across boundaries. And as the kind of interoperability you’re trying to achieve becomes increasingly complicated, the difficulty of making the interoperability actually happen turns out to be increasingly difficult. I think if you had to summarize at a high level “why is interoperability hard?” these two bullets at least do a reasonably good job of pointing out some of the major issues.

As you cross different boundaries, there are different levels of understanding and different kinds of things that need to be understood – and certainly some types of interoperability are harder than others and that has to do with whether you want computable semantics or if you just want syntax. Secondly you must understand the breadth of the deployment context – exactly what are you interoperating across.

In the end, we’re talking about managing complexity. And I think if you look at a particular interoperability scenario and you ask “why did this interoperability scenario fail” – again not every scenario fails for the same reason – there usually is at least one or two of these three points.

The first point – the fact that there are no common technology standards – is probably the least important actually, while the next two are more important (i.e. that implicit assumptions that occur at multiple levels of the discretion don’t get made explicit until it gets out on the wire at runtime and of course everything’s made explicit at runtime). And then also, there are not a lot of formals ways to coordinate communication and explicitness between levels of stakeholders because of course stakeholders have very very different views, all the way from high level business use down to developer or tester mechanics.

The view that I use, and have used for quite some time, about how to describe a complex system – because I think interoperability by definition involves a complex system or defines a complex system – is actually a view that I got from a book from a long time ago, in 1994, by Ivar Jacobson. He doesn’t have this exact picture or he doesn’t describe it exactly this way, but I give him full credit for this view of complexity, i.e. that a complex system is one that by definition has multiple levels of vertical organization and in order to produce whatever the Product of Value that that the complex system needs to produce there are processes that by definition cross these vertical boundaries. And of course, health care or health care IT and the interoperability that is involved, is a complex system. Recall, however, that I said at the beginning that the SAIF CD has nothing to do with health care IT per se. There are many other contexts where interoperability is important and if the context involves multiple levels of vertical organization with processes that need to interoperate across multiple boundaries then it is, by definition, a complex system.


Interoperability in Health Care

This is the only health care specific slide in the talk, and it is really just to point out the kind of interoperability scenarios that people in health care, clinical trials and life sciences worry about. And, in general, you can assume that any of these stakeholders can and does need to interoperate between or within the other ones. So you’ve got a fair number of possible connections of points.


Defining and Describing Complex Systems

So if you have a complex system, we agree that an interoperability scenario or a set of interoperability scenarios exist and, of course, if you think about Thomas Erl’s SOA Design Principles and you think about Intrinsic Interoperability as a derivative or result of the application of the Design Principles (intrinsic interoperability meaning we don’t want to have one-off integration scenarios, i.e. we want to actually have intrinsic interoperability that comes from well architected services) then we have to say “well if we’ve got a complex system how do we actually define and describe that complex system?”

It turns out that there is actually a fair amount of knowledge about how to go about doing that – not necessarily linked to software per se – but the examples I’ve given on the slide of course are the ones I mentioned before that are enterprise architecture frameworks that do have to do with defining complexity. And basically the general approach to defining complexity or a complex system is that it has different Dimensions and it has different Perspectives. You will see as we move forward here that SAIF is really just an explicit definition of some Dimensions and an explicit definition of Perspectives with rules on how to make those different Dimensions and different Perspectives explicit in the various cells, if you will. We’ll talk about an actual intersection device that pulls all of that stuff together.


Interoperability Specification Matrix

There is a core construct in SAIF called the Interoperability Specification Matrix. The Interoperability Specification Matrix is – as the slide says – a container of artifacts and collectively specified systems components. So in SAIF the dimensions were chosen to use RM-ODP Viewpoints. For those of you familiar with RM-ODP Viewpoints that probably makes perfect sense to you, but if you’re not familiar with RM-ODP Viewpoints it’s not actually critical. The point is to use Dimensions and intersect them with Perspectives. And we’ll talk a little bit further down the road here on what the actual Dimensions and Perspectives in SAIF are. I think the important lesson from this slide is that a) interoperability across enterprise boundaries is a complex system in and of itself and that b) to define or describe a complex system we need to worry about intersecting Dimensions with Perspectives.


SAIF Semantics and Frameworks

Now in SAIF we think about two kinds of semantics – informational or static semantics, and behavioral or dynamic semantics – and what you’ll see as we move forward is that we have both types of semantics represented as part of a specific Dimension and specific Perspective.

In the SAIF CD (Canonical Definition), there are actually four frameworks. The first one, and the one which we would argue from the overall perspective of the architecture, coordinates all of the other frameworks, and is therefore the single most important one, is the Governance Framework. The way that Thomas Erl and I came to discuss SAIF, and all that surrounds SAIF, is that I was privileged to be a reviewer on his just-published, extremely good SOA Governance book. In the course of doing that I became very much a believer in his governance framework which we’ll of course talk about later in this discussion. That Governance Framework is the basis for the Governance Framework of SAIF. There are some other aspects about SAIF that go beyond Thomas’ Governance Framework for reasons that I hope you’ll come to understand, but the core construct and the core language to describe governance in the SAIF Governance Framework is taken from Thomas Erl’s recent governance text book.

In addition there are three other frameworks. There is a Behavioral Framework (BF) that defines the language needed to specify behavioral semantics, so things like contracts, goals, operations, processes, etc. There’s an Information Framework (IF) that is for defining static semantics including information models, data types, classes, attributes, relationships, value sets, etc. And then there’s a final framework called the Enterprise Consistency and Conformity Framework (ECCF) which is associated with the Interoperability Specification Matrix and that defines the language that’s needed to really specify different component artifacts and talk about the relationships between them.


Part 2 of the YouTube presentation begins here.


Understanding the Essence of Interoperability: Shared Purpose

The essence of interoperability is not actually technical, and I think one of the things that SAIF CD really emphasizes is that technical considerations of interoperability should really follow business-level considerations of Shared Purpose. And in that sense you probably noticed, I didn’t comment on it, but the fact that SAIF stands for Service-Aware Interoperability Framework, it’s not SOA in particular. It’s certainly heavily influenced by SOA and certainly can be implemented (I would argue most successfully) in an SOA environment, but in the health care world there’s a lot of interoperability that’s based on messages and documents not on services per se, at least at this point in time (November/December 2011). But, the notion that drives interoperability – or that should drive interoperability – is Shared Purpose. I have in this slide deck a number of concept maps which I’m not going to talk through in detail because you have the slides and the video to look at the concept maps. However, I do want to emphasize the concept of Shared Purpose because Shared Purpose at a human level or at an organization level is ultimately manifested in interoperability at a technical level in an attempt – hopefully a successful attempt – to realize the goals of the Shared Purposes.


Applying Interoperability to Diverse Scenarios

I alluded to earlier, but I want to emphasize a little more at this point in time, is this notion that not all interoperability scenarios are created equal. They’re not all equally difficult. This is a sort of a rough approximation graph taken from the National Cancer Institute in the National Institute of Health where I work, and it basically points out that there are pretty much two dimensions to interoperability. And I say “pretty much” because I think there’s an almost third dimension which I’ll mention after I walk through this graphic.

The two dimensions are the Interoperability Type and the Deployment Context. Now by Interoperability Type, I mean everything from human-to-human interoperability which is fairly straight forward, to syntactic interoperability – so something like web browser based interoperability – to computational semantic interoperability which is, of course, the hardest because then you’re talking about having semantics that are both explicitly specified and computable, and they can be either static semantic, common data or metadata structures, or they can be behavioral semantics. There are more and more interesting opportunities for applying, for instance, RDF tuple/triple-based expressions of service interfaces for runtime computation of dynamics.

The point is that there are multiple and different kinds of Interoperability Types and any particular Shared Purpose scenario have to define what its Interoperability Type may be. In addition, there’s this notion of Deployment Context, and clearly the Deployment Context in part determines how difficult an interoperability scenario will be. So for any given Interoperability Type, the larger the context of deployment – as you go from single department to an organization to cross organization to across the enterprise to cross enterprise to cross multiple enterprises – the details (the devil is in the details) and the difficulty of interoperability in terms of a particular scenario becomes greater and greater.


The Third Dimension

Now I mentioned that there’s sort of a third dimension to this – and I don’t know if it qualifies as a full third dimension but I think it’s worth mentioning – and that is that if the interoperability scenario – no matter what the Deployment Context – it is really devoted to information integration. It’s mostly about static semantics and integrating static semantics. That’s probably easier than an interoperability scenario – in particular a computational one – in which you want some kind of behavioral-based application or service component integration. Those are obviously the hardest interoperability scenarios. But, the purpose of this slide is to point out that not all interoperability scenarios are the same, not all are as difficult, and the SAIF CD basically doesn’t say that you have to do everything, but it does say “here are the tools you need to do what you need to do” depending on the complexity or difficulty of the problem you’re addressing. So for simple interoperability scenarios you specify a lot less than you do for a more complex interoperability scenario. The SAIF CD is meant to provide the language necessary to describe, explicitly, interoperability scenarios of any level of complexity.

This is meant to give you a sort of cartoonish view of the fact that interoperability is always difficult, but the more you can agree on the better you can do in terms of interoperability. Remember I mentioned SAIF was formed around the notion that Dimensions intersect with Perspectives. The three perspectives in SAIF are – not surprisingly – called the Conceptual, Logical, and the Implementable perspectives – not to be confused with OMG’s MDA levels because the SAIF Perspectives are role- based Perspectives, not necessarily software engineering constructs.

Clearly, the more you can agree on the details at the Conceptual, Logical, and Implementable levels, the easier it gets to interoperate. And this diagram is meant to show that if you have one person who agrees on the conceptual perspective and another one who has details all the way down to the Implementable Perspective, then the interoperability scenario is going to require more negotiation than if you have two people who have used the same framework all the way down to the Implementable level. It’s always necessary to align expectations and assumptions, in order to achieve interoperability. It’s just a question of how difficult that alignment will be. The point is that by using the same framework from the beginning to describe complexity, you’ve got the same basic language in place. That does make explicit discussion easier to have.


SAIF in More Detail

Here is an overview of what SAIF is in a little bit more detail. It’s the intersection of this notion of computable semantic interoperability, software engineering processes (that’s where we get our Perspectives from) the Viewpoints of RM-ODP as the SAIF Dimensions. We could have used the viewpoints from Zachman or TOGAF, but we chose RM-ODP because we are a standards organization and we work a lot with ISO and RM-ODP is an ISO standard. And then we have, as I mentioned, fairly significant and deep influences from SOA and particularly Thomas Erl’s work – the Design Principles, the Governance Framework, etc. And then it’s all ultimately contextualized with this notion of shared purpose.

I don’t think for this audience that I very much need to go through what SOA or service-oriented architecture is about. This slide is really just to show what kinds of things SAIF carries with it from the world of SOA, and, in particular, it’s about the notion of behavior, contracts, consistency, separation of concerns, and of course, as I mentioned, the Governance Framework. It’s important when you talk about Dimensions versus Perspectives with SAIF that you recognize that the Perspective is really a notion about roles. It’s about different roles in the same Dimension have different perspectives and therefore they express different things in different explicit ways. And what SAIF is really trying to do is to provide language for each of those Perspectives and for each of those Dimensions.


SAIF Versus RM-OPD

These are the pillars of Computable Semantic Interoperability, and I’m not going to spend very much time on them because I figure that people who are really interested in them can either read through these, or there are some written in the literature about these Four Pillars. The point is that if you look at these pillars, each of them is about a certain level of explicitness.

Now RM-ODP, for those of you don’t know about RM-ODP, is an ISO standard – and you see the ISO standard number at the top there called Viewpoints – around which to build enterprise architecture. There’s a new book on RM-ODP. It’s actually getting a lot of traction recently. There are UML Templates for RM-ODP and several of the large health care organizations outside of the United States are now using RM-ODP. SAIF is not “just” RM-ODP.

However SAIF drew on RM-ODP for two things: it’s Dimensions, and for certain well-defined terms particularly for the Behavioral Framework. So if you know about RM-ODP, SAIF will be second nature. If you don’t know about RM-ODP, you should know that in fact you can take SAIF and apply it in non-RMODP environments very easily. In Canada, the national health program, it’s called Canada Infoway, is mapping SAIF with TOGAF, and the Department of Defense in the United States is using SAIF integrated with DODAF, which is their DoD version of TOGAF.

So here are the five dimensions of RMODP and if you know Zachman, then you’ll see they sort of look like Zachman – unlike Zachman they’re not fully orthogonal, but they serve the purpose and as we talk about the Interoperability Specification Matrix a little later in the presentation, I think the important message is to be explicit about Dimensions and Perspectives. It doesn’t actually matter where you put a particular artifact as long as you’re explicit about it and consistent about it.


A Deeper Look at Shared Purpose

And then as I come back to again Shared Purpose, Shared Purpose is the fundamental driver, and in some sense, the linkage between business level expectations and on-the-wire explicit interoperability scenarios. It is really very similar to – and in some sense identical with – one of the seven benefits that Thomas Erl mentions in the benefits and goals of SOA, which is tighter business-technology alignment. Ultimately, the Shared Purpose at the business level has to be able to be manifested at the technical level as a successful interoperability scenario.

Here’s a concept map of the overview of the SAIF CD (Canonical Definition), and you’ll see that it defines languages which support Shared Purpose semantics. You see the Governance Semantics, Behavioral Semantics, Information semantics as well as Consistency and Conformity Semantics.

The colors are meant to mean the following: blue, or turquoise, are meant to be things that are specifically defined in the SAIF CD, yellow are things that are defined specifically in SAIF implementation guides. The notion of a SAIF Canonical Definition is that there is one SAIF Canonical Definition and there are multiple SAIF Implementation Guides (IGs), each consistent with – but not identical to – the SAIF CD. The green concepts are concepts outside the domain of the IG (i.e. about the actual operational implementation, the instantiation of an implementation guide within an organization). And then the rust color, or earth color or terra cotta – however it shows on your screen – are really standards that SAIF drew on. In particular you see there the RM-ODP, as well as another important paper that really looked at RM-ODP and said RMODP needs context and that in fact is what SAIF has brought by its use of perspectives.


Connectedness of Languages in SAIF and Governance

Here is a concept map about the interrelationships between the languages in SAIF. So remember I said there were four languages: a governance language, a behavioral language, an informational language and there’s a consistency and conformity language. And the important thing about those languages is that they are related in some very specific kinds of ways which are specified on this content map. I think the most important aspect of this is the role that governance plays. And remember I said there were aspects of SAIF governance that are not explicitly talked about in Thomas Erl’s book although there’s nothing contradictory in Thomas Erl’s book to anything on this slide or anything in SAIF. But in particular, the Governance Framework has language to talk about artifact governance and it also has language to talk about community governance because ultimately when you cross enterprise boundaries you are talking about community participation and ultimately therefore community governance.


Part 3 of the YouTube presentation begins here.


This a very high level view from Open Group of governance that certainly its consistent with Thomas’ view of the world., I’m going to go through a series of slides here – if you don’t know Thomas’ view of the world of governance, I would strongly encourage you to go out and invest in the book. It’s an excellent book.
The next several slides really take that very very high level notion of governance and push it down; aligning it with Thomas Erl’s book simply because we – at HL7 within the Architecture Board and Technical Steering Committee – think that it is a very good framework. We actually think it is not unique to SOA at all, but one which we we’re able to adapt very successfully to the SAIF CD.

I probably don’t need to read through definitions of what governance is but I want to emphasize – on “What is Governance (2)” slide – is governance is an overarching set of policies about how decisions are made, how management is done, how methodology is executed – in particular governance and methodology and management need to be separated. And that’s probably the most important aspect which is shown on “What is Governance Not” . I think that it’s been very instructive to HL7 to really dig into the details – thanks to Thomas’ book – of separating out management, methodology and governance. And I would say irrespective of whether you choose to adopt some or all of SAIF, and whether you choose to indulge or invest yourself in trying to understand cross-enterprise interoperability, that the importance of governance and the importance of separating governance from management and methodology is essential no matter what it is you’re trying to govern – whether it’s IT, whether it’s SOA or whether it’s just an organization.

Okay so I’m now up to the slide that says SAIF CD Languages, and I’m emphasizing again that the governance language – the Governance Framework contains language about governance, the Behavioral Framework that contains language about behavioral semantics. It’s very important to note that the Governance Framework also has language about behavior, but its behavior is at an organizational level whereas the Behavioral Framework is really behavior at the technical level, so it really focuses on what’s happening at the interface. So there is some overlap between the Behavioral Framework terms which are specified in large part by RM-ODP and the Governance Framework terms that have to do with behavior, that are specified to some degree in Thomas’s book and other degrees by the actual SAIF CD by members of the HL7 Architecture Board. And then finally, the ECCF, the Enterprise Consistency and Conformity Framework, contains language that, at the present, scopes just to artifact governance.


Governance Framework in Detail

So now we’re going to talk about the Governance Framework in a little bit more depth. For those of you that are familiar with Thomas Erl’s SOA governance book, this will be absolute repetition because as I said at the beginning, the SAIF CD has taken the basic framework that Thomas and his coauthors describe in the SOA governance book and essentially said “this is the language” and “this is the way we need to talk about” at least certain aspects of governance. So those of you not familiar, the basic framework – what I call a governance vector, although that’s my term, not Thomas’ – defines governance vector which consists of a four-tuple of Precepts, People, Processes and Metrics.

If you drill down the Precepts component, it has its own four-tuple of Objectives, Policies, Standards, and Guidelines. In my experience in implementing a Governance Framework, both in my job at the National Cancer Institute and then working with HL7 in the Architecture Board, this actually is one of the most important aspects of the Governance Framework that Thomas Erl proposed or defined in his book because it actually gives you a very concrete way to say “Here is what I’m trying to accomplish at this point in my governance.” Governance should be about, at least in the beginning and I would argue always, is “what am I going to govern?” You can’t govern everything at once.

We must consider: How can I start without first of all freaking everybody out like some heavy-handed monster that’s going to come in the door, and second of all how can I really actually understand this governance is working? How do I know it’s making any sense?

And the way that both Thomas Erl’s text and the SAIF CD address the notion of governance or how to govern or where to govern or what to govern is governance should be intersected with risk management. So you apply governance vectors to specific points along your risk matrix. And this notion that a Precept has an Objective and associated Policies – often organizational policies or constraints, standards that you want to apply or guidelines that you’d have liked to have considered – is a perfect concrete way to say okay these are actually how I’m going to get my arms into the risk management that I’m trying to accomplish by doing governance at this point in my product development.

Then we have people – or people in roles – processes and metrics. I want to emphasize that the processes we’re talking about here are not the processes that generate the things that are being governed. These are the governance processes themselves. And if you invest in the governance book, you’ll see very well done, associated precepts, processes and people. And then, of course, metrics are the way you quantitatively assess whether you’ve accomplished a particular precept. So here is the concept map of the Governance Framework, along with the language, and you’ll notice over in the lower left-hand corner you see Precepts; you see People (Roles), Processes and Metrics. And then farther to the right you see a bunch of other things called Terms of Art. Those are additional terms that the SAIF CD finds from the perspective of cross-enterprise interoperability that are not explicitly covered in Thomas’ book in the context of governance, but certainly if you look at those terms, many of them come right out of SOA or are completely relevant to an SOA environment. As I said before, I think that the tremendous value of Thomas Erl’s book is that, although it’s very useful in the world of SOA governance, I don’t think it’s unique to SOA. It has much more applicability than just SOA.


SAIF Constructs and Frameworks

Now there are a few core constructs in SAIF and I’ve mentioned most of them. I’ve mentioned Thomas Erl’s governance framework. I’ve mentioned RM-ODP. I’ve mentioned the notion of software engineering roles – architects at the ontological level, domain experts at the conceptual level and developers being at the implementable level. Another core construct of SAIF that really does help us define in really explicit terms how we deal with shared purpose and that is Martin Fowler’s Accountability Pattern.


Martin Fowler’s Accountability Pattern

Another important aspect of the SAIF Canonical Definition specification is Martin Fowler’s Accountability Pattern. This Accountability Pattern which Martin Fowler published probably twenty years ago now is very good about specifying the notion of in any particular context where you have accountability you’ve got a Commissioning Party and a Responsible Party. Now ultimately of course that is exactly what happens at a service interface, but it also turns out to be a good way to think about Shared Purpose at the business level. So the SAIF CD really does take this notion of a Responsible Party and a Commissioning Party and the associated Accountability that goes with it and starts to be explicit about it at the Conceptual level – the business Shared Purpose level if you would – and then drives that all the way down through the Logical level, through the Implementable level all the way down to testable implementations.


Behavioral Framework

Here are a quick couple of slides on the Behavioral Framework and the core constructs of the behavioral framework which grow out of that Martin Fowler kind of Accountability Pattern and in particular have to do with services, operations and roles. And again, I’m not going to talk to you about the concept maps in detail because I’m going to assume you have the concept maps to look at and you can look at them as much as you’d like.

This is the concept map around contracts and you’ll see that contracts are constrained by policies and you have to realize the objective of community. That’s true of a contract whether it’s a technical contract or whether it’s a Shared Purpose business level contract. You’ll also notice the notion of policies and remember that policy is the second part of the four-tuple that defines a Precept; with Precept being one of the four-tuple that defines a governance point or a governance vector. So you see how the basic notion of governance is sitting throughout the SAIF CD and in fact it is very consistent that it is inspired by much of the work from Thomas Erl’s SOA governance book.

Figure 1 - Governance is Often Applied to Mitigate Risk. The GF Defines the Language to Specify Governance Vectors Based on the Framework Presented in Thomas Erl's SOA Governance Book.

Part 4 of the YouTube presentation begins here.


Here’s the Behavioral Framework concept map of operations, preconditions, post conditions, etc. Remember I said that the Behavioral Framework was restricting its governance and its definitional language to technical governance, so we’re talking about governance at an interface and of course this stuff naturally manifests itself in an SOA-based implementation.

And then finally Behavioral Framework processes, all of these, are – remember the SAIF CD is a set of languages –terms and relationships that are very explicitly defined in the SAIF CD. And then here remember I showed you this slide before, if you think about this it has to do with a certain level of difficulty in realizing an interoperability scenario. Now I would say again, it’s the degree of realizing the particular interoperability scenario scoped in a particular set of contracts that define roles, operations and processes. So that’s really, if you think about Thomas’ Goals and Benefits of SOA number one – Intrinsic Interoperability—this is another view, the SAIF-based view, of Intrinsic Interoperability.

Okay now, I said that there was some overlap between the Behavioral Framework and the Governance Framework. This is a picture of that overlap. The terms in bold are terms that are used in both languages – both the Behavioral Framework language and the Governance Framework language. And again, I don’t want to go through this in detail because you all have the document or you have the slides and then also the SAIF document is openly available.


Information Framework

Now the Information Framework. The Information Framework is probably a framework that is more well-defined in health care than most other places because much of the data that flows around health care is static data – patient data or research data or clinical trial data. And I think that for most people the notion of information modeling is probably something that everybody knows a lot about, but it’s probably not been carried, at least in many domains, to the degree it has been in health care. But you won’t see anything in here that you wouldn’t recognize if you had done information modeling, including codes, classes, attributes, data type, data type bindings, multiplicity, value sets, those sorts of things.


Enterprise Consistency and Conformity Framework

Okay now we come to the Enterprise Consistency and Conformity Framework and I want to just comment briefly on the choice of the words consistency and conformity. They’re taken from ISO very specifically and they are meant to disambiguate once and for all the difference between conformity, compliance, coordination, consistency – all of those words that we throw around and we sort of know what we mean but nobody ever quite means exactly the same thing. These terms are formally defined in SAIF but actually we’re just using the formal ISO definitions.

This is the concept map of the ECCF – the Enterprise Consistency and Conformity Framework, and probably the most important piece of this slide – remember blue is what’s defined in the SAIF CD – are the Terms of Art including, Province, Traceability, Localization, Compatibility, Consistency, Correspondence, Conformance and Compliance. The most important point to know is that those terms define how we navigate between artifacts or artifact definitions. Because remember now you’ve got a single SAIF Canonical Definition and the various languages it defines that allow you to define multiple Implementations Guides. And those Implementation Guides specify the content and representation details of specific artifacts. And then you’ve got actual artifacts that are developed using those rules in the Implementation Guide. So on this slide the blue is SAIF, which would be the definitions. The yellow is the Implementation Guide, and then the purple are the things that actually get specified, i.e. the artifact instances.


Interoperability Specification Matrix and Artifacts

Now how do those actual artifacts get defined? They get defined in the Implementation Guide and the Implementation Guide is defined using the SAIF CD. And they’re all collected in something called the Interoperability Specification Matrix. And the Interoperability Specification Matrix is in fact the physical matrix that resolves from the intersection of Dimensions – RM-ODP Viewpoints – and Perspectives – software engineering roles if you will. This is the relationship that I just mentioned of the SAIF CD. On the top there is a Type definition, and then you’ve got multiple Implementation Guides – potentially multiple Implementation Guides. There are now four SAIF Implementation Guides that are being either fully developed, have been fully developed or are being developed. They are not at all identical, but they are all using the SAIF CD as their root. And then once that Implementation Guide is defined – so it defines the artifacts that you need to specify – it defines the content and representation of different artifacts for different Dimensions and for different Perspectives. Then you actually have artifacts. That’s the set of Interoperability Specification Instances. And then from those artifacts you actually build things. You actually build actual code and that’s the purpose of the SAIF CD in the first place.


Conformance, Compliance, Consistency, Traceability and Compatibility

So here’s the walk through an Interoperability Specification Matrix. At the level of the SAIF CD all that’s specified is basically the semantics of the column names and the row names. That’s what’s specified in the SAIF CD. A SAIF Implementation Guide specifies what’s called an Interoperability Specification Template – not the Interoperability Specification Matrix itself, but an organization-specific instance of it – and it actually says here are the things that we think in our organization is going to need to define explicitly for the host of interoperability scenarios we can have realizing that not every interoperability scenario has the same level of specification requirements.

Here are the relationships that the ECCF defines, so there are Conformance Statements that are a very important part of SAIF. In the end, what you want is – I said this in the very beginning, now I’m making a point to repeat it – the number one enemy of successful interoperability is lack of explicitness. And what SAIF does is basically provide a mechanism for making explicit Conformance Statements at any level – Conceptual, Logical or Implementable – that are ultimately then asserted by pair-wise Conformance Assertions in an implementation.

So a Conformance Statement at the Implementable level can be a computable conformance statement, it can be tested automatically. At the Logical level it may be able to be tested automatically. At the Conceptual level it might not be able to be tested automatically, but it should be testable and verifiable in a Boolean sense as to whether or not the implementation was successfully able to fulfill that Conformance Statement. So Conformance Statements made in a specification and Conformance Assertions made in an implementation are essentially bound together pair-wise and then you can measure conformance.

Conformance is linked only to the relationship between an implementation and an instance and a specification. All the other relationships have to do with how you relate different artifacts to each other. So there is the notion of compliance. A compliant artifact is usually one that has some sort of restriction on another artifact – so you see the arrow there source and target – as you move up and down, either across the rows or up and down the columns, you’re always worried about compliant movement, not conformant movement.

Then you see a few other terms, e.g. consistency – so that would mean for instance that if you specified some static semantics in your informational perspective or your informational dimension, that you would want those same semantics to be consistent across the other dimensions that showed up so that if you had behavior showing up in the computational dimension you would want the static structures moved around, by say an activity diagram, to be consistent with the information structures defined in the informational dimension. Traceability (everybody knows about traceability) becomes much more of a challenge and also much more valuable when you realize what you’re tracing is tracing explicit statements that are going to support conformity assessments. And finally there is the notion of compatibility which has largely to do with making sure that localization of value sets, data type restrictions, etc. are consistent across the interoperability scenario.

Here’s a picture of the description that I just gave of the notion of pair wise Conformance Statements and Conformance Assertions. Conformance Statements can be made at any level and ultimately when you have an implementation instance they are paired with Conformance Assertions to assess conformity of an implementation instance.


Conclusion

So in summary what is the SAIF CD about? SAIF is about interoperability and the reason it is important for people in the SOA community to hear a little bit about SAIF is that SAIF really does bring interoperability up to the level of first-class citizen in an enterprise architecture which is, of course, one of the goals of SOA. And what the SAIF CD is doing is providing a set of languages for specifying the various aspects of components that ultimately affect their interoperability. SAIF is not enterprise architecture. It is not meant to replace RM-ODP, to replace TOGAF, to replace Zachman. It is meant to be used as an adjunct in any of those or any other enterprise architecture, framework or approaches that one may have. It basically focuses on and concentrates on making explicit those aspects of particular component specifications – and of course with SOA that would be a service specification – that have to do with intra- or inter-enterprise interoperability. I think that if you go through the various publications in the Prentice Hall SOA series [REF-5] that Thomas has authored and edited, what you will consistently see is that the goals and benefits of SOA Design Principles all have, in one way or another, implications in SAIF. (Some have more implications and some have less because SAIF is really focused on the number one goal of intrinsic interoperability – cross enterprise, cross boundary interoperability.) I think that concludes this discussion.




References

[REF-1] Erl, Thomas. SOA Governance: Governing Shared Services On-Premise & in the Cloud. Prentice Hall, 2011.

[REF-2] http://www.hl7.org/

[REF-3] http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/csd03/soa-ra-v1.0-csd03.pdf

[REF-4] http://www.hl7.org/permalink/?SAIFCDR1PUBLIC

[REF-5] http://www.soabooks.com/