Software AG Reality Check
            

Last year's Reality Check anticipated that we would see a year of digital transformation in action. The sheer volume of investment in digital and technology initiatives that started in the middle of 2020 dramatically accelerated digital transformation initiatives, but with a pressure to deliver real-world outcomes that we had not seen before. 

Looking back on the previous year we have seen companies investing in a number of initiatives that have been focused on providing a more connected working environment for their employees, better experiences for their customers and more efficient supply chains with their partners. This is not to say that there have not been challenges throughout this time, but it’s safe to say that the evolution of digitalization got a real shot in the arm during 2021. As a result organizations have started to become more connected as they have digitized themselves.

The boom is not over yet. 78% of organizations project that their IT budget will be higher in 2022 than in 2021…with one third saying that that increase will be significant. Only 2% think it will be lower. Of that, 74% say that more will be spent on digital transformation initiatives.

The technical parts of digital transformation have not been the biggest challenge though. The cultural aspects of these changes have been the make or break. Digital companies aren’t defined by the platforms they use, but by their attitude towards technology and their behaviors. Of the many behaviors of truly digital companies – and one of the key characteristics of the original digital disruptors – is the commitment to a Minimum Viable Product (MVP) approach. 

Spotify is one example of a company that started with an MVP. From when it was founded to when it went public, it was essentially an MVP, because it knew two things: first, it needed to assess the quality of the streaming itself; second, that there would be issues with rights management. So it focused on maintaining the MVP while these other issues could be worked on. Had it waited to launch until these things were sorted it would have both missed an opportunity and likely never have gotten the best quality insight.

Sheryl Sandberg is famed for saying “done is better than perfect”. This idea is driving many of the companies under pressure to enable hybrid working, shift sales online or operate remotely.

MVPs do – and will continue to – enable companies to be more reactive to customer or employee needs; more alert to shifts in market conditions and more agile to opportunities that may be presented. However, the trade-off to this responsiveness is that MVPs create technical debt. This will prompt a shift in the next couple of years of how companies approach their transformation. Some technical debt is inevitable and a benefit to those who embrace it, when managed correctly.

We’ll explore in this Reality Check the state of play around technical debt and what companies should be thinking about as the next steps in their evolution.

1. What is technical debt?

Technical debt has several definitions, but for our purposes we are defining it as the additional work or re-coding that must be done to digital systems after they have gone live. 

It is very comparable to using a credit card. Take an amateur cyclist who needs a new bike for an upcoming race, but doesn’t have all the cash on hand to buy it. As long as they can pay the whole balance by the time it becomes due, a credit card will help them perform better in the race; using a credit card was a positive decision. The same is true of technical debt.

Pasta Evangelists is an entrepreneurial success story in the UK because it decided to jump in at the deep end. Talking to the UK’s Daily Express, founder Finn Lagun said: “Often the best way to improve something is simply to start doing it…if you wait and wait, you may miss the bus.” Clearly showing that the ‘credit card’ approach to business development helped set the company on the path to success.

Technical debt is not inherently positive or negative, it’s simply a condition of operating in an agile way. But how it’s accrued can have a significant bearing on whether it’s good or bad debt.

Technical debt that’s the result of an MVP, launching at 80% capability, for instance has high potential to be good. Organizations should be aware of the outstanding 20% and can make decisions about the debt they’re taking on. 

However, unintended technical debt is far more frequently negative. It could be the result of something missed in the original development, which happens but shouldn’t be a regular occurrence. Then there is that which emerges over time: the result of digital standards evolving, regulations changing or simply the transformation of businesses that can complicate IT infrastructure and operations. The quicker a company transforms, the faster some of this dormant debt can emerge.

Technical debt, both good and bad, is a natural part of being a digital first company. In fact, 78% of organizations have accrued more technical debt in the past year than in previous years. The pandemic has been an accelerator of digital transformation efforts, and with it has sped up the onset of greater levels of technical debt. 

