CIOs and CTOs: How frequently do you perform a health check up of your portfolio?

An IT landscape, like any other real estate, grows and changes continuously. In the process, it accumulates technical debt, grows equally well in both legacy and modern technologies, redevelops functionality, creates redundant systems and keeps tweaking many products to suit the BAU scenario. On top of it, if the organization acquires another company, the diversity of the portfolio multiplies. In the entire melee, no one bothers about keeping a proper count of inventory or documentation or health of the portfolio.

Very few organizations invest in a portfolio assessment exercise and fewer do so periodically. No doubt, such an exercise is time consuming and expensive. But, the benefits of a proper exercise, if done well, will help the organization to take decisions faster. Not knowing the extent of technical debt or the inability of the agility of the portfolio will creep up more and more work in every IT project and eventually pull back the organization’s ability to develop new differentiating products or services.

Now the industry is moving from on-premises to cloud; legacy to differentiating technologies; from systems that are obsolete or about to go out of support to open sources; separate development and support to DevOps; waterfall methodology to agile; sedate landscape to one that evolves and learns. Consequently, the focus of such assessment exercises should bring out these factors in the form of metrics.

Based on my experience, here is a primer in the form of FAQ on such an exercise:

What is such an exercise called?

It is typically known by various names. Some of them are APA (Application Portfolio Assessment), APR (Portfolio rationalization) or APO (Portfolio Optimization) or APM (Portfolio Modernization).

How frequently this should be carried out?

Once in three years is a minimum. This should be modified depending on the growth of the organization in terms of IT systems, inorganic acquisition of other entities etc. If the pace of change is more, once in 2 years will be better.

What is the duration and involvement of such an exercise?

The duration can range from 1 to 3 months depending on the quality of the IT assets and configuration data base maintained. Involvement from Product owners, Enterprise architects, procurement and senior management will be required. This initiative should be owned and driven from the CTO’s office.

Let’s talk about the outcome of a typical APA exercise.

Once we understand the output, the activities to be done, during the exercise, can be inferred easily. For the purpose of clarity, let’s look at the output as consisting of two parts:

1. Part-1 is about metrics that indicate the health of the landscape across various dimensions
2. Part-2 is about resulting initiatives and recommendations.

What does Part-1 focus on?

This has 2 sets of metrics. First set focuses on hygiene factors; the second set on value added parameters. The hygiene set should address, at the minimum on the completeness, quality and currency of data pertaining to the following 7 dimensions:

1. Inventory (List of applications and related details like description, technology, # users etc.)
2. Mapping (Business capability or function to Platform Platform to IT application and IT application to Infra)
3. Product Usage (Product Name, associated details, Extent of customization of the product, Vendor)
4. License (Vendor, License, ILF – Initial License Fee, RLF – Recurring License Fee, Contract expiry date etc.)
5. Documentation (Required documents for understanding the system, required documents for providing support/development of the system)
6. Technical debt (a quick assessment in the form of KLOC – Kilo Lines of Code or Cost)
7. Cost related (Various cost elements including but not limited to resources, service provider, product vendor, license vendor, compute, network, storage, cloud etc.)

The second  value-added set should focus on the ability of the IT organization to closely align with business and quickly respond to the changing needs without undue lag. What are the areas to focus here?

Cloud readiness – Cloud is great leveler of the landscape and imposes more uniformity and standardization without compromising on the business capability. How much of the landscape can be easily shifted from on-premises to cloud?

Platformication readiness – How are the IT systems and infra being developed? Do they lend themselves to a vertical clean cut enabling business, application, data and infra layer to go towards a platform or a utility model? Typically the top 30 to 40% of the landscape that are key to the business should fall into this bucket.

System of innovation and differentiation – All the systems can be bucketed into system of records (back office, core, legacy that undergo little change), differentiation (the middle layer that gives opportunities to differentiate the services) and innovation (the key ones that are integral and unique to the organization’s capability). As the landscape matures, more and more systems should move from records to differentiation and differentiation to innovation. That way, more and more of the landscape will lend itself to agility and help in a faster turn around.

DevSecOps readiness – How are changes implemented in the portfolio? How is support provided? Is there a wall between them? What type of people are being used across the landscape? What is the release periodicity? Is the entire IT operating on a single cadence even if many methodologies are followed? How is security principles embedded in the life cycle? Today’s world is taking the landscape towards a common set of cadence with no blockers to the ground.

Skill readiness – The organization should adopt a uniform system across its internal as well as external employees / contractors / service providers to denote the skill and competency. Dreyfuss or SFIA can be adopted. This help in talking the same language, drawing up training plan, cross-skilling of people, providing a career path etc.

Tell us about Part-2 of the outcome

Once the above is complete, various metrics can be collected that can provide a useful basis for arriving at a set of recommendations. We can classify the recommendations into 3 categories:

Category-1: Hygiene initiatives

All the hygiene factors, mentioned in part-1, should be ranked on a scale of 1 to 10 (10 being high quality, complete and up to date). Wherever the score is below 5, a program plan for bringing it to 8+ should be provided. If the score is > 5, either a separate plan or as a by-product of a major upgrade/project should be specified.

Whatever it is, by a certain time line, all the hygiene factors should be brought to 8+. Even if no modernization is undertaken, this is very important. Otherwise, this will drag the entire development and release.

Category-2: Extrinsic initiatives

These should address factors like the following:

1. Data centre Consolidation (Number and locations)
2. Service Provider Consolidation (for a given IT spend, how many service providers should exist? 
3. Scope for consolidation; Dependency vs Risk vs Savings)
4. License Optimization (Optimization of licenses across the organization, management of RLFs, negotiation with vendors etc.)

Category-3: Intrinsic initiatives

These arise from within the portfolio and enable the organizations to move to a certain state. Every state should be characterized by the set of value-added factors mentioned in part-2.

Some of these could be:

• Categorization of applications into those that can be decommissioned, migrated and modernized and consequent programs to implement the same. All the initiatives (a functional migration, technical reengineering, refactoring etc.) should be ranked according to the RoI, Time taken to implement and risk including cost of change across the organization. Implementing such initiatives will lead to reduced application intensity, reduced technology spread etc.
• Program plan for increasing the cloud usage
• Program plan for bringing the entire organization into uniform DevOps or DevSecOps
• Program plan for eliminating niche, obsolete and other technologies that will soon go out of support
• Program plan for baselining the skill, productivity and measurement across the landscape

Tell us about the stakeholders

These exercises should be driven by the CxO through an appointed PO (Program Owner). A ToR (Terms of Reference) of such an exercise, objective, timeline and involvement and support of different stakeholders should be drawn up and roadshows held one to two months before the exercise. The program should be part of the CxO’s steering committee. A dashboard indicating how the health and agility of the portfolio evolves during the next 3-year is a must.