White paper

Transform
applications
Learn about the seven deadly sins

White paper | Transform applications

Table of contents
1 Avoid the seven sins
1 Gain from prevention
1 Sin #1Microsoft Excel
3 Sin #2Old stuff
5 Sin #3Too much juggling
6 Sin #4Stovepipes
8 Sin #5Imprecision
10 Sin #6Lack of discipline
11 Sin #7Top-down planning without bottom-up estimates
12 Prioritize investments
13 Application transformation schema sample
14 Learn about the author

White paper | Transform applications

Seven sins or bad practices can damage your application

transformation plan from current mode of operation (CMO) to
future mode of operation (FMO), regardless of your source and
target technologies. Learn how to avoid them.
Avoid the seven sins
The seven deadly sins
Sin #1Microsoft Excel
Sin #2 Old stuff
Sin #3Too much juggling

Several indicators help detect if your application transformation is suffering from any (or
all) of the seven deadly sins. For each of themMicrosoft Excel, old stuff sitting around,
juggling, stovepipes, imprecision, lack of discipline, and top-down planning without bottom-up
estimateswe have counter measures to prevent them from causing irremediable damage to
your transformation plans.

Sin #4Stovepipes
Sin #5Imprecision
Sin #6Lack of discipline
Sin #7Top-down planning without
bottom-up estimates

Gain from prevention

As a transformation lead, you are accountable for plans and schedules, justifying delays,
and preventing bad surprises. As a CIO, you should be viewed as the enabler to grow your
company business, not as a dragging cost center that cannot evolve fast enough, unless you
scrap and rewrite everythingwhich is not an approach to application transformation. As a
business domain leader, you will reap benefits from transformation with low disruption to your
normal operations. You will gain reassurance that while movers transport or transform your
application, it will be done in due time; and with proper planning, it will have no impact to your
normal business activities or your customer. As an IT director, it is the reassurance that you
have the right staff to perform the right amount of work, and transform according to plan. Even
if those plans change midway, you will not be left destabilized and need to take another three
months of planning. Rather, you will be able to adjust and be agile to meet the fast-changing
nature of modern IT.

Sin #1Microsoft Excel

Use of Microsoft Excel, in any form, requires massive transformation work because of
processed lists and pivot tables, the server footprint of an application, the inventory of
operating system version, and the sheer number of application components that have to be
migrated. In fact, the use of tables and well-identified fields is mandatory. So, you ask, Whats
wrong with Excel, then? To which I respond, Its not so much the tool, but rather the use of it.
Excel, unless used outside of SharePoint 2010 and only with editing features, dangerously
unlinks information from its master source. You can use Excel as much as you want or need,
as long as you remember that you must have the same source of information as everyone
else. Its so easy to create, transport, and reuse master information in Excel that you run the
severe risk of creating a gradual misalignment, which prevents any bottom-up or top-down

White paper | Transform applications

decision-making without taking considerable risks. For example, you have a list of servers for
a group of applications. However, another organization has a different list of servers because
your applications have their own lifecycle while you study them. Suddenly, you find yourself
reworking your incident heat map or currency inventory created two months ago because the
base information has changed.
Counter actions
You must get acquainted with two key principles:
Repository
Versioning and tracking
In short, you have to use a database for your master information. And while you may pass data
in the content of an Excel document or chart application topologies, you must keep track of
where the information came from in the first place. And if you changed it, you must ensure the
information source is kept updated or current. The challenge is that adding a column in an Excel
document is far easier than changing the schema of a CMDB or even a field in a SharePoint list.
And while you may decide to consolidate schemas on an annual or semi-annual basis, the most
important point is ensuring any information you create, or discover as a result of an interview
with an application owner or maintainer, is stored in a repository and given to the owner. Every
month, quarter, or at a frequency of your choice, you have a chance to revisit the repository.
Asking owners to update the information they own is much quicker than restarting another
interview and inventory process.
A possible solution is to use SharePoint lists instead of Excel. They are extremely powerful for
several reasons:
They can easily be modified; fields can be added and hidden from one view to another,
ensuring each can find the information they want or need, with minimal disruption to others
within reason.
They are ubiquitous in the enterprise, and can be shared with application owners inside or
outside of your company through use of extranet SharePoint farms.
They implement a rudimentaryyet good enoughversion control, enabling you to track
who changed what on which item in real time or on a periodic basis.
You can run reports and automate them through Excel Web Parts, directly into your portal,
which becomes the single source of the truth for information you wish to store.
An example of a schema for a SharePoint tracker during application transformation is
provided at the end of this paper.
In summary
Dont think you should avoid Excel. It can deliver tremendous value (see Figure 1) when
reporting on activity progress or identifying bottlenecks. Just remember any source of
information used in Excel must be tied to a repository, and if you generate additional data about
an application, you must store it in a repository. Short of having SQL database skills, go with
Microsoft SharePoint for list management and Infoview for form entry. They both provide a
great way to rapidly collect information about items in your application environment/portfolio.

