Military Health System (MHS) Future State Work Group (FSWG) In Progress Review (IPR)

1. Military Health System (MHS)Future State Work Group (FSWG)In Progress Review (IPR) Business Software Architecture (BSA) Containing Software Definition Framework (SDF) Supporting Integrated Requirements Design (IRD) Sets of Integrated Management Information (IMI) Within Business Capabilities Lifecycle (BCL) Send updates to Stephen.Hufnagel.ctr@tma.osd.mil, editor Last updated 18 Dec 07 Aligned-Interoperable-Agile Healthcare Information Technology

2. EXECUTIVE SUMMARY:The objective of the Software Definition Framework (SDF) is to specify software components and their services within an Enterprise Architecture (EA), also known as a Business Software Architecture (BSA). The objective of the Integrated Requirements and Design (IRD) process is to guide investment portfolio, acquisition managers and engineers with the appropriate Software Development Lifecycle (SDLC) documentation needed for the Business Capability Lifecycle (BCL) of a Business Transformation Architecture (BTA). The SDF defines a BSA that supports the SDLC by specifying IRD solution sets which become part of the BCL “Integrated Management Information” (e.g., within the center purple box of the following figure). This “Integrated Management Information” should contain a “future state” strategic architecture and a BTA transition plan composed of IRD solution sets. Both the “future state” enterprise architecture and BTA transition plan are composed of SDF views and related artifacts, as shown in the following slides. EXECUTIVE ORDER#13335 and #13410 mandate federal agencies to have interoperable Electronic Healthcare Records (EHR), as specified by the Health and Human Services (HHS) Healthcare Information Technology Standards Panel (HITSP). See the companion paper and brief, which discusses the MHS-VA standardized “Healthcare SOA Reference-Architecture (H-SOA-RA)” for categorizing, describing and constructing system functional components within a HITSP compliant Enterprise Service Oriented Architecture (SOA).

3. Integrated-Requirements Design (IRD) Process Perceive Needs 1.1 Process Submission Triage Decision 1.2 Prepare IRD Package for Investment Decision Generate Exhibits for Acquisition Documents Integrated Management Repository JCIDS, PPBS, IT300 1.3 Investment Decision Architecture, IRD Packages, Business Cases, Investment Portfolio, Processes, Capabilities, Requirements, Meta Data, Standards, Policies, Governance Acquire Build Test Field Sustain 1.4 Prepare IRD Package for Execution Decision 1.5 Execution Decision Notional MHS Capability Lifecycle

4. MHS Mission-Driven Business Architecture Framework Business Rules Strategic Vision Support the Core Mission Areas with high-quality, low-cost, aligned, interoperable and agile Healthcare Information Systems (HIS) Clinical Logistics & Readiness Financial & Budget HR and Operations CIO Core Mission Areas Business Value Chain Segments Business Process Models Information Models Solution Architectures Core Services Common Services Security & Privacy Information Assurance Service Oriented Architectures

5. Notional Time/Cost of IRD Process Deployment Decision IRD 2.0 Acquire, Build, Test, Field, Sustain Year of Execution Note: Coefficient “C” varies depending on submission size • IRD OBJECTIVES: • Minimize costs of IRD “overhead” phases 1.0, 1.1, 1.2 and 1.3 • Make changes and fix problems as early as possible • Avoid high cost changes in IRD phase 2.0 C*10 Hours C* 100 Hours C* 1000 Hours C*10,000 Hours C*100,000 Hours Acquisition Decision Execution Decision IRD 1.5 Define Quality Assessment Attributes Investment Decision IRD 1.4 Refine Funded Solution IRD 1.3 Prioritize Solution Sets IRD 1.2 Conduct Enterprise Analysis of Requirements-Design Sets IRD 1.1 Process Submission IRD 1.0 Conduct Strategic Generation of IT Requirements IRD 1.0 IRD 1.1 IRD 1.2 IRD 1.3 IRD 1.4 IRD 1.5

