HL7 SAIF Executive Summary and Implementation Guide by I66V751d

VIEWS: 10 PAGES: 7

									                    Service Aware Interoperability Framework

 1                                                                                      HL7
 2                    Service Aware Interoperability Framework (SAIF)
 3                                                                         Introduction
 4   Executive Summary
 5   The goal of SAIF is to enable Working Interoperability1 (WI); where, the biggest impediment to
 6   WI is implicit assumptions. As such, SAIF provides a set of grammars that enable developers
 7   and users of “components” involved in WI scenarios to explicitly define and govern those
 8   aspects of the component’s structure and behavior that affect its ability to seamlessly engage in
 9   a WI scenario.
         mmd SAIF



                                                                                                        Business                System
                           Enterprise                                        Enterprise                                       Architecture
                                                                            Architecture               Architecture
                           Structure

                                                                                                                                                Technical
                            Guiding                                                                                                            Architecture
                           Principles


                                                              apply to
                                                                                                                                              populates


               Evolution                Design
                                                                                                                      Interoperability
                                                                                 SAIF
                                                                                                                       Specification



                                                                                    goal


                                                                              Working
                                                                          Interoperability
                                                                                                                                         populates




                                                                                                  manages
                            Information                   Behavioral               Governance
                                                                                                                   Enterprise Compliance and
                           Framework (IF)               Framework (BF)           Framework (GF)                  Conformance Framework (ECCF)
                                             supports

                                                          defines concepts and
                                                          structuring rules                                                       maintains




                                                                                                                      Coherence               Traceability




10
11                                                               Figure 1: SAIF Concept Map
12
13   The scope of SAIF is the interoperability space between business objects, components,
14   capabilities, applications, systems and enterprises. Specifically, SAIF manages the
15   interoperability specifications among distributed systems that may involve information


     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.


     August 31, 2012March 26, 2011                         SAIF Book Introduction for March-April 2011 Ballot                                                 Page 1
                 Service Aware Interoperability Framework
16   exchanges, interactions and state changes. SAIF is not Enterprise Architecture (EA)2 nor is it an
17   Architecture Development Methodology (ADM); but instead SAIF can be used to manage an
18   EA, such as DoDAF or TOGAF3, and organize an EA’s artifacts into interoperability
19   specifications.
20    The approach of SAIF is to organize and manage architectural complexity with a set of
21      constructs, best practices, processes, procedures and categorizations.
22    The focus of SAIF is on managing and specifying architectural artifacts that explicitly
23      express the interoperability specification characteristics of software components.
24    The technical objective of SAIF is to create and manage easy-to-use, coherent4 and
25      traceable Interoperability Specifications (ISs) for systems, sub-systems, and other software
26      components providing layers of specification abstractions from the conceptual to the
27      platform bound, including message, document or service interoperability-paradigms.
28
29   SAIF combines four sub-frameworks, composed of grammars, for defining and managing
30   comparable interoperability specifications.
31       The Information Framework (IF) defines the grammar for information and terminology
32        models, metadata, value sets and schemas that specify the static semantics of interactions.
33        This includes the grammar for patterns of structured and unstructured data, documents,
34        messages and services, quality measures and transformations. The IF defines the grammar
35        that a SAIF Implementation Guide (IG) must follow to define information and terminology
36        models, metadata, vocabularies and value sets that specify the static semantics for
37        expressing concepts, relationships (including cardinalities), constraints, rules, and
38        operations needed to specify data, data type bindings, vocabulary and value set bindings
39        within a SAIF IG. The canonical IF simply says that to achieve explicit expression of a
40        component’s informational/static semantics, those constructs must be formally defined. This
41        includes specifying how they relate to each other, e.g. an information model has concepts,
42        attributes, and relationships, where attributes are bound to a formal data type specification,
43        value sets are bound to data types, etc...
44       The Behavioral Framework (BF) grammar defines constructs to specify the dynamic
45        semantics of interactions in an interoperability specification. The BF focus is the
46        accountability required to achieve working interoperability. Accountability is a description of
47        “who does what when.” Accountability manifests itself as implicit or explicit contracts at
48        business object, component, application, system and enterprise boundaries. The BF
49        grammar specifies accountability of system role relationships among various stakeholders,
50        system components and applications. These relationships involve information exchanges
51        and state changes within use case scenarios.



     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.



     August 31, 2012March 26, 2011               SAIF Book Introduction for March-April 2011 Ballot                                            Page 2
                 Service Aware Interoperability Framework
