FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: INFORMATION TECHNOLOGY INFRASTRUCTURE
TRANSFORMATION
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor,
SERVICES LIMITED Nariman Point, Mumbai,
Maharashtra 400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to Information Technology (IT) infrastructure transformation and, in particular, relates to generating a plan for the transformation of IT Infrastructure.
BACKGROUND
[0002] IT infrastructure in modern organizations typically includes a multitude of resources, such as computing devices, desktops, laptops, servers, networking and communication hardware, storage resources, enterprise applications, operating systems, customized software, and the like. Over a period of time, the IT infrastructure tends to become large, complex and distributed over multiple facilities. Hence, infrastructure optimization is used to maximize the utility and efficiency of the IT resources. Further, organizations also have to optimize the infrastructure with changes in business practices and technology upgrades. The IT infrastructure optimization process inevitably involves one or more sub-processes, such as migration, consolidation, expansion, modification and addition of infrastructural elements. These sub-processes can be, individually and collectively, referred to as IT infrastructure transformation.
[0003] Generally, the number of transformation options available in a modern organization is enormous since a number of infrastructural elements and operational constraints have to be handled together. Usually the task is achieved with considerable expense of money, resources and time, and yet the transformation process may not be efficient. This is because, the transformation process is conventionally based on manual planning, which may not be effective in case of complex transformation processes and so, results in a sub-optimal transformation.
SUMMARY
[0004] This summary is provided to introduce concepts related to generating a plan for IT Infrastructure transformation, and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject

matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, the method includes analyzing an initial IT infrastructure specification and a target IT infrastructure specification based on data in a knowledge repository to determine a transformation specification, the transformation specification including an ordered series of tasks and steps for each task. The method further includes translating the transformation specification into a planning specification in a planning language, the planning specification comprising planning operators to operate on software and hardware objects based on an initial state of each object, a final state of the each object and dependencies between the objects. The planning specification can then be converted into a transformation plan, which meets at least one planning objective, using a planner tool. The transformation plan includes actions corresponding to the planning operators and time duration for performing each action.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying figures. In the figures, the right-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1 illustrates a system for generating a plan for IT Infrastructure transformation, in accordance with an embodiment of the present subject matter.
[0008] Fig. 2 illustrates a method for generating a plan for IT Infrastructure transformation, in accordance with an embodiment of the present subject matter.
[0009] Fig. 3 illustrates task levels of an example of a plan for IT Infrastructure transformation.
[0010] Fig. 4 illustrates an example of a transformation plan presented as a Gantt chart depicting the transformation plan of fig. 3.
DETAILED DESCRIPTION
[0011] Systems and methods for IT infrastructure transformation are described herein. The systems and the methods can be implemented in a variety of computing devices, such as laptops, desktops, workstations, mainframe computers, and similar systems. However, a person skilled in

the art will comprehend that the embodiments of the present subject matter are not limited to any particular computing system, architecture or application device, as they may be adapted to take advantage of new computing systems and platforms as they become available. [0012] Generally, modern organizations use a variety of IT resources, which form the IT infrastructure to support front end operations. Over a period of time, the IT infrastructure tends to become large, complex and distributed, leading to high operational cost, low utilization and brittleness. Hence, organizations make regular efforts to transform the IT infrastructure to make it smaller, more cost-effective and easily manageable. At times, IT infrastructure transformations are also performed in accordance with changing business practices and technology upgrades.
[0013] For the IT infrastructure transformation, the organizations are generally able to prepare initial and target IT infrastructure specifications based on overall transformation objectives. However, the specifications have to be converted into an executable plan while meeting other objectives related to optimized execution time, efforts, team size required, and risks to business operations. Preparing such a plan involves identifying detailed tasks for migrating the resources, such as system software, databases, middle-ware and business application software, along with data across different servers. There may be several kinds of dependencies, such as among the servers and business applications, among different business units, IT applications and data, and precedence to be followed among different tasks, which have to be taken into account when preparing the plan.
[0014] Such transformation plans are conventionally prepared manually from the IT infrastructure specifications using inputs from multiple teams of experts. For example, IT infrastructure transformation specification may be created by an analyst team, plan specification may be created by another team, practical constraints information and other domain knowledge may be provided by different teams, while execution of the plan may be carried out by a transformation execution team. Therefore, it becomes difficult to capture and use relevant information for generating and executing the plan. Hence, the manual preparation of the transformation plans can be a large, time-consuming and error-prone task, very often leading to sub-optimal plans. Moreover, it may not be practically feasible to dynamically re-plan in case of deviations, delays and errors in completing transformation tasks during execution of the transformation plan.

