Developing Enterprise Evergreen Strategy

Many organizations find themselves in a persistent challenge of maintaining the technical health of their enterprise systems. Vendors are constantly changing their release schedules and the battle to manage the underlying technology components such as the operating systems, databases, browsers and development code is enough to make any CIO lose their mind.

Over the last decade IT leaders turned their focus to developing enterprise cloud strategies and identifying functional areas that could move to the cloud to deal with these challenges. The advancement of cloud solutions like Microsoft 365, Workday, ServiceNow and Salesforce give organizations a pathway to at least partially address these challenges by moving technical health into a vendor's lap. However, this creates additional complexities for managing hybrid environments and securing the data across these environments. None the less, there will always be systems which must remain onsite, so it is essential to have a game plan to keep technical debt under control.

There are many white papers, articles and videos that discuss these concepts as technical debt or technical health. We like the term evergreen because of the traditional definition, "A plant that retains green leaves throughout the year". The sole purpose of an evergreen strategy is to ensure that an enterprise is persistently maintaining the health of their systems all the time. An evergreen mindset should be a core operating principle for every organization.

Starting the Evergreen Journey

• The first place to begin is executive ownership. Every single executive leader utilizes applications to support the needs of the business. Maintaining system health is every leader's responsibility. This issue must be owned from the top down and be a focal point for your company's core objectives.
• Develop a definition of what evergreen is to your organization. One of the challenges is finding a good definition that applies to your organization. When you google evergreen IT, you will find dozens of definitions however depending on what you are trying to accomplish as an organization the definition may need to change. For example, if your primary goals are to reduce cost or complexity then ensure these fundamentals are incorporated. If you are heavily regulated and maintaining compliance is essential, include this into your definition for what you are trying to achieve.
• Define your objectives. Good general objectives like reducing operational risk, maintaining regulatory compliance, or decreasing maintenance costs are great examples. Ensure your objectives are measurable and quantifiable.
• Develop your enterprise evergreen principles. It is important that you develop core principles that all projects or operational activity must follow which aligns to your evergreen strategy. Some example principles are:

• Build an evergreen application inventory. It will be important to have a master list of all your applications and their underlying components that support your business and IT operations. Have the list tied to your enterprise portfolio, business service, function including a named business owner.
• Map the application inventory to an Evergreen Framework and categorize the applications to the appropriate risk impact area for your business. Below is an example framework which could be utilized to map your applications to the core areas of focus. For cloud applications, these systems could be classified as low risk systems or simply an organization could exclude cloud systems from the evergreen strategy.

For the core applications which have a high degree of complexity, interaction with multiple applications and a large volume of users these systems would continue to maintain technical health through traditional capital project channels. These are your high risk, critical business applications. For these systems, managing the health of the system operationally without the rigor or project management processes would be too great of a risk for the enterprise to manage operationally. Additionally, many of these large-scale upgrades can be several million dollars and may require a separate, formalized capital expenditure to execute.

Determining the Delivery Approach

As your enterprise continues its journey developing an evergreen technical health strategy, you may discover one size does not fit all for the multitude of technology types. For example, your data center infrastructure’s tech health may be addressed by a reoccurring data center refresh initiative that occurs every 5 years, whereas complex application stacks that contain multiple interdependencies may contain quicker release cycles with shorter end of life and support cycles. How you approach the health of these systems may be different. This evergreen viewpoint is referred to as a top-down, bottom-up approach.

Technology Component Upgrades

For the applications classified under the framework as pure Technology Component Upgrades, the tactic will be to take a bottom up approach. These applications are generally custom applications, or the application support is either vendor managed or outsourced. Each technology component will need a roadmap which will be a continual roadmap managing the health of each of the technology components such as the database, operating system, browsers and the development code such as Java.

Application and Underlying Technology Components

For the applications classified under Application and Underlying Technology Components, the approach would be a top down approach. Ideally, the application and all the underlying components would be upgraded at the same time. This will reduce user impact for testing and streamline the automation supporting the system.

When combining these pieces, it will be important to create constructs for these configurations and identify the common constructs which could be bundled together.

Each construct will have its own roadmap depicting the iterations and timeline for when each component which will be upgraded. The key with these construct roadmaps is to align the upgrades carefully with what the application vendor is supporting with the underlying components.

In some cases, application vendors run behind industry standards supporting the most current databases or operating systems and in other cases vendors are ahead of the game forcing companies to remain current or lose support. Either way, tracking and managing all of this data should reside in your enterprise architecture repository and organizations should leverage the repository to manage these roadmaps. Below is an example of a roadmap construct for an application and its underlying components.

Capital and Operational Considerations

Many organizations are challenged with these technical health initiatives and the constant fiscal burden maintaining health has on the overarching capital budget for the organization. If an organization is addressing these technical health issues utilizing formal capital budget expenditure there may be some hybrid approaches to managing and funding the work.

