Strategies and Priorities for Information Technology at the Centers for Medicare and Medicaid Services (2012)

E

A Two-Phase Approach to Modernization and Transformation of Business and Information Ecosystems

Chapter 3 provided an overview of the committee’s recommended meta-methodology for the modernization and transformation of CMS systems. The approach described there consists of two phases, the first focusing on the business systems and the second focusing on the information systems. This appendix offers a more detailed elaboration of each of those two phases.

META-METHODOLOGY PHASE 1: MODERNIZATION AND TRANSFORMATION OF CMS BUSINESS ECOSYSTEMS

Phase 1 of the meta-methodology for the modernization and transformation of business and information ecosystems of the Centers for Medicare and Medicaid Services (CMS) relates to business ecosystems. Phase 1 consists of three sequential tasks: the first is to understand the source business ecosystems (existing constructs), the second is to understand the target business ecosystems (desired constructs), and the third is to carry out mapping between them. Each of these tasks involves understanding and documenting the business ecosystems in business terms, which include business and process models for each major distinct CMS role and its information, events, and shared resources, including automated and non-automated aspects. Source business ecosystems encompass both those that support CMS internal roles and those that either depend on or provide roles to external business ecosystems.

Characterization of Source Business Ecosystems

The task of characterizing source business ecosystems consists of two steps, as presented below. The first step develops an understanding of a set of source business ecosystems, and the second step synthesizes a comprehensive view of those source business ecosystems. The initial set of source business ecosystems chosen will depend on the most critical needs; for example, good candidates might be those that are either “in trouble” (burning platforms) today or those for which the requirements are changing dramatically.

• Step 1: Develop an inventory of source business ecosystems. The set of internal CMS business ecosystems chosen must be analyzed so that they can be included in the modernization and transformation plan. A proper inventory not only will list the systems but also will document them— including their characteristics and the way in which they interact with other systems. External business ecosystems that interact with internal CMS business ecosystems must also be inventoried and analyzed, at least to an extent, so that the interaction requirements will be understood for modernization and transformation planning.

• Step 2: Characterize the source global business ecosystem for the set of business ecosystems chosen. The deep understanding of the existing source business ecosystems developed in Step 1 makes it possible to analyze these ecosystems together for potential shared business services and to determine requirements for the target ecosystem. This approach to comprehensive modeling at the business layer is one of the leading trends for achieving a shared-services organization. From what the committee understands, CMS has developed an analysis along these lines, but only for information ecosystems, not for business ecosystems. The committee argues that a similar analysis of the interactions of the parts of the global business ecosystem is also needed.

CMS requires a comprehensive view of CMS business roles. Decades ago, independent CMS business organizations, each with responsibility for a specific CMS role, developed the business and operational models required for that role. With limited requirements for the roles to interact, each role was developed and operated independently by independent CMS organizations. Over time there were increased requirements for the roles to interact more closely. In 2011, there are significant requirements for a comprehensive view of CMS business roles from both a health care perspective and an operational perspective.

Characterization of Target Business Ecosystems

Once the source global business ecosystem is understood, the target business ecosystems can be addressed, again building toward a global view. Because CMS will likely continue to evolve indefinitely, it will need to plan its target business ecosystems incrementally and to expect ongoing iteration, starting with those functions that are known, and using methodologies to support continuous, incremental evolution, following the principles outlined in Chapter 2 of this report. The target global business ecosystem at any time will comprise those target business ecosystems whose requirements are then known and the source business ecosystems that have not yet changed.

This second task—characterization of target business ecosystems— consists of two steps, analogous to those for source business ecosystems given above.

• Step 1: Identify and characterize target business ecosystems. Target business ecosystems are identified in various ways. Some existing (source) business ecosystems may be mandated to continue as currently constituted. In other cases, new roles may be mandated by new requirements from the Department of Health and Human Services or Congress. In still other cases, the earlier analysis of source business ecosystems may suggest the need for refactoring of these ecosystems into different roles. Factors that may affect the prioritization of target ecosystem development include the importance of the business processes and associated use cases to the agency’s mission and priorities. Once target business ecosystems have been identified, they must be defined and documented.