52   Collectively, the IF and BF grammars allow the interoperability-specification of business objects,
53   components and their services, capabilities, applications, systems and their respective roles,
54   responsibilities and interactions (e.g., information exchanges).
55       The Governance Framework (GF) grammar enables an organization implementing SAIF to
56        manage risk by relating decisions and policies, to the IF and BF interoperability
57        specifications within the ECCF. The overall management of the life cycle of each artifact –
58        whose content and representation must be defined in the context of a given organization’s
59        SAIF Implementation Guide (IG) – including the correctness and completeness of the
60        artifact as well as the IG-specified RACI relationships for the artifact – are defined by the
61        Governance Framework grammar. The GF scope includes Precepts5 (which are defined in
62        terms of objectives, policies, standards, and guidelines), Roles (e.g., people, organizations
63        and systems), Processes and Metrics. A SAIF IG should operationalize the GF grammar to
64        cover expectations, grant authority and resources, verify performance, manage
65        configuration baselines, etc.
66       The Enterprise Conformance and Compliance Framework (ECCF) enables an
67        organization implementing SAIF to organize and manage interoperability specifications. The
68        ECCF is based on the well-established experience from cognitive science that has shown
69        that complexity is best described by partitioning a complex system-of-interest into a number
70        of Dimensions, each viewed from one or more Perspectives. In particular, the ECCF is a
71        structured collector of artifacts expressed using the grammars of the IF and BF. The GF’s
72        grammar is used to specify various aspects of the ECCF’s artifacts that can then be used to
73        determine whether a given implementation of a specific component’s specification can be
74        verified as being a “valid implementation instance.” In the context of WI, the ECCF
75        specifications of components enable developers and users of ECCF-specified components
76        to more tractably and predictably manage the myriad of details associated with achieving WI
77        scenarios. The ECCF purpose is to manage the relationship between architectural artifacts
78        and the implementations of those artifacts to insure compatibility6 among systems. The
79        objective of a fully qualified ECCF is to be a coherent and traceable interoperability
80        specification, which is easy-to-use. The ECCF can be an assessment framework, which
81        supports configuration management baselines, development status, audit compliance and
82        risk assessments throughout a business-capability lifecycle. The ECCF can be used to
83        specify information exchange interoperability and conformance statements for documents,
84        messages and services. An ECCF provides a template, called a Specification Stack (SS)
85        that allows the specification of business objects, components, capabilities, applications and
86        system interoperability. An ECCF SS is organized as a matrix of Dimension columns
87        (Enterprise, Information, Computational, Engineering and Technical) and Perspective rows
88        (Conceptual, Logical and Implementable).
89   The ECCF is the centerpiece of SAIF. It supports both technical interoperability (IF and BF) and
90   the GF management of interoperability. The SAIF ECCF provides external stakeholders with a
91   coherent picture of exactly what is required to interoperate with an organization’s software

     5 A Precept (from the præcipere, to teach) is a commandment, instruction, or order intended as an authoritative rule of action.
     6
       Compatibility is a relationship between two or more conformance statements involving two or more specification stack instances. The
     relationship identifies whether two or more implementations certified to be conformant to the specification stack instances can achieve WI
     without further transformations. If so, the two SS instances and associated implementations are called compatible.


     August 31, 2012March 26, 2011               SAIF Book Introduction for March-April 2011 Ballot                                          Page 3
                  Service Aware Interoperability Framework
 92   components. A given component's specification is SAIF-compliant if it is compliant with an
 93   organization’s SAIF implementation guide. The ECCF IG should require "just enough"
 94   compatibility to enable the desired level of interoperability7 for appropriate SS types. The notion
 95   of “just enough” is grounded on the combination of the complexities associated with a given
 96   component’s deployment context (e.g. individual lab, organization, cross-enterprise, etc.) and
 97   Interoperability Type (human readable syntactic through computable semantic).
 98
 99       SAIF Implementation