White paper | Transform applications

Figure 1. Cumulative flow view

120

100

60

40

20

Cancelled
Business project
Migration & upgrade done
Move & upgrade
Design review

17-Jan-13

10-Jan-13

03-Jan-13

27-Dec-12

20-Dec-12

13-Dec-12

06-Dec-12

29-Nov-12

22-Nov-12

15-Nov-12

08-Nov-12

01-Nov-12

25-Oct-12

18-Oct-12

11-Oct-12

04-Oct-12

27-Sep-12

20-Sep-12

13-Sep-12

06-Sep-12

30-Aug-12

23-Aug-12

16-Aug-12

09-Aug-12

02-Aug-12

26-Jul-12

19-Jul-12

12-Jul-12

05-Jul-12

28-Jun-12

21-Jun-12

14-Jun-12

07-Jun-12

31-May-12

0
24-May-12

Projects

80

Design in progress
Closed good for design
HLA reviewed
HLA to be released

Sin #2Old stuff

Old applications have been around since the dawn of IT times, which no one ever changed,
because they never broke. They were fit for a purpose from the beginning, and run on that
dusty server, and by the way, the last person who actually modified that application left the
company five years ago. Thats old stuff, and its all too common. You are about to embark on
an application transformation that will leverage standardized platforms and environments,
and reduce the complexity of your estate. The problem is, if you have determined the
target operating system (OS) and database standard versioning you require for your target
environment, you will have to upgrade these old applications, or they wont migrate to the
target data center or infrastructure.
The key question is whether the bar is set too high for your target environment. For example,
you may decide you are going to standardize all of your Microsoft Windows estate to Windows
2008. Then, you will realize that upgrading Windows also means upgrading application
components such as an image processing package or a reporting tool, and things become more
complicated. If for some reason that application hasnt been touched for a long time, you may
experience two problems:
The in-house knowledge of that application is gone.
The independent software vendor that sold this component has disappeared, resulting in no
support, no upgrade, nothing.

White paper | Transform applications

Of course, you may believe this is exaggerated, but if you realize that a third problem is the
simple loss of source code and customization, this will make you think twice about your
application lifecycle management. It will also help you decide whether to maintain the currency
of your application estate or let it decay in the hopes business users will request replacement
with a more modern version. Transforming an old application is more difficult than it seems, and
most likely will require external and specialized help, coming at a cost you had not envisioned.
Consider this: If the application broke as you transformed it from one environment to another,
and the broken components dont work anymore, who are you going to call?
Counter actions
First, you should define your FMO standards such that they are not too restrictive. In fact,
aim for at least 70% of your existing estate to meet the FMO standards. Anything lower than
that is going to take you down a hazardous and twisted road of infrastructure and application
upgrades. Upgrades might be technically feasible, but you will find very little appetite from
business stakeholders in providing funding for fixing applications that dont break in the CMO,
and will not bring any extra features in the FMO. Of course, application modernization is a good
way to circumvent those issues, but the reality is that few companies can modernize their entire
application estate.
Second, you must impose a discipline to keep your application estate current, at least for
business-critical applicationsthose that can interrupt key activities such as order processing
or order entry. This introduces the concept of triage1 (illustrated in Figure 2) for your application
estate, an activity that will help counter other sins.
Figure 2. Application triage data sheet

Application indicators
Documentation quality
Application age
Application complexity
Application stability
Change history

low
old X
complex X
low
never

high
new
simple
X high
frequently

Yes
HP managed

Business group: Payroll