The encouraging news is that 82% of companies feel that they can assess some or all of their technical debt. However, and more crucially, 58% don’t feel that they have a formal strategy in place to manage it. This is one of the problem statements that should be high on the agenda for every company.

This is especially true when we look at the kinds of activities that most frequently lead to technical debt: new digital products (39%), infrastructure modernization (34%) and data analysis/integration (32%) are the top three most common causes. All of them essential parts of digital transformation and/or day-to-day operations. 

So in a world where technical debt will be commonplace, companies need to have strategies for addressing it. Intentional debt is simpler to manage but still has many challenges. Managing unintended debt is much harder…and while companies need to find ways to work through it, they should also think about what might cause more unintended debt in the future and how they can neutralize the threat.

2. Intended vs. unintended debt

Managing intended debt: visibility of the situation

Only 42% of companies feel that they have the ability to assess all of their technical debt, which goes some way to explaining the gap to those that have a formal strategy for managing it. Knowing that the debt is there is only the first step, albeit an important one. Managing it requires an understanding of the current impact and an estimate of what will happen at different points in time in the future. 

As with financial debt, the thing that makes it unmanageable is the rate of interest. How long do companies have before technical debt starts accruing interest? The answer is individual to every company, but they need to try and identify how much time they have before it starts to negatively affect operational efficiency, resilience or growth. 

How technical debt is affecting the business now is a good place to start. Assess the whole digital landscape looking for bottlenecks or any parts of the infrastructure that are being otherwise restricted. It won’t always be something that’s causing a major issue, but it will often be something that’s standing in the way of progress. 

Using architecture management tools can help to understand, from a platform/infrastructure level where there might be systems that negatively impact the whole organization. Perhaps they don’t integrate, they don’t handle particular types of data accurately or perhaps they’re simply very slow and/or overloaded by the volume of demand. These are typical signs that technical debt exists and needs to be resolved. 

The Cape of Good Code in Germany used this kind of approach in building the Corona-Warn-App. It was able to analyze the earlier versions of the app to determine how defects might be reflected in the code as well as assessing architecture quality and technical debt.

Similarly at an application and employee level, process mining can help to assess the efficiency and effectiveness of individual systems or processes. Are the desired outcomes being achieved, and in the most efficient way possible?

This will help to identify if certain processes are being overloaded and whether the functionality exists for employees/customers to get what they need. These challenges are another indication of technical debt that needs to be cleared.
Making a digital twin of an organization (DTO) is one way to assess changes in a more thorough way, allowing more informed decisions to be made.

A DTO can be used to plan, test and optimize new process or systems, giving predictions based on a range of real-time and historic data sources. The software-based representation of the organization knows the interdependencies between different assets and uses operational data to deliver its insights. What could be better for understanding the impact of technical debt and helping to prioritise managing it?

A challenge that many organizations will run into – both in creating a DTO and more broadly in day-to-day operations – is getting all of their data into the same place…or at least the right place. A certain level of integration is going to be required in order to achieve many of these management measures. This is always easier said than done and unintegrated, siloed data/processes are the top barrier to clearing technical debt for nearly one third (31%) of organizations. 

Organizations could consider bringing in platforms that help to automate some elements of integration (either the integrations themselves, or API discovery and other management layers). If a sufficient level of integration is not in place, then it must become a high priority. 

But it’s not just a technical challenge. As with all transformation efforts, the culture around technology needs to support these initiatives. And a lack of internal alignment/organizational siloes is another key challenge to clearing technical debt for 27% of organizations.

Managing technical debt where it’s a conscious, strategic choice holds several key challenges…and yet it’s not the hardest to solve. That comes from its more threatening cousin: unintended debt.

Managing unintended debt: anticipating future changes

