A pragmatic planning and execution model can effectively modernize integration technology across the enterprise.

1. • Cognizant 20-20 Insights
An Execution Approach for Large-Scale
SOA Technology Migration
A pragmatic planning and execution model can effectively modernize
integration technology across the enterprise.
Executive Summary realistic viewpoint. The context is that of a large
program to migrate the integration endpoints of
Large-scale migration programs are among the
core banking services from an end-of-life integra-
toughest to plan and execute for any enterprise,
tion technology, CORBA (Common Object Request
especially when the migration is only about
Broker Architecture), to currently mainstream
technology and no new functionality is delivered
technology (SOAP/HTTP Web services).
to the business that is funding the program.
One such case is that of technology migration After introducing the context elements, we
to a service-oriented architecture, or SOA. Such describe the key elements of a program execution
programs have a simple vision — retirement of a model that is based on the concept of stages and
legacy integration technology through controlled that leverages a factory approach to migration
migration of services to the new standard before during certain stages. The migration unit opti-
support ends for the existing technology. mization approach is based on a concept of
migration cycles and multiple influencing factors,
In any such large-scale technology migration
such as application dependency and budget avail-
program, one of the most critical elements of
ability, organizational priority and others. The
design is the unit of migration. Determining how
recommended approach is applicable to many
these migration units are designed and sequenced
migration programs that are executed across
for execution during a long-running transforma-
today’s large enterprises.
tion program is of paramount importance from
both the portfolio management and enterprise
Migration Context
architecture points of view.
IT organizations at large enterprises the world
The approach presented in this white paper is over have continually needed to retire costly
based on the principles of staged lifecycle, iterative legacy technology infrastructures. In such
delivery, multicriteria decision-making and retro- situations, IT organizations typically select among
spection. Although the principles, techniques and mainstream and future-oriented technology to
tactics recommended are applicable to all legacy which they can migrate. To achieve this type of
technology migration programs, we have chosen migration, a centrally managed program is often
a real-life migration case in order to provide a designed with funding support from both appli-
cognizant 20-20 insights | october 2012

2. cation development and CTO organizations. Such of program scope, there were more than 1,000
programs impact multiple stakeholders, and providers that offered 2,500 business services,
therefore, the coordination effort is typically quite consumed by about 400 consumer applications
large. In addition, these programs have a lifetime through the common middleware mentioned
of four to five years; this extended time horizon earlier.
presents problems such as a lack of long-term
visibility, risk of strategy change midway, change Migration Elements
in organization priorities (and thus funding), etc. Before outlining the approach for migration, it
is important to understand the key elements
Given this situation, enterprises need a holistic, involved in migrating integration technology. Each
top-down approach to program management of these elements will be part of the migration
and planning. Technology typically is the least units (defined in the next section) that are
of the migration pains, because if the project executed during the program. The following fun-
is scoped properly, software vendor partners damental elements must be properly considered
provide necessary automated tools to facilitate while planning the migration of integration tech-
the technology upgrade. nologies:
We propose an approach to migration program • Service and service interface: A service in
execution and its internal optimization, based SOA is the logical, self-contained business
on our experience with migration of the core function offered by the provider of the
banking services of a global bank from an end- service for the consumer of the service and
of-life integration technology (CORBA) to current is described by a well-defined functional/data
mainstream technology (SOAP/HTTP Web delivery contract between these two parties.
services). The previous landscape consisted of The service interface is the primary manifesta-
core banking systems mostly implemented on tion of the service, describing both functional
mainframe systems and front-end channel appli- (service signature) and quality of service
cations implemented on contemporary tech- (execution and invocation policies) aspects of
nologies — Java and .NET. From an SOA perspec- the offered service. While in the case of CORBA
tive, more than 80% of service providers offer the interface is described in the form of IDL and
mainframe-based applications, while the rest are NS configurations, the Web services technology
delivered via Java technology. makes use of WSDL, XSD and associated WS-
artifacts to describe the same.
These services were provided to consumers
via common middleware built on a service bus • Service provider (provider application/
topology (see Figure 1). The bank had already component): These applications are the ones
established mechanisms for SOA governance and that host the actual functionality/data being
middleware integration that were expected to be served through the service interface provided.
applied during the migration program. In terms The service interface lifecycle is primarily in
Integration Technology Migration Context
Consumers Consumers
CA CA CA …. CA 4 to 5 years CA CA CA …. CA
Migration Program Special case
CORBA WS
Technical transformation Web Services CORBA
of integration layer from
SPA SPA SPA …. SPA CORBA to Web service SPA SPA SPA …. SPA
Providers CA: Consumer Application Providers
SPA: Service Provider Application
Figure 1
cognizant 20-20 insights 2