Number of uses: 2101
Data Center: Sao Paulo
Main software components used: Acme Sw V5.1
Number of servers: 4
OS: 3x MS Windows 2003 (N-1), 1x MS Windows 2000 (N-2)
DB: Oracle 9.2 (N-4)

Application type

Price proposal (+/-30%):

 riage: the action to sort items using basic

T
patterns or attributes.

COTS

Bespoke

Sources used
Sources

Yes

Mood

Site inventory

CMDB

Project roadmap

Questionnaire

Justication:
2 DBs to upgrade from Oracle 9.2 (N-4) to N
1 server to upgrade from Windows 2000 (N-2) to N
The SW vendor supports the FMO DB upgrade as proposed (COTS application)
While upgrading App-A DB, it should be considered that App-B (UUID) is also
using the same DB. A DB link between App-A and App-B exists.

No

Application description:
Description: Attendance control (Workforce administration, no badge application)

In transfer

No

Not available

Disposition status from client

Supposed
Dont move
Like4Like
Upgrade
Assessment in progress
Not available

White paper | Transform applications

Third, attempt to upgrade your application prior to transformation to help secure the migration.
For example, upgrading to Oracle 11g R2 will deliver better results for database transport and
synchronization compared to Oracle 10g, thanks to its advanced compression features. After
all, if you have to migrate massive quantities of data from one environment to another, it is
perhaps better to reduce the data volume and do it with a fully supported database engine.
Finally, depending on your application transformation goals (typically, to close data centers
running traditional IT), you may find that upgrading your application, prior to migrating it, is
virtually impossible. This is either because you have no budget to acquire new hardware in the
CMO, or upgrading prior to the move would run the risk of delaying the data center closure. For
example, you have to close a data center in 2013, but the upgrade project is a good nine months
project, with high potential of delays. While it really should be a project management decision,
its important to combine it with technical recommendations: Migrate the application as is, but
make the promise that you will bring it up to date and hold to that promise.
In summary
Business applications do not mature well with age. You have to keep them current or expose
yourself to uncertainty of being able to swiftly migrate your applications and unwanted
faults to the FMO during migrations. Keeping an application current is not always in scope of
application maintainers, and you must ensure there is a provisional budget in the application
lifecycle to keep it current. On the other hand, if no one is willing to maintain the currency of the
application, you may think twice about its level of importance and decrease its priority during a
triage exercise.

Sin #3Too much juggling

While planning your data center transformation from CMO to FMO, you may be tempted to
set up an environment using the most current version of operation system and databases, to
maximize database and server consolidation. You can also avoid upgrading the application after
migrating it, because you migrated the application to a modernized or upgraded environment.
This temptation is sound, and in fact, will apply to a number of relatively straightforward
applications that do not care about their host operating system or database version. However,
the challenge is that you run the risk of turning a complex operation into an even more complex
operation, where you will have to migrate and upgrade, and hope you dont drop any balls
during the operation.
On the other hand, you may not have the choice: Moving an SAP application running on ECC 6
and Oracle 10g is virtually impossible, as SAP (very wisely) will stop you from re-creating such a
target environment (database obsolescence). You may also decide to not migrate and upgrade,
but standup a brand new green field environment, and migrate applications logic to that green
field environment. That particular approach was common in the 1990s for migrating from one
version of Microsoft Exchange to another: A new topology was created, and mailboxes were
transferred from the existing mail environment to the new one. The whole upgrade process
was relatively transparent and favored server consolidation and data rearrangement in the
messaging topology.
A good example is your Enterprise Service Bus: Instead of moving servers, move the functions
that those servers fulfill, such as the application interfaces, at the pace of the applications.
Do not attempt to migrate servers hosting hundreds of application interfaces all at once. This
type of smooth, application-oriented migration is by far the most stable and predictable
approach to application migration, however, not necessarily applicable to all types of business
applications. Reporting applications are also good candidates for server consolidation/business
logic migration.
As you can see, several factors come with the design of the application transformation itself,
and depending on the application, its implementation, currency, and topology, you will have to
adopt one approach or another. Trying to do too many things at once is not a good approach,
unless youre dealing with a relatively small environment.

White paper | Transform applications