[0015] Certain conventional methods provide for automated generation of a high level IT transformation plan based on pre-configured rules. However, these conventional methods do not take into account practical constraints like availability of team members, expertise, and number of persons required per task, and domain specific constraints like the dependencies mentioned above. This can lead to a plan which is sub-optimal and resources are either over-utilized or under-utilized for a given task under the plan. Further, even with such plans it may not be feasible to dynamically incorporate changes, for example, due to a sudden change of strategy or to absorb deviations, delays and errors in the execution.
[0016] The present subject matter describes systems and methods for generating a plan for transformation of Information Technology (IT) infrastructure from an initial specification to a target specification.
[0017] In one implementation, the initial specification and the target specification, collectively referred to as specifications, are received by a system. The specifications can include various elements of the transformation to be achieved, such as business applications, existing system configurations, target system configurations, time zones, available time for transformation, and the like. The specifications can be analyzed to determine practical constraints, such as availability of human resources, time duration, time zones where servers are utilized and shipping data from original data-center to new data-center. Furthermore, domain-specific constraints, such as priorities of business applications, inter-dependencies of business applications and inter-dependencies among IT applications carried out by different servers, can also be determined.
[0018] In one implementation, the system first identifies transformation tasks to be performed to transform the initial specification to the target specification, based on a knowledge repository. The knowledge repository can include all domain knowledge, business knowledge, and practical knowledge, and can be built over a period of time based on prior transformation experience, inputs from IT, operation and business stakeholders, and expert inputs. Thus, knowledge can be effectively captured and re-used without having to collect the information for every instance of an IT infrastructure transformation.
[0019] Based on the knowledge repository, detailed steps are also identified for each transformation task. The detailed steps and the transformation tasks are further analyzed, again

based on the knowledge repository, to determine the practical constraints and the domain-specific constraints and to generate a transformation specification having ordered transformation tasks and corresponding steps.
[0020] The system can then translate the transformation specification to a planning specification of a planning problem, for example, in a standard planning language, such as Planning Domain Definition Language (PDDL). In one implementation, the planning specification includes planning operators that correspond to the steps in the transformation specification. The planning operators can operate on different objects, such as hardware and software components, which undergo the transformation. Further, the system can add an initial state and a final state of each object to the planning specification and can verify whether the planning operators are consistent with dependencies that each object may have with one or more other objects. In one implementation, the dependencies may be identified based on the knowledge repository. In another implementation, domain knowledge experts can provide inputs to additionally identify and check the dependencies, and refine the planning specification.
[0021] Based on the planning specification, the system can generate a plan using a planner tool. In one implementation, the plan can be generated using an artificial intelligence (AI) domain-independent metric temporal planner which accepts domain and problem specification in planning domain language PDDL. For example, the system can generate the plan using SAPA, Crikey-3, etc., as the planner tool. The planner tool can receive the planning specification as input along with at least one planning objective. The planning objective can be, for example, minimization of time required, minimization of team size required, minimization of risks involved, and the like. Based on the planning specification and the at least on planning objective, the planner tool can generate a detailed executable temporal plan for transformation. The transformation plan so generated by the system is a series of sequenced actions that obey the dependencies and order given in the planning specification. Further, the transformation plan can also include the duration required for each action for optimum execution of the plan. In one implementation, the plan may be refined based on the domain knowledge in the knowledge repository. In another implementation, expert inputs can also be used to verify consistencies of dependencies and time durations allocated.

