Your SlideShare is downloading. ×

An Execution Approach to Large-Scale SOA Technology Migration


Published on

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

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

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. • Cognizant 20-20 InsightsAn Execution Approach for Large-ScaleSOA Technology MigrationA pragmatic planning and execution model can effectively modernizeintegration 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,000programs impact multiple stakeholders, and providers that offered 2,500 business services,therefore, the coordination effort is typically quite consumed by about 400 consumer applicationslarge. In addition, these programs have a lifetime through the common middleware mentionedof four to five years; this extended time horizon earlier.presents problems such as a lack of long-termvisibility, risk of strategy change midway, change Migration Elementsin organization priorities (and thus funding), etc. Before outlining the approach for migration, it is important to understand the key elementsGiven this situation, enterprises need a holistic, involved in migrating integration technology. Eachtop-down approach to program management of these elements will be part of the migrationand planning. Technology typically is the least units (defined in the next section) that areof 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 consideredprovide 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 inexecution and its internal optimization, based SOA is the logical, self-contained businesson our experience with migration of the core function offered by the provider of thebanking services of a global bank from an end- service for the consumer of the service andof-life integration technology (CORBA) to current is described by a well-defined functional/datamainstream technology (SOAP/HTTP Web delivery contract between these two The previous landscape consisted of The service interface is the primary manifesta-core banking systems mostly implemented on tion of the service, describing both functionalmainframe systems and front-end channel appli- (service signature) and quality of servicecations implemented on contemporary tech- (execution and invocation policies) aspects ofnologies — Java and .NET. From an SOA perspec- the offered service. While in the case of CORBAtive, more than 80% of service providers offer the interface is described in the form of IDL andmainframe-based applications, while the rest are NS configurations, the Web services technologydelivered via Java technology. makes use of WSDL, XSD and associated WS- artifacts to describe the same.These services were provided to consumersvia common middleware built on a service bus • Service provider (provider application/topology (see Figure 1). The bank had already component): These applications are the onesestablished mechanisms for SOA governance and that host the actual functionality/data beingmiddleware 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 inIntegration 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 ApplicationFigure 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 DesignAs the first executable step in the migrationprogram, the services that were so far available inCORBA need to be modeled as per the standardsof Web service technology. Subsequently, the code Providerartifacts of newly created Web services need to Integrationbe generated or implemented (as appropriate) forintegration 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 incrementalunits are designed and sequenced after taking manner. The model that follows is based on thismultiple factors into account. Each migration consideration.cycle (described later) executes a set of migrationunits planned for the duration of the cycle. For Overall Execution Modelsimplicity and easier reference, we will use a The execution model recommended for theshorter name — LUM (logical unit of migration) — migration program is based on the notion ofthroughout the rest of this paper. stages, where each stage has different require- ments in terms of milestone delivery and thusAn example of such a migration unit would be a requires its own delivery model.LUM containing one consumer application with15 call points that are consuming 15 service The three stages depicted in the model representinterfaces provided by six different service the progression in the lifecycle of a serviceprovider applications. Such a configuration would interface to be migrated. While Stage 1 lendstypically be called a consumer-driven migration itself to a one-time delivery style, Stage 2 is moreunit, which is described later. suited for following a factory-like approach to migrate the interfaces in migration cycles. StageMigration Lifecycle Model 3, on the other hand, involves on-demand deliveryAs 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 StageIT landscapes, it is critical to adopt an approach 2 is where the actual migration of applicationsbased on an agile philosophy of delivering in to the new interface is carried out. As soon as allmultiple iterations instead of a big-bang, four-year applications dependent on migrated interfaceswaterfall planning approach. That said, such a move over and accept the new interface, the oldlong 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 Cyclesdelivery models of their own, the entire process Properly defined planning and governanceof technology transformation goes through four units, as well as the criteria leading to designworkstreams (in line with what is depicted in and sequencing of the LUM, are two of the keyFigure 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 migrationFigure 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 isdelivered. At the end of each workstream, a typically too large to apply this mechanism, wegovernance mechanism in the form of a quality recommend assessing and planning the migrationgate 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, andacceptance criteria specified for the deliverables the entire migration program is a set of cycles. Inof the workstream. each migration cycle, a set of LUMs is planned andThree foundational elements are critical to all migrated. The application of cycles is an internallarge 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 aand, 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 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 theestablishing 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 arenot 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 nextby applying the approach recommended in this migration execution starts. This migration cyclepaper 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 withinscope 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 Optimizationthat might need to be incorporated during the The design of the migration units — and the orderprogram lifecycle based on the changing business in which these are planned to be released — isand 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 migrationyearly budgeting cycle. Considering the migration elements and their interdependencies, on thescope presented earlier and the size of a sample other we have to take care of the contextualmigration 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 followsexecution 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 alsoThe 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 LUMsLUMs to be migrated in a cycle, with each LUM might be composite in nature and of manageablemigrating a combination of one consumer and size and complexity, meaning we may have toup 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 examinedduring the entire program. is inter-application dependency in the form of coupling. Both afferent and efferent couplingThe 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 numberstarted so that all the necessary preparation, of consumer applications that depend uponplanning, dependency resolution, syndication interfaces of the provider application. It is anParallel 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 simpledriven LUM will be a preferred approach. A lower weighted rating method (described below) canCa indicates a provider with fewer consumers be applied. Another option is to use a formaldependent on it and thus can be considered for a technique such as an analytic hierarchy processmigration unit driven by one of these consumers. (AHP), but that would require availability of moreOn 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 isprovider applications, and thus a consumer-driven available, the AHP technique can help inform anLUM model should be followed. If the Ce value optimal decision about design and low for the application, it might be efficient to The following is a comprehensive list ofmigrate it as part of a provider-driven LUM. parameters that can typically be considered inIt is not feasible to cover large applications in evaluating such cases of integration interfaceone LUM due to the sheer size of call points and migrations. As this list is fairly large, the twointerfaces offered, respectively. In such cases, it’s dimensions of importance and ease of datarecommended to use a hybrid approach to LUM availability can generally be applied to identifycreation. 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: AvailableLUMs is a single driving application with less than from program management groups.five dependencies. This means that for a consum- • Business criticality of applicationser-driven LUM, there should be no more than five and interfaces: Available from programprovider 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: AvailableMigration Unit Sequencing from infrastructure and testing teams.As demonstrated in the previous section, the In some cases, sequencing cannot be decideddependency 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 ParameterNumber 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 integrationFigure 6 cognizant 20-20 insights 8
  • 9. happens, other parameters can be utilized from indicative list) and the weight that should bethe 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 calculationfirst level of decision-making, the five parameters is carried out for all the LUMs in the scope ofreferenced 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), thesequencing of the LUMs needs to be carried out Key Recommendationsalong with the design of the LUM. For this, the In addition to the approach referenced above, thesame criteria-based decision-making can also be following are among the key recommendationsapplied to arrive at a score, called a migration for migration design and sequencing that wouldsequencing 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 sometimesmigration sequencing index in detail. a need to apply weightage correction in the model due to organization and environmentAs depicted, it is a simple weighted rating method dynamics. The cycle retrospective proposedfor determining the suitability of a unit for earlier provides an opportunity to discuss anymigration. The model is based on the maturity required corrections or actions.analysis model that we use widely for applicationmigration 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 thatcritical 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 theDetermining 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 maturityThere 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 aredue to dependencies on or of other applications in some of the environmental factors that must bethose LUMs. In such cases, this application should carefully evaluated in the context of the migrationbe migrated as part of the first LUM being moved program being carried out. As mentioned fromin that set. This will mean that during migration the start, although the context in the paper is thatof 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 AuthorDinkar Gupta is an Associate Director and Principal Architect in Cognizant’s Banking and FinancialServices (BFS)Technology Consulting Group, where he heads the strategy, architecture and technologyteam 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 isalso 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 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 CognizantCognizant (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 inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 145,200 employees as of June 30, 2012, Cognizant is a member of theNASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at 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: Email: Email:©­­ 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 anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.