Counter actions
Lets face it: In a massive application transformation, you will hardly be confronted by technical
issues but by hard decisions instead. And unless you have found a way to sort, you have no
chance to set your priorities and make the tough decisions. You will need to learn to triage.
There are several attributes to be considered for an application to be triaged:
Is it important to the business?
Does it require extensive support resources?
Has the application been recently changed?
Is it running on outdated hardware or software components?
Do you have all the knowledge, including customization or source code, for that application?
The list could go on. In fact, triage attributes are determined by your objectives, that is,
measurable outcomes from your application transformation. For example, it could be data
center closure by a given date, or the rationalization of the application portfolio, with 30%
of the applications retired by a certain date, or, at most two different versions for any
database engine (for example, Oracle 11g and Oracle 11g R2). For your business units,
those outcomes will have to come with tangible results, such as shortened upgrade window,
improved application performance, decreased maintenance and support costs, and a reduction
of severe incidents.
In summary
Dont try to do too much at once. Simplify a massive application transformation by identifying
the usual quick wins, and take measure of the problem size when you face itdont run from it.

Sin #4Stovepipes
Stovepipes can be found in any organization. Between IT groups targeting the migration of
hundreds of applications for migration to FMO, the IT director that must close at least two major
data centers, or businesses that need better applicationseach comes with his or her own
agenda. Where it becomes interesting is when you consider the number of parties that typically
revolve around a business application:
The business consultant knows the customers business and industry best and has created
the application architecture from well thought-out requirements.
The business user has been using the application for years, sometimes in creative ways,
and will never accept landing the plane while switching engines even if that is what the
business requires.
The infrastructure provider has a number of towersnetwork, security, user computing,
midrange servers, storage, and so forth.
The application operations group has enough permissions on the infrastructure order to
install and configure the application, store volumes, and order unique network configurations
and bypass firewalls. They are important because they are the interface between the
infrastructure and the applications maintenance and support.
The application maintenance and support organization is in charge of release management,
regression testing, application emergency fixes, ad hoc code changes, and ongoing application
support. This organization talks to the user if level 1 support cannot resolve a problem.
These organizations must be involved during the applications transformation. When you
consider you may have a different SAP application maintenance and support vendor than
for your custom-made portal, you quickly realize your application transformation project
can involve dozens of companies, organization representatives, application owners, and
vendors. While it may be manageable for a few applications, which will be handled as individual
projects, you cannot afford any form of stovepipe, miscommunication, or misalignment in your
multiorganizational workflow (see sample in Figure 3).

White paper | Transform applications

Figure 3. Migration cross-functional workflow

Industrialized application migration
Capacity planning
and deployment

Hopper transport

Upgrade
partner

Optional
remediation

Source to
target
specication

HP
ITO/
DCO

Wave
kick-o
template

Raise
server
build
request

Wave
kick-o
presentation

CMO
security
scan
Application
migration
technical
meeting

FMO
security scan

Migration
run book

Create
migration
run book

Apps
ops

TPC
required?

Raise
change
requests

Data transfer/
synchronization

Adjust/change
application
monitoring

Application
installation

Application
migration
technical
meeting

Source to target
specications

RTPA2

Decomm

Application
testing

Create
SOW/PO
for TPC
Application
setup?

Client
business

Cutover

Application
installation

Application
testing

UAT

UAT OK?

Create
migration
run book
Create UAT

UAT
specications

Review DEI
and user
communication

Counter actions
When you have several organizations, possibly companies, involved in performing a specific
activitytransformation of an application from CMO to FMO with assorted suitable upgrades
and testing activitiesyou will find that cross-functional workflow tools essentially:
Define your process
Use it
Improve it
Sounds like Kaizen? It is. Thats exactly what you will have to do. In fact, you will need to adjust the
process based on the information at hand, and the level of involvement you can afford. Then, after
10 or 20 applications, you will have a process that runs by itself, and enables quick onboarding
and off-boarding of migration and transformation players, and delivers predictable results.
The benefits of cross-functional workflows include:
Owners of all activities taking part in the execution process must be determined. Any activity is
part of one swim lane, and the organization that is assigned to that swim lane naturally owns
the activity.
When the workflow crosses from one lane to another, it indicates an inter-organizational
activity, which has to be formalized with tools and data formats. For example, provisioning of
the application landscape (the list of servers that compose the test environment of a given
application), must be done by a different team (infrastructure provisioning) than the one that
uses that environment (application maintenance). As you cross from application maintenance
to the infrastructure provisioning, you must identify the collateral that is to be used.
Any activity will have a predecessor except the process kick-off, and as a result, has a clear list
of dependencies. You will then need answers to two fundamental questions:
What do you need to carry out your activity?
Who depends on your work?
7

