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 documents, 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 from 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 ancient data and current conditions reported, I am able to model the expected outcome of stress, corrosion, stability, etc. to then assess and manage the 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 stress 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 these 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 and predict when the deck will fail due to stress. Different locations on the ship and material have been shown to exhibit varying degrees of stress or deterioration. Based on this information, I can appropriately 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 researching 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 have assessed the risk of failure or casualty, if a more complex or larger tasks is labeled as "critical", it can be deemed a priority and is thus 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 higher costs and additional fees. Only tasks deemed critical are added as growth work, and I must use my best engineering judgement to determine what is necessary and urgent using my models as support.

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

Effective Communication and Cross-functional Teams

As an 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. A drydock is literally a dry dock. The ship is lifted out of the water onto a platform.

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 28 hours feel a wee bit like an 8 hour shift). 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. Naval ships cost hundreds of millions of dollars to build so I try my hardest to not break them! 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!

Even though I enjoy what I currently do, I would love the opportunity to transition in a role in Solution Architecture and am confident that the skills (or powers) that I've harnessed will come in handy in a Solution Architect or similar role!