Académique Documents
Professionnel Documents
Culture Documents
Transform
applications
Learn about the seven deadly sins
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
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
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.
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
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
Application type
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
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.
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).
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
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
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.
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
25770ACE
25770ACE 26248-OWINS
25770ACE
HP-UX 11.31
Informatica 9.1
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
Services
Link
12985
Tax
Vertex
25955
XMS
25812
IDR
24642
ePIC
70588
12DM
70627
BPPM
80001
OWINS
26248
Apollo
BW
70574
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.
10
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.
11
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
Comment
Application ID
A unique ID for the applicationuse the one from applications online if you have
Application name
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
Infrastructure designer
The technical authority for the design and supply of the infrastructure that supports the application and its various
landscapes/environments
The name of the company or organization that delivers application maintenance and support services
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
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
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
Learn more
hp.com/go/applicationtransformation
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