3. control of these applications, and the interfaces both providers and consumers have been tested
are evolved based on demand from consumers to their satisfaction — the existing services (on
or due to a change in underlying functions or legacy technology) need to be decommissioned
technology infrastructure. as per the retirement process defined under the
SOA governance standards of the organization.
• Service consumer (consumer application/
Figure 2 depicts these steps as a continuous cycle
component): These applications host the
of workstreams in a migration program.
modules that invoke and consume the services
of the third-party provider applications. Such The service repository has a
applications are the clients of the providers and critical role to play in this model,
In IT organizations
as it is the only place where the with mature SOA
thus have a strong influence on the evolution
of the service interfaces. As reuse is one of the old and new services must be practices and
fundamental reasons why a service orienta- modeled and managed by the
tion is applied, there is generally a many-to- service designers of provider
governance, the
applications. All existing and service repository also
many relationship between the consumer and
provider. new consumer applications acts as the design
• Service implementation point: An implemen- refer only to the repository for
time and change time
tation point is that part of the provider applica- services they wish to consume.
tion that is bound to the service endpoint when In IT organizations with mature governance platform.
invoked by the consumer applications. The SOA practices and governance,
implementation program/component/class is the service repository also acts as the design time
typically the entry point to the functional/data and change time governance platform. Therefore,
access logic that the service provides. From a the modeling, planning and lifecycle management
migration point of view, all such implementa- tools (critical in migration projects) are developed
tion points must be considered individually, in close proximity to the repository itself. The
because post-migration, the endpoints in the lifecycle and its actual elaboration as a migration
new technology also need to be bound to the execution model are described later in this paper.
implementation.
Migration Units
• Service call point: A call point is that part
In the context of SOA technology transforma-
of the code in the consumer application from
tion, a migration unit is defined as a logical unit
where the provider service interface is invoked.
of work composed of the migration elements that
A consumer application may have multiple call
must be migrated as a group for dependency,
points for a given interface. For the purpose of
migration, each call point is considered as a
separate element to be migrated. Iterative Workstream Model for
• Service repository: As the name signifies, the SOA Migration
repository is essentially the hosted catalog of
all services offered by the provider applica-
tions and all associated information therein.
The users of the repository search for services
Legacy
in the catalogs, and if consumers use these Planning
Retirement
provided services, they register themselves
as consumers at this central location. Please
note that the repository here doesn’t provide Applications
runtime lookup and resolution of services,
Service Interfaces
which is the job of typical service registries.
Consumer Service Repository
Migration Design
As the first executable step in the migration
program, the services that were so far available in
CORBA need to be modeled as per the standards
of Web service technology. Subsequently, the code Provider
artifacts of newly created Web services need to Integration
be generated or implemented (as appropriate) for
integration with the provider and consumer appli-
cations. Once the integration is complete — and Figure 2
cognizant 20-20 insights 3