• Step 2: Characterize the target global business ecosystem for the chosen roles. The target global business ecosystem—the integration of the individual target business ecosystems chosen, plus the source business ecosystems that have not changed—will be the target of the mappings described below. The target global business ecosystem combines the characterizations from Step 1 of the target business ecosystems, additionally indicating the relationships among them, and identifying all commonalities such as potentially shared roles, services, and resources.

A key element of this global business ecosystem will be the business glossary—the standardization of the various data to be shared across all the target business ecosystems. As discussed elsewhere in this report, CMS needs to become a data-driven, information-centric organization. CMS daily creates, collects, maintains, uses, and exchanges vast amounts of data electronically. These data become a mission-critical component for CMS and a key element of the manner in which the agency achieves its core strategic goals and objectives. At the heart of this data-driven

ecosystem is the need to establish an enterprise-wide, standard reference health terminology and value set structure that lists, defines, and maps each data concept being represented in any part of the agency’s data infrastructure. This reference health terminology and value set structure should be mapped back to the Federal Health Terminology component of the Federal Health Interoperability Modeling and Standards Initiative being developed by the ONC. The health terminology and value set structure require that a core set of semantic and syntactic interoperable standards be identified, selected, adopted, implemented, and governed across the enterprise. These standards will then become the foundational principles and practices governing information technology (IT) initiatives (see below).

Although CMS has established internal standards for IT systems acquisition and development, there is a lack of an authoritative, enterprise-wide health information model (HIM) by which the data for all roles and projects are governed. Without such a model, each project, unit, program, and office is able to define its own data and, as a result, at the IT level, expensive and complex data interfaces must be developed to integrate data systems and allow for cross-program analysis.

An HIM is an authoritative set of policies and practices that define the health data objects within an enterprise that will be commonly used by business services (and their underlying software services), including the relationship between information elements. Large health care organizations (such as the Department of Veterans Affairs,¹ the Mayo Clinic,² Kaiser Permanente, Intermountain Healthcare,³ and others⁴) are adopting such enterprise-wide HIMs. The HIM determines the standard terminology regarding health data objects that are defined in the business glossary.

¹ Department of Veterans Affairs, VHA Health Information Model, available at http://www.va.gov/VHIM, last accessed July 27, 2011.

² Christopher Chute, Scott Beck, Thomas Fisk, and David Mohr, 2010, “The Enterprise Data Trust at Mayo Clinic: A Semantically Integrated Warehouse of Biomedical Data,” Journal of the American Medical Informatics Association 17(2):131-135, available at http://jamia.bmj.com/content/17/2/131.full.pdf, last accessed July 27, 2011.

³ P.D. Clayton, S.P. Narus, S.M. Huff, T.A. Pryor, P.J. Haug, T. Larkin, S. Matney, R.S. Evans, B.H. Rocha, W.A. Bowes III, F.T. Holston, and M.L. Gundersen, 2003, “Building a Comprehensive Clinical Information System from Components: The Approach at Intermountain Health Care,” Methods of Information in Medicine 42(1):1-7.

⁴ Richard Lenz and Klaus A. Kuhn, 2003, “A Strategic Approach for Business-IT Alignment in Health Information Systems,” in On the Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE, Lecture Notes in Computer Science 2888:178-195; S.M. Huff, R.A. Rocha, J.F. Coyle, et al., 2004, “Integrating Detailed Clinical Models into Application Development Tools,” Studies in Health Technology and Informatics 107(2):1058-1062; and C.G. Parker, R.A. Rocha, J.R. Campbell, et al., 2004, “Detailed Clinical Models for Sharable, Executable Guidelines,” Studies in Health Technology and Informatics 107(1):145-148.

With such a model in place—albeit a model that will be evolving over time—the expensive task of creating customized, one-of-a-kind interfaces between disparate systems is greatly simplified and may be eliminated altogether. Data would be integrated and could be shared internally and, when necessary, externally. The time to create and the cost to build new systems, integrate legacy systems, or extract data from any system are improved. Aiming toward an HIM for all health care data in the organization will also ensure that any future system being developed will follow strict semantic and syntactic interoperable guidelines and standards, which themselves may be modified and adjusted over time as needed. Such an approach will allow the agency to take data from any one of its systems and represent them all in a consistent, comprehensible manner.