[0022] Further, the system can convert the transformation plan into various output files like Gantt Charts, team size and skill matrix, flow chart, and the like. These output files can then be provided to a user for plan execution.
[0023] In one implementation, based on user inputs, execution of the transformation plan can also be tracked. Any changes that may be required in the transformation plan can be incorporated by changing one or more inputs to the system, such as the specifications, data in the knowledge repository, the dependencies, and the planning objectives. The transformation plan can then be re-generated accordingly to dynamically incorporate real-time effects.
[0024] Transformation plans that are thus created are more efficient, objective and near optimal as compared to the conventional plans, since these transformation plans are generated using domain knowledge and business knowledge that is captured, re-used and kept updated in the knowledge repository, rather than relying on manual inputs alone. Further, the transformation plans can be easily designed to meet one or more planning objectives, which is difficult to achieve when creating a complex plan manually. Also, new plans can be re-generated dynamically to cater to real-time constraints and conditions observed during execution of the plan with minimal duplication of efforts. The above described systems and methods can be used for various kinds of IT infrastructure transformations including consolidation, migration and simplification.
[0025] These and other advantages of the present subject matter would be described in greater detail in conjunction with the following figures. While aspects of described systems and methods IT Infrastructure transformation can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
[0026] Fig. 1 illustrates a system 100 for generating a plan for IT infrastructure transformation, according to an embodiment of the present subject matter. It will be understood that the system 100 can be implemented in any computing device, such as mainframe computers, workstations, personal computers, desktop computers, multiprocessor systems, laptops, network computers, minicomputers, servers, and the like. In addition, the system 100 may be a single device or a collection of devices, such as a server farm. The system 100 may also include multiple servers to perform mirrored tasks for load balancing.

[0027] In one implementation, the system 100 includes one or more processor(s) 102, input/ output (I/O) interfaces 104, and a memory 106 coupled to the processor 102. The processor 102 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor 102 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 102 is configured to fetch and execute computer-readable instructions and data stored in the memory 106.
[0028] The I/O interfaces 104 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, a display unit, an external memory, and a printer. Further, the I/O interfaces 104 may enable the system 100 to communicate with other devices, such as web servers and external databases. The I/O interfaces 104 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interfaces 104 may include one or more ports for connecting a number of computing systems with one another or to a network.
[0029] The memory 106 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In one implementation, the memory 106 also includes modules 108 and data 110. It will be understood that in other implementations, the modules 108 and the data 110 may be present outside the memory 106, for example, in other hardware components.
[0030] The modules 108, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. In one implementation, the modules 108 further include an analysis module 112, a translation module 114, a planner module 116, a track and update module 118, and other module(s) 120. The other modules 120 may include programs that supplement applications on the system 100, for example, programs in the operating system.

[0031] The data 110 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules 108. The data 110 includes specification data 122, plan data 124, and other data 126. The other data 126 includes data generated as a result of the execution of one or more modules in the modules 108.
[0032] In operation, in accordance with one implementation, the analysis module 112 can receive an initial IT infrastructure specification, also referred to as an initial specification, and a target IT infrastructure specification, also referred to as a target specification, from a user or a memory device. The initial specification and the target specification can be collectively referred to as specifications 128 and can be stored in the specification data 122. It will be understood that the specifications 128 can be received from any source, such as a separate computing device connected to the system 100 or from an external memory device or can be input directly into the system 100 by a user.
[0033] The analysis module 112 can analyze the specifications 128 to determine transformation tasks, detailed steps for each task, and practical and domain-specific constraints. The transformation tasks include high level activities to be carried out to achieve the transformation from the initial specification to the final specification. The detailed steps for each task include the actions to be taken to complete the corresponding task. The practical constraints include resource and scheduling constraints, such as availability of human resources, time duration for cutout, time zones where servers are utilized, and the like. The domain-specific constraints include priorities of business applications, interdependencies of business applications, interdependencies of IT applications, hardware and software configurations, and the like. Based on the identified transformation tasks, detailed steps and constraints, the analysis module 112 can generate a transformation specification, which is a set of ordered tasks and steps. The transformation specification thus generated can also be stored in the specification data 122.
[0034] For example, in case of a transformation related to data center migration, if a source server uses a dataset, then the dataset also needs to be migrated to a target server. The migration of dataset can be identified as a transformation task, which can include a multitude of steps, such as taking backup of the dataset, migration of the dataset, installing the dataset and testing the dataset. Similarly, other transformation tasks and corresponding detailed steps can be identified for achieving the data center migration. These tasks and steps can be ordered based on