4. efficiency and organizational reasons. These milestones that can be achieved in an incremental
units are designed and sequenced after taking manner. The model that follows is based on this
multiple factors into account. Each migration consideration.
cycle (described later) executes a set of migration
units planned for the duration of the cycle. For Overall Execution Model
simplicity and easier reference, we will use a The execution model recommended for the
shorter name — LUM (logical unit of migration) — migration program is based on the notion of
throughout the rest of this paper. stages, where each stage has different require-
ments in terms of milestone delivery and thus
An example of such a migration unit would be a requires its own delivery model.
LUM containing one consumer application with
15 call points that are consuming 15 service The three stages depicted in the model represent
interfaces provided by six different service the progression in the lifecycle of a service
provider applications. Such a configuration would interface to be migrated. While Stage 1 lends
typically be called a consumer-driven migration itself to a one-time delivery style, Stage 2 is more
unit, which is described later. suited for following a factory-like approach to
migrate the interfaces in migration cycles. Stage
Migration Lifecycle Model 3, on the other hand, involves on-demand delivery
As legacy technology migration programs have a of interface decommissioning. Stage 1 is a prereq-
typical span of four to five years in large enterprise uisite for starting the actual migration, and Stage
IT landscapes, it is critical to adopt an approach 2 is where the actual migration of applications
based on an agile philosophy of delivering in to the new interface is carried out. As soon as all
multiple iterations instead of a big-bang, four-year applications dependent on migrated interfaces
waterfall planning approach. That said, such a move over and accept the new interface, the old
long timespan requires provisions for defined one is retired in Stage 3.
Migration Lifecycle Model Guiding the Execution Approach
Stage 1 Stage 2 Stage 3
Migration Planning
Assess Interface Remodeling Provider and Decommissioning
Consumer Migration
Applications Validate
Prioritize Rate
Usage data, dependencies,
Publish Interface Model
Specify
budget, business criticality,
platform alignment, etc.
Generate
Report Design
Migration
Defined sequence, as-is interface
specification quality, standards
Units
compliance, automation, etc. Analyze
Test Migrate
Interface
Migration Planning
Archive Notify
• Sequencing and release planning Dependencies, release planning,
• Dependency coordination maintenance complexity,
• Test data and infrastructure platform alignment, budget, etc. Decommission
planning
Dependencies,maintenance
cost,new technology interface
quality, legacy support, etc.
Testing Strategy and Infrastructure Setup Continuous Test Services Delivery (ongoing)
Migration Monitoring and Reporting Migration Plan Tracking, Management and Reporting (ongoing)
Infrastructure Setup
Operational and Governance Model Setup Operations, Lifecycle Management and Governance (ongoing)
Figure 3
cognizant 20-20 insights 4

5. In addition to the stages that mandate specific Migration Cycles
delivery models of their own, the entire process Properly defined planning and governance
of technology transformation goes through four units, as well as the criteria leading to design
workstreams (in line with what is depicted in and sequencing of the LUM, are two of the key
Figure 2): factors that drive success of the entire migration
program. For the design and sequencing of the
• Migration planning. migration units, an important prerequisite is to
• Service interface remodeling (design). establish the set of criteria that guides this activ-
• Provider integration and consumer migration. ity. It is highly recommended that this criteria is
established during the early part of the migration
• Decommissioning (legacy retirement). planning phase. During assessment, a migration
Figure 3 outlines the steps that are followed sequencing index is computed using these crite-
in each of these workstreams and the con- ria. The units are then sequenced accordingly.
straints that apply while the workstream is being
As the duration of the entire program is
delivered. At the end of each workstream, a
typically too large to apply this mechanism, we
governance mechanism in the form of a quality
recommend assessing and planning the migration
gate is recommended. This quality gate should
in cycles. Similar to an agile notion of iterations,
certify completion, as per the objectives and
a migration cycle is a time-bound iteration, and
acceptance criteria specified for the deliverables
the entire migration program is a set of cycles. In
of the workstream.
each migration cycle, a set of LUMs is planned and
Three foundational elements are critical to all migrated. The application of cycles is an internal
large migration programs: tracking and reporting operating mechanism for the migration program,
tools, governance and operating mechanisms and it does not interfere with the concept of a
and, most importantly, a robust and compre- logical grouping of applications in LUMs; instead,
hensive testing facility. Such a facility must act it serves as a complement.
as the quality signoff authority throughout the
In order to balance duration and size constraints,
migration program. A detailed approach for
we recommend a cycle duration similar to the
establishing and operating these foundations is
budgeting and planning cycles of the organiza-
beyond the scope of this paper and, therefore, is
tion if the program scope and participants are
not described here.
fairly stable and known (which is true in most
legacy migration cases).
Illustrative Migration Cycles for Program Execution
Program Lifespan: 4-5 years
Cycle 1 Cycle 2 Cycle 3 Cycle 4 …
Specify Specify Specify Specify
Assess
Applications Report Report Report
Design Design DesignReport Design
Migration
Prioritize Rate Units
Test Test Test
Migrate Migrate Migrate Test Migrate
Retrospective
Planning and budgeting Migration cycle execution as per sequencing defined for the cycle
First 6 months Last 12 months
18-month migration cycle
Migration cycle composed of migration units planned for migration.
(Note: Does not indicate sequential ordering of cycles.)
Figure 4
cognizant 20-20 insights 5