100   Any organization choosing to implement SAIF should assemble its own SAIF Implementation
101   Guide (IG). An organization’s SAIF IG is the practical interpretation and localization of the
102   canonical constructs defined in the HL7 SAIF book.
103
104   SAIF defines the grammars8 and patterns9 common to all ECCF Interoperability Specification
105   Stack (SS) instances. Each organization should document how to instantiate and guide the
106   population of its interoperability SSs. Note that just as an enterprise may have systems-of-
107   systems, an interoperability SS may reference and be built from component SSs. Additionally,
108   for different SS types10, an IG may require different SS architectural artifact profiles11. This
109   means that an SS for a complete solution may reference SSs for more primitive building blocks,
110   where each interoperability SS type may contain or reference different numbers and different
111   types of artifacts.
112
113   Table 1 is a sample template, which shows a super-set of common architectural-artifacts within
114   an ECCF SS. As appropriate, within each cell, you might
115    place or reference and discuss appropriate architectural artifacts and specifications,
116    define conformance statements, which are testable-representations of the specifications,
117    assert, as true or false, that one-or-more conformance statements are met
118    manage traceability within columns and consistency across rows.
119    do Topic Maps among viewpoints and architectural artifacts to define traceability
120    do RACI Charts for each viewpoint to define stakeholder roles and responsibilities
121    identify and mitigate risks across the organization’s component development life cycles.
122
123   SS maturity implies that an SS instance is coherent and traceable within-and-across the SS. SS
124   maturity does not require complete coverage of all cells in the SS; rather, coverage should be
125   “fit-for-purpose”. Examining relevant SS instances provides a scalable approach to assessing


      7
        Levels of Interoperability [Center for Information Technology Leadership]
            1. Viewable (e.g., paper based)
            2. Machine Transportable (e.g., electronic form, such as PDF)
            3. Machine readable structured messages with unstructured content
            4. Machine interpretable structured messages with standardized content
      8 Grammar is the set of rules that deal with syntax and semantics of interoperability specifications.
      9 Pattern is the SS cell placement of architectural artifact types.
      10 SS types include business objects, components, capabilities, systems, enterprises
      11 SS profiles define the fit-for-purpose architectural artifacts that are distributed across the ECCF matrix of Dimensions (columns) and through

      the ECCF Perspectives (rows) for different SS types.


      August 31, 2012March 26, 2011               SAIF Book Introduction for March-April 2011 Ballot                                           Page 4
               Service Aware Interoperability Framework
126   the risk or degree of difficulty and specific amount of effort required to enable trading partners to
127   attain Working Interoperability.




128
129       Table 1 Notional Super Set of Common Architectural Artifacts within an ECCF SS
130   An IG specifies which types of architectural artifacts are required by an organization, program,
131   project, etc. Obviously, an enterprise SS will have different artifacts than a component or
132   business object. In Table 1Table 1Table 1, a super set of common architectural artifacts are
133   distributed across the ECCF Dimensions (columns) and through the ECCF Perspectives (rows).
134   “Fit-for-purpose” criteria should be used to determine the appropriate architectural artifacts for a
135   particular SS type. Artifacts are first placed in the most intuitively obvious SS cell and then are
136   organized to facilitate horizontal consistency and vertical traceability. A “mature” or “fully-
137   qualified” interoperability SS need not be densely populated; but, it shall contain a coherent,
138   traceable and easy-to-use set of architectural artifacts. For instance, the Enterprise Dimension
139   is primarily bound to the Conceptual Perspective and the Engineering and Technical
140   Dimensions are primarily bound to the Implementable Perspectives; their other Perspectives
141   may be sparsely populated. Key to understanding SAIF is the relationship of the IF, BF and GF
142   to the ECCF Dimensions and the relationships among the Dimensions needed to achieve
143   coherency, traceability and ultimately working interoperability. The Conceptual Perspective is of
144   primary interest to – and directly consumable/readable by – Domain/Subject Matter Experts
145   (DEs/SMEs), the Logical Perspective primarily supports architects and “inward-facing analysts”,
146   and the Implementable Perspective primarily supports developers, often in concert with
147   dialogues among designers and/or architects.
148
149   The dimensions of Table 1 are categorized along the following criteria:
150    Enterprise Dimension (ED) defines the business and reference context and is
151      concerned with the purpose and behaviors of the subject SS type as it relates to the
152      organization’s business objectives and the business processes. This dimension answers the


      August 31, 2012March 26, 2011   SAIF Book Introduction for March-April 2011 Ballot             Page 5
               Service Aware Interoperability Framework
