CUTTER IT JOURNAL VOL. 29, NO. 3
The IT function in the typical Fortune 500 company is increasingly expected to enable business innovation and support digital disruption while ensuring secure and reliable operations of existing enterprise applications. The expectations of IT are funded by IT budgets that are subject to regular cuts during the fiscal year when the company does not meet performance targets or experiences other competitive pressures. In the marketplace, shorter product and service lifecycles are creating enormous pressure for businesses to innovate to retain profitable market share.
One major obstacle to business agility and innovation is technology debt (TD). TD obstacles manifest themselves as non-IT executives complain that “we can’t launch this new product/service as our IT systems will not allow us to.” From an IT standpoint, the inability of existing IT systems to support the proposed new product/service launch is a result of past technology “workarounds” that were implemented to meet an accelerated timeline or reduced budget.
Given this history, how can the IT function engage with the business to remove technology debt and enable business agility and innovation? It is nearly impossible to prevent technology debt from being created — product/service lifecycles are getting shorter, making time to market an imperative for which taking shortcuts becomes a necessity. (The only exceptions that come to mind are of systems being developed and deployed for highly regulated environments or mission-critical applications in areas such as medicine and defense.) However, the size and scope of the technology debt being created can be contained, and on rare occasions some technology debt can be prevented, with proper analysis of the impact of a proposed workaround on business process agility/scalability.
Within IT, we have existing methodologies that can help non-IT executives engage with and take ownership of retiring technology debt. Despite enterprise architecture (EA) being touted for over a decade, rarely do we see companies map business architecture (BA) to underlying IT applications and supporting systems infrastructure. Transforming the EA function from a conceptual group to one that is responsible for creating the solution architecture will lay the groundwork for engaging business/functional owners in making the tradeoffs forworkarounds.
In this article, I will explain how to get business engagement and “buy-in” to remove technology debt using existing IT processes such as the quarterly/annual budgeting process, design reviews, and functional walkthroughs. To obtain funding and business sponsorship for TD remediation projects, it is important to get non-IT executives to understand and support the TD remediation challenges. Understanding how technology debt is created is essential to preventing, containing, and retiring the debt.
TECHNOLOGY DEBT CREATION AND GROWTH
For discussion purposes, I will expand the definition of “technical debt” to “technology debt” to include different layers of the technology stack that composes a business application or function. For example, the technology stack could consist of custom-developed code, configuration options for a COTS package, and the underlying database, computing, storage, network, and presentation layers that together deliver business functionality. The functionality could be a simple order entry (OE) system or a more complex ERP system with integrated business functions.
Figure 1 depicts an OE system and its components across the technology stack. At its inception, the system would have been designed to work with other layers of the stack through the application and Web service layers. The proper design for interaction is depicted with the thick bidirectional arrow. During the development phase, to meet performance goals or deal with resource constraints, workarounds are written to interact directly with other systems (such as the CRM and general ledger [GL] applications). These shortcuts — point-to-point integrations — are shown in Figure 1 as thin bidirectional arrows. For simplicity, the diagram shows point-to-point interactions with just one application; in reality, there would be hundreds of point-to-point integrations with other applications and systems (such as the operational data store) by the time the OE system goes into production.
Once the OE system is in production, more integrations are added over time to deliver incremental functionality. The workarounds developed are typically not well documented, and the developers who wrote them would likely have moved on. The mostly undocumented workarounds (see Figure 1) create a “lock-in” between the OE, CRM, logistics, GL, MRP, and other layers of the technology stack. This lock-in grows over time as more and more upstream and downstream integrations are created. Any major changes to, or replacement of, systems requires a thorough analysis and remediation of the hundreds of integrations. This is an example of technology debt that needs to be remediated before enterprise applications in the lock-in category can support new capabilities or enableinnovative business processes.
There are other sources of technology debt besides the example given above. To meet a reduced project budget, project teams make suboptimal choices on infrastructure areas such as servers, storage, and so on. While these choices allow teams to deliver systems that meet the current need, they may limit future growth — creating technology debt that needs to be addressed at a future date.
Technology debt can grow exponentially, especially if the company achieves business success using the IT system with workarounds. Successful workarounds create lock-in with the functional users of the system, making change difficult if not impossible. The IT workaround inproduction could consist of software shortcuts, quick-and-dirty definition of databases, and/or suboptimal systems infrastructure choices. The successful IT system will propagate through integration with upstream and downstream systems. Years later, when the business wants to change upstream or downstream systems to launch a new product/service, the production system may not support this without the workarounds being modified or replaced. In some instances, replacing the workarounds will have an adverse impact on current operations.
Systems inherited through mergers/acquisitions and “shadow IT” add to the technology debt. The size of the problem in most mature companies makes it a Herculean task, and no one wants to clean the proverbial Augean stables, especially if the debt is not visible. We need to document the technology debt across business processes and operational systems before we can seek non-IT executive support to remediate the problem. Using business architecture and IT service catalog processes, the IT function can identify TD areas, obtain business sponsorship, and secure funding for projects to remediate the debt.
The business architecture process coupled with the IT services catalog gives us the context to build and maintain an inventory of TD areas and their impact on business processes, operating costs, and service-level expectations.
GAINING BUSINESS BUY-IN USING BA AND THE IT SERVICES CATALOG
For the most part, the IT function is technically capable of designing and implementing solutions that remediate technology debt. The challenge lies in obtaining non-IT executive sponsorship and funding for TD projects. Figure 2 shows a high-level overview of the IT budgeting process that can be used to gain executive sponsorship and funding for TD projects. The suggested approach is applicable even if a company does not have a formal IT services catalog or a BA repository.
Let us assume that the company depicted in Figure 1 decides to move to a cloud-based, software as a service (SaaS) provider for sales force automation (SFA), thereby replacing their existing CRM system. Migrating to the new platform will require an analysis of the upstream and downstream business processes that interact with the current CRM system.
During this analysis, the typical solution architecture is created with the sole purpose of implementing the SFA system. As part of the solution architecture, a TD review of the workaround integrations between the old CRM systems and other systems also needs to be done. The review and documentation of the technology debt in the BA repository should be led by the EA function, with input from subject matter experts of the various systems and technology stack areas. This review will pinpoint areas of technology debt that create process lock-in, impact scalability, and prevent improvement of existing business processes. This will result in the identification of TD remediation projects that should be funded as capital projects in support of the SFA system.
The SFA project team’s primary focus will be on implementing the new system and not on removing technology debt surrounding the CRM system. The TD project needs to be executed in parallel with the SFA project. Artifacts from the BA process are critical for gaining support from non-IT executives for investment in TD remediation projects. The business process and IT roadmaps are visually compelling tools that can show the impact on business capabilities, agility, and prevention of innovation if technology debt is not remediated.
The other funding track for TD remediation projects is the annual/quarterly IT operating budget review. Most firms have elements of the data shown in the IT operating budget arrow in Figure 2. Even if a company does not have a comprehensive IT services catalog mapped to every operational system, it will have a high-level breakdown of the IT operating budget in support of different functional and technical areas. Areas of technology debt that would — if remediated — simplify IT infrastructure/applications, improve service levels, strengthen security, and repurpose the IT budget should be identified as part of this review process.
It is not necessary for systems providing new business capability to come out of the capital budgeting process or for IT infrastructure simplification projects to come out of the IT operating budget process. For ease of discussion, I have simplified the two tracks even though they are not mutually exclusive in terms of the types of projects. Similarly, the IT services catalog and BA processes can be quite extensive and detailed. However, to educate and engage non-IT executives in the sponsoring and funding of TD remediation projects, high-level business process maps and IT roadmaps that illustrate the impact of workarounds should suffice.
TACKLING TECHNOLOGY DEBT
Preventing TD
Technology debt can be created in the development, deployment, and production phases of the software development lifecycle. BA and functional ownership ofthe application/system are critical to preventing the creation of technology debt. Showing the non-IT system owner that implementing point-to-point integrations creates process lock-in and limits future business process improvements may lead to surprising results. Well-informed system owners may decide to reduce project scope to meet budget reductions instead of approving workarounds that create technology debt.
Developed over time, an accurate BA repository and a comprehensive IT services catalog become invaluable tools in preventing technology debt from being created. By using artifacts from the BA repository and the IT services catalog, the adverse potential impact of workarounds can be shown on the business process and on the IT operating budget and service levels.
Containing TD
A major source of technology debt is the shadow IT functions within companies. In many instances, the IT function is unable to service the technology needs of a business unit or function, prompting the business unit to obtain and implement local IT solutions without the IT function’s buy-in, budget, or resources. Conversely, the typical enterprise IT function is stretched thin and does not have the bandwidth to support ad hoc business/functional IT needs. Going forward, the enterprise IT function should engage, support, and guide shadow IT to make the optimal technology choices.
Optimal technology deployment may not be feasible if the business unit/function is evaluating quick-and-dirty prototype systems. Instead of fighting the business unit in question, IT should continue engagement and support, documenting the TD areas that will need to be addressed at a later date. Increasingly, business process innovation enabled by IT systems is coming from regional/local functional and business areas. The enterprise IT function should set aside resources to support shadow IT. Over time, most successful shadow IT systems become enterprise IT’s responsibility anyhow, and engaging early with shadow IT can help contain the size and scope of technology debt by providing technical guidance that is typically missing in the business unit orfunction.
As part of the functional and technical design review gates for the OE system in Figure 1, the solution architect can educate the owners of the GL, MRP, and other systems about the process lock-in created by the point-to-point technology integrations. This can turn into a confrontational situation between the project manager and the functional owners of the OE, GL, MRP, and other systems, from whom the project manager will need resources to address the process lock-in issues. Tight budget and resource constraints can cause the functional owners to push back on the project manager.
The objective here is to identify the business processes outside the OE system impacted by the workarounds and to get functional owners to sign off on the workaround design that creates point-to-point integrations with the GL, MRP, CRM and logistics systems, as it has the potential to create process lock-ins (depicted in Figure 1). At a future date, any changes/upgrades to the GL or MRP processes would have to account for the impact of the OE workaround integrations. In the worst-case scenario, the process lock-in caused by the workaround is not discovered until an upstream or downstream system (such as the CRM or MRP) is modified and causes the OE system (now in production) to crash.
Typically the IT project team implements the workarounds without obtaining signoff from functional owners of upstream and downstream systems, as that would require expending scarce resources to obtain buy-in from these owners. As I’ve just noted, the result of such avoidance can be disastrous. Instead, discussing these issues as part of design review processes allows the business unit owners to provide input and take ownership of approved workarounds. This process of engagement allows the IT function to document the TD areas that may become remediation projects as part of the annual IT budget cycle.
Retiring TD
A small amount of technology debt is often retired as part of technical upgrades or maintenance releases. But in general, most mature companies grow the debt at a significant rate. Explaining the concept of technology debt to a non-IT person using Figure 1 can be challenging. Technology debt gets created because it is easy to hide in multilayered, complex systems.
The first step to retiring technology debt is to document the workarounds. The documentation should identify areas where the workarounds make innovation difficult, create process inefficiencies, allow security exploits, and increase IT operating costs. The IT function should use the existing BA framework to document and inventory the areas of concern. The second step is to effectively communicate and gain sponsorship from non-IT owners for the technology debt retirement projects. The third step is to ensure successful execution of funded TD remediation projects.
Consider the example of the OE system in Figure 1. The BA artifacts for the OE process would show the process flow of quotes, order placement, order confirmation, shipping notification, and so on. The supporting IT architecture artifacts would map the IT systems enabling the OE business processes. Similarly, the MRP system BA artifacts would show process flows for sales orders, forecast, planning, scheduling, order processing, and the like, with supporting IT systems artifacts.
The workaround of direct integration to the order processing module in the MRP system for order confirmation in the OE system creates process/system dependencies across OE and MRP business processes. This workaround would have been in response to the sales function demanding that a customer’s order confirmation be immediate. Over time, the workaround results in not having enough product to meet the customer orders on the committed schedule, as the commitment was made while bypassing the MRP process flow. Correcting these types of issues caused by the workaround with more short-term fixes taxes the IT operating budget with reduced service levels.
The thin lines in Figure 1 represent hundreds of similar workarounds between functional business processes and supporting IT systems. The business and IT architecture artifacts can help educate non-IT executives onthe existing process lock-ins between subprocesses across finance, operations, OE, business development, and so forth. One approach to determining the operating costs of supporting the hundreds of workarounds is to review the prior year’s incident response and problem resolution logs to determine the resources expended to fix problems caused by the workarounds.
NOT A BURNING PLATFORM
Technology debt is insidious and grows like a giant underground fungus. On those occasions when a workaround is exploited to steal data, and the company gets unwanted publicity, tackling technology debt in the systems that were breached suddenly becomes a“burning platform,” and enormous resources are expended to remediate the workarounds.
A company does not have to wait for a burning platform scenario to address technology debt. The situation described in Figure 1 occurs to varying degrees in most companies with enterprise systems. Retiring this debt will not happen without efforts being funded and run as separate projects with stakeholder sponsorship. In many instances, the sponsorship could run across multiple departments. It requires an organizational view of the business processes and supporting IT portfolio of applications.
The IT function supports the systems that enable business processes within a function (e.g., finance, sales, manufacturing, HR) and across the functions. Addressing technology debt within a function (e.g., finance) is relatively straightforward, as IT can inform and seek the CFO’s sponsorship to remediate the debt. To remediate technology debt that is created across functions, as in Figure 1, IT needs to educate and gain sponsorship from multiple non-IT stakeholders. This is a challenging task, and having the BA artifacts in hand can help illuminate the problem areas.
If companies do not clearly identify initiatives that prevent, contain, and retire technology debt in their capital and operating budgets, they are only adding fuel to the fire. The process and technology lock-in that results will hinder innovation and increase operating costs.