6. Notional ROI of IRD Process Cost to make changes or fix problems C*1 C*10 C*100 C*1,000 C*10,000 10X 100X Cost of Change - Fixes • https://www.thedacs.com/databases/roi/display_all_facts.php?datasource=ROI&label=Cleanroom&improvement2=Cleanroom • Basili, V., McGarry, F., Page, G., Pajerski, R., Waligora, S., Zelkowitz, M., "Software Process Improvement in the NASA Software Engineering Laboratory", Technical Report CMU/SEI-94-TR-22, December 1994, Carnegie Mellon University, Pittsburgh, Pennsylvania: Software Engineering Institute. • Sherer, S. W., Kouchakdjian, A., Arnold, P. A., "Experience Using Cleanroom Software Engineering", IEEE Software, May 1996, pp. 69 - 76. IRD 1.0 Pre-Acquisition IRD 2.0 Build, Test, Field, Sustain Note: Coefficient “C” varies depending on submission size Notional 10:1 ROI  Six Sigma 1X 10X Cost of Software Engineering

7. KEY CONCEPT:Business Software Architecture (BSA)Components are Specified by theSoftware/Service Definition Framework (SDF)

9. Pre-requisite of the IRD Package • “Master plan” – the MHS EA Future-State vision • The future-state vision is a strategic view of the entire MHS architecture: • Principles • Architectural Drivers • Architectural Constraints • The future-state vision constrains and guides the IRD process • The IRD packages expand the future-state vision • Challenge: vision will be created/expanded as we implement the IRD process • Cannot wait for a full version of the future-state vision to be completed before we start doing IRD

10. IRD Package • Design is explicitly included • Key part of the IRD package • Not ALL the design – only as much as needed to ensure interoperability and adherence to the master plan • The entire package is now considered the “requirements” • Shall statements used as an adjunct, not as the primary vehicle to represent requirements • No need to create shall statements to reiterate constraints/assertions/data elements/etc already described in other artifacts within the package

11. What is included in the IRD Package • Overarching information • Business purpose, scope • Behavioral descriptions • Process models, use cases – how the business occurs and how the systems will support it • Structural descriptions • All the parts of the system and the organization and how they are decompose and relate to each other • Note that there is no separation of operational vs. system at the top level • There are multiple touch points between behavioral and structural description elements

12. Overarching information • Define the business value to be realized • Who is the customer? • What value (benefit) will be achieved? • What will change? • How does the change achieve the value? • How can we measure success in achieving the value (metrics)? • Overarching section is mostly textual, can include sample narrative scenarios • Focus must be on the business value

13. Behavioral Descriptions • Starts with a high-level business process diagram • Include participants in dedicated swimlanes (DoDAF “operational nodes”) • Explicitly identify information inputs and outputs of each step • Refine these processes iteratively • Individual steps in higher levels are decomposed into detailed process at lower level • Explicitly add systems / services as actors • Information requirements must be mapped to an enterprise information model • Identify common activities that are “reused” by multiple processes • At the detailed end of the refinement process, we will have formal system use-cases, which can be traced back to higher-level business processes • Corresponds to DoDAF OV-6c and SV-10c, but more of a continuum than separate products

14. Notional Detailed Use Case

15. Notional Behavioral Description

16. Structural Descriptions • Three levels • Specifications • Implementations • Deployments • Additional constraints / requirements / policies / security requirements will be associated to elements are all three levels (this is where the “shall statements” will come in)

17. Specification Level • Decomposition of system functions • A service is a special kind of system function • Logical description of what each system function does and how it relates to other functions • Includes operations, which act upon messages, which in turn must carry the information required in the behavioral description • Similar to (but more expressive than) DoDAF SV-4

18. Notional Specification

19. Implementation Level • Describes actual units of software (“components”) that implement the system functions specified previously • Lack of precise differentiation between a system function specification and its implementation in the architecture is a big drawback of the classic DoDAF approach

20. Deployment level • Describes Execution Environments (physical boxes and the computing environments they host, such as web server, databases, transaction managers, etc.) • Specifies which components will be hosted in which execution environments • Specifies communication paths between execution environments • Specifies the runtime bindings and protocols that allow components to interface to other components • Some of this information is in DoDAF SV-1 and SV-2, but the proposed metamodel includes more detail