6. During migration planning, the LUMs are designed and coordination is taken care of before the next
by applying the approach recommended in this migration execution starts. This migration cycle
paper and evaluating applications for the defined planning (about six months) is a recommend-
criteria. There are two options in terms of the ed activity before the actual migration within
scope for which the design activity is carried out: the cycle (expected to span a 12-month period).
Before the migration of the defined cycle has
• Design LUMs for the entire scope (difficult due been completed, a retrospective is also recom-
to time horizon; not recommended).
mended to assess execution and apply necessary
• Allocate LUMs to cycles (after evaluation and adaptations to the execution approach of the
discussion with relevant stakeholders) and next cycle being planned.
then sequence LUMs on a cycle-by-cycle basis.
The latter approach is more sensitive to changes Design and Sequencing Optimization
that might need to be incorporated during the The design of the migration units — and the order
program lifecycle based on the changing business in which these are planned to be released — is
and IT scenarios. Figure 4 details this approach an area that is impacted by a number of factors.
with a scenario of a financial institution that has a While on the one hand we have the migration
yearly budgeting cycle. Considering the migration elements and their interdependencies, on the
scope presented earlier and the size of a sample other we have to take care of the contextual
migration unit, a cycle duration of 18 months elements, such as budget, resources and orga-
can be proposed in which the following three nizational priorities, among others. What follows
execution phases will be carried out: is one approach for optimally designing and
ordering (or “sequencing”) the logical units of a
• Migration planning and budgeting of migration migration program.
cycle (about six months). This can be performed
in parallel with the execution of the previous Migration Unit Design
cycle. Due to a preference for demand-led models, the
• Migrationexecution for the identified and organizational intent is most often to design
planned LUMs (12 months). LUMs driven by a single consumer application.
While we agree that this approach is suitable
• Migrationretrospection (two to four weeks
considering a demand-driven model of resource
toward the end of the migration cycle).
allocation and execution, certain LUMs can also
The reason for proposing a 12-month execution be designed in a provider-driven way. Generally,
phase is based on the possibility of around 80 there is also a good probability that the LUMs
LUMs to be migrated in a cycle, with each LUM might be composite in nature and of manageable
migrating a combination of one consumer and size and complexity, meaning we may have to
up to five provider applications (consumer-driv- split the larger LUMs into smaller ones.
en LUM). Given the scope of migration, approxi-
mately five such migration cycles will be executed A key metric in LUM design that must be examined
during the entire program. is inter-application dependency in the form of
coupling. Both afferent and efferent coupling
The migration cycles are not sequential in nature. needs to be considered.
During the last six months of the migration cycle,
the migration planning of the next cycle can be
• Afferent coupling (Ca): Applicable to provider
applications, this metric indicates the number
started so that all the necessary preparation, of consumer applications that depend upon
planning, dependency resolution, syndication interfaces of the provider application. It is an
Parallel Migration Cycle Planning and Execution
Cycle 1 Planning Cycle 2 Planning Cycle 3 Planning Cycle 4 Planning
Cycle 1 Execution Cycle 2 Execution Cycle 3 Execution Cycle 4 Execution
…
Figure 5
cognizant 20-20 insights 6

