SAEAF Education Series 2: SAEAF Behavioral Framework April 2009

1. SAEAF Education Series2: SAEAF Behavioral FrameworkApril 2009 HL7 Services-Aware Enterprise Architecture Framework (SAEAF)

2. SAEAF Education Series (1) • The SAEAF Education Series includes the following: • 1: Introduction and Overview • SAEAF Value Proposition: Working Interoperability • SAEAF Structural Components • Behavioral Framework • Enterprise Conformance/Compliance Framework • Governance Framework • SAEAF Organizational Implications • Education • Change Management • Alpha Projects

3. SAEAF Education Series (2) • The SAEAF Education Series includes the following: • 2: Behavioral Framework • Contracts, Roles, Collaborations • Mapping to HL7 Dynamic Model • Relationship to the Unified Field Theory • Examples

4. SAEAF Education Series (3) • The SAEAF Education Series includes the following: • 3: Enterprise Conformance/Compliance Framework (ECCF) • A multi-dimensional world • Conformance • Compliance • Consistency • Certification • Traceability • Jurisdiction • Provenance • The SAEAF Specification Stack and the ECCF • ECCF and Governance

5. SAEAF Education Series (4) • The SAEAF Education Series includes the following: • 4: SAEAF Governance • Definitions • The Governance Challenge • Contextualizing Governance • Governance Perspectives • Types of Governance • Putting it all together • Summary

6. SAEAF Education Series (5) • The SAEAF Education Series includes the following: • 5: SAEAF Examples • Service Interoperability Paradigm • Message Interoperability Paradigm • Document Interoperability Paradigm • More topics possible as deck is developed (Feb 09)

7. SAEAF Series Part 2:SAEAF Behavioral Framework • Mandatory Pre-requisites • Knowledge of SAEAF Education Series Parts 1 • Part 1: Introduction and Overview • Optional Pre-Requisites (some concepts overlap) • Part 3, SAEAF ECCF • HL7 Behavioral Framework and ECCF are intimately linked via… • Traceability and Levels of Conformance • Scope of Collaboration • Specification Stack Topic • Part 4, SAEAF Governance • Service-oriented behavioral models insist on boundaries and separations of concerns, which leads to notions of jurisdiction and provenance

8. SAEAF Series Part 2:SAEAF Behavioral Framework (2) • Outcomes • Understanding and application of primary Behavioral concepts • Service Roles, Collaborations, Contracts • What Behavioral Models are (and why they are important) in the context of Working Interoperability (WI) • Conformance • Compliance • Ways to use Behavioral Concepts • In a Standards Development Organization • As an Implementer

9. SAEAF Value Proposition (1):Working Interoperability Interoperability Paradigm (Messages, Documents, Services): specifications which enable two or more (HL7) trading partners to collaborate in the context of a specific business interaction No assumptions of size, character, or identity of parties Nations, Enterprises, Departments, Individual, Systems, etc. No assumptions of exchange details (What, Why, How, etc.)

10. SAEAF Value Proposition (2):Working Interoperability D C E Component Component B F Agree on “Platform -Specific” view A Agree on “Platform-Independent” view Agree on “Conceptual” view Agree on “Reference” view • Interoperability: the deterministic exchange of data/information in a manner that preserves shared meaning • Two parties interoperate based on a certified “level of shared compliance” to interoperability specifications/standards • Certified “level of conformance” determine degree of automated interoperability that is possible and/or the difficulty of the transformations that are required to enable interoperability

11. SAEAF Value Proposition (3):Working Interoperability • Achieving WI is a matter of assembling certain building blocks. • These building blocks describe • when information flows across data interchange points, • how those interchange points are described, • who or what those interchange points represent • how the information is bound to data flows, • interdependencies between separate data flows, • other aspects of control flow that ensure that data is flowing properly over the course of the interaction and in such a way as to support the business function from which the service specification is derived.

12. Outline • Introduction • Contracts • Defining a Service Role • Examples: • A Degenerate Collaboration and implicit Contract • A Richer Collaboration Model • Examples: • A more explicit Contract and a rich Collaboration • Service Classifications • The Unified Field Theory • The Legacy HL7 Dynamic Model • SOA ML

13. Introduction

14. Definitions (1): Behavior (1) • From the Merriam-Webster Dictionary; • The manner of conducting oneself • The way in which something functions or operates • Common Synonyms: • Protocol; Custom; Pattern; Mores • Common IT Synonyms • Conversation (between whom?) • Sequence (when?, of what?) • Collaboration (to accomplish something …)