constraints, such as operating system (OS) has to be migrated before the dataset is migrated. Thus the transformation specification can be generated.
[0035] To determine the transformation tasks, the detailed steps, and the practical and domain-specific constraints, the analysis module 112 can use data stored in a knowledge repository 130. The knowledge repository 130 can be understood as a collection of domain knowledge, practical knowledge, and business knowledge related to an organization and its IT infrastructure.
[0036] The knowledge repository 130 can be built over a period of time, based on knowledge that can be captured in different instances of an IT infrastructure transformation and re-used for future instances. The domain knowledge, such as knowledge of data centers, can be captured, for example, in the form of rules, constraints and restrictions, based on inputs from domain experts and IT administrators. The practical knowledge, such as manpower and time zones, can be captured based on inputs from the IT administrators and stakeholders, such as an operations team. The business knowledge, such as business divisions and business applications, can be captured based on inputs from business stakeholders. Further, the knowledge repository 130 can be updated by adding new data and modifying existing data as may be required for a particular transformation instance. By using a knowledge repository 130, the previously gathered knowledge can be effectively re-used and built upon, thereby saving time, effort and resources as compared to conventional methods where the knowledge has to be gathered afresh for each instance of an IT infrastructure transformation.
[0037] In one implementation, the specifications 128 and the transformation specification can also be analyzed by domain experts and the transformation specification can be fine tuned based on inputs provided by the domain experts.
[0038] The analysis module 112 provides the transformation specification to the translation module 114, which can translate the transformation specification into a planning specification of a planning problem. The planning specification can also be stored in the specification data 122. In one implementation, the translation module 114 can generate the planning specification in a standard planning language, such as Planning Domain Definition Language (PDDL). The planning specification can include planning operators that correspond to the steps in the transformation specification and are associated with pre-conditions and post-conditions. The

planning operators can operate on different objects, such as hardware and software components, which are part of the transformation specification. The pre-conditions correspond to conditions which have to be satisfied before the planning operator can be executed, while the postconditions correspond to effects of execution of the planning operator. Examples of the preconditions include object name, type, current status, resources to be utilized, availability of the resources, and the like. Examples of post-conditions include final state of the objects, availability of resources after transformation, and the like.
[0039] In one implementation, the translation module 114 determines the planning operators based on domain knowledge present in the knowledge repository 130. Further, the translation module 114 can add an initial state and a final state of each object, dependencies between the objects, and expected time required to execute each step in the planning specification. The translation module 114 can also verify whether the planning operators are consistent with dependencies that each object may have with one or more other objects. In one implementation, the dependencies may be identified based on the domain knowledge in the knowledge repository 130. In another implementation, domain knowledge experts can provide inputs to additionally identify and check the dependencies, and refine the planning specification.
[0040] The translation module 114 sends the planning specification to the planner module 116 for generation of a transformation plan 132. The planner module 116 also receives at least one planning objective as an input from a user. The planning objective can be, for example, minimization of time required, minimization of team size required, minimization of risks involved, and the like. The planner module 116 can generate the transformation plan 132 from the planning specification such that the transformation plan 132 meets one or more planning objectives as provided by the user. In one implementation, the planner module 116 can use any known planner tool for multi-objective temporal planning. For example, the planner module 116 can use an AI domain-independent metric temporal planner which accepts domain and problem specification in planning domain language PDDL. For example, the planner module 116 can generate the plan using SAPA, Crikey-3, etc., as the planner tool.
[0041] The transformation plan 132 so generated is a series of sequenced actions that obey the dependencies, the pre-conditions and the post-conditions given in the planning specification and also meet the provided planning objectives. In one implementation, the transformation plan