White paper | Transform applications

From the list of activity and inter-organizational touch points, you can identify the people,
tools, and activities, and determine the responsible, accountable, consulted, informed (RACI)
matrix for each of those activities and collaterals. This makes it easy to track, and if the
process is blocked, know which organization owns the blocking point.
From that same list, and put in the context of several hundreds of applications to be
transformed, you can estimate the workload necessary to conduct the activities required, and
analyze and describe the landscapes of your applications.
Dont be put off by complexity, and if need be, use a simple pencil and paper approach and a
black belt business process consultantjust because they work with business processes does
not mean they cant help with infrastructure or application services processes.
In summary
Stovepipes are more common than you would like, and the best way to fight them is to
document the process and touch points, and assign responsibilities and accountability.
From that, you can obtain executive support and sign-off, and proper staffing to conduct the
execution of your cross-functional activity, and beat the organization stovepipes that appear
as soon as two organizations have a disconnected agenda. Documentation, in our modern IT
delivery, is not always favored by practitioners. But in a massive application transformation,
it is required. It will also help address other sins, such as Sin #1 (Excel) by employing the right
tooling to facilitate the exchange of information and delivery of activities.

Sin #5Imprecision
In an effort to create executive-level pitches, we are often tempted to summarize the status of
an application portfolio, so the decision is not made on 200 individual data points, rather on four
to five key influencing factors. For example, you will be more inspired to summarize the volume of
servers that need an upgrade, instead of providing the list of 2,500 servers present in your estate.
If you can estimate that 30% of the server farm needs a serious operating system upgrade, this
gives a good view to the executives for steering the work and making the next decisions.
The problem comes when you attempt to extrapolate those high-level figures without paying
attention to particular cases. For example, you must be able to quickly assert the technical
feasibility of the operating system upgrades, given some applications are actually sensitive
to the underlying operation system functions, and may require an upgrade themselves. Just
because it works with one application does not mean it will work for another application. You
cant just embark on a massive operating system upgrade program if you havent determined
the implications of those upgrades. Some applications will not require any testing; other
applications may require a complete new architecture because they are not compatible with the
target environment. That can change by several orders of magnitude to make things happen.
Counter actions
You must keep a well-defined and globally communicated portfolio of technical reference
pointsdesign documentation of your FMO, application standardsand regularly
communicate it. Unless your target environment is precisely documented, you will struggle to
address a large portfolio of applications to migrate. It is possible you will not find a one-sizefits-all at first, but at least you must be able to rapidly detect the target standards and identify
the exclusion process to determine what is in or out of scope. As a result, while you will be far
from technical considerations on the application transformations, you will be equipped to deal
with the necessary boundaries so you can staff and execute the application transformation.
Whether your profile is technical or not, it is important that any work you carry forward is
registered within a well-defined and mutually agreed scope. Failure to do so will lead to agreed
upon surprises such as the inability to mobilize resources when its time to perform specific
actions in your application transformation journey.
You must also extend the level of dependency details on your applications. Thanks to server
consolidation trends of the 1990s, you may find you have more dependencies than you
thought, and that its not a matter of data exchange, but a matter of strategic application triage
activities. For example, a single server hosts two applicationsone to upgrade, another to
drop. Which decision will you make when you have to move this application to FMO? Will you
move the entire server and keep the dropped application, or will you carve out the application
8

White paper | Transform applications

from the consolidated server, and leave the current in place, and push this application on a
new (modernized) server in FMO? Precision in the application analysis and mutual dependency
is paramount, because no matter the outcome of the business-driven portfolio prioritization,
technical dependencies affect prioritization, and change the scope and application retirement
assumptions and possibly migration efforts. A good way to document your applications
is to apply the A3 Composite Application view (for example, Figure 4) which describes the
implementation of an application against four distinct layers:
Front-plane describes the interface to users, in terms of fat-client, web application, and
so forth.
Cross-plane describes the intermediate application components that will typically
perform business logic, data transformation, or document processing such as translation
or printed output.
Back-plane describes the back-end server and component infrastructure, typically composed
of database servers and other application component servers that act as information
repositories. It may include scheduling services for regular job execution for back-end
processing, such that information and transactions can be processed asynchronously from
user interactions.
Interfaces can optionally be documented, and preferably implemented by an enterprise
service bus, which extract and optionally transform into canonical format, and transfer
information between applications.