The world is changing to become more connected and companies are evolving to value technical debt as a tool for operating in this new environment. More than 9 in 10 think it’s important for transformation (94%), growth (93%) and business culture (90%). Looking back on the last 18 months, 86% of businesses say taking on more technical debt was worth it to launch new products and services; 83% said they’re open to technical debt where it allows them to operate more quickly.  

The technical debt that builds up over time can come from things being missed initially (31% say that technical debt is created because they didn’t have the necessary resources at the time of launch). The rest happens simply because things change over time. Systems are layered on other systems, new strategies are put in place and different technologies are stitched together. More organizations (44%) attribute increased technical debt to this growing complexity. 

Managing this kind of technical debt is much trickier. But what if some of it could be avoided? Taking just a little more time in the initial design process to anticipate the future requirements of any given platform or app could help circumvent some of this costlier technical debt. MVPs are naturally focused on the immediate task at hand, and that shouldn’t change. However, balancing considerations of resilience, such as how apps may need to integrate in the future, could avoid unexpected debt. 

3. Key drivers of change

Customer-driven changes

We know that people don’t live their lives in siloes and that their experiences shouldn’t be that way either. That has been, and remains one of the bigger challenges being faced by organizations right now. However, the goalposts are always moving.

We will begin to see customers expect blended experience journeys. Not just one great experience, which already challenges your ability to connect multiple data sources, but a string of connected experiences. Not just a moment in time, but a journey. It could be from your home to your office, connecting your commute, your breakfast stops, payments, your office building and more. Or it could be a literal journey, connecting ticketing, visas, customs and accommodation. Everyone lives a life of blended experience journeys, as technology plays a more integral part in those day-to-day interactions it must be mirror that.

A commitment to open standards is going to be crucial for organizations if they are going to deliver this kind of joined up service. The requirements are increasingly sophisticated and playing catch up will be incredibly challenging. Implementing an open standards approach from the earliest stages of development will make subsequent fixes or integrations much easier to handle. 

In order to deliver some of these connected journeys, organizations will need to team up with others around them. They might link up with partners, or engage in agreements that look a little more like coopetition – where companies that are rivals in one area find other areas in which sharing insights is mutually beneficial. 

Marks & Spencer, the British fashion retailer has embarked on an ecosystem strategy to bolster its business. It has teamed up with food delivery company Ocado to grow its food business, launched a new fashion ecommerce platform to work with partners. It is now planning to launch opticians services in its stores, to connect together even more experiences for its customers. 

Internally-driven changes

More than two thirds of businesses (69%) believe that technical debt means that they can’t continue their digital transformation at the same pace as during 2020. It’s understandable that companies (68%) will need to commit more resources to paying down technical debt in the future, but it’s important to balance this with continuing transformation. 

We’ve already mentioned the double edged sword of more digital transformation creating more technical debt (from MVP launches and growing complexity). Technical expertise is required in order to complete the coding and development needed to clear technical debt. But it’s those same skills that are needed to continue transformation as well as ensure that an MVP is resilient enough to avoid some of the costliest debt. 

One option is creating multiple teams. In 2017, this is the approach taken by LEGO, which realized that managing legacy technology and clearing the technical created by its incremental transformation was too challenging. It established two teams: one to manage the existing infrastructure and the other to work on and launch new initiatives.

Automation is another potential solution. If companies can automate heavily manual processes, then they can free up valuable developer time not only to manage technical debt tasks, but also to continue transformation initiatives. 

Pasta Evangelists – as previously mentioned – used automation of back-office tasks to help focus its limited IT resources on development of its MVP. Additionally, a recent Verizon survey showed that 30% of small businesses in the U.S. have used automation tools to make up for a lack of workers. This was forced by the pandemic, but the use of some of these tools helps to show the benefits of such an approach.

At a business process level, analyze tasks and identify what can and cannot be easily automated. This is an important first step in applying Robotic Process Automation (RPA) to key operational processes. Having some of the management tools that have already been talked about in place will help to ensure that these automated processes continue to operate efficiently.

