Skip to main content
Blog

Part of the Ship, Part of the Crew

By July 8, 2019December 23rd, 2020No Comments
Ecclesiastes laments that there is nothing new under the sun. In Enterprise IT we see new
technologies trying to solve the same old problems. The new technologies themselves are
rebranded iterations of that which came before. The cost of adopting and implementing new
technologies, even to maintain the status quo, can be daunting. However daunting this cost, it
pales in comparison to the cost of inaction.

 

The systems that make up an Enterprise IT organization are like a ship, complete with its keel,
sails, and rudder. This seafaring vessel is captained by a CTO, crewed by an IT staff, and
occupied by its users who depend on this boat every single day. When the ship launched, it was
shiny and new, a marvel of its time. But the journey has been long, full of unexpected detours,
shoals, and storms. Some sails have torn, wood has rotted, and boards have splintered; all
nautical-technical debt. This decay must be addressed, the ship must sail on, and the captain must
set a course for remediation. Following this course, the ship will see changes beyond just its
location; will it resemble Theseus’ ship or turn into the Flying Dutchman?

 

In the Pirates of the Caribbean movies, rotting, zombie-like men crewed the Flying Dutchman.
The crewmembers’ mantra is “part of the ship, part of the crew,” as their fate involves complete
decomposition until they become a part of the ship. In contrast, the mythical Greek figure,
Theseus, had a very different approach to shipboard maintenance. Albeit well-constructed, from
the moment his vessel hit the water, its components began to decay. Unable to replace the entire
ship while it was underway, Theseus planned to renovate each component of his ship just as it was nearing the end of its lifecycle. When he returned from his journey, the people of Athens remarked on the quality of his new ship. Though flattered by the comments, Theseus knew this was the same vessel upon which he embarked years ago.

 

Thin Client, Fat Client, Thin Client, Thicc Client
Since the earliest days of client-server computing a question has been asked, “Where shall I
place the application code; the client or the server?” A product of limitation rather than choice,
first came the Unix mainframe and dumb terminal… enter the thin client. As the years went by,
the mainframe shrunk and migrated to every desktop. The birth of the Windows Personal
Computer brought power, freedom, and Visual Basic to all… enter the thick client. Weary of
purchasing beige boxes biannually, customers then entered the recentralization race by way of
web application, Citrix, or VDI… thin client again. Before the dust from the race had settled, we
began to hear a new song, sung by a chorus of one million JavaScript frameworks espousing the
glories of the Single Page Application… make the thick client great again?
As the lair of Atlantis’ Leviathan was littered with shipwrecks from every era, I have scarcely
seen an enterprise IT ecosystem without “shipwrecks” of their own. In IT we face a Leviathan of
our own creation, the monolithic system. Initially a marvel of automation and a beacon of user
experience, the monolithic monster grew to a size we never intended. The relationship has
changed; we now serve the monster that used to serve us.

 

SQL Server Web Services (SSWS)
What makes a cloud platform? I think of a service that offers pay-as-you-go compute, storage, networking, developer tools, data analytics, etc. Which cloud platform was the first to offer these services, Amazon Web Services? Truly, before AWS was a twinkle in Jeff Bezos’ eye, there was Microsoft SQL Server, the ultimate development platform.

I’ve spent the last several years of my career helping clients embrace cloud-native solutions for their use-cases. For clients with existing systems, the most arduous migration tends to be that of their databases, especially if they use Microsoft SQL Server. The difficulty lies not in the migration of the database itself, but in migrating the Swiss Army knife of other tools SQL Server offers. For every new toy AWS creates, a trusty SQL Server feature is already in place. You need to send emails with SES? Just use DB Mail! No need for PowerBI/Quicksight when SSRS is around! Why use AWS Glue when SSIS is so easy to use? Is a Lambda function like a stored procedure? Source control? Just deploy the code to the database!

The platforms upon which you build your IT systems are the ports where your ship can drop anchor. We select ports favorable for their supplies, good weather, or convenient location on our route. Maybe we found more even more than we had hoped, made some friends, and decided to stay awhile. But when the winds change or the local economy crashes, will we be ready to weigh anchor, head for calmer seas, and find greener pastures? 

If SQL Server could serve web pages, I’m convinced IIS wouldn’t exist and AWS/Azure would be fringe movements in the industry. It is a powerful addition to an enterprise ecosystem and one hell of an RDBMS, but this power brought reliance and narrowing of vision. Many forgot of the world outside of SQL Server. Years went by, faithful SQL Servers chugging, but when the time came to upgrade, SQL Server started tugging. Customers found their systems tied to various pieces or specific versions of SQL Server. The familiar, safe harbor turned into a rusty old anchor.

Tale of Two Ships

As a captain or crewmember on the ship of enterprise IT, take after Theseus. Don’t be like Davy Jones; derelict in his demonic duties. Enterprise applications tend to become “legacy” they day they are released; many can be used for decades. The longevity of use is to be welcomed as a sign that the application has received much use and generated much revenue. But this application can then become the Leviathan monolith, a ghost ship full of rotting crew, or the rusty anchor. 

Strive to craft a fast ship, not necessarily in motion, but in transformation. Use architectural patterns and planning to ensure that no one component of the enterprise grows too large to move or replace. Keep track of the catalog of systems that make up your enterprise, anticipating those that need replacement. Finally, when a component does reach its time, actually replace it, turn it off, and fully decommission it; don’t leave it around to rot. A component left to rot, long after its due will stay part of your ship, part of your crew.

Corey Masters

Author Corey Masters

More posts by Corey Masters
Close Menu