Figure 4. A3 composite application view

Front-plane

Web-client

User interfaces

Cross-plane
Dedicated services
and databases

Web-client

Teradata DB

dnu57pdw01-a.ndc.client.com
dnu57pdw02-a.ndc.client.com
dnu57pdw03-a.ndc.client.com
dnu57pdw04-a.ndc.client.com
dnu57pdw05-a.ndc.client.com
dnu57sws.ndc.client.com
dnu57view.ndc.client.com

ETL server

dnu55pdw01-a.zam.client.com
dnu55pdw02-a.zam.client.com
dnu55sws.zam.client.com

hedwap00.ndc.client.com

Informatica 9.1

Oracle 11R2

SuSE SLES 10 SP1

Teradata 13.0

25770ACE

25770ACE 26248-OWINS

25770ACE

HP-UX 11.31
Informatica 9.1

SuSE SLES 10 SP1

Teradata 13.0

ETL server

Teradata DB

usilapp2.ndc.client.com

HP-UX 11.31

Oracle 11R2

25770ACE 26248OWINS

Back-plane
Dedicated services
and databases

Pointsolutions
Down or upstream
applications

Production

BO XI Platform

BO XI Platform
usnavsboxiss01.ndc.client.com
usnavsboxiss02.ndc.client.com

MS Windows 2008

BO XI Platform

us70twapp039.zam.client.com
us70twapp040.zam.client.com
us70twapp041.zam.client.com

BO XI Platform

BO XI 3.1 SP4

MS Windows 2008

BO XI 3.1 SP4

BO XI 3.1 SP4

BO XI 3.1 SP4

BO repository Oracle DB

BO repository Oracle DB

usilclus08db2.ndc.client.com

us70thdbs005.zam.client.com

SunOS 5.10
Oracle 11.2.0.2

HP-UX 11.31
Oracle 11.2.0.2

SAP
Ebox
25949

SAP
Fbox
25950

Development test

SAP
Vbox
25953

BI HR
DW
70250

Mesa
12597

Oracle le transfer (ConnectDirect)

Services
Link
12985

Tax
Vertex
25955

XMS
25812

IDR
24642

ePIC
70588

12DM
70627

BPPM
80001

OWINS
26248

Apollo
BW
70574

25770 Applications that are hosted on the same server

White paper | Transform applications

You may also want to associate your applications with a particular technical, functional, or
business domain that may be immune from the general application transformation rules. For
example, an information management and analytics domain may need a migration approach
that takes advantage of new technologies more rapidly, scaling on specific platforms that
require physical lift and shift for migration, and involve relatively large quantities of data (above
50TB). The strategy for transformation and techniques for migration will most likely be different
compared to an application that sits on a leveraged web server and accesses a back-end
Microsoft SQL databasenot that this application is less important.
Finally, you will identify an area of its own, SAP, which is hardly to be ignored in any major
application transformation. The approach you need to take to the SAP environment is most
likely going to be significantly different from the rest of your application landscapes. And the
tooling available on the market and capabilities from consulting organizations are likely to
significantly affect the transformation approach, and be specific to those environments.
In summary
Hidden essential information may hamper progression of your application transformation, and
come with a series of exceptions that may take you into analysis paralysis, or scope change, and
incur additional delay in the decision-making process. For this reason, you should have a precise
view of your application dependencies when you triage your applications. Understand that an
application pulling 2GB of data from a file server may be less sensitive to transformation than
one that shares database tables with another application, possibly hosted on a different server,
but sharing the same database server.

Sin #6Lack of discipline

