Don’t settle for maintaining software – sustain and evolve it

Launching a new application or digital product is rarely easy, and should be reason enough to celebrate. But most enterprises quickly realize that when they’ve successfully created a digital asset, the battle has in many ways just begun. 

Constant pressure to innovate, transform and extend their digital capabilities has left organizations with a growing burden of software and technology investment to manage. By some estimates maintaining and updating an application can account for up to 70% of its total cost of ownership – to say nothing of the collective effort required to ensure it continues to engage end-customers, and perform at a high level.

“If you look at the entire lifecycle of any digital asset, the build phase is very short term,” says Nivetha Padmanaban, Head of DAMO™ Managed Services at Thoughtworks. “Assuming an application’s lifespan is ten years, it might take two to build. The remaining eight will be a phase where you not only have to keep it up and running and in good health, but ensure it stays evolvable at any given point in time, since business and customer demands won’t stay still.”

This sets up a tough dynamic where demand for software support and maintenance is continuous, and in most cases constantly expanding, while the resources available are expensive and unlikely to ever hit sufficiency. One study by Stepsize estimates developers spend a third of their time on maintenance and aging systems, with attempts to address the technical debt – the gulf between legacy infrastructure and current business demands – accounting for a big part of that. This has implications not just for the company’s speed and ability to deliver, but also team morale.

Maintenance and tech debt drain developers’ time

Developers spend ~1 day a week dealing with technical debt

Companies often have little choice but to shift innovation efforts from creating new products to shoring up the resilience of their existing operations. Forrester estimates 80% of businesses are making this kind of pivot.

The quest to ‘keep the lights on’ is encouraging firms to explore alternative approaches to software maintenance – not least, enlisting outside help. Research suggests even as many industries confront a downturn, the global application management services market will more than double by 2026, to just under US$60 billion.

“Historically, it’s been much more common for companies to regard software development as a period of intense activity, after which you hand it over to a production support or maintenance team, or you’ve engaged a managed services provider to do that for you,” says Scott Shaw, Head of Technology, Thoughtworks. “And typically, those providers operate through ticketing systems. They fix things that break, get the application back up and running based on certain service levels, without necessarily addressing the root cause of the problem.”

But perceptions are changing. “People have come to see software delivery much differently,” Shaw explains. “Rather than having a project to build it and you’re done, like you would with a physical asset, people understand that software is a living product, and evolves over time.”

In fact, “applications live much longer than people anticipate,” he notes. “When they were first deployed, nobody expected to still be maintaining some of the applications that remain critical to running big companies today. So it makes sense to make enhancements and evolve software in such a way that it's easier to change, that it can stay current with modern technology, that it's still secure, robust and resilient, throughout its lifetime.”

Managed services relationships can be a welcome solution to talent or resource shortfalls. But with the right mindset and partnerships, they can, and should, be much more. The highest levels of service and support can take the enterprise beyond simply maintaining software, to elevating software to the point where tech capabilities expand and the road is cleared for strategic leaps in the business. 

“Companies have limited budgets in the current environment but still want to keep evolving digital products so they can adapt, respond quickly and help business resilience,” says Yang Liu, Principal Consultant, Thoughtworks. “But that means maintenance has to be more than keeping the lights on. You need engineering work to reduce the tech debt, and improve your architecture and software quality.” 

i. Change your mindset, and forget the software ‘m’-word

According to Nivetha, enterprises will often reach out to a managed services provider when software is clearly teetering or on the brink of failure. But by that point, significant damage may have already been done to reputation and revenues.   

“The way companies need to look at support and maintenance has completely changed,” she explains. “Twenty years back it was very reactive; if something broke, you went and fixed it. But technology has evolved, everything has moved to the cloud and availability is taken for granted. You can’t afford to be down even for a few seconds. We’re living in an era where if something fails, it should automatically move onto a different node, or attempt to heal itself.”

These trends mean failures also have higher consequences. Customer tolerance of downtime is waning; one study in the UK found around a third of consumers are prepared to move to a competitor's website in less than 30 seconds if their preferred brand suffers an outage.