7. indicator of the responsibility of the provider indicators of whether a consumer- or provider-
application. driven approach should be adopted. That said,
this is not the only parameter that will determine
• Efferent coupling (Ce): Applicable to consumer the final decision on LUM design. Other aspects,
applications, this metric indicates the number
of provider applications upon which the such as business criticality, budget availabil-
call points of the consumer application are ity, lifecycle alignment, resource availability, etc.,
dependent. This is an indicator of the indepen- need to be considered to arrive at a final LUM
dence of the consumer application. design decision.
If a provider has a high value of Ca, a provider- In order to evaluate all such parameters, a simple
driven LUM will be a preferred approach. A lower weighted rating method (described below) can
Ca indicates a provider with fewer consumers be applied. Another option is to use a formal
dependent on it and thus can be considered for a technique such as an analytic hierarchy process
migration unit driven by one of these consumers. (AHP), but that would require availability of more
On the other hand, if a consumer has a higher Ce, it data and information about migration candidates,
indicates that the consumer is dependent on many which might be difficult. However, if such data is
provider applications, and thus a consumer-driven available, the AHP technique can help inform an
LUM model should be followed. If the Ce value optimal decision about design and sequencing.
is low for the application, it might be efficient to
The following is a comprehensive list of
migrate it as part of a provider-driven LUM.
parameters that can typically be considered in
It is not feasible to cover large applications in evaluating such cases of integration interface
one LUM due to the sheer size of call points and migrations. As this list is fairly large, the two
interfaces offered, respectively. In such cases, it’s dimensions of importance and ease of data
recommended to use a hybrid approach to LUM availability can generally be applied to identify
creation. the effective set of criteria. In this example, we
have rated the criteria based on the assumption
• In the case of a consumer-driven LUM, if the that the migration needs to be carried out with
Ce is too large to manage (see below), separate a global services provider for the landscape
LUMs must be designed by splitting the main described earlier in the paper.
LUM into sub-LUMs, each of which is driven by
one of the modular units of the consumer (e.g., As depicted in Figure 6, and based on our analysis
an accounts module in an online banking appli- and rating in the context of global migration
cation) and all providers on which the client list programs, we recommend that IT organizations
component is dependent. include the first five parameters in the initial
criteria for design and sequencing. All of these
• In the case of a provider-driven LUM, if the Ca are important, and the data to use these criteria
is too large to manage (see below), separate
LUMs must be designed by splitting the main should be available and able to be extracted with
LUM into sub-LUMs, each of which is driven minimum effort. This means the first set of criteria
by one consumer and contains the interfaces for the migration sequencing index entails:
of the provider on which the consumer is • Application dependencies: Available from soft-
dependent. ware analysis and application repository tools.
The optimal size that should be considered for the • Budget and resource availability: Available
LUMs is a single driving application with less than from program management groups.
five dependencies. This means that for a consum- • Business criticality of applications
er-driven LUM, there should be no more than five and interfaces: Available from program
provider applications. When the number is higher management groups.
for a LUM, splitting should be considered (as rec-
ommended above). That said, the complexity of
• Availability of the application and interfaces
in the development and test environments:
these interfaces should also be looked into as an Available from infrastructure teams.
important factor while deciding such a split.
• Availability of required test data: Available
Migration Unit Sequencing from infrastructure and testing teams.
As demonstrated in the previous section, the In some cases, sequencing cannot be decided
dependency metrics Ca and Ce are important upon even after applying these criteria. When this
cognizant 20-20 insights 7