In order to best meet CMS goals and congressionally mandated requirements, CMS should accelerate the implementation of its health information model under the Federal Health Interoperability Modeling and Standards Initiative, part of the Federal Health Architecture Project.⁵ Similarly, CMS should work within this initiative to implement its reference health terminology and value set standard. CMS should leverage the experience that the Veterans Health Administration has had in implementing its VHA Health Information Model (VHIM).⁶ Furthermore, CMS should consider engaging in and participating with other national and international organizations, such as the Mayo Clinic, Kaiser Permanente, Intermountain Health, HL7 International, and others, in developing a cross-organizational HIM that can ensure interoperability across enterprise models.

Mapping of Business Ecosystems

The task of mapping business ecosystems develops a plan for modernization and transformation by creating a mapping between the source and target business ecosystems. The mapping will describe, still at the business level, how the source and target business ecosystems are related. This mapping process requires a multidisciplinary, incremental approach driven tactically by the most urgent target business ecosystems. Maps between source and target business ecosystems will be complex. For

⁵ All federal agencies (including CMS) are expected to follow the Federal Health Information Model (FHIM). The FHIM is a critical component of the Federal Health Interoperability Modeling and Standards initiative, part of the overall Federal Health Architecture Program (see http://www.fhims.org/). The emphasis in this report is to note that CMS needs to take the FHIM and apply/adopt it to its enterprise-wide data structures.

⁶ For more information, see Department of Veterans Affairs, VHA Health Information Model, available at http://www.va.gov/VHIM, last accessed July 27, 2011.

example, multiple source business ecosystems may map to individual or multiple target business ecosystems.

The source and target global business ecosystems provide a context in which to identify and address strategic or global issues that apply at the global business ecosystem level. One example of such issues is information strategy, which is concerned with what the business requirements and guidelines are for the collection, analysis, management, access, and dissemination of information across the global business ecosystems. The information strategy should be expressed in the terminology defined in the business glossary and health information model. The business ecosystem mapping will provide guidance for the mapping of the corresponding information ecosystems.

Three steps are needed to perform this task. In the first step, how to derive each target business ecosystem is considered. In the second step, given what is now known about the targets, it is decided how to deal with the sources. The third step documents the relationships between the sources and targets, and it leverages earlier work on potentially shared services, documenting which sources will contribute to new shared services and how the targets will use them.

• Step 1: Determine hozu each target business ecosystem will be derived. Some target business ecosystems will be driven by new requirements without a corresponding source business ecosystem and will therefore be designed without historical constraints; such an ecosystem is sometimes referred to as a green field. Many target business ecosystems, however, will have antecedents, such as fee for services. Nevertheless, designing a target business ecosystem conceptually freed from details of the antecedent (which is addressed in the mapping step, below) can bring fresh insights, leading to improved performance and efficiencies.

More specifically, in this step, target business ecosystems will be evaluated to determine how each should be formed. Dispositions may include the following:

   —Green field: These business ecosystems will be developed from new requirements and have no corresponding source business ecosystem.

   —Unchanged (simple): These business ecosystems correspond to one or more source business ecosystems with minimal changes.

   —Modernized (simple): These business ecosystems correspond to one or more source business ecosystems after modest changes.

   —Transformed: These business ecosystems correspond to one or more source business ecosystems after substantial or fundamental change.

   —Unchanged (complex but refactored): These business ecosystems incorporate components from one or more source business ecosystems with minimal changes to the resulting functionalities, but with substantial

refactoring (including the removal of redundancy and the elimination of unnecessary components).

•  Step 2: Determine whether to discard, modernize, or transform each source business ecosystem chosen. This determination will be based on the expected need for a particular role, in its current form, in the future. This decision in turn will be based on the work done in Step 1, above. In particular, each source business ecosystem might be:

   —Retired: Put out of service by a defined date.

   —Unchanged: Able to be operated as a target business ecosystem more or less unchanged.

   —Modernized: Operated as a target business ecosystem after modest enhancements or changes.

   —Transformed: Used as a target business ecosystem after substantial or fundamental change.

•  Step 3: Map source to target business ecosystems. This step starts by determining the services, if any, to be shared across the target business ecosystems chosen for instantiation. The relevant source services must be mapped to these new shared services so that the target can rely directly on these shared services (rather than on the sources). Because the global context (the global business ecosystem) is built incrementally, the initial mapping increment may or may not identify some shared services. Subsequent increments may identify additional shared services and confirm or question the previously identified shared services.

In general, this step determines in detail how each target business ecosystem is formed, using the source and target global business ecosystems as a guide, as well as the dispositions of source and target business ecosystems decided as described above. The mapping is done at the business level in terms of the roles that the business ecosystem implements. Mappings involve all aspects of a business ecosystem, including stakeholders, processes, events, information, and shared resources.

When undertaking this step, the ecosystem requirements developed in the above analysis and mapping steps should be used to justify the ecosystem mapping and thus provide the essential ecosystem or business details for the relevant business case. Indeed, the development of models and methods to be used and governed across CMS is a central feature of the overall approach. The meta-methodology should be tailored to CMS’s requirements and published and taught across CMS. Similarly, the HIM and other models that are to become standard should be documented, published, and evolved.

META-METHODOLOGY PHASE 2: MODERNIZATION AND TRANSFORMATION OF CMS INFORMATION ECOSYSTEMS

Modernization and transformation planning at the information ecosystem level is guided by planning corresponding to that described for business ecosystems, in the same sequence as in Phase 1: characterize the existing source information ecosystems, then the targets, and then decide which to modernize and which to transform, and create the mappings between them. Decisions on how to treat each information ecosystem should be guided by corresponding decisions for the corresponding business ecosystems. An incremental approach should be followed, guided by the decisions from Phase 1 on which of the business ecosystems should be tackled first. Again, planning starts by understanding individual information ecosystems and builds to a global view. As with the business ecosystems discussed above, the information ecosystems analyzed include both internal CMS information ecosystems and those external to, but interoperating with, CMS.

Phase 2 consists of five tasks. The first task is to develop frameworks to guide the design of the common components of the global information ecosystem (those common to multiple information ecosystems) and its life-cycle management. Again, this is an incremental process. The first time through this task establishes the first increment of the required frameworks. Subsequent increments expand the frameworks as needed. The next three tasks are analogous to those of Phase 1: understanding the source information ecosystems, understanding the target information ecosystems, and mapping between them. Finally, the fifth task is to actually implement the required transformations in order to create the new information ecosystems and move them to production.

Development of the Necessary Frameworks

A framework is a set of rules, guidelines, and standards for development and life-cycle management. An enterprise architecture (EA) framework defines the standards and guidance for the enterprise architecture of all the target information ecosystems. A framework also provides a context within which to identify components that will be shared by two or more target information ecosystems.

The CMS Office of Information Services (OIS) has defined architectural policies and guidance for OIS systems, such as its CMS Technical Reference Architecture (TRA).⁷ The CMS OIS documentation that the

⁷ See CMS, Technical Reference Architecture (TRA) Standards, 2011, available at http://www.cms.gov/SystemLifecycleFramework/TRAS/list.asp, last accessed July 27, 2011.

committee has seen is not, however, inclusive of all global information ecosystem requirements, nor is it developed for or applied to a CMS global information ecosystem. It is noted above that the enterprise architecture encompasses several architectural components, including the process, applications, information, and infrastructure architectures. An EA framework defines the necessary standards for the design, development, and deployment of information ecosystems, to facilitate interoperation and other properties among new and existing information ecosystems. A key piece of this framework should be the information architecture framework. This latter framework and the corresponding information architectures require more focus from CMS. This section briefly explores the information architecture component of the enterprise architecture as an example of how the EA framework would be applied. The business requirements that drive the development of the information architecture comprise an information strategy.

Information Strategy and the CMS Enterprise Data Environment

Data-driven health care⁸ must have an “information strategy”—a basis in business requirements at the global ecosystem level. This strategy addresses questions such as the following: What is the scope of health care data that CMS will manage and/or access? What is the nature of health care data? How should health care data be organized? What are appropriate uses of health care data? Who owns health care data? Where can health care data reside? Who has access to health care data? Under what conditions can health care data be disseminated? And how should health care data be governed? An information strategy that answers these and other questions guides the information management solutions developed

⁸ CMS and its predecessor organizations began with a business model similar to that of a large insurance company and focused their business processes on those activities necessary to keep track of patients, providers, and organizations and to pay for medical services rendered to the covered patients. With time, health care financing has become more sophisticated and more analytical, so that CMS has been tasked with the responsibility for gathering many new forms of data in addition to claims. These data include quality metrics, aggregate utilization data, and even individual abstracted clinical records to support specific studies on effectiveness and costs of various approaches to treating patients. CMS’s responsibilities under the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 (Public Law 110-185) also require it to collect and analyze data on the meaningful use of health information technologies, and under the Patient Protection and Affordable Care Act (Public Law 111-148), it must collect additional data that are not yet well specified that will help to analyze the costs and effectiveness of future ways to organize patient care. An important part of CMS’s business strategies will be to decide the degree to which such analyses can be done by aggregate reporting and attestation by its client organizations and to what extent CMS will need the ability to handle additional patient-specific data.

for the global information ecosystem. Those guidelines are part of an information architecture framework that defines standards and guidelines for the information architecture components of the global information ecosystem.

CMS has correctly recognized the need for an information architecture component for the global information ecosystem: CMS’s proposed enterprise data environment (EDE). As with all large-scale, complex components, the EDE will need to be developed incrementally to meet known requirements, using technical solutions that have been proven to meet the specific requirements of CMS. The meta-methodology outlined here is intended to support such an incremental development of an EDE and other global information ecosystem components. All information ecosystem solutions and components should be designed, developed, tested, and deployed incrementally relative to specific requirements that are known at the time of the current increment. Although it is impossible to predict future requirements accurately, good engineering practices and judicious architecture, technology, and product choices can contribute to meeting some anticipated but not precisely defined requirements, such as future reuse and interoperability.

At the time that the committee examined it, the EDE was just a part of what is needed. In addition to the EDE, which requires solutions for business intelligence, enterprise content management, advanced analytics, master data management, and other information management solutions that can be shared across the global information ecosystem, there will be a need for shared, enterprise-wide solutions to identify and access management; enterprise governance, risk, and compliance; security; fraud prevention and detection; and business process management.

Components of the Enterprise Architecture Framework

Enterprise architectures and standards for them have been industry best practices for several decades. U.S. federal government policies and guidelines recommend them. Reports of the National Research Council (NRC)^9,10 have recommended them for some time. For example, the 2004 NRC report on the Federal Bureau of Investigation’s (FBI’s) Trilogy system recommended an enterprise architecture as both critical and urgent,

⁹ NRC, 2004, A Review of the FBI’s Trilogy Information Technology Modernization Program, Washington, D.C.: The National Academies Press.

¹⁰ NRC, 2010, Critical Code: Software Producibility for Defense, Washington, D.C.: The National Academies Press.

as does the committee here. CMS has already created a Technical Reference Architecture¹¹ that includes some aspects of an EA framework.

In terms of the meta-methodology proposed here, CMS’s EA framework would leverage a comprehensive understanding of target information ecosystems and their requirements. However, since the modernization and transformation effort will of necessity take several years, an incremental approach must be adopted. The initial EA framework should meet all of the requirements for the initial target information ecosystem. It should also include requirements that are known or anticipated.

The CMS EA framework should include the following:

• Requirements for the standard EA components;

• Guidance for product selection, configuration, certification, optimization, operation, and maintenance for EA components; and

• Guidance on EA life cycle: design, development, construction, deployment, operation, management, and evolution.

Care should be taken to ensure that the standards are as generic as possible and not specific to a model or technology. The purpose of highlevel standards is to ensure flexibility, efficiency, interoperability, and so forth, and not to choose a specific implementation model (such as Software-as-a-Service) or a specific technology (such as Java or .Net). Such standards should permit evolution in order to accommodate inevitable future target information ecosystems requirements and EA solutions. The initial framework should be based on the most advanced technologies and products that are proven to meet the requirements of the known enterprise architectures.

All selections of technologies, models, and methods must be proven at scale to meet CMS requirements for the target information ecosystem, which in turn must meet the business requirements of the target CMS business ecosystem that it supports. As the target information ecosystems are designed and as source information ecosystems are mapped to these, detailed models and technology designs will need to be created, consistent with the EA framework.

Frameworks also provide guidance for the design and development of services that are shared across information ecosystems. These shared resources include those core functions required for any and all information ecosystems. For example, the shared business services defined by CMS in its enterprise and shared services plan,¹² as well as its modern-

¹¹See CMS, Technical Reference Architecture (TRA) Standards, 2011, available at http://www.cms.gov/SystemLifecycleFramework/TRAS/list.asp, last accessed July 27, 2011.

¹² CMS, 2011, 18-Month Plan for Enterprise and Shared Services, Baltimore, Md., July 7.

ization report,¹³ would be part of this framework, including an EDE-like component to provide information management services across the global information ecosystem. There could also be global functional components, for example for beneficiary registration and for various health care delivery quality metrics. Hence, the framework is an extension of the work that CMS is already doing.

Characterization of Source Information Ecosystems

At this stage the enterprise architecture of each information ecosystem needs to be understood and documented. This understanding includes the interrelationships between ecosystems, including their interoperation by means of processes (i.e., their process architectures) and by means of information exchange (i.e., their information architectures). This task consists of two steps. The first step develops an inventory of the source information ecosystems, and the second advances that understanding toward a global view of the source information ecosystems.

• Step 1: Inventory source information ecosystems. This step starts by identifying and documenting the source information ecosystems that are relevant to the business ecosystems identified in Phase 1. For each of these, it characterizes the enterprise architecture for each source information ecosystem in terms of the process architecture, applications architecture, information architecture, infrastructure architecture, and so on.

Then analysis methods similar to those for source business ecosystems are applied. The characterization of related business ecosystems should be used to guide that of the corresponding information ecosystem. Information ecosystem analysis must be done for each layer, listed above, of the enterprise architecture.

• Step 2: Develop a characterization of the comprehensive CMS source global information ecosystem. The source global information ecosystem will provide a context within which the modernization and transformation of CMS information ecosystems will be planned. The CMS plan for the future of CMS is focused primarily on the enterprise data environment.¹⁴ This component is missing from the source CMS information ecosystem. As described earlier, the EDE is a critical component; however, its requirements and function can be understood only in terms of the requirements

¹³ CMS, 2010, Modernizing CMS Computer and Data Systems to Support Improvements in Care Delivery, Version 1, IT Modernization Program, December 23, available at http://www.cms.gov/InfoTechGenInfo/downloads/CMSSection10330Plan.pdf, last accessed July 27, 2011.

¹⁴ CMS, 2010, Modernizing CMS Computer and Data Systems to Support Improvements in Care Delivery, Version 1, IT Modernization Program, December 23, available at http://www.cms.gov/InfoTechGenInfo/downloads/CMSSection10330Plan.pdf, last accessed July 27, 2011.

that it must meet to support all target information ecosystems. Hence, CMS must develop, incrementally, as comprehensive a view as possible. This view, imposed on the source systems, aids in analyzing the source and the potential for shared services in the targets.

The global information ecosystem is created by combining the characterizations of the identified source information ecosystems indicating the relationships among them, including all commonalities, with a specific focus on actual and potential overlapping or redundant artifacts.

Characterization of Target Information Ecosystems

The task of characterizing target information ecosystems applies to those target information ecosystems for which a target business ecosystem has been identified and characterized in the business ecosystem plan. A comprehensive view of the target information ecosystems assists design not only of those information ecosystems but also of the target global information ecosystem. As usual, this task proceeds incrementally, starting with those functions that are known, and using methodologies to support continuous, incremental evolution. Again, there are two steps: the first is to understand the target information ecosystems, and the second is to understand the relevant portion of the target global information ecosystem.

• Step 1: Inventory target information ecosystems. This step is analogous to Step 1 for the target business ecosystems. It starts by identifying and documenting the target information ecosystems that are relevant to the target business ecosystems identified in Phase 1. For each of these, it characterizes the enterprise architecture layer by layer. The functional and nonfunctional requirements of each architectural layer are defined following the guidance and standards defined by the EA framework and guided by the business requirements expressed in the characterization of the corresponding business ecosystem.

• Step 2: Develop a characterization of the CMS target global information ecosystem. As with the corresponding business ecosystem step, this step will be accomplished by combining the characterizations of the target information ecosystems identified above and indicating the relationships among them. This global context is required for the analysis of potential and actual commonalities such as shared software, components, and resources. However, these cannot be determined a priori because the target systems do not yet exist. These shared facilities may be hypothesized, but they must be designed, developed, and tested with respect to concrete requirements. Further shared services and components will be discovered incrementally as the global information ecosystem evolves.

Mapping and Disposition of Information Ecosystems

Mapping source information ecosystems to target information ecosystems means mapping between their corresponding enterprise architectures layer by layer   — that is, understanding and defining how to move from the existing “artifacts” (functional or architectural components or services) in the source information ecosystem to the desired, target artifacts. The term “artifact” is used to suggest that these methods are applicable to all aspects of information ecosystems. Mappings are needed for software artifacts (processes and applications), information artifacts (e.g., databases and files), and infrastructure artifacts (other components, especially the operating systems, database management systems, web servers, and application servers). The goal is to create a plan that can be sequenced so that individual technical transitions can be conducted one at a time.

The source and target global information ecosystems provide a context within which to address strategic issues that arise for the source and target global information ecosystems, including shared services and information sharing. Factors that affect prioritization choices, in addition to decisions made during the global business ecosystem analysis phase, may include implementation difficulty, and the potential for the early retirement of legacy systems, freeing up resources from legacy sustainment to be applied to modernization. Mapping is also guided by the source to target business ecosystem mappings created in Phase 1. If a target business ecosystem has one or more source business ecosystems, there will be source to target business ecosystem mappings that define the business requirements for the source to target information ecosystem mapping process. And, of course, the components of the target enterprise architecture must comply with the standards defined by the EA framework.

As at the business ecosystem level, there are three steps to mapping information ecosystems: decide how to create each target artifact, decide how to leverage each source artifact, and then document the relationships between sources and targets, determining shared services. Each of these steps is done EA layer by EA layer.

• Step 1: Determine how best to create each target information ecosystem and its artifacts. Target information ecosystems and their artifacts—that is, enterprise architecture components—should be analyzed to determine a disposition for the modernization and transformation process, including the following:

   —Green field: The target artifact will be developed from original requirements with no mapping from a source artifact.

   —Unchanged: The target artifact will map unchanged from a source artifact; no substantial modernization and transformation are required.

Minor changes, such as moving to a new platform and recompiling, may be required.

   —Changed: The target artifact requires modification for modernization and/or transformation from one or more source artifacts.

   —Candidate shared service: The target artifact is a candidate for being a target shared service.

Note that layers are somewhat independent. For instance, a new application or process could be identified at one layer of the architecture, and yet, lower down, artifacts from the infrastructure or information layers could be preserved or modernized and transformed.

• Step 2: Determine how to leverage each source information ecosystem and its artifacts. Source information ecosystems and their artifacts—for example, enterprise architecture components, should be analyzed to determine a disposition for the modernization and transformation process, including the following dispositions:

   —Unchanged: The source artifact will map unchanged to a target artifact; no substantial modernization and transformation are required. Minor changes, such as moving to a new platform and recompiling, may be required.

   —Changed: The source artifact requires modification for modernization and/or transformation to one or more target artifacts.

   —Retired: The source artifact will be retired at some future defined date in the source information ecosystem and will not map to any target artifact.

   —Candidate shared service: The source artifact is a candidate for mapping to a target shared service.

Here, too, layers are to a certain extent independent. For example, an information ecosystem may be unnecessary going forward. However, a database from that ecosystem’s information architecture layer might be reused in a new service, even though the applications that were originally built on it are no longer necessary.

• Step 3: Create the mapping between source and target information ecosystems and their artifacts. Using as a guide the corresponding source and target global information ecosystems and the results of the above analysis, the source information ecosystems are mapped to the target information ecosystems. The mappings will provide guidance for the ultimate modernization and transformation activities that will achieve the planned result. Mapping from source to target information ecosystems requires mapping from the source to the target enterprise architectures layer by layer, as for the analysis in Steps 1 and 2 above.

FIGURE E.1 A simplified representation of the several types of mappings are possible. Systems can be retired, newly created (green field), split into one or more systems (parts of which may be retired), or merged out of one or more existing systems (some of which may be new).

In general, mappings can be arbitrarily complex. Examples of types of mappings (Figure E.1) include the following:

   —Null mapping: Retired source artifacts and green-field target artifacts map to or from “null.”

   —Direct mapping: A source artifact may map directly to a target artifact.

   —Split mapping: A source artifact may map to multiple target artifacts.

   —Join mapping: Multiple source artifacts may map to a single target artifact.

The simplest mappings are direct mappings, especially those that hold at all levels of architecture. For example, CMS may plan to use a source information ecosystem unchanged in any way to be the target information ecosystem. The most complex mappings involve mapping multiple source artifacts from potentially several source information ecosystems to one or more target artifacts, perhaps in several target ecosystems, when

artifacts from different layers of the architecture may be mapped differently (Figure E.2). For example, there is a null mapping for green-field information ecosystems; however, at the information architecture level in the enterprise architecture, a new information service might be based on an existing database, from some source information ecosystem. As another example, a green-field payment process may leverage payment and registration services that do have source mappings.

One of the most important aspects of information ecosystems analysis and mapping is the identification of potential services to be shared across two or more target information ecosystems. There is substantial input into this already, from Phase 1’s analysis of shared business services, to the layer-by-layer analysis of potential shared services in Steps 1 and 2 of Phase 2. In the mapping process, the plan for creating the target artifacts will depend on these decisions. The design of target artifacts and mappings from source to target artifacts should attempt to leverage as many shared artifacts as possible. Since modernization and transformation planning occurs incrementally, a comprehensive analysis of what ser-

FIGURE E.2 A complex mapping. Target information ecosystem (IE) 5 is derived from source IE 2, but one application is a merge of an application from source IE 1 with one from IE 2. Target IE 7 is new but uses a database from IE 1.

vices could be shared is not possible. Hence, the identification of shared services will be incremental, like all other aspects of CMS modernization and transformation.

Implementation of the Mappings

A considerable amount of the meta-methodology described above is intended to ensure appropriate context and identification of affected source and target components. The actual transitions—modernizations or transformations—that result from the planned mappings, however, take place on individual components and/or the lowest-level elements of the architecture. The final task in the modernization and transformation of a chosen component is to plan for the implementation of the mappings defined in the fourth task above and then to implement them. For each of these mappings, the implementation plan will include (1) creating a development version of the newly envisioned technical ecosystem, (2) testing and evaluating this version against requirements, and (3) moving this ecosystem to production once the requirements are satisfied, replacing the source ecosystem. Implementing a single source to target information system mapping often requires a significant project and considerable resources.¹⁵, ¹⁶ Implementing a source to target information ecosystem mapping that involves multiple information systems is correspondingly larger and more complex, requiring an incremental approach.

The information ecosystems requirements developed in the above analysis and mapping steps should be used to justify the information ecosystem mapping and thus provide the information systems details for the relevant business case.

15 For example, see Michael L. Brodie and Michael R. Stonebraker, 1995, Legacy Information Systems Migration: The Incremental Strategy, San Francisco, Calif.: Morgan Kaufmann Publishers.

16 For example, see Willem-Jan van den Heuvel, 2007, Aligning Modern Business Processes and Legacy Systems: A Component-Based Perspective, Cambridge, Mass.: MIT Press.