Infosys – eBook | 11
3.4 Application Interdependencies 
Today’s complex application architectures interface with large number of other Enterprise & business applications. Migrating 
complete / partial application infrastructure to another data center does not only need a due-diligence from all the facets of 
application in question, but also need a thor
would assist in first understanding the existing interdependencies and then in evolving appropriate Move Bundles. Some 
dependencies during migration window. 
ocessing may require that such applications 
be bundled together for the purpose of migration.
dependencies:
Particular 
Description 
Interface Name 
Name of the interface 
Related Application 
Unique Application Identifier of the interfacing Application 
Initiator 
Application / Bound Application 
Description 
A brief description of the interface 
Direction 
Direction of dependency (Inbound / Outbound / Both) 
Layer Making Connection 
Web / Application / Database Layer 
Latency Sensitivity 
Yes (If tolerance is < 50 ms, No if tolerance is > 50 ms) 
Protocol 
HTTP / SOAP / NDM / FTP etc. 
Bind Environment 
Applications have both Mainframe and distributed components.) 
Frequency of Access 
Daily Batch, Real-time, Adhoc etc. 
Tolerance for unavailability Can process without impact / Can process with impact / cannot process at all 
Integration Type 
Pr
of
3.5 Current Facilities Profile 
In order to plan the capacity & nature of facilities environment needed in the target data center viz. Floor Space, Number 
& Type of Racks, Power, Power Distribution system, Network & Storage Cabling, Air-conditioning systems etc. it is 
important to conduct an assessment of source data center facilities infrastructure. The utilization and pain points (if any) 
in existing facilities will provide meaningful data to plan capacity, distribution & design of target data center facilities. A 
mapping between the IT Infrastructure profile (hardware devices deployed), allocated facilities capacity, utilization patterns, 
Assessment of past outages, shortcomings provides information about:
• Total Allocated UPS power, % utilization (peak & average) 
• Battery backup time 
• BTUs of Heat dissipated by different hardware 
• Distribution pattern of dissipated heat based on Server rack layout and hardware mounted in each rack. 
• Any hot spots needing extra cooling, suction of heat / redistribution of hardware dissipating heat to racks where 
enough cooling is available etc. 
• essure 
• Energy consumption patterns 
• Handling capacity of PDUs, % utilization 
• Any Single points of failure 
• Any capacity bottlenecks 
Converter pdf to powerpoint - C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
and paste pdf into powerpoint; pdf conversion to powerpoint
Converter pdf to powerpoint - VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
how to convert pdf into powerpoint on; change pdf to powerpoint
12 | Infosys – eBook
Business Service Reviews (BSR) 
It is very important to understand the service level expectations defined by business to ensure that all Data Center Migration 
Planning, Build & Test work is base lined in view of the same. 
4.1 Why do we need to conduct BSR? 
Business Service Reviews aropriate / cost 
effective Service level objectives are defined / agreed at. 
• What level of availability does your business require? 
• How much data is the business willing to lose in a catastrophic event? 
• How will you mitigate data loss? 
• How much revenue will be lost or additional expenses incurred by an unscheduled system outage for different 
durations (i.e. 10 minutes, half hour, one hour, etc.)? 
• Is this financial impact more likely to be felt during certain peak processing times? If so, what are the peak periods? 
• What hard processing commitments do we have to external agencies or trading partners that are critical? 
• What is your customer’s tolerance for this service not being available? 
• What reputation risk or regulatory consequences are at stake for certain processing commitments? 
Business Partners should be educated to appropriately gauge the target state Service Level objectives for their Business 
Services. Following concepts about availability and recoverability should be made clear before seeking these Service level 
objectives. 
• Availability is different from Disaster Recovery. 
• Availability provides for recovery from localized routine or non-routine events, with potential end-user impact. 
Disaster Recovery involves recovery between data centers following catastrophic/extraordinary events, with certain 
end-user impact from a disruption in service. 
• The business lens used for what would be relevance in 
normal processing (Availability). 
• Recoverability has both a technology and business operations component
• The technology will recover lost 
transactions.
• Application inter
C#: How to Use SDK to Convert Document and Image Using XDoc.
You may use our converter SDK to easily convert PDF, Word, Excel, PowerPoint, Tiff, and Dicom files to raster images like Jpeg, Png, Bmp and Gif.
convert pdf file to powerpoint online; how to convert pdf file to powerpoint presentation
C# PDF Convert: How to Convert MS PPT to Adobe PDF Document
Microsoft PowerPoint to PDF. |. Home ›› XDoc.Converter ›› C# Converter: PowerPoint to PDF. You maybe interested: PDF in C#,
changing pdf to powerpoint file; pdf to powerpoint slide
Infosys – eBook | 13
Exhibit A below demonstrates differences between Availability & Recoverability.
Based on this understanding, the ultimate goal of this exercise is to capture RPO, AO & RTO values for the target state so 
that Application & Infrastructure design activities can be based on these business requirements. In the next section we will 
understand the definitions of these Service level objectives and how typically these objectives are classified in an organization. 
XDoc.Converter for .NET, Support Documents and Images Conversion
file converter SDK supports various commonly used document and image file formats, including Microsoft Office (2003 and 2007) Word, Excel, PowerPoint, PDF, Tiff
pdf to powerpoint; convert pdf into ppt online
Online Convert PowerPoint to PDF file. Best free online export
Online Powerpoint to PDF Converter. Download Free Trial. Convert a PPTX/PPT File to PDF. Just upload your file by clicking on the blue
convert pdf pages to powerpoint slides; pdf to powerpoint conversion
14 | Infosys – eBook
4.2 Application - Recovery Point Objective 
Recoveressed in units of time, 
which may be irretrievably lost before a disaster event in order to meet business requirements. Some applications can handle 
up to 24 hours or more of data loss in the event of a true disaster, while others require near zero data loss.
Below table illustrates how typically Recoverability Objectives are defined for each application. These will be utilized while 
defining the target state and further in Bundling of Applications for creating move groups.
RPO 
Typical Use 
Notes 
A - Up to 15 minutes of data loss 
(Target: 15 minutes
Transaction Processing Applications 
• RPO standard for critical 
applications
• Minimal data loss via hardware 
based data replication solutions 
B - greater than 15 min and less than 
24 hours (Targets: 1 hour, 4 hours, 8 
hours, or 16 hours
Data Warehouses 
• Intra-day snapshots or platform- 
specific data replication solutions
• Target data loss of less than  
24 hours 
C - Equal to or greater than 24 hours of 
data loss (Targets: 24 hours or 48 hours
Departmental Applications 
• RPO Standard for non-critical 
Applications Impact - up to 2 
business days of data loss 
X - Not Applicable 
Pass-Through applications 
• Applications do not store any 
business data, database, or file 
structures 
Z - Near Zero data loss 
Third- Party custom solution, e.g. Wire 
Transfer System 
• Custom IT solution 
• Requires completing Exception 
Process for approval
4.3 Application - Availability Objective 
Avice to perform its required function at a stated 
instant or over a stated period of time. In determining the most appropriate/cost effective Availability Objective, the following 
business considerations must be addressed: 
• How much revenue will be lost or additional expenses incurred by an unscheduled system outage for different 
durations (i.e. 10 minutes, half hour, one hour, etc.)? 
• Is this financial impact more likely to be felt during certain peak processing times? If so, what are the peak periods? 
• What hard processing commitments do we have to external agencies or rading partners that are critical  
(i.e. Fed deadline or Balance Reporting)? 
• What is your customer’s tolerance for this service not being available? 
• What reputation risk or regulatory consequences are at stake for certain processing commitments 
RasterEdge XDoc.PowerPoint for .NET - SDK for PowerPoint Document
Able to view and edit PowerPoint rapidly. Convert. Convert PowerPoint to PDF. Convert PowerPoint to HTML5. Convert PowerPoint to Tiff. Convert PowerPoint to Jpeg
conversion of pdf into ppt; convert pdf to powerpoint online
C# WinForms Viewer: Load, View, Convert, Annotate and Edit
View PDF in WPF; C#.NET: View Word in WPF; C#.NET: View Excel in WPF; C#.NET: View PowerPoint in WPF; C#.NET: View Tiff in WPF. XDoc.Converter for C#; XDoc.PDF
convert pdf to powerpoint online for; convert pdf slides to powerpoint
Infosys – eBook | 15
Below table illustrates how typically Availability Objectives are defined for each application. These will be utilized while 
defining the target state and further in Bundling of Applications for creating move groups. 
App Category Overall Service 
Availability 
Peak Service 
Availability 
Scheduled 
Service Outage 
Service 
Restoration 
Targeted 
Solution 
Business Need 
Objective 
Platinum 
Greater then 
99.95% 
Monthly 
Availability 
(22 minutes 
/ month 
unavailable) 
100% Monthly 
Availability 
(zero minutes 
/ month 
unavailable) 
No scheduled 
outages 
(changes can 
be made w/o 
customer 
impact) 
2 minutes 
to restore 
application / 
service 
2 completely 
independent 
Production 
environments 
Used for 
Extremely 
Time Critical 
Products or 
Services. 
Gold 
Between 99.9% 
- 99.95% 
Monthly 
Availability 
(44 minutes 
/ month 
unavailable) 
99.95% 
Monthly 
Availability 
(22 minutes 
/ month 
unavailable) 
Infrequently 
scheduled 
outages (ex – 
quarterly) 
1 hour 
to restore 
application / 
service 
Fully 
redundant 
Production 
environment 
with no single 
points of failure 
Used for Highly 
Time Critical 
Products or 
Services 
Silver 
Between 
99.5% - 99.9% 
Monthly 
Availability 
(3.65 hours 
/ month 
unavailable) 
99.9% Monthly 
Availability 
(44 minutes 
/ month 
unavailable) 
Regularly 
scheduled 
outages  
(ex – monthly) 
2 hours 
to restore 
application / 
service 
Partially 
redundant 
Production 
environment 
with some 
single points of 
failure 
Used for 
Important 
Products or 
Services that 
need Intraday 
Support 
Bronze 
Between 
99.0% - 99.5% 
Monthly 
Availability (7.3 
hours / month 
unavailable) 
99.5% Monthly 
Availability 
(3.65 hours 
/ month 
unavailable) 
Regularly 
scheduled 
outages (ex – 
monthly) 
6 hours 
to restore 
application / 
service 
Single 
Production 
environment 
with no 
redundancy 
Used for 
Products or 
Services that 
are not Intraday 
Time Critical
4.4 Application - Recovery Time Objective 
Recovery Time Objectives (RTO) repr
the process or application needs to be restored. Typically, the Business Continuity Planning Group works with partners in 
the lines of business and technology to ensure each system/application has an RTO assigned reflective of the criticality of the 
business services delivered.
Depending on the level of RTOs, appropriate technologies, processes, roles and responsibilities are laid to ensure that 
applications / business services can recover from a disaster in a given time frame. E.g. in table below, an RTO 1 (i.e. lowest in 
criticality from RTO standpoint) may require only a warm / cold DR and thereby save energy, rack space maintenance costs. 
In such cases, sufn warm / cold DR infrastructure 
into production without compromising on RTO objectives. Similarly, an RTO 5 application is deemed as a critical application 
with a very little time to recover from a disaster. Applications with RTO 5 may need a hot DR with automated failover 
technologies in place since no human intervention is expected to recover such mission critical applications from a disaster.
C# powerpoint - Convert PowerPoint to PDF in C#.NET
RasterEdge Visual C# .NET PowerPoint to PDF converter library control (XDoc.PowerPoint) is a mature and effective PowerPoint document converting utility.
export pdf to powerpoint; converting pdf to powerpoint
VB.NET PDF Converter Library SDK to convert PDF to other file
editing if they integrate this VB.NET PDF converter control with for converting MicroSoft Office Word, Excel and PowerPoint document to PDF file in VB
add pdf to powerpoint slide; converting pdf to ppt
16 | Infosys – eBook
RTO
Duration (Tolerable Time to Recover)
RTO 5
0 - 4:59 hours
RTO 4
5 - 24:59 hours
RTO 3
25 - 72:59 hours (1-3 days)
RTO 2
73 – 168 hours (4-7 days)
RTO 1
Greater than 168 hours (more than 1 week)
So, the Ae that 
business services supported on that application are being provisioned as per expectations and to prevent outages. Selection 
of appropriate technologies to meet these service level objectives has been discussed further in the target state design process 
where deployment patterns are explained in detail.
4.5 High Level Cost estimation 
The cost discussion in Business Ser
business can expect to see based on the target data center configuration. This is also necessary to support decision making 
around the appropriate Availability and Recovery objectives. 
The Availability & Data Protection 
technologies to be implemented on Servers, Network & Storage environment. Therefore, Enterprises generally attach 
standard costs on the basis of type of hardware, selected Availability & Recoverability objectives for planning purposes. 
At this point in the program we are not aiming for actual Bill of Material / target state costs as those will be assessed towards 
the end of Target State Application & Infrastructure design. The objective to undergo this high level estimation is to ensure 
that business understands: 
• Selecting a higher AO, RPO, and RTO values for the target state would translate to a certain standard cost levels 
• If business wants to revisit selected service level objectives, they are prompted to do so before proceeding with detailed 
Application & Infrastructure Design activities for target state. 
• Seek sign-off prior to detailed target state design. 
In general, key components of Cost Data are described as below: 
4.5.1 Recurring Expenses 
Illustrative Expenses that business would see as recurring, as a result of Data Center Migration include: 
• Data retention and recovery 
• Server support 
• Network chargeback’s 
• Server system administration chargeback’s 
4.5.2 One-Time Expenses 
Illustrative Expenses that business would see as one-time, as a result of Data Center Migration include: 
• Approximate cost of new servers, and other hardware associated with new data center configuration 
• Approximate cost of the Data Center Migration Move project and associated application testing. 
Infosys – eBook | 17
Application & Infrastructure Design – Target Data Center 
Application & Infrastructure design for the target state is based on multiple parameters such as business defined service 
level objectives, Enterprise IT – Hardware & Software standards, opportunities for Infrastructure optimization, Data Center 
efficiencies and reduction in IT costs. 
In general, Target Application & Infrastructure Architecture is designed keeping in mind: 
• Current & Target Availability, Recovery Time & Recovery Point Objectives 
• Status of Applications (Development, Production, Sunset, Obsolete etc.) 
• Retiring Hardware & Software requiring technology refresh 
• Dependencies on Shared Hosting environments / Shared Databases. 
• Storage requirements 
• Virtualization & Consolidation opportunities 
• Existing single points of failure 
• Capacity, Performance & Scalability requirements 
• Network & Security requirements 
• External Vendor communication requirements 
• Supported Vendor products & technologies 
• Latency Sensitivity Analysis (in view of revised network routes connecting to Target Data Center
Target State Application & Infrastructure design would consist of following components that are discussed further in detail as 
we follow:
Design Layer
Description
Core Infrastructure Layer
Target Data Center Facilities requirements (Space, Power, Cooling, Cabling etc.)
Target Data Center Rack Layout
Core Network, Security & Storage Infrastructure design
Shared Services Layer
Enterprise Shared Services (Authentication, Shared Databases, Messaging, Internet, 
Monitoring & Management systems etc.)
Application Layer
Application Architecture at target state (in view of capacity, scalability, BSR expectations)
Individual Application specific Hardware, Software requirements 
Definition of Deployment 
Patterns
Selection of appropriate technologies to ensure Availability, Data protection at Target Data 
Center in-line with BSR expectations)
5.1 Core Infrastructure Design 
Assessment of the Source Data Center environment carried out earlier provides all the necessary high level indications to the 
scale, size, and type of hardware that will be built / moved to the target data center. Although, a detailed application level 
design is not available at this point in the program, the design and build out of Core Infrastructure layer needs to occur in 
parallel / prior to the actual application Infrastructure build, for obvious reasons. For capacity planning purposes, current 
• Number of racks of each category based on power ratings / cooling requirements / physical size of hardware to be 
deployed
• Power & Cooling requirement based on expected number of Servers, Network & Storage devices to be hosted in the 
target data center.
• Type & capacity of network & security hardware to be deployed
• Overlaying technologies to be deployed
• SAN / NAS / DAS / Backup Hardware & technologies to be deployed
18 | Infosys – eBook
Enterprise Technology standards are followed in creating a skeleton of Infrastructure layer such as standard hardware, Core – 
Distribution – Access framework for aggregation & Distribution of Network & Storage traffic, deployment of security zones 
to host different applications / sero-
active monitoring, troubleshooting and administration of Core infrastructure. 
Core Infrastructure is not only designed to accommodate the present IT requirements, but also to accommodate business 
growth projections of the enterprise in the near future. So, Core Infrastructure should be flexible, modular, scalable & 
capable of meeting varying service level objectives defined by business for different applications.
Below is an illustrative exhibit showing Core Infrastructure components. 
Infosys – eBook | 19
5.2 Enterprise Shared Services Design 
Enterprise shared services serve as common service infrastructure for all the other business applications of the organization. 
As, a large number of applications utilize enterprise shared services for their full functionality, it is logical to design and 
Security Services etc. 
Following are some of the parameters that should considered while planning the capacity of shared services infrastructure at 
target data center. 
• Enterprise vision on selection of Shared Services technologies to be deployed at the target data center 
• Number of Intranet / Internet / VPN users accessing different shared services in the source data center 
• Expected number of Intranet / Internet / VPN users accessing these shared services in the target data center (based on 
growth trends) 
• Expected Differences in IT workload on various systems & associated hardware & software sizing. 
• get data 
center based on Applications & Business Services being migrated to the target data center. 
• Geographical locations from where shared services at target data center will be accessed, performance requirements 
thereof. 
• Any additional shared services that can enhance the value to services offered by business should be considered in the 
target state architecture. 
• Criticality of Shared Services planned to be offered to serve business needs. These services should be evaluated 
for appropriate Service Level Objectives (AO, RPO, RTOs). So that, their resiliency & data protection is planned 
accordingly. 
• Explore opportunities to conduct a technology refresh in the target state if any of the Shared Services at Source Data 
Center are running on near “End of Life” Hardware / Software. 
• Network, Server, Storage & Database Monitoring requirements in the target data center. 
• Shared Database requirements (e.g. Oracle Grid, SQL cluster etc.) 
• Shared hosting requirements (e.g. Shared Web / Application Server farms) 
5.3 Application Re-Architecture – As needed 
Re-architecturent state analysis of certain 
Applications, it may be need to make revisions to their logical architecture. Some of the illustrative reasons are: 
• End of life of associated Hardware / Software / both. 
• Consolidation of applications for cost optimization 
• educed individual application related 
database instances and moving towards utilization of Shared Databases / Application hosting farms. 
• Feature Upgrades to cater new business scenarios 
• OS / DB Platform Migration requirements e.g. Mainframe to Distributed or DB2 to Oracle etc. 
• Changes to application interdependencies in target state that pose an impact on application architecture 
• New security requirements in the target state data center .e.g. Enterprise strategy might enforce maintaining 
Application & DB Servers in different Tiers based on certain parameters in Application profile. 
• chitectural change to mitigate the same. 
• Requirements to adhere to any new Enterprise Standards in the target state. 
20 | Infosys – eBook
5.4 Selection of Deployment Model / Patterns – Infrastructure Perspective 
Generally, laredundancy, reliability & data protection 
to its physical deployment. These guiding principles enable a standard way of deploying applications in a data center 
configuration. Moreover, these patterns help for a better co-ordination between IT and Business in terms of identifying what 
infrastructure IT needs to provision in order to provide a certain grade of service to the business users. 
From a data center migration standpoint, selection of deployment patterns may be needed to either enhance or optimize the 
infrastructure implementation in the target state. e.g. in the source data center if a lower criticality RTO / RPO application 
has been deployed with unnecessary redundancies, there may be a potential to optimize the infrastructure deployment in 
the target state. Similarly, if the current business conditions require an upgrade to RTO / RPO of an application, it may mean 
deployment of additional availability infrastructure or implementation of other technologies to facilitate quicker data retrieval 
/ better performance / zero human intervention / elimination of any other points of failure etc. 
Ser
messaging servers, application servers, web servers, and nearly any other type of workload. The deployment architecture 
should consider the High Availability requirements (based on Availability objectives) and Data protection requirements (based 
on the Recovery Point and Recovery Time Objectives). As a result, three popular deployment patterns can be derived: 
• Active-Passive failover 
• Active-Active failover 
• Load Balanced 
5.4.1 Active-passive failover: 
vers, web servers, and messaging 
servers. Cluster management software (such as Microsoft Cluster Service or VERITAS Cluster Server) detects either a software 
or hardware failurs IP 
address to the takeover node. 
5.4.2 Active-active failover: 
model above. All nodes in the cluster are running applications, with enough reserve capacity across all of them to take over 
workloads from a failed node. Cluster management software monitors all nodes and services in the cluster and enables for 
migration of services from failed nodes to active nodes. As with active-passive failover, applications that maintain state with a 
e. 
Documents you may be interested
Documents you may be interested