21. Notional Implementation & Deployment Specifications

22. What is not included in package • Detailed software design (e.g. Java classes and methods) • Physical database schemas/models • Focus is on logical information model and message schemas • Detailed “as-is” business process models • Too much time spent describing something that is usually not uniform across the enterprise, with limited value • IDEF-0 “ICOM” diagrams • Limited value of this activity does not justify the significant effort required

23. High Level Overview of Future State Framework and its use within the IRD process The future state architecture group has developed a first version of a Future State Framework (the “Framework” hereafter) to be followed and complemented by appropriate Future State architecture content and supporting artifacts. The Framework, while having a COTS version as a starting point, is being adapted to MHS needs. It includes a series of interrelated “views” which are defined in an UML model. The Framework supports the IRD process and the MHS Enterprise Architecture (EA).   Central to the Framework is the support for Requirements-Design Sets from the from the capability/change request inception, through acquisition and deployment. There are three views which are meant to be extensively used in the initial IRD phases: Business View, Solution View, Software Specification View. Each view should increasingly become more detailed as the IRD process advances towards acquisition and later on towards deployment: • The Business View supports concepts such as Capability which is further detailed by Processes, Subprocesses, Elementary Processes. • The Solution View is defined in terms of Use Cases involving Actors and Use Case Steps. Use cases may be composites of other use cases and a set of requirements quite often is described as a collection of use cases. • The Software Specification View relies on concepts which include Transaction. A transaction can further contain transactions at increasingly lower levels.  These three views may be linked at a higher level (Capabilities, Processes, Use case are supported by some software specifications) but they may be further linked at various lower levels by appropriate choices of transactions associated to use case steps or elementary processes. Thus in a Requirement-Design set one may choose to pair in a flexible manner elements from the requirement side with elements from the design side, maintaining visibility and understanding for all stakeholders involved. One can also control the cost of the IRD process by calibrating the level of details of the required views at various decision points during the IRD process starting with the Triage step and continuing through the investment decision phase and further through acquisition, deployment and other phases deemed necessary.  A completed IRD package for acquisition purposes will have also (partial and incomplete) Framework Implementation, Deployment and Runtime views covering constraints, compliance and other aspects (such as network and communications specifications). These views will be completed after the acquisition phase by contractors, vendors and other entities as they become involved during the software development and deployment lifecycle.  The Framework views aim to allow for the recording of information sufficient for deriving various compliance artifacts (such as DoDAF OVs and SVs). The Framework needs to be extended in several directions including the areas of: Security, Testing, Error Handling, Federation.

25. Data Set for IRD Phases 1 & 2

26. Data Set for each IRD Phase 4

27. UML RelationshipsAmong Classes and Objects Association:a solid line represents an unspecified relationship between classes or objects; Optional open arrowheads indicate flow (e.g. messaging) Association - Composition: a solid line with an open arrowhead and a solid diamond at the tail end that represents a "has-a" relationship. The arrow points from the containing to the contained class. A composition models the notion of one object "owning" another and thus being responsible for the creation and destruction of another object. Association - Aggregation: a solid line with an open arrowhead and a hollow diamond at the tail end that represents a "has-a" relationship. The arrow points from the containing to the contained class. An aggregation models the notion that one object uses another object without "owning" it and thus is not responsible for its creation or destruction. Generalization - Inheritance: a solid line with a solid arrowhead that represents an “is-a” relationship. The arrow points from a sub-class to a super-class or from a sub-interface to its super-interface. Generalization - Implementation: a dotted line with a solid arrowhead that points from a class to the interface that it implement Generalization - Realize: a dotted line with a solid arrowhead shows that the source object implements or realizes the destination. Realize is used to express traceability in the model. Dependency: a dotted line with an open arrowhead that shows one entity depends on the behavior of another (e.g., Realization, Instantiation and Usage) client (tail) refines the source. Typical usages are to represent that one class instantiates another or uses the other as an input parameter. Message: a solid line with an open arrowhead that shows that one entity communicates with another.