Getting More from Your Application Portfolio

By Ramesh Dorairaj

(Back to article)

Minimizing and eliminating waste is the central theme of lean manufacturing. This and a follow up article will address the issue of non-value added work and suggest ways of minimizing or eliminating it. Non value added work can arise due to the following factors: over production, motion, waiting, the process itself, inventory, correction, and conveyance.

Over Production

Overproduction is the set of activities that leads to manufacturing products that do not have a demand. In application maintenance, these can be translated as: excess of applications and excess of maintenance on those applications.

Excess of Applications: Given the extensively distributed nature of some IT installations, especially in large organizations, there is every possibility of a number of redundant applications are simply not being switched off. Look closely at the production tickets/issues that are forthcoming. The first candidates are those applications on which there are no activities.

To identify applications that are no longer needed, begin with an application map. The application map is a simple table that lists the business function (e.g. Payroll), business process, business sub-process, and the corresponding applications.

First Step: Discover Overlapping Applications : Overlapping applications are those that have significant commonality of features. Multiple functions supporting a single business process/sub-process are most probably overlaps.

For the applications that appear to be overlaps:

  • Get an overview of the data stored by or reported by all the applications;
  • Explore for duplicate functionality, data storage, technology mismatches, and investment; and
  • Identify interfaces between such applications.
  • Second Step: Discover Singleton Applications : Singleton applications service a single critical link-process or an interface process. In your application map, these appear only once. The cost of maintaining these applications tends toward extremes, either very negligible, or very high. Singleton applications should be retired.

    Third Step: Discover Redundant Processes and Applications : Redundancies creep into application portfolios typically by acquisitions and expansion into new geographies, addition of service lines, and in some cases, the addition of new customer categories.

    Redundancies also occur as a consequence of similar business processes being followed in different units, and therefore, handled by different applications. Check whether some of the applications can be consolidated.

    Step Four: Discover Stop-Gaps, Roamers, and Chains: Stop-gaps, roamers and chains are applications that usually occur in large portfolios. They usually soak up more than their share of maintenance costs and are ideal candidates for consolidation and replacement.

    A stop gap is an application that services a sub-process whose predecessor and successor processes are supported by one application. Gaps, on the other hand, are processes unsupported by any application.

    Roamers are applications that appear at random in the application map. They usually differ in architecture from the rest of the applications. They tend to consume a higher proportion of maintenance costs.

    Chains are a series of sub-processes, each supported by a different application.

    Now that the applications contributing to inefficiencies in your portfolio have been identified, you can prepare your roadmap to rationalize your portfolio. Identifying applications that need to be retired makes it easy to filter out requests pertaining to that application.

    Excess of Maintenance

    The major causes for needless and early releases are: poor governance inadequate communication between the maintenance teams and business; inadequate controls on the requesting process; inability of the IT team to establish, communicate and allocate costs to business units; and politics.

    Adequate governance on application maintenance is the needed protective cover under which maintenance teams can function effectively. Governance must be designed in a manner to ensure that genuine requests are handled in a smooth and easy manner; while filtering out the needless requests.

    Retaining Flexibility while Optimizing Releases : One of the concerns repeatedly mentioned by clients is the fear of loss of flexibility in moving to a structured model of request prioritization. However, flexibility needed for a business usually occurs within a narrow time-window. You can schedule adequate effort for these time-windows and empower a few people within those units to break request queues. The other stakeholders need to be also informed of this calendar and ensure that their critical requests are not affected. Motion

    The concept of motion in manufacturing is the time wasted by a worker in moving from one work station to another to complete a set of activities. Reduction of motion reduces fatigue in the worker. The ideal is that all the tools and the work item must be within easy reach.

    In the application maintenance world, motion can be the translated as the amount of time a person spends ensuring that all necessary information and tools to complete his/her work are available at the right time and easily accessible.

    To minimize the time spent by the maintenance team in motion, there are a few questions to ask:

  • How many times do you have to call the user to clarify a request?
  • How many times do you have to call another maintenance team to clarify a request?
  • How much of your time is spent in coordinating between a third-party vendor and your programmers and users.
  • How do you get the user to accept your fix/change to the application?
  • While completely eliminating movement is neither feasible, nor recommended (people-to-people interactions are far too important), providing people with an empowered desk-space with appropriate tools and information can greatly minimize the time wasted in non-value added movement.

    There are no set methodologies to minimize motion in the application maintenance context. However, there are a few things that can be done:

    Consider classifying requests into standard categories with templates for each category. Each of these requests has its own template and the user fills them in to ensure that clarifications are minimized.

    Consider introducing self-help features for some of these requests, like queries and reports. Educate the users on these features and gently turn away all such requests to the self-help feature.

    Consider nominating one member of the team as the business interface who will interpret user requests.

    Consider an on-line collaboration mechanism that eliminates the need for people to seek out information from other people on a regular basis.


    Waiting is closely related to motion. In fact, waiting induces motion in the context of application maintenance. Waiting can include idle time due to lack of tickets or work, and waiting for code being modified by another team member.

    The way to eliminate waiting is to let the team figure out and list the key problems that lead to the waiting. It could be the unpredictable arrival rates of defects with unrealistic resolution expectations, which can induce overstaffing and therefore, waiting and idle time.

    Editor’s Note: In next week’s column Ramesh will discuss ways of improving process, inventory, correction, and conveyance.

    Ramesh Dorairaj is head of Application Management Services for MindTree Consulting. Ramesh has more than 18 years of industry experience across domains such as banking, commercial markets, retail, utilities and manufacturing. He currently advises MindTree customer on better management of their application portfolio, establishing appropriate support organization structures, implementing quality frameworks like CMMi and scaling up IT organizations to meet growth challenges.