Revisit existing Flexo architecture documentation

[lewismc]

We are interested in restructuring the Flexo architecture so that it reads like an intuitive guide. An example of that is the Cassandra architecture documentation.

Cassandra architecture is broken down into the following

• Overview: abstract in nature, specifies the reason Cassandra was developed in the first place. Justifies it's existence.
• Dynamo: what architectural design principles (from 3rd party existing systems) motivated Cassandra's own architecture. Details "first class citizen" concepts/objects which provides the system functionality or are used within the system.
• Storage Engine: explains how storage is actually implemented in the database. For a relational database equivalent we would be talking about tables and their characteristics e.g. LOGGED/UNLOGGED and any other optimizations which can be applied to different use cases.
• Guarantees: references foundational computer science Consistency, Availability & Partitioning Tolerances (CAP) theory to easily communicate where Cassandra fits in and what it can be used for.

AWS's DynamoDB documentation provides another excellent example of straightforward, intuitive information which someone can engage with and educate themselves with before attempting to use the product. We need to do the same for OpenMBEE/Flexo.

We can use these as motivation for identifying what is missing from our architectural documentation.

The desired outcome from this task is for us to outline a structure for our architectural documentation and then create separate tickets which will deliver the documentation for each of those areas.

[lewismc]

@vaishnaviyathirajam and I determined that we don't really have the know-how to overhaul this documentation right now. We propose that we organize a working documentation session where we can collaborate on language.