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:
- Part-1 is about metrics that indicate the health of the landscape across various dimensions
- 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:
- Inventory (List of applications and related details like description, technology, # users etc.)
- Mapping (Business capability or function to Platform Platform to IT application and IT application to Infra)
- Product Usage (Product Name, associated details, Extent of customization of the product, Vendor)
- License (Vendor, License, ILF – Initial License Fee, RLF – Recurring License Fee, Contract expiry date etc.)
- Documentation (Required documents for understanding the system, required documents for providing support/development of the system)
- Technical debt (a quick assessment in the form of KLOC – Kilo Lines of Code or Cost)
- 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:
- Data centre Consolidation (Number and locations)
- Service Provider Consolidation (for a given IT spend, how many service providers should exist?
- Scope for consolidation; Dependency vs Risk vs Savings)
- 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.
