Gazinta's and Gazouta's

A long time ago I was working on a simulated environment for a hardware mission computer on a 1553 bus and my boss told me to make sure and match the gazintas and gazoutas. As a freshly graduated Mechanical and Aerospace engineer who found himself doing hardware-in-the-loop work with computers I was somewhat confused. He told me that they were the things (data/information) that goes in to (gazinta) or goes out of (gazouta) each device on the bus. That made sense. And for information to flow on a 1553 bus everything had to be defined up front. We had a data dictionary we had to implement and we had to get it right because we had to talk to real hardware that already existed. And that was a challenge, because our simulation didn't necessarily work the way the real world did.

On the other hand, it was also liberating. As long as we met that requirement we were free to do whatever we wanted. It let us innovate on our side of the line and not worry too much about how it would work.

But that data dictionary also had a bunch of other good points. It defined not just the data that flowed between the subsystems, but it described the overall system. It let us understand not just what we were doing, but the bigger picture as well. It let us see how a change to one system would impact (or not) other systems. It let us reason about the architecture of the system.

Now data dictionaries (ICDs, thrift files, protobuf files, db Schemas) are critical, but they are very detailed and focused, and while it's possible to get the big picture from them, it's challenging to say the least. And when you're describing your system to someone all the details in the world don't matter without context to put it in. And that's where your software architecture diagram comes in. It's the boxes on the whiteboard diagram. The one with boxes for processes and durable stores and buffers, but no mention of the technology inside them. There are lots of ways to make them. UML, Visio. Rational. No matter how you make them, the goal is to understand the bounded context(s) of your system and how they fit together.

So whether you're writing UML, Thrift, gRPC, AXL graphs, or using LucidChart to describe the relationship between various doggos, the better you can document your architecture and data flow, the better you can work with others and be on the same page.