You are here

Stop making spaghetti: Removing custom code will ease heartburn

public://pictures/James Donelan.png
James Donelan, VP Engineering, MuleSoft

Custom code for integration is a big business, accounting for an estimated $220 billion of IT spend. If done right, it’s a great investment, but if done wrong, it’s a costly endeavor. Roy Fielding, the creator of REST, hit the nail on the head when he stated:

“Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release.”

Although he was speaking specifically about API design at the time, his words still hold true for general integration code.

In other words, what starts out as a simple integration quickly expands into a series of hacks and one-offs, accompanied by growing endpoints and increasingly more complex data transformation and integration logic. The problem, then, becomes the massive investment in developers, time, and money that’s needed to maintain these custom code solutions. 

The good news is it doesn’t have to be this way. By acknowledging up front that system integrations will need to change frequently and that new technologies will need to be quickly adopted, business leaders can put a connectivity layer powered by APIs in place that turns custom code’s potential liability into a competitive advantage.

[ Get up to speed on quality-driven development with TechBeacon's new guide. Plus: Download the World Quality Report 2019-20 for lessons from leading organizations. ]

Why custom code doesn't fly

There are plenty of examples out there. One of my favorites is a system developed for the U.S. Air Force that was estimated to cost $88.5 million to develop. Dubbed the Expeditionary Combat Support System (ECSS), the project racked up $1.03 billion in costs in seven short years and did not yield “significant military capability,” according to an Air Force spokesperson. The ECSS was supposed to integrate and replace more than 200 legacy systems but was eventually disbanded after the team realized they were creating an overwhelming amount of additional custom coding and integration work.

While the U.S. Air Force’s development team had the option of calling it quits, it’s not always that easy in reality. These types of systems usually evolve over decades, and the short cuts taken, one after another, build on top of each other to create one big spaghetti code mess. The short cuts that stick around end up becoming a huge liability to a business. The features and functionality behind them take longer and longer to change as developers spend an inordinate amount of time just trying to figure out how things work. Pivots in strategy, changes in business direction, or new products and technologies simply can’t be adopted in an efficient way. The technology team eventually starts to move at a slower pace to the business, hindering digital transformation.

[ Get up to speed with TechBeacon's Guide to Software Test Automation. Plus: Get the Buyer’s Guide for Selecting Software Test Automation Tools ]

Connectivity is king

The main goal of a connectivity layer is to flexibly connect all points in a business with APIs, especially in a way that allows a business to easily change how these points interact and communicate with each other. This includes connecting legacy systems, applications, data, and devices that are hosted both on-premises and in the cloud. For instance, if a business integrates to a third-party billing system but decides to switch systems halfway through the year, developers are able to easily swap the systems out without needing to rewrite code.

Home entertainment pioneer TiVo is a great success story. Using custom Java code at first, the company heavily depended on point-to-point architecture to connect more than 40 web services to its own systems and its partners, including DirectTV, Virgin Media, and HP. TiVo’s development team quickly found that every new service required an exorbitant amount of development effort, since any change to the system would trigger changes that cascaded throughout the app. The team quickly found itself bogged down by the tremendous maintenance burden of its spaghetti architecture, creating not just an IT problem but a business problem.

As its growth continued to accelerate with new partnerships and web services, TiVo switched to a new architecture and integration model that utilized a connectivity layer. This helped get new partners up and running faster, reduce development costs, and ease the maintenance burden over time. With this connectivity layer, TiVo cut development time for new services by up to 75 percent in many cases. An integration project that might have taken four weeks to develop with point-to-point integration now only took one week.

Cut back on the carbs, buddy

A connectivity layer offers businesses a competitive advantage in that they can easily kick off new projects or swap in and out of different types of systems as needed. In turn, development teams accrue major cost savings, as developers can refocus about two-thirds of their time from doing integration work to building better products and services.

At the end of the day, businesses shouldn’t waste valuable developer hours on grunt work that’s difficult to maintain and often someone else’s mess to untangle. The real crème de la crème for developers lies in building innovative products and services that bring overall value to a business and occasionally transform an industry. So stop making spaghetti, and start creating magic.

[ Learn how to apply DevOps principles to succeed with your SAP modernization in TechBeacon's new guide. Plus: Get the SAP HANA migration white paper. ]