The Integration Challenge

James Holdren
theFramework
Published in
4 min readDec 16, 2019

Many modern systems contain both in-house written code and integrations with third-party libraries. Using outside code repositories is powerful. It can boost productivity and delivers new features to systems faster. The best part for engineers? All this comes without having to rebuild existing tools and capabilities themselves.

As nice as it is to grab someone else’s code off the shelf, integrating isn’t as straightforward as it should be.

Don’t Reinvent the Wheel

Using outside code can bring a ton of value to development teams. When developers don’t have to understand a library’s internal workings, they can grab something off the shelf and expect it to work without having to learn the code line-by-line.

The profit of using external code diminishes with the cost of learning someone else’s codebase. A developer wouldn’t use a library that sends emails if they had to take time to understand each line of code. With that level of effort, a developer could write their own library. The mental cost of learning someone else’s code often outweighs the value of using the code to do something.

Well-documented third-party codebases help to reduce this cost. Developers can integrate without the need to learn a new codebase.

Communication is Key

Imagine that some behavior of a codebase isn’t documented. Often, this isn’t far from the truth. Developers frequently deal with libraries doing unexpected things at random times. An even bigger challenge arises when third-party libraries update without documenting or announcing breaking changes.

This happened recently at Tangram Flex. We wanted to return error messages from one of our servers, but every time we received one it had changed. We didn’t know that our transport layer, a third-party framework that delivered the errors, was changing the error messages. This behavior wasn’t documented, so we had to dive deep into the transport framework’s code. We delved into code we didn’t write, adding log statements throughout in an attempt to understand the behavior.

At the end of the day we finally found where the behavior was occurring, but it didn’t feel like a victory. Hours spent on debugging led to our tasks for the day rolling over to tomorrow.

What seems like a small lapse in documentation led to a much larger cost. Instead of using the framework, our development team had to learn its internals. We lost the profit from that off-the-shelf convenience and had to own the framework like it was our code to maintain.

The cost of integration challenges compounds at scale.

Imagine an unexpected error in a car or airplane with thousands of moving parts. Each new integration has the potential to introduce unexpected behaviors when its code changes. These challenges increase as the size of applications increase. As systems become more complex, it is even less likely that the integrated codebases will get the changes and updates they need.

Forging into the Unknown: The Tangram Approach

Integration challenges are complex across the board, but especially difficult in large legacy systems. Tangram Flex uses a component-based approach to understand integration points and identify risks. This means identifying each component of a system and its function. For example, a quadcopter is composed as parts like “Radio”, “Camera”, and “Rotor Control”. We then document what each piece does and what sort of data it sends and receives.

Viewing systems this way encourages engineers to think in encapsulation. It requires documenting how each component behaves and what it produces. The integration points are fully identified and understood. This is a huge step towards solving the integration challenge. Components are self-contained and easier to swap.

Some integrations will be difficult no matter what. We aim to bring better understanding to engineers when they include outside components into their system. Marching towards that goal returns time to engineers and ultimately leads to better, safer systems.

Tangram Flex is a software company in Dayton, Ohio. Our team is a group of leaders from the DoD, private industry, and innovative startups committed to helping engineers build configurable systems for secure, rapid delivery of technology to the market. Have questions? Get in touch with our team.

--

--

James Holdren
theFramework

I’m a solution architect at BigNerdRanch, and I’m usually hacking on Go or Rust nowadays.