“We've seen how neglecting applications and treating software as an asset that you build once, and then letting it sit there over time and accumulate issues has cost the American airline industry,” says Shaw, referring to a series of disruptions in late 2022 and 2023, including a maintenance mistake that paralyzed flights across the US. “That brought it home for a lot of businesses. They’re concerned about this, and looking at how they can not only run an application, but make sure it’s resilient in the face of catastrophic changes or unexpected circumstances.”   

These ‘unexpected circumstances’ include security breaches. Software and system vulnerabilities have more than tripled over the last decade, according to Skybox Security. Given the average cost of a data breach has topped US$4 million, this represents an aggregate risk of billions of dollars that simple patching can’t address. 

Surge in software vulnerabilities leaves enterprises struggling to keep up

Vulnerabilities have more than tripled over the past ten years

Source: Skybox

At the same time, with companies facing economic pressures, it’s not necessarily modernization or security that are top of mind. Rather it may be “how to save money by shrinking investment in IT, or new product development,” Liu says. 

Before going down that road, enterprises “really need to look at the tech debt that might result,” he adds. “If you shrink investment in new features, or software maintenance, you may not immediately see the debt created by adding code that’s not well-tested, or defects are not visible because you haven’t invested in observability. That can lead to serious risks, and incidents that have big consequences, especially in industries like healthcare or finance.” 

According to the Consortium for Information & Software Quality (CISQ), in 2020 alone poor quality software cost US enterprises over US$2 trillion, with operational failures accounting for the bulk of that. Meanwhile the estimated tech debt accumulated by defects that will eventually need to be fixed topped US$1.3 trillion. 

The high price of skimping on software quality

Rather than viewing maintenance as an expense that can be deferred or avoided altogether, financial and strategic goals can be balanced by approaching it differently. 

In essence, “applications need to be run the same way they’re developed,” says Nivetha. “You develop with so much care, so much focus on the quality of the code, right? The same care and the same love should go into the applications even in the production phase. That’s what we see as important, and what’s often missing.”

While ‘zero maintenance’ software is an appealing concept, Nivetha advises companies to temper their ambitions. 

“When everything around you is changing constantly, zero maintenance software is tough to achieve,” she says. “Even if the code base doesn’t go through changes, the way the software is used might, and the tech landscape and frameworks will evolve. Instead of achieving zero maintenance the company should aim for the flexibility to evolve applications.”

Yet it’s still quite rare that flexibility remains a priority post-development. According to Liu, while useful, frameworks like IT service management (ITSM) and information technology infrastructure library (ITIL) sometimes feed the perception that software maintenance has to be highly process-driven. 

“I’m not saying (these frameworks) aren’t good, but they can limit innovation and the business’s imagination in the support stage,” he explains. “We believe people can and should innovate in the process, because this facilitates learning.”

If for example, teams are wedded to a process and encounter a non-standard problem, they may feel like they don’t have room to break protocol to come up with an inventive solution. 

“(Processes) can make people afraid to make mistakes,” Liu says. “And that’s bad when it comes to improving software quality, or to finding the reasons behind defects or incidents. Maintenance shouldn’t be process-focused – it should be people-focused.” 

Without flexibility, inevitably “software becomes so rigid, it’s not at all evolvable,” agrees Nivetha. “A lot of big enterprises are afraid to touch their software even in one small place because they don’t have a safety net, and don’t know what else they might break. And then a couple of years down the line, they have to rewrite the entire thing or throw it away.” 

Enterprises can break this cycle by seeing support and maintenance as a continuation of the development stage. “Look at the run phase or run problem as a development problem – not a support and maintenance problem,” Nivetha advises. “That can be a challenge, because often the business owner is thinking about business problems, while an operations person will be looking at the costs and how to reduce those over time. The priorities are different, but you need to have an intersection between them. This is why we see the need more as a mindset change than a capability or skill difference.” 