However, some operational processes don’t take up a lot of time of the developers that can influence digital transformation. So how about automating architectural tasks? 

At an architectural / infrastructure level, it’s possible to help speed up the time-to-completion of many jobs by automating a lot of discovery and integration tasks. For instance, integration platforms that automate API discovery and connection that can take up time for developers.

That thought leads us into the mildly controversial area of low-code and no-code systems. Controversial because there is a division of opinion over the proper application of this kind of technology. They can be tremendously empowering – a Software AG governmental customer has been able to roll out 800 new apps in just a few years with a no-code platform. However, they can also make their own contribution to technical debt if not done correctly. 

Crucially low code or no code applications are beneficial in situations where the task is relatively simple and completely definable. If the owner can be very specific about the process and the outcomes, then it’s possible to have a very functional outcome. However, where any complexity is needed – or the owners want the app to do too much – a gulf can emerge requiring more development.

Goldman Sachs recently announced a high profile – and high value – investment into a low-code platform. This clear intention to bring more automated tools into the organization, to speed up the implementation of new tools shows what the future could look like for this kind of approach.

The issue of how and where to use low or no code platforms is one for businesses to decide for themselves on a case-by-case basis. However, for those that do decide to go down this route, the issue of technical debt should be high in their thinking. As with any automation effort – whether low code development, RPA, AI, IoT or anything else – the open standards that enable it are crucial. 

Automating one process in isolation can be – and often is – done in whatever way the developer thinks best. Because many of these tasks are done with a very focused goal in mind, there are many stages of development that seem unnecessary…so knowingly or not, a lot of these new automated systems will carry a technical debt. The impact of that technical debt may not be apparent for some time, but will be evident at the point at which these automated processes or apps need to work together.

For example, separate RPAs in different departments may one day need to interact, as organizations evolve and become more connected. Apps developed through no-code platforms may need to channel data to one another to create more connected customer experience journeys. This is where technical debt could pop up – and an instance where companies can take out ‘protection’ from the beginning by using open standards and/or thinking of a more connected future and developing accordingly. 

Driven by bigger issues

It’s not just internal transformation though where this effect will be felt. As sustainability goals rise up the corporate agenda, new innovate is the only way to find the big solutions. Whether looking at environmental, social or economic issues, changing the world requires new ways of thinking. 

Technical debt is already slowing down some companies in their digital transformation efforts and it will have the same impact on other innovation challenges if not managed effectively. Finding the time and resource needed to innovate around new challenges will, in part, rely on how technical debt is managed. Whether they decide to split teams, automate, or find another solution, those that are able to balance the needs to re-code and update versus the need to innovate, will keep moving forward.

Finding the right balance is something that companies should think about from an employee perspective too. Retention and recruitment of the top technology talent is something front of mind for most, if not all organizations. Becoming absorbed in solving technical debt may not be the kind of innovative work that some people are looking for. At a time when it’s never been more important to consider the shape of work, how to manage resources around technical debt is definitely a piece of the puzzle.

4. Is technical debt a practical strategy?

The short answer is yes. Looking to 2022, 78% of organizations suggest that fast tracking the launch of new products and/or services will be a top (14%) or high (64%) priority for them. We already know that technical debt is an integral, if not essential, part of this process. 

Creating technical debt is a strategy that companies can use to become more responsive, capitalize on opportunities in the best way possible and continue to evolve their transformation. 

That transformation is also still a top priority. 81% of organizations say that modernizing their existing technologies will be a top (19%) or high (62%) priority for 2022. Similarly, 77% said that exploring new technologies will be the top (17%) or high (60%) priority.

This shows that the balance of accruing and managing technical debt needs to be kept fluid and harmonious. Clearing technical debt will be a top (15%) or high (53%) priority for organizations in 2022. 

An effective strategy for managing it that also takes into account measures to minimize unexpected debt will enable companies to become truly connected, turn their data into value and continue successfully on their path of digital transformation.