132 also includes the duration required for each action under the plan for optimum execution of the plan. The duration specified for an action may be a fixed time period, a variable time period, or a time period dependant on size or complexity of data to be processed in the action. Further, the transformation plan 132 can also include details of the team carrying out the transformation tasks, their expertise, their availability, etc., and for each task, an expert to carry out the task can also be specified. Therefore, the transformation plan 132 is a multi-agent temporal plan, which includes details of team being utilized and duration of utilization of different teams to carry out the transformation along with detailed actions.
[0042] Further, the transformation plan 132 may be refined based on domain knowledge in the knowledge repository 130 and additionally, expert inputs may also be used to verify consistencies of dependencies and time durations allocated. Thus, based on the planning specification and the at least on planning objective, the planner module 116 can generate the transformation plan 132, which is an executable detailed temporal plan for the transformation. The transformation plan 132 can be saved in the plan data 124.
[0043] In one implementation, the planner module 116 can generate output files in one or more formats for providing the transformation plan 132 to the user in a user-friendly format for use during execution of the plan. For example, the output files can include Gantt chart, flow chart, Microsoft Excel TM workbooks, and other auxiliary outputs as will be understood by a person skilled in the art. The output files can be saved in the plan data 124, and can be provided to the user via any peripheral device, such as a display device, a printer or a memory device.
[0044] Further, the track and update module 118 can be used to monitor the execution of the transformation plan 132 and revise the transformation plan 132 by taking into account real-time effects, such as changes in the specifications 128, delays or errors in execution of the plan, and the like. In one implementation, the track and update module 118 can utilize one or more the analysis module 112, the translation module 114, and the planner module 116 to dynamically incorporate the real-time effects and accordingly re-generate the transformation plan 132.
[0045] Fig. 2 illustrates a method 200 for generation of IT infrastructure transformation plan, according to one embodiment of the present subject matter. The method 200 may be implemented in a variety of computing systems in several different ways. For example, the

method 200, described herein, may be implemented using the system 100 for generation of IT Transformation Plan, as described above.
[0046] The method 200, completely or partially, may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. A person skilled in the art will readily recognize that steps of the method can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described method 200.
[0047] The order in which the method 200 is described is not intended to be construed as a limitation, and some of the described method blocks can be combined to implement the method, or an alternative method. Additionally, some of the individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. It will be understood that even though the method 200 is described with reference to the system 100, the description may be extended to other systems as well.
[0048] At block 202, IT infrastructure specifications including an initial specification and a target specification are analyzed to generate a transformation specification. For example, the analysis module 112 can analyze the specifications 128 to determine transformations tasks, detailed steps, and practical and domain-specific constraints, based on data stored in the knowledge repository 130. The analysis module 112 can then accordingly generate the transformation specification.
[0049] At block 204, the transformation specification is translated into a planning specification using a planning language. In one implementation, the planning specification includes planning operators that operate on software and hardware objects in accordance with dependencies, pre-conditions and post-conditions that are determined based at least in part on domain knowledge in the knowledge repository. For example, the translation module 114 can generate the planning specification using Planning and Domain definition Language (PDDL).

The planning specification so generated can also be refined based on the knowledge repository 130 and expert inputs.
[0050] At block 206, a transformation plan is generated from the planning specification and based on at least one planning objective. In one implementation, a planner tool is used to generate the transformation plan using an AI domain-independent metric temporal planner which accepts domain and problem specification in planning domain language PDDL.. For example, the planner module 116 can generate the plan using SAPA, Crikey-3, etc., as the planner tool. Further, the planning objectives can be one or more of minimization of total time required, minimization of total team size required or minimization of risks involved, and like.
[0051] At block 208, the plan can be converted into output files of various formats and can be provided to the user for use during execution. For example, the planner module 116 can generate output files, such as Gantt chart, flow chart and other auxiliary output files, and can provide the output files to the user.
[0052] Thus, the method 200, helps in systematically generating an executable plan from given IT infrastructure specifications using domain knowledge and business knowledge that can be captured, for example, in the form of rules, constraints and restrictions, in a knowledge repository and re-used therefrom. The plan also includes a schedule of transformation and takes into account not only the IT infrastructure constraints, but also real transformation execution constraints like time zone of stake holders, team availability, etc. Hence, the plan generated is efficient, objective and near optimal and is designed to meet one or more planning objectives. Further, as described with reference to fig. 1, execution of the plan can also be efficiently tracked and dynamic re-planning can be performed at any stage in the face of delays or any other problems or conditions that may arise.
[0053] Fig. 3 illustrates task levels 300 in an example plan for data center migration. In this example, the goal is to consolidate all IT infrastructure resources from N source data centers into M target data centers, where M < N. Such a transformation is typically made to save operating costs, and to simplify, rationalize or upgrade the IT infrastructure resources, such as servers, databases, system software, storage, application software, etc., used in the data center.
[0054] In this example, the source data centers may be divided into movegroups. A movegroup can include a subset of servers in the source data center such that each server in a