If rules dont fit your particular application transformation scenario, you may want to change them,
but dont ignore them. Ignoring them sidetracks the application transformation and will not
deliver any benefit. It will not be reusable, nor predictable in the master plan, and while
delivering a tactical benefit, will not support the application transformation.
You may address Sin #4 (Stovepipes) with a solid cross-functional workflow, clear deliverables,
and RACI matrices for all phases of an application assessment. To make it effective and reap
benefits of those processes, you must have an organization that is disciplined enough to follow
the process, and if the process is flawed or not adaptable to the local delivery conditions, be
open to modifying it. Change management is something that can drive your project off track,
when ignored. Change management can also slow you down when you extensively use it.
Advancing without change management may solve an immediate problem, but does not help
in the long run, and exposes your application transformation to recurring problems instead of
preventing them.
Counter actions
You must be open and collect feedback from any level of organization involved in the
application transformation and address that feedback in a constructive and positive manner,
even if the feedback is communicated in a negative form. While being kind and generous
on receiving feedback, you must be ruthless in the application of standards and processes,
methods, and tools. There is no room for local creativity unless it is shared with the broader
delivery organization. Sharing is equally important because it is normal to experience a
certain churn rate in a delivery organization. And if you are involved in a massive application
transformation, you have to understand that the team who did the kick-off and set the
transformation basics is not the same one that will turn off the lights in the last CMO data
center. The continuation of knowledge and experience must not be interrupted by the sudden
departure of one team leader or another enterprise architect, and the spirit must remain.

10

White paper | Transform applications

In summary
Massive application transformation is a long journey and involves many parties. The earlier
you can set expectations, the calmer the trip will be. As you stick to standards, give yourself a
chance to improve them. At any delivery level, there are probably a dozen voices and opinions
that are worth listening to and collating in the grand master plan that you need to create before
you embark on the application transformation journey. Without such a plan, you will not get
sponsorship. With a plan too disconnected from reality, you will have no success. This leads to
our 7th sin.

Sin #7Top-down planning without bottom-up estimates

A top-level plan is developed to create the application transformation business case. Expressed
in savings due to data center closures, or reduction in capital expenditures from infrastructure
acquisition, an initial vision must be created, including a traditional business case, return on
investment, and so forth.
The reality can be much tougher, and while it is important to create a general vision across
organizations, especially from global IT organizations, it is important to keep connected with
the terrainthe entrenched delivery organizations. They have the right level of knowledge on
what it takes for an application to be transferred from one state to another.
There must be a junction point at which each and every high-level assumption is verified or
challenged by facts. For example, if you believe you can retire 30% of the applications in your
portfolio, make an inquiry to each business unit leader and ask these leaders to come with a list
of the applications they actively use. You may be shocked by the reality on two fronts:
Businesses may not have complete knowledge of the applications used, and the report
may be different from your solution portfolio, which contains the list of applications
officially supported.
Businesses have been creative in the way they procured applications, and you would be
surprised by the count of under-the-desk servers that run business applications, and for
some, that depend on the existing application portfolio.
While due diligence cannot take too long, there is always a level of risk, assumption, and issues
in any program. You must be careful in any top-level planning that will never touch ground, and
be subject to constant rescheduling because there is simply no one to go and do the job.
Counter actions
It is fairly straightforward to address this particular sin. You must have regular connections
between high-level planners and bottom-up resource estimators to track the effort and
activities required for your massive application portfolio transformation. For this to happen, you
must have content-aware project or program managers, surrounded by subject-matter experts
that support the applications, and provide the necessary level of details within a reasonable
time. Often, people who know best about the applications attributes, which are most relevant
to the transformation, do not have the time to help a transformation team or are not readily
available when the planning is created or reworked.

11

White paper | Transform applications

To prevent stall periods during which you wait for a particular application support contact to
provide the technical information you are after, try to establish a plan by which you will handle
applications by waves and upfront. Reach out to the application support delivery leadership to
gain their support and ensure the individuals with the right knowledge can be made available on
relatively short notice, within a given time lapse.
In summary
Between the executive drive and the delivery execution, there can be such a distance that it
can slowly destroy a mutual trust relationship. Every plan will shift, and every shift will have an
explanation. However, more than two shifts in a high-level plan is an indication that something
is not fully understoodthe landscape is too complex, the effort is too ambitious, the scope is
not well understood, or the stakeholders are not on board.

