Apples to Oranges or Oranges to Nectarines? (Aspiring Solution Architect)

Comparing Solution and Naval Architecture

For the past four years of my professional career, I have worked as a Naval Architect. Most people have no idea what naval architecture is and contrary to what the name may imply, I do not do any sketching or drawing at all. Surprisingly, Solution Architects and Naval Architects have more in common than just their job titles. We have similar job duties! We just work in different industries.

Simply put, I design technical solutions for naval ships. These solutions are based on data that I use to calculate/model the expected behavior of ships and their structure using stress analysis and buoyancy theories, technical requirements and specifications, and data provided to me by the "customer". I review customer provided designs, proposals, and any other submitted documented, create a model, and then either provide or approve a solution to a given problem.

Note: we call projects "work items" or "availabilities" so you can use this interchangeably when reading here on.

Data Analysis & Designing Technical Solutions

Much of the data used in these models are as old as the Navy itself. Long ago, naval architects conducted and recorded various experiments on the behavior of naval ships due to various stresses such as wind, flooding of tanks, earthquakes and hurricanes, and explosions. Using this data in conjunction with current readings and values reported, I am able to model the expected outcome of stress, corrosion, stability, etc. to then assess and manage risk of structural failure or casualty. Here are two examples:

1. Of these experiments, there were "inclining experiments" to model the behavior of buoyancy or stability due to loads aboard the ship. Long story short, heavy weights were moved to various locations and the buoyancy was observed, recorded, and eventually turned into charts and respective formulas. Naval architects in my office less than a decade ago had to endure the long grueling process of reading through these many many many charts and making additional tables and charts to then model the expected behavior of buoyancy due to the removal and addition of weights, all by hand. Instead now, all of these charts and data have been uploaded into a lovely interactive database (even though I have had to do the calculations by hand as almost a rite of passage). I now simply input the new data of columns and rows and out comes our new stability model complete with a couple visuals. Then I am able to either approve the requested solution or present an appropriate alternative.

2. Let's say there is a hole on a deck that needs to be repaired but based on the work items already scheduled, there is no time to complete the repair. Taking such data as the size and location of the hole and material type and thickness, I can estimate the corrosion and failure rate through a model when the deck will fail due to stress. For example different locations on the ship and material have been shown to exhibit varying degrees of stress or deterioration. Then based on this model, I will recommend the best method of repair and its required completion date.

There are many other components that I manage that all have their own tech manuals and formulas. There is never a dull day in the office, fortunately!

Project Estimation and Risk Analysis

While learning about Solution Architecture, I came across a project estimation technique/concept that seems similar to a method that I use in my current role: T-shirt sizing. In my current position, we have scheduled future projects called availabilities with pre-assigned tasks outlined in a "work item". There are smaller or larger tasks that are assigned to shorter or longer scheduled availabilities respectively in order to remain on or close to schedule. Shorter availabilities are much more frequent and longer availabilities can be spaced out by years.

However, once I create and assess the risk of a failure or casualty, if a more complex or larger tasks is labeled as "critical", it can be deemed priority and is reassigned to shorter or sooner availabilities regardless and tasks assessed as "low" can be reassigned to longer availabilities.

Contractors are also prepaid for work before an availability starts and any additional tasks or "growth work" added have additional and higher costs. Only tasks deemed critical are added as growth work.

I am of course not an expert on T-shirt sizing but it seems similar to this method.

Cross-domain Communication

As a SME, I am in constant communication with various people in many different positions and areas of expertise. Once we have created a model, assessed the problem, designed a solution, the last step is to communicate this solution to the rest of the project team.

For a docking evolution (which is the start or end of an availability), there are divers, dock masters, enlisted and commissioned sailors, rope handlers, crane operators, etc. that are all working on getting the ship into or out of drydock. It may seem simple but it takes days of prep and getting the ship into the drydock and completing an evolution can take almost 28 straight hours (thankfully there is overtime which makes it a wee bit more manageable). During this time, we have to be in constant communication with all personnel to track, record, and report every stage of this process as we are the official government oversight and lead POC and are also expected to find a solution to any and every problem that may arise whether it be who to call or what technical manual to read. Below is what a docking evolution looks like.

For structural repairs or alterations, we often perform onsite inspections and meet with different personnel and project managers to get the complete picture of the issue before recommending a solution. Having strong communication skills in order to understand the task at hand and effectively communicate all requirements and solutions is definitely a must and is a great strength of mine!