Service Aware Interoperability Framework
HL7
Service Aware Interoperability Framework (SAIF) Introduction
Executive Summary
The goal of SAIF is to enable Working Interoperability[1] (WI); where, the biggest impediment to WI is implicit assumptions. As such, SAIF provides a set of grammars that enable developers and users of “components” involved in WI scenarios to explicitly define and govern those aspects of the component’s structure and behavior that affect its ability to seamlessly engage in a WI scenario.
Figure 1: SAIF Concept Map
The scope of SAIF is the interoperability space between business objects, components, capabilities, applications, systems and enterprises. Specifically, SAIF manages the interoperability specifications among distributed systems that may involve information exchanges, interactions and state changes. SAIF is not Enterprise Architecture (EA)[2] nor is it an Architecture Development Methodology (ADM); but instead SAIF can be used to manage an EA, such as DoDAF or TOGAF[3], and organize an EA’s artifacts into interoperability specifications.
· The approach of SAIF is to organize and manage architectural complexity with a set of constructs, best practices, processes, procedures and categorizations.
· The focus of SAIF is on managing and specifying architectural artifacts that explicitly express the interoperability specification characteristics of software components.
· The technical objective of SAIF is to create and manage easy-to-use, coherent[4] and traceable Interoperability Specifications (ISs) for systems, sub-systems, and other software components providing layers of specification abstractions from the conceptual to the platform bound, including message, document or service interoperability-paradigms.
SAIF combines four sub-frameworks, composed of grammars, for defining and managing comparable interoperability specifications.
· The Information Framework (IF) defines the grammar for information and terminology models, metadata, value sets and schemas that specify the static semantics of interactions. This includes the grammar for patterns of structured and unstructured data, documents, messages and services, quality measures and transformations. The IF defines the grammar that a SAIF Implementation Guide (IG) must follow to define information and terminology models, metadata, vocabularies and value sets that specify the static semantics for expressing concepts, relationships (including cardinalities), constraints, rules, and operations needed to specify data, data type bindings, vocabulary and value set bindings within a SAIF IG. The canonical IF simply says that to achieve explicit expression of a component’s informational/static semantics, those constructs must be formally defined. This includes specifying how they relate to each other, e.g. an information model has concepts, attributes, and relationships, where attributes are bound to a formal data type specification, value sets are bound to data types, etc...
· The Behavioral Framework (BF) grammar defines constructs to specify the dynamic semantics of interactions in an interoperability specification. The BF focus is the accountability required to achieve working interoperability. Accountability is a description of “who does what when.” Accountability manifests itself as implicit or explicit contracts at business object, component, application, system and enterprise boundaries. The BF grammar specifies accountability of system role relationships among various stakeholders, system components and applications. These relationships involve information exchanges and state changes within use case scenarios.
Collectively, the IF and BF grammars allow the interoperability-specification of business objects, components and their services, capabilities, applications, systems and their respective roles, responsibilities and interactions (e.g., information exchanges).
· The Governance Framework (GF) grammar enables an organization implementing SAIF to manage risk by relating decisions and policies, to the IF and BF interoperability specifications within the ECCF. The overall management of the life cycle of each artifact – whose content and representation must be defined in the context of a given organization’s SAIF Implementation Guide (IG) – including the correctness and completeness of the artifact as well as the IG-specified RACI relationships for the artifact – are defined by the Governance Framework grammar. The GF scope includes Precepts[5] (which are defined in terms of objectives, policies, standards, and guidelines), Roles (e.g., people, organizations and systems), Processes and Metrics. A SAIF IG should operationalize the GF grammar to cover expectations, grant authority and resources, verify performance, manage configuration baselines, etc.
· The Enterprise Conformance and Compliance Framework (ECCF) enables an organization implementing SAIF to organize and manage interoperability specifications. The ECCF is based on the well-established experience from cognitive science that has shown that complexity is best described by partitioning a complex system-of-interest into a number of Dimensions, each viewed from one or more Perspectives. In particular, the ECCF is a structured collector of artifacts expressed using the grammars of the IF and BF. The GF’s grammar is used to specify various aspects of the ECCF’s artifacts that can then be used to determine whether a given implementation of a specific component’s specification can be verified as being a “valid implementation instance.” In the context of WI, the ECCF specifications of components enable developers and users of ECCF-specified components to more tractably and predictably manage the myriad of details associated with achieving WI scenarios. The ECCF purpose is to manage the relationship between architectural artifacts and the implementations of those artifacts to insure compatibility[6] among systems. The objective of a fully qualified ECCF is to be a coherent and traceable interoperability specification, which is easy-to-use. The ECCF can be an assessment framework, which supports configuration management baselines, development status, audit compliance and risk assessments throughout a business-capability lifecycle. The ECCF can be used to specify information exchange interoperability and conformance statements for documents, messages and services. An ECCF provides a template, called a Specification Stack (SS) that allows the specification of business objects, components, capabilities, applications and system interoperability. An ECCF SS is organized as a matrix of Dimension columns (Enterprise, Information, Computational, Engineering and Technical) and Perspective rows (Conceptual, Logical and Implementable).
The ECCF is the centerpiece of SAIF. It supports both technical interoperability (IF and BF) and the GF management of interoperability. The SAIF ECCF provides external stakeholders with a coherent picture of exactly what is required to interoperate with an organization’s software components. A given component's specification is SAIF-compliant if it is compliant with an organization’s SAIF implementation guide. The ECCF IG should require "just enough" compatibility to enable the desired level of interoperability[7] for appropriate SS types. The notion of “just enough” is grounded on the combination of the complexities associated with a given component’s deployment context (e.g. individual lab, organization, cross-enterprise, etc.) and Interoperability Type (human readable syntactic through computable semantic).
SAIF Implementation
Any organization choosing to implement SAIF should assemble its own SAIF Implementation Guide (IG). An organization’s SAIF IG is the practical interpretation and localization of the canonical constructs defined in the HL7 SAIF book.
SAIF defines the grammars[8] and patterns[9] common to all ECCF Interoperability Specification Stack (SS) instances. Each organization should document how to instantiate and guide the population of its interoperability SSs. Note that just as an enterprise may have systems-of-systems, an interoperability SS may reference and be built from component SSs. Additionally, for different SS types[10], an IG may require different SS architectural artifact profiles[11]. This means that an SS for a complete solution may reference SSs for more primitive building blocks, where each interoperability SS type may contain or reference different numbers and different types of artifacts.
Table 1 is a sample template, which shows a super-set of common architectural-artifacts within an ECCF SS. As appropriate, within each cell, you might
· place or reference and discuss appropriate architectural artifacts and specifications,
· define conformance statements, which are testable-representations of the specifications,
· assert, as true or false, that one-or-more conformance statements are met
· manage traceability within columns and consistency across rows.
· do Topic Maps among viewpoints and architectural artifacts to define traceability
· do RACI Charts for each viewpoint to define stakeholder roles and responsibilities
· identify and mitigate risks across the organization’s component development life cycles.
SS maturity implies that an SS instance is coherent and traceable within-and-across the SS. SS maturity does not require complete coverage of all cells in the SS; rather, coverage should be “fit-for-purpose”. Examining relevant SS instances provides a scalable approach to assessing the risk or degree of difficulty and specific amount of effort required to enable trading partners to attain Working Interoperability.
Table 1 Notional Super Set of Common Architectural Artifacts within an ECCF SS
An IG specifies which types of architectural artifacts are required by an organization, program, project, etc. Obviously, an enterprise SS will have different artifacts than a component or business object. In Table 1Table 1, a super set of common architectural artifacts are distributed across the ECCF Dimensions (columns) and through the ECCF Perspectives (rows). “Fit-for-purpose” criteria should be used to determine the appropriate architectural artifacts for a particular SS type. Artifacts are first placed in the most intuitively obvious SS cell and then are organized to facilitate horizontal consistency and vertical traceability. A “mature” or “fully-qualified” interoperability SS need not be densely populated; but, it shall contain a coherent, traceable and easy-to-use set of architectural artifacts. For instance, the Enterprise Dimension is primarily bound to the Conceptual Perspective and the Engineering and Technical Dimensions are primarily bound to the Implementable Perspectives; their other Perspectives may be sparsely populated. Key to understanding SAIF is the relationship of the IF, BF and GF to the ECCF Dimensions and the relationships among the Dimensions needed to achieve coherency, traceability and ultimately working interoperability. The Conceptual Perspective is of primary interest to – and directly consumable/readable by – Domain/Subject Matter Experts (DEs/SMEs), the Logical Perspective primarily supports architects and “inward-facing analysts”, and the Implementable Perspective primarily supports developers, often in concert with dialogues among designers and/or architects.
The dimensions of Table 1 are categorized along the following criteria:
· Enterprise Dimension (ED) defines the business and reference context and is concerned with the purpose and behaviors of the subject SS type as it relates to the organization’s business objectives and the business processes. This dimension answers the question “why” and refers to policy. Note that the ED is closely related to the overall Conceptual perspective. In particular, there should be appropriate linkages among the ED Perspective viewpoints and Perspectives of the Information and Computation Dimensions.
· The ED Conceptual Perspective viewpoint is primarily useful to project sponsors, project managers, program directors, IT directors and requirements analysts.
· The ED Logical Perspective viewpoint is primarily useful to project managers and business process experts.
· The ED Implementable Perspective viewpoint is primarily useful to implementation managers, compliance staff and auditors.
· Information Dimension (ID) is defined by one-or-more domain analysis models and is concerned with the nature of the information handled by systems and constraints on the use and interpretation of that information. This dimension answers the question “what” and refers to information content.
· The ID Conceptual Perspective viewpoint is primarily useful to Clinicians and Clinical Analysts.
· The ID Logical Perspective viewpoint is the ID core. It is primarily useful to clinical Informaticists and Architects.
· The ID Implementable Perspective viewpoint is primarily useful to information modelers, implementers, compliance staff and auditors.
· Computational Dimension (CD) is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This dimension answers the question “how” and deals with behavior.
· The CD Conceptual Perspective viewpoint is primarily useful to business analysts and functional analysts.
· The CD Logical Perspective viewpoint is the CD core viewpoint and is primarily useful to System Engineers, architects and Business Process Modelers.
· The CD Implementable Perspective viewpoint is primarily useful to system integrators and solution implementers.
· Engineering Dimension (ED) is defined by existing platform capabilities and is concerned with the mechanisms and functions required to support the interactions of the computational components. This viewpoint answers the question “where” and generally refers to the software (SW) implementation environments. Note that the engineering viewpoint is closely related to the overall Implementable Perspective. The use of reusable components and services or an Enterprise Service Bus (ESB) may naturally fit into this Dimension.
· The ED Conceptual Perspective viewpoint is primarily useful to Enterprise Architects.
· The ED Logical Perspective viewpoint is primarily useful to Application Architects.
· The ED Implementable Perspective viewpoint contains the core ED content and is primarily useful to Application Developers and Deployment Engineers.
· The Technology Dimension (TD) is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the hardware components. This viewpoint answers the question “where” and generally refers to the hardware (HW) deployment environments.
· The TD Conceptual Perspective viewpoint is primarily useful to enterprise architects.
· The TD Logical Perspective viewpoint is primarily useful to Solution Architects.
· The TD Implementable Perspective viewpoint is the ED core and is primarily useful to deployment engineers.
March 26, 2011 SAIF Book Introduction for March-April 2011 Ballot Page 7
[1] Working Interoperability is an instance of two “trading partners” –- human beings, organizations, or systems, successfully exchanging data or information, or coordinating behavior to accomplish a defined task, or both.
[2] An enterprise architecture (EA) is a rigorous description of the structure of an enterprise. EA describes the terminology, the composition of subsystems, and their relationships with the external environment, and the guiding principles for the design and evolution of an enterprise. This description is comprehensive, including enterprise goals, business functions, business process, roles, organizational structures, business information, software applications and computer systems.
[3] DoD Architectural Framework and The Open Group Architecture Framework
[4] Coherent implies clear, complete, concise, correct and consistent.