8. Representative Migration Evaluation Criteria
Ease of
Parameter
Number Criteria Applicability Description Importance Data
Rating
Availability
1 Dependencies Applications See Ca & Ce discussion, page 7 Y Y YY
(implicitly depends on number of
interfaces and call points)
2 Budget and Applications Availability of budget and IT resources Y Y YY
Resource to migrate
3 Business Applications The assigned business criticality as per Y Y YY
Criticality and interfaces the organization
4 Availability in Applications Whether the elements in LUM are Y Y YY
Development and interfaces available in development and test
and Test environment for migration
Environments
5 Test Data Applications Availability of the test data in Y Y YY
Availability and interfaces the target development and test
environment for the interfaces being
migrated
6 Release Applications Suitability (for migration) of the release N Y NY
Lifecycle lifecycle of applications
7 SLA Sensitivity Interfaces SLA sensitivity, coupled with the N N NN
of Interfaces current distance of the actual
performance from expected SLA limits
8 Interface Interfaces Complexity of interface contract and Y N YN
Complexity data types used in the contract
9 Implementation All (call points, How much coupling exists between the N N NN
Coupling interfaces, integration endpoints and functional
applications) logic of the applications/service
implementation or invocation unit
10 Reengineering Applications Existence of reengineering efforts N N NN
Effort within the provider or consumer
applications
11 Special Needs Applications Special needs in terms of hosting, N N NN
testing, technology or functions
12 Technology Applications Impact of the technology platform Y N YN
Platform release on the applications to be
Release migrated
Alignment
13 Migration Applications Migration state of the participating N N NN
State of applications— especially useful in plan
Dependencies adaptations
14 Domain Spread Applications Domain spread of the consumer and N Y NY
provider applications
15 Change Cycle Applications Change cycle of the applications. Those N N NN
Suitability with rapid change cycles are suitable to
early migration if other factors such as
business criticality are suitable
16 Outstanding Applications Although the migration is technical and N N NN
Defects no functional changes are needed, the
long defect list adds to the risk
17 Documentation Applications Quality of application documentation, N N NN
Quality as it will impact the efficiency of the
integration
Figure 6
cognizant 20-20 insights 8