The danger of focusing on costs is that “it leads you to trying to cut down in places where you probably shouldn’t be,” she adds. “When it comes to support and maintenance in general, I don’t even like to use those words – use sustain and evolve instead. Keep your tech debt as low as possible, so that it gives you the flexibility to evolve in the future in a way that extends the shelf life of your software.” 

ii. Talent’s role in the self-healing enterprise 

Along with costs being a misplaced priority, the perception of maintenance as a ‘low value’ activity needs to change.  

“There’s a misconception that supporting or running an application is somehow a lower-skilled occupation than software delivery,” says Shaw. “We see running and evolving applications as a continuum that requires the same skills and attention to detail.”

Nivetha agrees, noting clients and their service providers often assume entry-level talent should be delegated to handle support when that’s far from a given. 

“Organizations have to understand that if they developed a good codebase, the support team is going to have to maintain that, and if any issues occur, the team has to fix that codebase as well,” she explains. “So organizations really need to hire developers and engineers for that role.” 

The view that ‘good enough’ support and maintenance services can be obtained cheaply has been perpetuated by service providers that compete mainly on price and promise low upfront fees to win deals, notes Liu. 

Businesses often belatedly realize the true price of these arrangements when something goes wrong or requires support outside the confines of a nominally low-cost contract, as vendors may engage in lock-in practices that allow them to “charge businesses three to five times more than usual for change requests,” he says. 

Sustainably lower maintenance costs can only really be achieved through advanced automation – and that requires the skills and talent of experts. 

“When the costs of our application management services are lower than those of our regular software delivery team, it’s not because we use cheaper labor; it’s because we use engineering methods to increase automation,” Liu says. ”Reducing the amount of human work through a high level of automation not only cuts costs, but also reduces the probability of introducing new defects into software systems through human error.” 

“If you’re repeating any step a second time it means there’s room for you to automate it,” says Nivetha. “That’s the kind of mindset we adopt. But in some cases, organizations try to add more and more people to solve a problem.” 

According to Nivetha and Shaw, business owners tend to focus mainly on whether an application is up and running, and typically lack the technical expertise needed to improve it. That makes it all the more important to ensure the engineers on the ground are consultative, identifying and acting on opportunities to continuously enhance applications so they better serve business goals.  

“In the development phase, you have the clarity, you know what your week is going to look like, when the next upcoming release is – that’s on the mind of every single person on the team,” Nivetha says. “But you don’t have that in a run phase. You don't know whether you're going to have production incidents or whether one incident is all you’re going to work on tomorrow. You really need highly motivated individuals to actively look for areas to automate and optimize even when things aren’t going wrong, because the business owner is not going to come and tell anyone where to do that.” 

Consequently, the ideal support team is not only highly skilled but has an inclination to proactively drive improvements. When a team falls back on reactive approaches, they eventually become consumed by an operations backlog. 

“If you’re focusing mainly on production incidents you’re not fixing the root cause of a problem, only the symptoms,” says Nivetha. 

In creating support teams, breadth rather than depth is key. “When we build a team, we look for people based on their tech skills and their operations experience, but also consider the other things they can do,” Nivetha explains. “We want ‘jacks of all trades’ – some scripting, some language, exposure to cloud deployments, some incident management.”  

Even as the tech industry grapples with consolidation and layoffs, this kind of versatile talent remains in short supply, encouraging businesses to explore offerings like Thoughtworks’ DAMO™ managed services to augment their internal operations.

Focuses and benefits of next-level managed services

DAMO™ Managed Services revolutionizes the way to manage digital assets

For clients who have come to see software delivery as creating a product that's alive and evolving, solutions such as DAMO managed services help extend the close relationship they had with their technology partner during the build stage to the run phase. 

“When we develop software with a customer, we work closely with product owners, try to understand their business goals, and give them rapid feedback,” says Shaw. “When applications move into the run phase, they have to evolve and potentially there are improvements to be made that could lower the cost of ownership over time. Generally, the client wants to work with the same team to make feature enhancements.”