15. Behavioral Framework (BF) • The Behavioral Framework deals with the way that you describe the computational aspects of distributed systems • The Framework is a top-down means of expressing the integration from two different perspectives: • The global view of interactions – conversations between various parties endeavoring to fulfill a business purpose or mission, which the Behavioral Framework calls Collaborations. • A system implementation may be an orchestration, collaboration, or choreography • The business capability view – analytical business roles exposing sets of behaviors, which the Behavioral Framework calls a Service Role • A system implementation of which is known simply as a Service.

16. The Fundamental Use CaseStairway to Heaven: Two parties which to exchange meaningful information • Two parties who wish to integrate build things to achieve “Working Interoperability.” • Interoperability is the deterministic exchange of meaningful information • Interoperability broaches the “system of systems” viewpoint – it is not a single system architecture • Understanding where A,B,C,D, and E are requires an Enterprise Architecture C D B Same Platform E Agree on Models A Agree on Concepts Agree to Agree

17. The role of the BF in WI (1) • The essence of the Stairway of Heaven is that the participants work via Contracts • A SOA analysis of a distributed systems’ environment yields a decomposed set of business-oriented capabilities. These capabilities are advertised and exposed through explicit interface specifications called services*. • Composing these services together to support common business functionality within a domain is accomplished, at least nominally, through the idea of a contract. * Note that Services may be realized using Documents and Messages

18. The Role of BF in WI (2) • The BF is an attempt to explicitly capture the contractual nature of integration by dealing separately and in detail with the notions of • Services (denoted as Service Roles) • Compositions of Service Roles for a Business Purpose (denoted as Collaborations) • Contracts that bind Service Roles to Collaborations • It allows for a technically neutral specification stack to be implemented in a variety of ways.

19. Behavioral Framework and Behavioral Models • The BF generates instances of Behavioral Models that are specific to a given business purpose • HL7 has historically dealt with a Dynamic Model, including Application Roles, Interactions, and Trigger Events • The BF is an abstraction away from a single model for capturing interactions towards a comprehensive means of capturing the semantics of system collaborations • Flexible – not technology specific • Specific – describe semantics precisely and appropriately • Layered – according to the ECCF specification stack

20. The BF and Conformance • Layered - The BF is layered according to the ECCF’s Specification Stack • Flexible - Both Collaborations and Service Roles are specified independently of any given technology • They serve as a testable architecture for interoperability for systems (via exposed Services) and between systems (via realized Collaborations). • This is another way of saying that a given Behavioral Model provides requirements for interoperating with specific components to achieve a business purpose • Collaborations and Service Roles have Conceptual Components that describe Behavior independently of any Interoperability Paradigm • Specific – Capable of capturing integration semantics – specifically the computational aspects – at various levels of abstraction, providing provenance, traceability, and consistency.

21. Standardization and the BF • The BF within the SAEAF includes two types of artifacts that follow the familiar specification and constraint pattern • The table shows semantics captured by each specification • These can be balloted to support various domain needs both separately and together • Contracts are not ballotable, but their format will eventually be fixed by HL7 to support local implementation as needed

22. Contracts

23. Contracts (1) • Etymology: Middle English, from Anglo-French, from Latin contractus, from contrahere to draw together • The term contract is used colloquially in technical circles both to describe the specification of the behavior of one party in a collaboration (e.g., a WSDL for a web service) or for the sum conversation as a whole (i.e., a collaboration). • The term contract within the SAEAF explicitly means the artifact scoped to the overarching sets of interactions that support a business purpose and binds together the various participants. • An artifact that serves to centrally capture essential computational viewpoint semantics (or references to them) for management and reuse

