Preventing Integrations from Becoming Technical Debt

Poorly implemented integrations can quickly become costly technical debt – or integration debt – if left unaddressed. 

It’s especially problematic as organization’s often implement integrations to tackle integration debt. 

That’s because well-implemented integrations help simplify complex enterprise architectures and introduce greater automation, freeing development resources from the burden of time-consuming manual intervention and maintenance. 

It’s hard to imagine that Ward Cunningham, the father of the Agile method, created the concept of technical debt only 10 years ago. Today, if you work in development or IT operations, you feel this concept acutely through every system you support and integrate. And Agile or not, technical debt inevitably costs an organization in both revenue and time. 

When your integrations are a source of technical debt, critical systems can be affected and even taken offline. 

The Problem with Technical Debt

Technical debt describes the cost you’ll have to pay to make a solution work over time. That could be the time your developers spend fixing an implementation. It could also be the time lost, the risk introduced, or the impact on employee morale in a break/fix environment. 

The pandemic has further complicated organization’s enterprise architectures and introduced more scope for technical debt. Organizations are introducing more technologies to enable remote collaboration and other digital transformation efforts to support and connect workers. 

For critical enterprise applications, technical debt is a huge problem. A recent study from Stripe, found that ‘bad code’ – just one example of technical debt – costs companies $85 billion annually, and integration architecture is a large part of that problem. 

But technical debt doesn’t just impact the organization as a whole – it impacts the individual too. 76% of respondents to Stripe’s Study said paying down technical debt has a negative impact on personal morale. 

With turnover among developers high, this is a situation organizations should be keen to avoid. This dynamic can create a negative feedback loop, increasing the amount of technical debt, and exacerbating existing issues. 

Think about it: if frustrations regarding technical debt force developers to leave the business before documenting their code and processes, organizations lose best practices and efficiencies. 

Custom –integrations are particularly at risk to this type of technical debt; The integration processes and code are often only wholly understood by the developer(s) responsible for its implementation and maintenance. 

Technical debt also leads to reduced hours for innovation and a detrimental effect on overall business performance. The Stripe study found that developers spend considerable time on maintenance issues, with on average, 33% of engineering time is spent dealing with technical debt. 

Integration Debt: When Integrations Become Technical Debt

Integration debt happens when a new project inevitably needs integrating with the rest of the business’s IT ecosystem. 

Often, businesses consider integration after the project scoping decision instead of by default during the selection process. Therefore, it’s more likely the business will see integration debt after-the-fact. And while technical debt creeps in one change at a time, integration debt tends to come in large leaps.

Organizations need to review the integrations they support that don’t contribute to larger business objectives. Based on our research, integration debt has profound impact to IT operations:

• 40% said that building custom integration technology hinders developer productivity
• 22% of developers said API-based services impact the company. That’s in contrast with 15% of C suite employees who said the same thing. 

We must remember that when we onboard SaaS solution, we are almost always taking on integration debt. Even if an employee onboards and application by simply swiping their credit card, as that application becomes more critical to the organization, it will eventually need integration into larger, more mission critical systems. 

• 10 Reasons to Implement Integration and ITSM Simultaneously

Integration Debt Consumes Considerable Resources

When internal resources – your employees – spend a lot of their time maintaining the integrations between your largest business applications, it moves key employees away from more proactive tasks. 

As the integrations age and need patching/support, the organization is left fighting their own technical debt. They then spend considerable time making integrations meet the business rules instead of capitalizing on the extra time and efficiency the integration intends to provide. 

Employee Turnover and Integration Debt

To prevent integrations from turning into integration debt when an employee moves on, you must document the integration’s processes and tools. But even this approach isn’t foolproof. The documentation is unlikely to reflect the nuances of the project, and there will always be details that fall through the gaps.

You also limit the organization’s capacity to backfill the open developer role. Even if you carefully document knowledge required to facilitate the integration, any new hires must have the skill in-line with integration, which can be difficult to find. 

ServiceNow Integration Debt

As one of the leading ITSM tools on the market, ServiceNow is a critical business function for many organizations, and a common integration target.

When integrations for ServiceNow are built in-house, API errors are more likely to occur. There is greater pressure to rush the implementation – to get it done, get it fixed, get it working; and API errors lead to broken integrations that result in whole host of problems for the target database(s). 

ServiceNow pushing updates to its core application can also break custom integrations and cause API errors. In this case, the custom code that facilitates integration often needs to be rewritten and can be difficult to maintain consistency. 

What we learned:

• Integration debt is a subset of technical debt often overlooked in the scoping project
• SaaS implementations often cause integration debt
• When employees responsible for the integration leave, the integration is at increased risk of becoming technical/integration debt
• When integrating ServiceNow, custom-built integrations can cause issues ranging from poor data quality, to a lack of continuity

It’s true that integration complexity and technical debt are only increasing due to the proliferation of more SaaS and on-prem applications. 

IT Operations professionals are faced with mounting pressure over integration decisions with the accelerated pace of digital transformation necessary to succeed in today’s rapidly changing environment. 

With the average enterprise subscribing to over 600 SaaS apps, traditional integration approaches such as point-to-point custom integrations and general purpose iPaaS are no longer fast enough. 

To accelerate time-to-value, reduce cost, and deliver integrations at scale, we recommend custom-built, expertly supported ServiceNow integration solutions. 

Want to learn more? See how Perspectium DataSync offers the best alternative.