Prioritize investments
The real challenge of the CIO is to construct a transformation of a business application
landscape that suitably prioritizes the necessary investments required, between those aimed at
strategic platform modernization versus those that support the application transformation. In
both cases, a large application portfolio with disparate technologies will appear at first hard to
grasp, and may lead to analysis paralysis.
When you engage in a massive application transformation that aims, for example, at moving
hundreds of organically grown business applications to a brave new world (possibly based on
private cloud infrastructure, for example), you will find typical patterns:
Applications that can be serviced through a simple server migration, either physical to virtual,
physical to physical, or virtual to virtual. They are equally simple with little or no dependency
on other applications or CMO infrastructure topologies.
Applications that cannot be moved by the means of infrastructure movements, but instead
must be addressed through special modernization or consolidation projects. SAP applications,
enterprise bus are good examples where it is better to plan for a new build infrastructure, on
modernized infrastructure and database services, and application logic migrated more or less
automatically by the means of specialized tooling.
Applications that are complex and/or built out of outdated components and have no upgrade
path require further analysis to prioritize upgrading to the current legacy data centers, or
rearchitecture through a true modernization project, possibly involving a platform change or
code translation. Those applications cannot be put into an application transformation general
process, but should rather be handled as individual projects.
Applications that no one wants to touch or approach, where the knowledge has been lost, and for
which there is no appetite to invest any further into them. As part of the necessary applications
portfolio assessment, you will have to determine how fast you can transfer the functionality
of the application to a strategic, go-forward platform, provided you have defined one.
Regardless of these categories, pay attention to the deadly sins. They are likely to cause
disruption in the progress of the application transformation, possibly failure in meeting the
initial business objectives of the transformation.

12

White paper | Transform applications

Application transformation schema sample

Field

Comment

Application ID

A unique ID for the applicationuse the one from applications online if you have

Application name

Short name of the application

Transformation

Fate of the applicationkeep, upgrade, archive; often this field can change because of change of directions or
application strategy

Status-step

Indicates where the application is in the transformation of the landscapediscovered, assessed, analyzed, quoted,
migrated, upgraded, and so forth; tracking status over time gives you a great insight of your transformation throughput
and efficiency (or lack of)

Transformation owner

The (named) individual in charge of driving the application through the main steps of an application transformation;
preferably it should be someone who understands the inside of the application and its dependencies

Application designer

The technical authority for the design of the application

Infrastructure designer

The technical authority for the design and supply of the infrastructure that supports the application and its various
landscapes/environments

Application Maintenance &

Support (Apps Run) organization

The name of the company or organization that delivers application maintenance and support services

Apps Run SPOC

A single point of contact (SPOC) in the organization that delivers maintenance and support services for this application

Application Operations
(Apps Ops) organization

The name of the company or organization that provides the infrastructure and operational services to the application

Apps Ops/infrastructure SPOC

A single point of contact in the organization that delivers infrastructure and operational support services for
this application

Security SPOC

A single point of contact in the security organization who can outline current security issues/constraints

Affinity

An indicator of a particular affinity, for example, if you have several applications that are all hosted on the same Lotus
Notes server, you will have to create a more or less soft link between those applications, given you may not be able to
move them independently

Target SLA

An expression of the target service level for the application

Application currency

An indication of the application currency versus the supportability of each component; the currency is mostly determined
by the supportability (mainstream, extended, out-of-support) of the individual components, and the overall currency
rating should not be greater than the lowest currency of the components

Infrastructure currency

An indication of the infrastructure (operating system, hardware, and layered products) currency; it can be expressed in N,
N-1, N-2, where N represents the most recent major release of said component

Replatforming

Indicates if the application contains components that should switch operating system platforms; keeping track of this is a
good way to prioritize application porting

Executive comment

Authored by the transformation owner, this should contain a short executive summary of the application (for example,
application is under review by ISV)

URL to application
documentation

A mandatory link to the unique location of the application documentation, including diagrams, presentations,
architecture artifacts

Source to target

The specifications of the infrastructure and services that will host the application in the target data center; considering
this is a document (most likely Excel due to the tabular nature of the information), it should preferably point to a
document hosted in the application documentation location (see previous item)

13

White paper | Transform applications

Learn about the author

Pierre Bijaoui
Pierre Bijaoui is a technology lead in the Application and Business Services of HP. He is based
out of Sophia Antipolis, France, and can be reached on pierre.bijaoui@hp.com

Learn more
hp.com/go/applicationtransformation

Sign up for updates

hp.com/go/getupdated

Share with colleagues

Rate this document

Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only
warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein
should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
Microsoft is a U.S. registered trademark for Microsoft Corporation.
4AA4-5977ENW, June 2013