More basic managed services may also not be adequate for organizations where tech is essential or core to the business, Shaw notes. “These have very high technical standards and are constantly enhancing and improving their applications. As they grow, they're looking to hand some of those applications over to a partner to maintain, and want somebody they can trust and that they know will give the applications the same level of attention, care and technical integrity that we give when we're developing applications.” 

On the other end of the spectrum, Liu points out traditional enterprises that have undergone difficult digital transformations but remain short on strong in-house digital expertise may find DAMO managed services complement internal capabilities and bridge critical gaps. 

Even when businesses are striving to rein in spending, Thoughtworks experts note engaging a service provider to share maintenance responsibilities can be a sound investment. 

“In the current economic climate, one of the big priorities for our customers is to preserve their revenue streams and client base while having to do more with less,” Shaw says. “So they’re focusing their in-house talent on a few differentiating applications that are going to have the most impact on customer retention and revenue growth – which leaves them stretched really thin on the rest of their applications. It’s no surprise they're looking to outsource the evolution of those.”

iii. Features of productive partnerships 

Like any relationship, those between organizations and external service providers can face challenges. One common concern is where to draw the line between reliance and developing internal innovation capabilities as a service partner takes on more responsibilities closer to the client’s technology strategy, or core business. But according to Shaw the two sides are not mutually exclusive, or part of a zero-sum game.  

“For example, when a DAMO managed services team took over one of our client’s applications and immediately implemented improvements that dramatically reduced the time it takes from making a change to getting that change into production, the methodology was then adopted back into the organization, and shared with the in-house team,” notes Shaw. “Advances like that are possible only when the partner is in continuous communication with the customer and sharing these opportunities for improvement.”

Frequency and depth of communication is therefore a key factor that businesses should consider when evaluating their service relationships. “You want to know if the team is providing the information you need to be able to determine what you have to do with the application,” Shaw notes. “Are you getting feedback to help you visualize its performance? Are you getting data that tells you how the application is being used and what the customer experience is like? You want reports that help you do a better job of managing and planning the trajectory of your application over the long term.”

This applies even more in times of emergency. “Outages occur even under the best of circumstances,” Shaw notes. “So another challenge is how well the partner keeps you informed. How comfortable do you feel with the skills of the team especially when it's a critical outage, and you're counting the minutes to when the application can be restored?”

Exceptional skills and best practices when it comes to security are another important consideration, and a potential differentiator. 

“It’s a big job to keep track of all the security bulletins that are sent out, all the patches to open-source software that are released, and getting those rolled out quickly; that is sometimes a real problem for organizations,” Shaw notes. “It's helpful for them to be able to hand that over to their partners because that should be part of these teams’ bread and butter – keeping the applications up and running, current, and secure.”

Businesses with global operations in particular will need to weigh a vendor’s ability to meet data residency requirements, and the strength of its data governance policies. This is one of the many arguments for organizations keeping a hands-on approach to their partnerships, regardless of how established or capable the partner may be. 

“Ideally, businesses should maintain a qualified in-house team – one that has strong domain knowledge and an open mandate to adopt new technology – to work with their software partners,” says Liu. “When organizations outsource everything to their vendors and don’t know enough about their digital infrastructure, applications and assets, and everything is controlled and managed by the vendor, they don't have bargaining power over vendor charges for change requests.”  

A good rule of thumb for deciding what to outsource or retain in-house is to focus internal teams on strategically important applications requiring expertise or unique knowledge that exists only within the organization, Shaw says. By contrast, “applications that are critical but don't require quite as much intimate knowledge of how the organization operates are good ones to partner out.” 

In the collaboration process, businesses and their service partners might find themselves working at different paces, and that can create problems. 

“For example, an in-house team adopting an agile approach but working with vendors doing things the traditional way might experience roadblocks,” says Liu.  

By the same token, a conservative business working with a software partner that is constantly bringing novel ideas to the table might be uncomfortable with the pace of innovation. “In such situations, the agile way of working, which we still practice in the run phase, is one key tool we use to quickly show some results, to prove the value of our ideas and help clients decide if they want to proceed further,” Liu says. 

