A Culture of No - A SQL versus NoSQL Case Study in the Coast Guard

I feel an overwhelming obligation to highlight some of my previous statements.

Mostly, it was abundantly apparent the Aviation Logistics Center Infrastructure Services Division (ALC ISD) was minimally staffed, and extremely resource limited. 1

This constrained an entirety of ALC ISD’s ability to maintain and respond to the developing needs of the legacy Information Technology system, Asset Logistics Management Information System (ALMIS). So, when the Data Readiness Task Force (DRTF) attempted to add work and requirements to the ALC ISD staff and ALMIS system (i.e. building a data connection between ALMIS and the Coast Guard’s Integrated Data Environment), it met immediate and substantial resistance. An inertia associated with a large bureaucratic system and the established status quo, effectively rendered the task unattainable.

My “overwhelming obligation” is mostly born of empathy, though also a little out of… guilt! As I think and write, it feels a lot like this post will be interpreted as an attack on ALC ISD. And it is neither that, nor resentment towards ALC ISD.

Rather, I am acutely aware that ALC ISD, like many commands and entities within the Coast Guard, is consumed by their primary task with extremely limited time and personnel to spare for additional tasking.

(With extremely limited spare time and personnel for pet/passion projects, ALC ISD would also have extreme limitations for innovation and advancement. Which means, ALC ISD is likely an entity always trying to keep up. So, there is very likely little fun or enthusiasm for work being generated within ALC ISD intrinsically. Which is why I find I have immense empathy.)

By approaching ALC ISD with additional work, the DRTF joined a growing queue. And because ALC ISD was barely staffed to “keep the lights on” with respect to the ALMIS system, the DRTF (at best) would have to wait for the nearest lapse in workflow to receive ALC ISD/ALMIS support.

Unfortunately, this scenario resulted in ALC ISD putting their foot down based on technical details. And to this day, I do not understand how those technical details prevent a data connection. Perhaps regrettably, as the ALMIS data connection to the Coast Guard’s Integrated Data Environment (IDE) failed to gain traction, the interactions between the DRTF and ALC ISD moved to positions of senior leadership, where technical understanding and background were lost. And a “Culture of ‘No’” overtook what was an otherwise, collaborative relationship.

As collaboration continued, ALC ISD identified the receiving IDE system would leverage a NoSQL format for data storage. And because ALMIS was in a SQL format (PostgreSQL), ALC ISD utilized this conflict as an insurmountable impasse.

I do not understand how the format of data stored within the receiving environment is of any concern to the source system in a data connection relationship. Obviously, ALC ISD’s desire was to be as collaborative as possible and to make a data connection that was as useful as possible to the receiving environment. Thus, they identified a conflict between the environments and pointed it out. However, the Coast Guard’s IDE contract had contractors on stand-by to support receipt and reformatting of the data to enable storage and use within the IDE (NoSQL) database. So ALC ISD/ALMIS was (still) only required to push data through the connection (no reformatting responsibilities from SQL to NoSQL were required from ALC ISD). As a result, it is necessary to gain an understanding between SQL and NoSQL databases.

Structured Query Language

A SQL database is simply a database where you can query through the SQL language. Which means the database is a Relational Database in structure. Simply put, it is a database where data is stored within tables of columns and rows, linked together by unique keys.

A SQL database is vertically scalable. Meaning that querying on the database is accelerated by adding to the environment’s processing power.

The primary benefit of a SQL database is data is stored within a structured format, which provides flexible querying and enables an easier understanding of data integrity and the underlying data itself. A SQL database does handle a medium level of transactions well. However, as the number of transactions on a SQL database rises, the database will lose capability/functionality when compared to a NoSQL database.

“Not Only SQL”

A NoSQL (Not Only SQL) database does not store data in tables with columns and rows. The data is kept in either a semi-structured or unstructured format, and thus is not as easily understandable when compared to SQL formats. Database types for NoSQL include Document-Type, Key-Value, Graph and Wide Column as opposed to SQL’s Relational Database. These formats for a NoSQL database enable the database to be horizontally scalable. Which simply means instead of adding additional processing power to the database environment to assist in transactions, additional instances are stood up to distribute the transactions throughout, effectively sharing any workload.

A metaphor for this cloud computing/networking concept is to imagine a person lifting a heavy weight. In this example as a SQL database, a singular person (the database environment) would need to get bigger or would require additional strength to lift the heavy weight (additional processing power, or vertical scaling). In the same example, but as a NoSQL database, a singular person would employ the help of one or more additional people (instances/additional servers within the database environment, or horizontal scaling) to assist with the lift.

Horizontal scaling makes the NoSQL format highly scalable, returning low latency for data retrieval and handling large amounts of transactions very well.

Resistance

As you may be able to see, ALC ISD’s resistance on the grounds of the database format for the receiving environment does not make a lot of sense. If contractors are on contract to receive and build parsers that will accept data within a SQL format and transform it to a NoSQL format that fits the target environment, then really, why should the sending end of the data connection be concerned? Effectively, they have done nothing except send the data. Which brings me to my belief that at the senior level (without a strong understanding of the technical details), ALC ISD responded emotionally and responded with “no”.

Because ALC ISD was under-resourced and unable to support the request coming from the DRTF, ALC ISD took the first excuse to filter their existing work queue and remove any potential additions to their workload; which meant not helping the DRTF with its data connection. In this situation, ALC ISD believed they were responding empathetically, “Oh, because you have a NoSQL format, our data will not be useful to you. Because we store our data in a SQL format.” The response that the DRTF did not require ALC ISD to alter the format of their data from how it existed, effectively fell on deaf ears due to the stress of their existing workload. Overwhelmed by the support for their primary task, a culture of no had set in to any notion of additional work.


These views are mine and should not be construed as the views of the U.S. Coast Guard.