Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Alternate title: 

The Blocking and Tackling of
Application Lifecycle Management

In the spirit of the colleges’ spring games going on across the country, I have entitled this inaugural blog “The Blocking and Tackling of Application Lifecycle Management.”  I love football and the phrase “blocking and tackling” has made its way into business vernacular. For my colleagues who have not grown up playing or watching football, please indulge me. Blocking and tackling are terms that refer to the basics of the game of American football. 

 

Blocking is the act of an offensive player bearing down on a defensive player to momentarily move him in a direction away from the ball. If the offensive line misses a blocking assignment, the intended organized play breaks down and bedlam ensues often times leaving the quarterback to scramble and use his improvisational skills to move the ball down the field. If he is good, he usually makes a few yards on a broken play or at the very least avoids a loss of yards.

Tackling, on the other hand, is a much more individualistic part of the game and it is the basic building block of the defensive. To tackle is to seize a player and bring them to the ground. This is a difficult task when you have the opposing team blocking your opportunity to pursue and square up to the person with the ball. The best tackler is placed as the middle linebacker. This person has vision across the offensive landscape and can usually predict where the ball is going to be in a split second and the pursuit for the tackle is on.

Application Lifecycle Management "basics" are important to IT portfolio planning for efficient use of resources. Once the basics are achieved, other higher-level concepts can be applied to build on its foundations. From a timing perspective, IT Portfolio Planning kicks off in the late summer, just before the fall football season, and you will be prepared by applying the ideas in this article!

 

The X's and O's of Application Lifecycle Management

The definition of Application Lifecycle Management is the supervision of a software application from its initial planning through retirement. The goal is to perform this in the most efficient manner. Referring to figure 1, an idea for an application takes shape in business strategy and grows as the management team prepares to achieve its objectives. It is the business objectives that drive a new initiative for increasing revenues or reducing costs. Each business initiative typically has an IT component, which feeds into an IT project portfolio planning process. Inside the project planning process, IT standards and policy also have to be incorporated in these initiatives to drive reuse and efficient selection of technology. As the applications are being developed, IT works with the business at a different level to automate the business to their specifications. Once an application is put into production and is added to the Configuration Management Database (CMDB), it becomes a configurable item (CI). The application portfolio planning process must review these application CIs to determine their useful life and manage how the business functionality will be remain automated when it is time to retire the application. Application roadmaps are useful tools to maintain the timing of these events. When an application is ready to begin the retirement process, it should be included in the annual Project Portfolio Planning process to ensure follow through and the benefits of retirement are tracked.

 

Figure 1 Application Lifecycle Management

 

Application Blocking Assignments

On the offense, every team member must follow his or her assignment just as each application must have a Senior IT Analyst or IT Manager associated with it. Let me first define applications to be business applications, which have end-users and support business functions. Software utilities and productivity tools do not fit into this category. For example, a database utility should not be considered a business application as it is a utility, and email and MS Office Programs should be considered productivity tools.

The Senior IT Analyst or IT Manager, owner of the application, is the individual called when there is a severe incident and the same person act as an advocate to secure funding for improvements. This person may interact with the business on functional changes, but is also an IT professional, who understands the technical details about the application and can put his hands on the documentation. 

What sort of details should the owner know about the application? First, general details about what the application does, the business functions it automates, application usage, and the application's criticality to the business. In addition, necessary details around the cost drivers of the application help IT perform business cases about the lifecycle events. Other details like operational statistics, documentation and technical architecture are useful in determining the trending costs of the application.  

 

Tackling the Application Landscape

Like the middle linebacker, having clear vision of the application landscape will focus your efforts and pick points to create value. By pulling together an application list and adding attributes, it will become apparent where each application ranks in its relative importance. In fact, this application inventory list, once assembled, should highlight a set of applications that should be on a road to retirement. Here a standard retirement play should be created so that the applications can be eliminated via a formal process where supporting infrastructure can be taken offline or repurposed. The retirement candidates should be identified, and dates for retirement should be forecasted. The retirement forecast could be used as a key metric for the monthly or quarterly IT leadership meetings. Application reductions are a key performance statistic that should be reviewed and monitored. While savings from application retirements are not all equal, tracking the total number of applications in the landscape indicates a level of maturity in ALM processes.

Using the same view of application inventory with mapping of business functions, the IT organization knows which applications automate a set of the business functions. To perform this mapping, the business organization should have a defined business process model. If a process model does not exist, it is a good opportunity for IT and the business to get together and decide on one. (Note that a business process model is sometimes called a business capability model.) American Productivity and Quality Center or APQC offers process models on their site APQC.org. Once mapped, the IT organization can review where multiple applications are performing the same business function in separate business units, divisions, geography, or from previous acquisitions. The functional redundancy of a set of applications needs to be reviewed and analyzed to determine where application reductions can take place. 

The technical architecture of the IT landscape is always changing and version control is important to maintain for operational sustainment and to reduce security vulnerabilities. Out of serviceable life operating systems are particularly vulnerable because security patch creation has stopped. Landscapes that have high technical debt may need to be addressed on a component-by-component basis. A factory approach should be considered to upgrade the landscape's obsolete technical components.

 

The Game Plan for IT Application Rationalization in Portfolio Planning

Keep in mind, the APM goal is to ensure efficient use of IT resources, which can be people, computing assets, and IT spend. So how do we put a game plan together? First, let's tackle the applications that we have determined should be on a path to retirement. Eliminating an application requires some investment to complete and should be a part of the annual Portfolio Planning Process and tracked alongside the other IT projects. The functional redundancy that has been identified should be placed on an application roadmap, which will be used for the current planning cycle and out years, and a three-year planning horizon should be used. Current year application roadmap activities are a part of the planning process as well. By sticking to the game plan of retiring applications, eliminating functional redundancy, and keeping technical components current, your organization will optimize resources and begin to drive winning IT strategies.  

 

About the Author

The author John Bagazinski works for Capgemini as an Engagement Lead for IT Strategy and Enterprise Architecture projects. Please feel free to reach out to John regarding any questions you have about this blog.  He can also be reached at @JohnBagazinski on Twitter.

 

 

About the author

John Bagazinski
John Bagazinski
As a trusted advisor, I have collaborated with clients on IT strategy and enterprise architecture engagements to identify rationalization and simplification opportunities in the client's application landscape resulting in cost savings and modernization.