9. happens, other parameters can be utilized from indicative list) and the weight that should be
the list based on data availability and importance applied based on the priority of the IT organi-
in the context of the LUM being considered. For the zation planning the migration. This calculation
first level of decision-making, the five parameters is carried out for all the LUMs in the scope of
referenced above should be sufficient. planning, and the result is an ordered list of LUMs
to be developed for the migration program.
For a given duration (cycle/program), the
sequencing of the LUMs needs to be carried out Key Recommendations
along with the design of the LUM. For this, the In addition to the approach referenced above, the
same criteria-based decision-making can also be following are among the key recommendations
applied to arrive at a score, called a migration for migration design and sequencing that would
sequencing index. The index represents the be useful for large SOA technology transforma-
relative rating of the LUMs with respect to the tion programs such as the one described earlier.
risks and suitability of the LUM for migration.
Figure 7 represents the calculation model for the • It has been observed that there is sometimes
migration sequencing index in detail. a need to apply weightage correction in the
model due to organization and environment
As depicted, it is a simple weighted rating method dynamics. The cycle retrospective proposed
for determining the suitability of a unit for earlier provides an opportunity to discuss any
migration. The model is based on the maturity required corrections or actions.
analysis model that we use widely for application
migration planning. The basic model has been • In large enterprises, there are various services
that are common to the entire landscape (e.g.,
adapted to make it more suitable in the context
technical foundation services such as authori-
of SOA integration technology migration. Two
zation checks for clients). We recommend that
critical elements of the model are the criteria
these services be migrated at the first oppor-
in each category (and the previously referenced
tunity possible. This helps in two ways. On the
Determining Planned Migration Sequencing of LUMs
Establishing overall maturity profile of provider and consumer applications
# Criteria rating
High Maturity Units*
Category rating Lowest risk levels have the highest
Provider # Criteria rating potential to be grouped in the first set
Applications … * for migration.
Category weight Application risk characteristics are low
Sequencing Assessment Criteria
# Criteria rating complexity, low business criticality,
higher level of documentation, etc.
# Criteria rating
Category rating
Consumer # Criteria rating Medium Maturity Units*
Applications
…
* Medium risk levels are good candidates
Category weight
for grouping in initial set for migration.
# Criteria rating Migration
Risks contributing to medium maturity
Sequencing are capable of being mitigated through
# Criteria rating
Index various fine-tuning activities.
Interfaces Category rating
and Call # Criteria rating Can have longer knowledge harvesting
Points
… * time than high-maturity applications.
Category weight
# Criteria rating Low Maturity Units*
# Criteria rating Highest risk levels have the lowest
Category rating potential for early migration and need
Organizational # Criteria rating longer preparation time.
Elements
… *
Category weight
Applications’ risk characteristics are
higher complexity, lower level of docu-
# Criteria rating mentation, higher business criticality.
* This maturity profile is an indicator of risk involved, but the sequencing decision is
a combination of various factors, including business priority, maintainability, etc.
Figure 7
cognizant 20-20 insights 9

10. one hand, it helps bring early confidence and Conclusion
stability to the core set of services. On the
As SOA technology evolves and product vendors
other, it paves the way for a comparatively
start to phase out older technologies and
simpler migration unit design because these
middleware, enterprises will be forced to carry
services are used across many consumer appli-
out such migration cycles every eight to 10 years
cations.
(in the case of very mature technologies). Addi-
• It is critical to align the migration cycles with tionally, with the growth in adoption of SOA-style
the technical platform releases planned by architectures in the enterprise IT space, there will
the organization’s technology infrastructure always be a substantial number of technology
teams. This alignment can help achieve faster services being retired. These two aspects
time to market and better quality of deliver- mandate a managed approach to migration of
ables. SOA integration technology. We believe that
the ideas presented in this paper provide the
• During migration analysis, indirect depen-
necessary guidance to carry out these migrations
dencies on the technology to be migrated
in a manner that maximizes service coverage and
should also be identified jointly with technical
execution efficiency. It also helps minimize the
platform or framework provider organizations.
risks associated with long duration planning and
In some cases, the technical platforms offer
a tightly coupled application landscape.
components that are consuming the services
being migrated and thus, indirectly, affect While we have presented the model and evaluation
the applications consuming those platform framework for migration planning and execution,
components. the criteria and parameters that are applied can
very well vary across organizations. The maturity
There might be cases where an application must
of an organization’s IT landscape, IT processes,
be considered to be part of more than one LUM
SOA adoption and governance controls are
due to dependencies on or of other applications in
some of the environmental factors that must be
those LUMs. In such cases, this application should
carefully evaluated in the context of the migration
be migrated as part of the first LUM being moved
program being carried out. As mentioned from
in that set. This will mean that during migration
the start, although the context in the paper is that
of the remaining LUMs, the application can simply
of CORBA to Web services migration programs,
be consumed, as it is already migrated.
the principles, techniques and tactics can be
leveraged for all legacy technology migrations.
About the Author
Dinkar Gupta is an Associate Director and Principal Architect in Cognizant’s Banking and Financial
Services (BFS)Technology Consulting Group, where he heads the strategy, architecture and technology
team assisting a global BFS client. He has a post-graduate degree in computer science and applica-
tions and has 14 years of software development experience across multiple industry segments. He is
also an IBM-certified solution designer for Rational Software Architect and is actively engaged in archi-
tecture transformation consulting and solution delivery for BFS customers. Dinkar can be reached at
Dinkar.Gupta@cognizant.com.
Acknowledgments
The author would like to acknowledge the contributions of Madhura Kulkarni, Senior Manager of Projects;
Partha Basu, Manager of Projects; Diptendu Mittra, Senior Manager of Projects; Tushar Wagh, Architect;
and Rishish Kumar, Manager of Projects within Cognizant’s BFS Business Unit.
cognizant 20-20 insights 10

11. About Cognizant
Cognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-
sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered in
Teaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industry
and business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50
delivery centers worldwide and approximately 145,200 employees as of June 30, 2012, Cognizant is a member of the
NASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performing
and fastest growing companies in the world. Visit us online at www.cognizant.com or follow us on Twitter: Cognizant.
World Headquarters European Headquarters India Operations Headquarters
500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road
Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam
Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India
Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000
Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060
Email: inquiry@cognizant.com Email: infouk@cognizant.com Email: inquiryindia@cognizant.com
©
­­ Copyright 2012, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein is
subject to change without notice. All other trademarks mentioned herein are the property of their respective owners.