24. Contracts (2) • The central organizing principle of the SAEAF’s Behavioral Framework is the notion of integration mediation through contract. • Bertrand Meyer’s “Design by Contract” • Martin Fowler’s Accountability Pattern (http://martinfowler.com/apsupp/apchap2.pdf) • Commissioning Agent • Responsible Agent • The goal is that each party designs the contract by which others engage with their component • This interoperability drives all other system design

25. Contracts (3)Bridging between Design- and Run-Time • Contracts serve to provide a binding between design time requirements and constraints and run-time components, facilitating exchanges of information • May be pre-defined or implicit (that is, defined but not created as an artifact) • Design-time constraints include: • Integration semantics • Required Roles • Required Participations • Legal issues • Quality-of-service • Jurisdictional • Policy components

26. Contracts (4) D C E Component Component B F Agree on “Platform -Specific” view A Agree on “Platform-Independent” view Agree on “Conceptual” view Agree on “Reference” view • The participants on the Stairway must work together via agreed contracts (real or implicit) • The basis of each contract is a collaboration that binds together roles. • Some participants will be playing a defined business role to support the collaboration • Each participant playing a business role is variably conformant to a specification • There are likely multiple Stairways to any given collaboration

27. Contracts (5) • The BF provides a way to talk about • Business Roles (aka Service Roles) • Collaborations • Participations in those collaborations • In some cases, these participations are playing both a business role and a run-time role

28. Contracts (6): Roles and Participations

29. Contracts (7): Roles and Participations • Note the separation of business roles and run-time roles • Business Roles are roughly equivalent to HL7 Legacy Application Roles (more on that later) • Run-time roles are of two types • Commissioning Agent – requesting some capability • Responsible Agent – providing some capability • Contracts bind the different parties and their capabilities / needs to patterns of behavior

30. Contracts (8): Roles and Participations Example • Commissioning Agent • Needs to create a lab order; needs to provide sufficient semantics to create the lab order • Responsible Agent • Service Role: Lab Order Service being used as a Lab Order Manager • Participation: has the responsibility to create a new lab order when provided appropriate information • The Contract defines the roles, their participations, the interactions, and the goals.

31. Contracts (9): More …. • Contracts can also deal with some platform-independent and platform-specific elements of behavior • Platform – Independent: behaviors, behavior groupings, shared state machines, pre-defined interactions, nested behaviors, and references to relevant Collaboration Specifications • Platform – Specific: Deployed components, defined operations, parameter format, quality of service, service level agreements, identified instances, shared tokens

32. Contracts (10)Summary (1) • Contracts serve to provide context in the form of quality and functional requirements around deployment of components involved in interoperability scenarios • Describe the logical pieces (Collaboration, Service Role dependencies … more later) • Describe performance expectations and agreements • Provide traceability to industry standards • Provide a testable set of components that validates the conditions of interoperability • The conformance statements of the specifications are asserted to have been met at the Interchange points

33. Contracts (11)Summary (2) • The Behavioral Framework helps to answer … • Who • What • When • How • The essential question is … • Who does What ….. When and How? | Service Roles | Collaborations | | ________Contracts________

34. Contracts (12)Summary (3) • Perhaps most importantly, contracts offer another place to capture essential integration semantics • In some paradigms like services, binding a service interface to a commissioning agent early is inappropriate • contracts provide a means to describe the essentials of interactions without creating siloed, one-off interfaces • Contracts may be nested (that is, referenced by commissioning agents) to provide fulfillment • Notice that Responsible Agents may reference a Contract • Like a Purchase Order or a Gift Card • Avoids “hard wiring” components into pre-configured spaghetti

35. Defining a Service Role

36. Defining a Service Role(1) • Service Roles provide a domain-focused way of defining a given capability (called a topic) and their relevant semantics that are essential and business relevant • A capability – exposed as an instance of a service - may be described in terms of the semantics required to integrate that capability into some larger behavioral pattern • Adopting / adapting a Service Role Specification is the key to outlining sets of reusable and durable business capabilities for an organization • Note: There is a body of work that preceded the SAEAF in this regard … • HSSP’s SFM • HL7 SOA WG’s SOA4HL7 • HL7 SOA WG’s SOA Interoperability Paradigm’s Methodology

37. Defining a Service Role(2):Essential Semantics • Organized by Topic • Enterprise Viewpoint: • Scope of the Service, Policy Considerations • Relationships with other Roles and Collaborations • Information • Domain Concepts  Parameters for Operations  Schema / Objects • State Machine for Focal Class (Optional) • Computation • Functional Profiles, Interface Specifications • Business Operations  Logical Operations  Functions • State Transitions for Focal Class (Optional) • Other Collaborations • Engineering • Deployment Considerations • Libraries

38. Defining a Service Role(3):Essential Concepts for Specification

39. Defining a Service Role(4): Notes on the Model • Service Role Specifications include the following essential components: • Behavioral Specifications (via BehaviorTypes) • Business Operations  Logical Operations  Functions • Behavior Groups (via BehaviorProfileTypes) • Functional Profiles, Interface Specifications • Collaboration Participations, either as …. • informational examples of Responsible Agents (to other members of one or more Collaborations) • as the Commissioning Agent (defining its own Collaboration Type and nested Contracts) via actual exchanges of information (via ExchangeTypes and InteractionTypes). • Explcitly part of the “realization” part of the specification, and not exposed in the interface itself.

40. Defining a Service Role(5):Notes on Deployment • It is simplest to think of a service = web service • A deployed piece software component that does something • ... But a Service Specification may be deployed by multiple systems in multiple places, or even by the same system multiple times for multiple clients • An organization may want ONE Source of Record for X Data, and then there needs to be a single URL to get that Data • …. But even then, there are likely multiple deployed service components to aid with performance, etc. • … And there may be multiple “Write” interfaces that need to be coordinated to insure data integrity • Example: An organization may want each of it’s hospitals to deploy a common service specification to help with reporting • NCI: Each Cancer Center deploys commonly specified reporting interfaces to support accrual reporting

41. Service Roles (6)Incremental approach to defining WI through Conformance: D C E Component Component B F Platform -Specific A Platform-Independent Conceptuals Reference • Two parties who wish to integrate build on the Specification Stack to achieve “Working Interoperability” centered around a single topic • C and D have the easiest time interoperating because they agree on interoperable components based on a platform-specific specification. This is most desirable, but not a precondition to interoperability. (They still have work to do …) • Should B wish to interoperate with D, B will need to write adapters that provide semantic interchanges for policy, behavior, and information, and technology, which would be derived from examining the related specification. • B and F can interoperate by agreeing on a Conceptual Specification, but F will have to write adapters to provide semantic interchanges (as above). • A has the farthest to go to interoperate with anyone else. Adapters will have to be written to accommodate constraints from several layers Service Role (Capability) Topic

42. Service Roles (6)Summary(1) • Service Roles provide a means of specifying core capabilities that are important to a domain • They represent a governable structure (see Governance) that encapsulates essential semantics of integration • They represent a commonly defined capability that may be adopted or adapted by an organization to either achieve WI (or to come into some level of compliance)

43. Service Roles (7)Summary(2) • Service Roles provide for the explicit solution to a particular topic • They are intended to provide an encapsulation barrier behind which something happens • …. But they don’t infringe on contract semantics or on Collaborations between other services • They are durable, reusable components that support a unity of purpose. They exist in the context of other durable, reusable components that support other purposes.

44. A Degenerate Behavioral Model

45. The Degenerate Behavioral Model (1):Service Roles and Relationships • When specifying behavior for a Service Role, notional (or better) clients are considered • For Example, Lab Order Manager Service needs a Lab Order Placer • The BF refers to these as RoleRelationships • RoleRelationships are the first place where we see the Interoperability Paradigms appear • Messaging – RoleRelationships are Well Defined, Normative • Services – RoleRelationships are Informative at best • RoleRelationships provide the basis for top-down analysis to support a Service Role Specification

46. The Degenerate Behavioral Model (2): From EIS Conceptual Model } 7User Scenario Interaction Details 7.1Create a new patient 7.2Link/Merge entities 7.3Update demographics 7.4Inactivate entity from general searches 7.5Activate (inactive) entity to general searches 7.6Unlink entity 7.7Look up a patient 7.8Unattended Encounter 7.9Remove entity from the system 7.10Look up patient across regional network 7.11Look up a patient specifying a specific external organization 7.12Link entities across regions within an organization • … This TOC is from the EIS Conceptual Model …. • These entries in the Table of Contents are the lists of Business-level interactions and operations that are defined for EIS • They represent the sum of behaviors that are considered relevant for Identification Management

47. The Degenerate Behavioral Model (3): Example … Summary Service Role Service Role Service Role RoleRelationship RoleRelationship RoleRelationship Commissioning Responsible

48. The Degenerate Behavioral Model (4): Example … Focus on Role Relationships Service Role Service Role Service Role RoleRelationship RoleRelationship RoleRelationship

49. The Degenerate Behavioral Model (5): Example … Focus on Commissioning and Responsible Agents Service Role Service Role Service Role Commissioning Responsible

50. The Degenerate Behavioral Model (6):Notes on the Example • The union of these sequences of interactions form the behavioral model that is expressed in the ECCF’s specification stack for a Service Role • Specifically the conceptual and platform independent specifications for a Service or Message • Only one RoleRelationship in the example (Identity Requester to Identity Manager) that is logically repeated between different instances of the Service, and only a few in the Service Role Specification • This is very simple • Only one relevant RoleRelationship to accomplish any particular business purpose • One Service Role • Several (but not many) Behavioral Groups to identify logically consistent sets of behavior