If you are managing your technical health through capital projects, you may want to initially migrate your medium and low risk applications and reside them under an initial two year capital program. This should include all current capital and operational efforts in flight or being planned which address technical health in scope. The goal of an initial programmatic view is to spend some time in planning, resource management and data analysis determining the cost and resources which will be needed to operationally manage the evergreen strategy.

Under the initial scope of the Evergreen Program could include the following:

• Optimize governance, project chartering, enterprise architecture and ITIL service management tools and processes to align with the new evergreen framework. For more information on how to align your processes, tools and governance refer to the following article, Aligning Strategy, Architecture, Process Management and Governance. An enterprise may need to consider procurement of supporting technologies such as enterprise architecture repositories or data analytic tools which can track and manage the information.
• Develop a preliminary annual budget, determine ongoing support staff needed to maintain the health of these systems on an annual basis. These evergreen efforts mandate dedicated staff focused on maintaining health.
• Assign a C-suite leader accountable for the success of the program and objectives. The evergreen program and strategy should be a KPI for the organization and its traction transparent to the entire organization.
• Transition to an "internal" product or portfolio management culture. For more details on approaches refer to Leveraging Product Management to Optimize Delivery. Migration to internal product management approaches will allow the organization to leverage more agile based processes for maintaining technical health. Note that organizations with clear functional delineations can use the product management methodologies and center them around functional portfolio areas versus individual applications. For example, customer relationship management, human resources or point of sale systems could be managed at a portfolio level versus a product level and the supporting evergreen resources would center their work around these functional portfolios.

Fiscal Management Approaches

Pending the annual budget allocation developed from the program effort began a formal capital to operational transition of the evergreen support strategy.

Managing and maintaining technology health should be driven by operational dollars and managed using best practice agile, devops and ITIL based processes. These foundational processes are the anchor to a successful evergreen strategy.

As the program migrates over to operational support, organizations can consider migration of the evergreen approach over to an internal "subscription" like model. These kinds of subscription models are supported by traditional IT Service Management tools like ServiceNow or Remedy. You will need to leverage the budgetary cost models built during the program to determine your average cost per application to maintain technical health for all systems. Below is an example of a high-level subscription model at the portfolio level.

The above subscription model is an example of IT chargeback. IT chargeback is a method of charging internal departments or portfolios for the IT services they used. Instead of bundling all IT costs under the IT department, a chargeback program allocates the various costs of delivering IT (e.g., services, hardware, software, maintenance) to the business units that consume them.?

In an IT chargeback situation, instead of simply charging all IT costs to one central department, the company charges departments or portfolios that most directly consume the goods or services that were purchased or in this case the management of technology health. IT chargeback is sometimes contrasted with other options for keeping track of costs, such as Showback. In Showback accounting costs are presented in a decentralized way, without being actually cross charged to the different accounts. In some organizations, Showback may work better depending on how the enterprise accounts for IT costs.

Finally, as you work through your program transition into operational management, ensure your financial leaders are partnered with you to help manage and track the cost information for this effort from beginning to end. Smart technical health fiscal planning can result in huge cost savings and avoidance for the enterprise. This partnership with finance will be key.

----------------------------------------------------------------------------------------------------

Co-Written by Amanda Justice and Kate Davis

Writers Note: We found very little information online available to leaders on holistic approaches for enterprise evergreen strategies. We welcome your feedback and suggestions on what you have learned developing and executing this strategy for your enterprise. We would be happy to incorporate all suggestions to this approach for the benefit of the many architects dealing with this same struggle. Thank you in advance for any suggestions you may have.

RECOMMENDED READING

• Gartner: Executive Essentials: Advance IT Financial Capabilities - IDG00748995 - May 2021
• Gartner: Toolkit: PAID Assessment for Technical Debt Prioritization - ID G00737669 - December 2020
• McKinsey: Tech debt: Reclaiming tech equity
• BMC: IT Chargeback vs Showback: What’s The Difference?
• Gartner: Address Technical Debt With Gartner’s PAID Model and Avoid Bankrupting Your Application’s Future - ID G00719923 - June 2020
• Gartner: Case Study: Stakeholder Incentives for Technical Debt Management (Intel) - ID G00740371 - December 2020
• Intel: Enterprise Technical Debt Strategy and Framework
• Gartner: How to Assess Infrastructure Technical Debt to Prioritize Legacy Modernization Investments - ID G00728674 - August 2020
• Carnegie Mellon: Managing the Consequences of Technical Debt: 5 Stories from the Field
• Nicus: Showback vs. Chargeback: Which Should Drive Your Bill of IT?
• Daniel Enberg: Create an Awesome Evergreen IT Strategy in 2021
• BMC: Technical Debt - The Ultimate Guide