Post date: Apr 11, 2013 3:16:31 AM

APR is part of Enterprise Architecture activities, APR can not be done without considering EA. Whether a company has formally setup and EA organization or not, it has to consider the enterprise vision and strategy before deciding on APR plans. So journey begins with considering EA looking in to vision of the organization and within EA, considering Business Architecture, based on Business Architecture deriving IT/Technology Architecture and so on.

So before APR exercise study of business processes, organizations operating model, architecture maturity etc should be considered and a gap analysis should be done to see where are the gaps between IT and business strategy and vision. This discussion is in separate writing, here focus in when you have decided for APR how to do it and what to do?

APR is a process by which analysis and reorganization of all applications in a portfolio is done to achieve following:-

• • Reduction in number of applications to eliminate redundancy

  • Reduction in complexity

  • Reduction of risks

  • Align IT with standards business process

  • Cost reduction

How it happens?

• • Reduction in cost due to less maintenance by removing redundant applications

  • Less infrastructure cost due to less infrastructure requirement by eliminating redundant applications

  • Improved IT management (reduction in cost) due to lower complexity

Steps in APR

• • Assessment

  • Analysis

  • Plan

Assessment(gathering information)

• • Gather information about all the applications:-

  • All the application, owners, versions, technology and platform

  • Map applications to business processes

Analysis (to evaluate based on facts gathered during assessment)

There are various aspects to be looked into to assess application portfolio of an organization. Some of them are:

Business

Analysis of business value is critical to decide whether an application is worth maintaining or should be retired. Business value comes from strategic vision of the company and alignment of an application with that vision. If an application is critical to business strategy and business can be seriously impacted by unavailability of an application its business value is high.

Technology

Analysis of technical quality is another aspect to decide about weather an application should be replaced by another better quality application or should be modernized if business value is high and technical quality is low.

Technical value can be derived from two parts:

• • Software quality

  • Hardware quality

Software Quality

Quality of software can be measured in different ways and all of them have their own advantages. Here are different ways to assess software quality:

1. Testing: Functional and Performance (response time, scalability or load etc)

2. Static code analysis : Static code analysis can give an idea what kind of standard practices are not followed in the code which can lead to issues in production like performance, robustness, security, maintenance, changeability and transferability.

3. Production feedback: Actual quality if the application comes from production environment from end users experience. Feedback through questioner focusing on type of incidence is important. Code analysis may not point-out a problem which may occur in production. Some of the examples of type of questions are:

• • What is the response time of various scenarios/pages/screens/transactions/reports?

  • What is the rate of incidences in production?

  • What is the availability/how frequently application goes down?

  • Is there any security incidence, hacking happened in past? etc

Hardware Quality

There are various factors which should be considered for assessing hardware quality. When hardware becomes very old it can not support new technology advancements and capabilities. Older hardware can not be scaled easily and hence becomes bottleneck for scalability. Here are some points to consider in summary:

• • Can not support demand/load

  • Can not be upgraded

  • Misfit in new hardware landscape/integration challenges

  • Can not support new software

  • Maintenance and support is a pain due to various reasons including skills needed, accessories etc

Risk

Assessment of risk is most important based on hardware and software quality of the application. Poor quality application supporting high business value functions are very risky and immediate steps should be planned for those applications. For each application specific risk analysis should be done and plan to mitigate the risk and contingency should be in place. Some of the rationalization options are mitigation or contingency for the risk an application is exposed to.

Identification of various risk factors, their cost and their probability can provide impact of those risks to the business. Even if risk is exposed to internal staff of internal customers it affects efficiency and finally impact business which should be identified as a business loss or cost to the company.

Cost

Cost of the existing application and its supporting infrastructure comes from following:

• • Support cost

  • Maintenance cost

  • Upgrade cost

  • Licensing cost

Plan

Based on analysis, planning to make changes in the application portfolio.

Low value and old applications - Retire

High value old applications - Modernize

Redundant applications - Eliminate

Another aspect is platform and infrastructure which should be standardized as a part of consolidation exercise.