source data center can belong to at most one movegroup. Further, the movegroup can also include related group of applications and datasets that have to be moved together. Hence, everything running on the servers in a specific movegroup will be migrated together to run on corresponding new servers in the target data centers. Hence, the data center migration process can be first broken down into movegroup level tasks 302.
[0055] For this, the specifications for the source and target data centers can be broken down into a set of specifications of the movegroups. Each movegroup specification includes complete details of each server in it, for example, number of Central Processing Units (CPUs), Memory, Disk, Operating Systems used, special-purpose hardware devices connected to it, system software running on it, details of business applications running on it, and the like. Such a movegroup specification is obtained for each source server as well as each target server in the movegroup. The movegroup specification also specifies which source servers are mapped to which target servers.
[0056] For example, consider a case where a movegroup includes 4 servers at the source data center, and out of the 4 servers, one server is installed with AIX operating system (OS), and the other three, with Windows. The server with AIX OS, may be a database server, while out of the three Windows servers, two may be application servers and the remaining one may be a Web server. Hence the movegroup specification will include the aforementioned details. The movegroup specification can also specify that the Web server is to be transformed as physical to physical (P2P) while the two application Windows servers have targets as physical to virtual (P2V) and the AIX database server is to be transformed as Logical Partition (LPAR). Accordingly, as a person skilled in the art would identify, the movegroup level task 302 can include making mksysb and copy mksysb for all AIX servers which are not SAN (storage area network) booted.
[0057] Each of the movegroup tasks 302 can be divided into business application level tasks 304-1, 304-2…304-n, collectively referred to as 304 hereinafter. For execution of business application level tasks 304, each business application can be picked in a sequence as per their priority based on application dependency and urgency of migrating the application.
[0058] The business application level tasks 304 can be further divided into server level tasks 306-1, 306-2…306-n, collectively referred to as 306 hereinafter, such as hand-over of servers,

belonging to the application, from owner of the servers to transformation execution team, etc. Further, in this example, at server level, one server may be running on the Windows platform, while other three may be used in Linux or AIX platforms. So, the three servers running on AIX or Linux platform have to be handled differently from the servers running on Windows platform as the dependencies vary. Thus, each server level task 306 includes some common tasks 308 and domain dependent tasks 310. Once, the server level tasks 306 of a business application are transformed, again the business application level tasks 304 like Go-Live may be executed. Thus, at each level of transformation, there are multiple objects to be handled with different dependencies and different software or hardware configuration, making this a multi-path problem.
[0059] In one implementation, the systems of Fig. 1 and methods of Fig. 2 facilitate identification of the multiple paths as per the given initial and target specifications of the data center migration and create domain-specific plans for the different task levels 300 of the transformation plan. The domain information, like the tasks at different levels to be carried out and their precedence, etc., are captured in PDDL (Planning Domain Definition Language) format as actions based on data stored in the knowledge repository 130.
[0060] For every instance of transformation for which plan has to be prepared, a transformation specification can be translated into a planning specification in PDDL format. Further, the planning specification can be used to generate a plan using an AI domain-independent metric temporal planner which accepts domain and problem specification in planning domain language PDDL. The plan can be provided to the user in an output file in an easy to understand format. For example, the transformation plan may be provided to the user as a Gantt Chart, which provides visual details of the generated plan, which task is being carried out for what duration, at what time point starts and at what time point stops. An example Gantt chart 400 for the movegroup level task 302 in the above example is illustrated in Fig. 4. The Gantt chart 400 can then be used to execute the transformation and track the progress of the execution of the movegroup level task 302.
[0061] Although implementations of generation of an IT infrastructure transformation plan have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or

methods described. Rather, the specific features and methods are disclosed as implementations for generation of a plan for IT infrastructure transformations.