153       question “why” and refers to policy. Note that the ED is closely related to the overall
154       Conceptual perspective. In particular, there should be appropriate linkages among the ED
155       Perspective viewpoints and Perspectives of the Information and Computation Dimensions.
156            The ED Conceptual Perspective viewpoint is primarily useful to project sponsors,
157               project managers, program directors, IT directors and requirements analysts.
158            The ED Logical Perspective viewpoint is primarily useful to project managers and
159               business process experts.
160            The ED Implementable Perspective viewpoint is primarily useful to implementation
161               managers, compliance staff and auditors.
162      Information Dimension (ID) is defined by one-or-more domain analysis models and is
163       concerned with the nature of the information handled by systems and constraints on the use
164       and interpretation of that information. This dimension answers the question “what” and
165       refers to information content.
166            The ID Conceptual Perspective viewpoint is primarily useful to Clinicians and
167               Clinical Analysts.
168            The ID Logical Perspective viewpoint is the ID core. It is primarily useful to clinical
169               Informaticists and Architects.
170            The ID Implementable Perspective viewpoint is primarily useful to information
171               modelers, implementers, compliance staff and auditors.
172      Computational Dimension (CD) is concerned with the functional decomposition of the
173       system into a set of components that exhibit specific behaviors and interact at interfaces.
174       This dimension answers the question “how” and deals with behavior.
175            The CD Conceptual Perspective viewpoint is primarily useful to business analysts
176               and functional analysts.
177            The CD Logical Perspective viewpoint is the CD core viewpoint and is primarily
178               useful to System Engineers, architects and Business Process Modelers.
179            The CD Implementable Perspective viewpoint is primarily useful to system
180               integrators and solution implementers.
181      Engineering Dimension (ED) is defined by existing platform capabilities and is
182       concerned with the mechanisms and functions required to support the interactions of the
183       computational components. This viewpoint answers the question “where” and generally
184       refers to the software (SW) implementation environments. Note that the engineering
185       viewpoint is closely related to the overall Implementable Perspective. The use of reusable
186       components and services or an Enterprise Service Bus (ESB) may naturally fit into this
187       Dimension.
188            The ED Conceptual Perspective viewpoint is primarily useful to Enterprise
189               Architects.
190            The ED Logical Perspective viewpoint is primarily useful to Application Architects.
191            The ED Implementable Perspective viewpoint contains the core ED content and is
192               primarily useful to Application Developers and Deployment Engineers.
193      The Technology Dimension (TD) is concerned with the explicit choice of technologies
194       for the implementation of the system, and particularly for the communications among the
195       hardware components. This viewpoint answers the question “where” and generally refers to
196       the hardware (HW) deployment environments.




      August 31, 2012March 26, 2011   SAIF Book Introduction for March-April 2011 Ballot         Page 6
                  Service Aware Interoperability Framework
197               The TD Conceptual Perspective viewpoint is primarily useful to enterprise
198                architects.
199               The TD Logical Perspective viewpoint is primarily useful to Solution Architects.
200               The TD Implementable Perspective viewpoint is the ED core and is primarily useful
201                to deployment engineers.




      August 31, 2012March 26, 2011   SAIF Book Introduction for March-April 2011 Ballot       Page 7

								
To top