Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 154
E
A Two-Phase Approach to
Modernization and Transformation of
Business and Information Ecosystems
C
hapter 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 elabora-
tion 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 transfor-
mation of business and information ecosystems of the Centers for Medi -
care 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 understand-
ing 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.
154
OCR for page 155
155
APPENDIX E
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 com-
prehensive 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.
OCR for page 156
156 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
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 ongo-
ing 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 eco -
systems 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 busi-
ness ecosystems are identified in various ways. Some existing (source)
business ecosystems may be mandated to continue as currently consti -
tuted. 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 cho-
sen 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 char-
acterizations from Step 1 of the target business ecosystems, additionally
indicating the relationships among them, and identifying all commonali -
ties 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
OCR for page 157
157
APPENDIX E
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 Initia-
tive 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, enter-
prise-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 organi -
zations (such as the Department of Veterans Affairs,1 the Mayo Clinic,2
Kaiser Permanente, Intermountain Healthcare,3 and others4) are adopting
such enterprise-wide HIMs. The HIM determines the standard terminol-
ogy regarding health data objects that are defined in the business glossary.
1 Department of Veterans Affairs, VHA Health Information Model, available at http://
www.va.gov/VHIM, last accessed July 27, 2011.
2 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.
3 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 Compre -
hensive Clinical Information System from Components: The Approach at Intermountain
Health Care,” Methods of Information in Medicine 42(1):1-7.
4 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 Guide -
lines,” Studies in Health Technology and Informatics 107(1):145-148.
OCR for page 158
158 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
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 organi-
zation will also ensure that any future system being developed will fol-
low 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. 5
Similarly, CMS should work within this initiative to implement its refer-
ence health terminology and value set standard. CMS should leverage
the experience that the Veterans Health Administration has had in imple -
menting its VHA Health Information Model (VHIM).6 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 enter-
prise models.
Mapping of Business Ecosystems
The task of mapping business ecosystems develops a plan for mod -
ernization 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
5 All federal agencies (including CMS) are expected to follow the Federal Health Informa -
tion 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.
6 For more information, see Department of Veterans Affairs, VHA Health Information
Model, available at http://www.va.gov/VHIM, last accessed July 27, 2011.
OCR for page 159
159
APPENDIX E
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 informa-
tion 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 ecosys-
tem 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 ser-
vices and how the targets will use them.
• Step 1: Determine how 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 ante -
cedent (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
OCR for page 160
160 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
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 par-
ticular, 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 mod-
est 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. Sub-
sequent 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 ecosys-
tems as a guide, as well as the dispositions of source and target business
ecosystems decided as described above. The mapping is done at the busi -
ness level in terms of the roles that the business ecosystem implements.
Mappings involve all aspects of a business ecosystem, including stake -
holders, 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.
OCR for page 161
161
APPENDIX E
META-METHODOLOGY PHASE 2: MODERNIZATION AND
TRANSFORMATION OF CMS INFORMATION ECOSYSTEMS
Modernization and transformation planning at the information eco-
system 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 busi -
ness 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 infor-
mation ecosystems and builds to a global view. As with the business eco-
systems 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 actu -
ally 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 develop -
ment and life-cycle management. An enterprise architecture (EA) frame -
work 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 architec -
tural policies and guidance for OIS systems, such as its CMS Technical
Reference Architecture (TRA).7 The CMS OIS documentation that the
7 See CMS, Technical Reference Architecture (TRA) Standards, 2011, available at http://
www.cms.gov/SystemLifecycleFramework/TRAS/list.asp, last accessed July 27, 2011.
OCR for page 162
162 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
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 archi-
tecture encompasses several architectural components, including the pro-
cess, 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 care8 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 appro-
priate 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
8 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 neces -
sary 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 sophisti-
cated 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.
OCR for page 163
163
APPENDIX E
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 architec-
ture component for the global information ecosystem: CMS’s proposed
enterprise data environment (EDE). As with all large-scale, complex com -
ponents, 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 ecosys -
tem 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 analyt -
ics, master data management, and other information management solu -
tions 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 sys -
tem recommended an enterprise architecture as both critical and urgent,
9 NRC, 2004, A Review of the FBI’s Trilogy Information Technology Modernization Program,
Washington, D.C.: The National Academies Press.
10 NRC, 2010, Critical Code: Software Producibility for Defense, Washington, D.C.: The Na-
tional Academies Press.
OCR for page 164
164 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
as does the committee here. CMS has already created a Technical Refer-
ence Architecture11 that includes some aspects of an EA framework.
In terms of the meta-methodology proposed here, CMS’s EA frame-
work would leverage a comprehensive understanding of target informa-
tion ecosystems and their requirements. However, since the moderniza -
tion 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, optimi-
zation, 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 high-
level 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 technolo-
gies 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, consis-
tent 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 informa -
tion ecosystems. For example, the shared business services defined by
CMS in its enterprise and shared services plan,12 as well as its modern-
11 See
CMS, Technical Reference Architecture (TRA) Standards, 2011, available at http://
www.cms.gov/SystemLifecycleFramework/TRAS/list.asp, last accessed July 27, 2011.
12 CMS, 2011, 18-Month Plan for Enterprise and Shared Services, Baltimore, Md., July 7.
OCR for page 165
165
APPENDIX E
ization report,13 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 deliv-
ery 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 informa-
tion ecosystem in terms of the process architecture, applications architec -
ture, information architecture, infrastructure architecture, and so on.
Then analysis methods similar to those for source business ecosys-
tems 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. 14
This component is missing from the source CMS information ecosystem.
As described earlier, the EDE is a critical component; however, its require-
ments and function can be understood only in terms of the requirements
13 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.
14 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.
OCR for page 166
166 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
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 char-
acterizations 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 eco-
system 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 sec -
ond is to understand the relevant portion of the target global information
ecosystem.
• Step 1: Inventory target information ecosystems. This step is analo-
gous 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 poten-
tial and actual commonalities such as shared software, components, and
resources. However, these cannot be determined a priori because the tar-
get 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.
OCR for page 167
167
APPENDIX E
Mapping and Disposition of Information Ecosystems
Mapping source information ecosystems to target information eco-
systems means mapping between their corresponding enterprise architec-
tures 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 arti-
facts. The term “artifact” is used to suggest that these methods are appli-
cable 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, espe -
cially 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 con-
text within which to address strategic issues that arise for the source and
target global information ecosystems, including shared services and infor-
mation 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 retire -
ment 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 busi-
ness 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 pro-
cess. 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.
OCR for page 168
168 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
Minor changes, such as moving to a new platform and recompiling, may
be required.
—Changed: The target artifact requires modification for moderniza-
tion 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 applica -
tion 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 exam-
ple, 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 modern-
ization 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 eco-
systems 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 mod-
ernization 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.
OCR for page 169
169
APPENDIX E
FIGURE E.1 A simplified representation of the several types of mappings are pos -
sible. 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
Figure E-1
systems (some of which may be new).
Bitmapped
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 arti-
facts 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 informa -
tion 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
OCR for page 170
170 STRATEGIES AND PRIORITIES FOR INFORMATION TECHNOLOGY AT CMS
artifacts from different layers of the architecture may be mapped differ-
ently (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 arti-
facts 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 transforma-
tion planning occurs incrementally, a comprehensive analysis of what ser-
Proc
IS
IS 4
Proc
Proc
1.1
1.1
Source Target
App
App
Proc
Proc
1.1
1.1
Informa on
5.1
5.1
Informa on
IS
IS 9
App
App
App
1.2
1.2
1.2
App
App
App
Ecosystem Ecosystem
DB 5.1
DB
DB 5.1
5.1
1.1
1.1 App
App
App
1 DB 5.2
5.2
DB
DB
5
1.2
1.2 DB
DB
DB
5.1
5.1
5.1
DB
DB
DB
5.2
5.2
5.2
IS 16
Proc
Proc
Proc
2.1
2.1
Source Target
App
App
2.1
2.1
2.1
Proc
Informa on
Proc
Proc
App
App
App
Informa on
1
1
2.2 IS 11
IS 11
2.2
Ecosystem
DB
DB
DB
Ecosystem
App
App
2.1
2.1
2.1 1
DB
DB
2
App
App
App
7
2.2
2.2 2
2
DB
DB
DB
1
1
DB
DB
2
2
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.
OCR for page 171
171
APPENDIX E
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 devel-
opment 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.15,16 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 Informa-
tion 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.