I/We Claim:
1. A system (100) for generating a transformation plan for information technology (IT)
infrastructure transformation, the system (100) comprising:
a processor (102) configured to fetch and execute instructions;
an analysis module (112) coupled to the processor (102), the analysis module (112) being configured to analyze an initial IT infrastructure specification and a target IT infrastructure specification based on data in a knowledge repository (130) to determine a transformation specification, the transformation specification including an ordered series of tasks and steps for each task;
a translation module (114) coupled to the processor (102), the translation module (114) being configured to translate the transformation specification into a planning specification in a planning language, the planning specification comprising planning operators to operate on software and hardware objects based on an initial state of each object, a final state of each object, and dependencies between the objects; and
a planner module (116) coupled to the processor (102), the planner module (116) being configured to generate the transformation plan (132) from the planning specification using a planner tool, wherein the transformation plan (132) includes actions corresponding to the planning operators and time duration for performing each action, and wherein the transformation plan (132) meets at least one planning objective.
2. The system (100) as claimed in claim 1, wherein the planner module (116) is further configured to generate one or more output files in a readable format and provide the output files to a user.
3. The system (100) as claimed in claim 1, wherein the data in the knowledge repository (130) comprises practical knowledge data, business knowledge data, and domain knowledge data in form of rules, constraints, and precedence.
4. The system (100) as claimed in claim 1 further comprising a track and update module (118) coupled to the processor (102), the track and update module (118) being configured to regenerate the transformation plan (132) based on real-time effects received from a user, wherein the real-time effects include at least one of deviations, errors, and delays.

5. The system (100) as claimed in claim 1, wherein the translation module (114) is configured to translate the transformation specification into the planning specification in Planning and Domain Definition Language (PDDL).
6. The system (100) as claimed in claim 1, wherein the planner module (116) is configured to generate the transformation plan from the planning specification using an AI domain-independent metric temporal planner which accepts domain and problem specification in planning domain language PDDL.
7. The system (100) as claimed in claim 1, wherein the at least one planning objective is selected from minimization of time required, minimization of team size required and minimization of risks involved.
8. A method for generating a transformation plan for IT infrastructure transformation, the method comprising:
analyzing an initial IT infrastructure specification and a target IT infrastructure specification based on data in a knowledge repository to determine a transformation specification, the transformation specification including an ordered series of tasks and steps for each task;
translating the transformation specification into a planning specification in a planning language, the planning specification comprising planning operators to operate on software and hardware objects based on an initial state of each object, a final state of the each object, and dependencies between the objects; and
generating a transformation plan from the planning specification using a planner tool, the transformation plan including actions corresponding to the planning operators and time duration for performing each action, wherein the transformation plan meets at least one planning objective.
9. The method as claimed in claim 8 further comprising creating one or more output files in
a readable format from the transformation plan and providing the output files to a user.

10. The method as claimed in claim 8, wherein the data in the knowledge repository comprises practical knowledge data, business knowledge data, and domain knowledge data in form of rules, constraints and restrictions.
11. The method as claimed in claim 8 further comprising refining the planning specification and the transformation plan based on expert inputs.
12. The method as claimed in claim 8 further comprising
receiving execution updates and real-time effects from a user, wherein the realtime effects include at least one of deviations, errors, and delays; and
re-generating the transformation plan based on the real-time effects.
13. The method as claimed in claim 8, wherein the planning language is Planning and Domain Definition Language (PDDL) and the planner tool uses an AI domain-independent metric temporal planner which accepts domain and problem specification in planning domain language PDDL.
14. The method as claimed in claim 8, wherein the at least one planning objective is selected from minimization of time required, minimization of team size required and minimization of risks involved.
15. A non-transitory computer-readable medium having embodied thereon a computer
program for executing a method comprising:
analyzing an initial IT infrastructure specification and a target IT infrastructure specification based on data in a knowledge repository to determine a transformation specification, the transformation specification including an ordered series of tasks and steps for each task;
translating the transformation specification into a planning specification in a planning language, the planning specification comprising planning operators to operate on software and hardware objects based on an initial state of each object, a final state of the each object and dependencies between the objects; and
generating a transformation plan from the planning specification using a planner tool, the transformation plan including actions corresponding to the planning operators

and time duration for performing each action, wherein the transformation plan meets at least one planning objective.