Building Technology Bridges

A version of this blog article was originally posted on Vertafore Voices, an internal company blog for employees to share perspectives.

Bridges are one of the most basic pieces of infrastructure for any civilization. The Arkadiko Bridge in Greece (pictured) is one of the oldest known stone arch bridges in the world. It was built in the Bronze Age more than 3,000 years ago for use by chariots. The chariots are long gone, but the bridge still stands today.

Not all bridges need to last so long, however. Ancient empires like China, Persia, Greece, and Rome all had engineers to construct temporary floating bridges made of boats to get their armies across rivers and straits. These were torn down after crossing to prevent enemies from using them, and to send a clear message to their own troops: we are only going forward, not back. Floating bridges of this type are still used today, such as the Guangji floating bridge in Chaozhou, China (pictured).

In our fast-paced world of technology, it is often necessary to build temporary spans between the technologies of the present and the future. I call these technology bridges.

Hybrid cars are a good example of what I mean by a technology bridge. They span the present world of fossil fuel powered cars and the future world of electric cars. They provide a way for car manufacturers and drivers to become more familiar with electric vehicle technology, and they’ll be needed until the day when the infrastructure for electric car recharging is as convenient and pervasive as gasoline filling stations are today.

Here is a smaller scale example of a technology bridge that I used in my job as as software development engineer in test (SDET).

My employer recently installed Team Foundation Server (TFS) 2017. This product includes powerful release management tools, but these tools are not yet installed at our company.

Meanwhile, our current release management system, which I helped to design and implement, is based on Jenkins, and integrates with an older version of TFS, making it incompatible with TFS 2017, at least for now. Many of our development teams are still using the older TFS version, so we cannot drop support for it yet.

So how can we release code that was built with TFS 2017? Here is how.

Software code stored in TFS 2017 is built in such a way that it LOOKS LIKE it was built by our Jenkins server. This process allows our current release management system (also using Jenkins) to release the software, even though it was built by TFS 2017, not Jenkins.

The solution is a temporary technology bridge between how we build and release software today (Jenkins) and how we will build and release software tomorrow (TFS 2017).

Technology bridges are useful because they buy time. Just as it takes time to move an army across a river, it can take time to move an organization from one type of technology infrastructure to another. Both processes involve lots of moving parts. Technology bridges allow part of your organization to remain on one side of a technology divide while others have already crossed over. Once everyone has crossed over, you can tear down the temporary bridge. Then everyone can march forward together.