Above all, businesses should partner with a service provider that’s as willing to embark on and invest in the change journey as they are, and which takes a similar view of success – that of the organization, and the organization’s end-clients in turn.  

Attributes of a strategic partner, versus a standard service provider

“(When building DAMO managed services teams) we hire the same way we hire developers ourselves,” notes Nivetha. “We use developers with operations experience in these kinds of projects, not tier-3 support people. That’s how we are able to follow the same engineering practices and keep up the same code quality as when an application was built, even in the run phase. We’re bringing in the same mindset, practices and emphasis on quality.” 

“Unlike traditional enterprises where the software development and maintenance departments are two different entities, we operate as a single team,” agrees Liu.

It’s also important that relationships are structured, with stages where responsibilities are clearly delineated, and others where client and service provider teams come seamlessly together. 

Thoughtworks’ typical end-to-end delivery model for ‘greenfield’ projects moves through three distinct stages, from releasing a minimum viable product (MVP); to active development, where in-house and DAMO managed services teams are working together; to ongoing evolution, where the DAMO managed services team can take over. Nivetha notes ensuring client and DAMO managed services teams work side by side early on makes this transition more seamless. 

For ‘brownfield’ projects, the transition period from the internal team maintaining the application to the point where it is fully taken over by a partner can be trickier. “Developers on the DAMO managed services team will work alongside the client’s developers during the transition to get to know the application so that when it's handed over completely, the DAMO managed services team is up to speed on all they need to know to improve the application over time,” says Shaw. 

Conclusion: From savings to value, and supporting strategic ambitions 

Ultimately along with skills and capabilities, the effectiveness of a client-service provider relationship comes down to trust – and “to build trust, service providers have to keep delivering client value,” Liu says.

That doesn’t simply mean doling out advice on best practices or passively fulfilling the client’s requests. Real value, as Liu puts it, is taking ownership of the digital products under the service provider’s purview, “quickly understanding the current situation and challenges, and working with clients to improve a digital product.”  

Shaw points out that while cost will always remain a primary driver for businesses, when trying to establish the real value of a relationship the focus should be on the total cost of ownership over three to five years. 

“Rather than looking at how much you are charged per ticket, per outage, or per enhancement, you need to consider whether the cost of operating an application is going down over time,” he explains. “Are you improving it so that it can evolve more quickly? Can you evolve the application more efficiently so that the cost of doing those enhancements decreases?” 

“The way that managed services are sold traditionally means businesses are paying for stuff they don't actually get,” he adds. “They may be paying for a certain number of outages or support tickets that get filed. Instead they should be paying for outcomes. Not just keeping the application up and running but making sure it evolves and improves, as ultimately they get more for their money that way.” 

Nivetha agrees that real value tends to accrue in relationships as time progresses. 

In the standard development process, “stage two is where the application is going through continuous development, and you're adding more features and users,” she says. “At that time you shouldn’t be focusing on how to reduce costs, but on how to add value. Once it moves to stage three, DAMO managed services teams focus more on automation, getting feedback from real users, understanding the patterns and seeing if there’s anything we can do to run it more efficiently.” 

Efforts to enhance stability, accelerate time to delivery and lowering the total cost of ownership can ultimately culminate in strategic advances, as they will often help clients understand the actual state of their systems, highlighting potential risks as well as areas and skills that can be targeted for improvement. 

“At least in a few cases, where we started with an assessment, we looked at the code base, all the incidents, and identified areas where we can improve and automate, as well as security vulnerabilities and test automation areas where the quality gates were a little poor,” Nivetha notes. “We’ve also implemented dashboards which give total visibility over key metrics like mean time to resolve (and) number of deployments.” 

“Even when managing ‘brownfield’ work, where DAMO managed services teams take over applications evolved over time by different vendors, they strive to improve them so they can run for a longer period, and increase the value of the application over time,” she adds. “That’s how we integrate and complement each other, and still add value for the client at the end of the day.”