Fish out of order

I typically include the following sections in any reference architecture:

​

• Core components: High-level building blocks of the system. Ideally, at this stage each core component should be linked back to a customer goal, for example, a block storage approach that is designed specifically to work well in typical high performance computing environments.

• Relationships and interactions: How components communicate and integrate. This helps customers understand how the solution may be integrated into their overall approach.

• Standards and best practices: Guidelines for implementation, security, and performance. 

• Customisation guidance: How to adapt the architecture to specific use cases. Depending on the solution, this may also be where I provide information on compatibility with popular products from other vendors.

​​

Depending on the exact nature of the product, I may also include a use cases section, though often this is provided to customers via solution briefs or case studies supplementing the reference architecture.

Again, depending on the exact product, I may also include a design considerations section. This explores what a customer may want to prioritise in their solution (e.g. data durability, performance) and how the product achieves these goals. It's similar to the core components section, but is written with sales leads working with key decision makers within a potential client organisation in mind.

​

I generally set up this structure before beginning consultation with subject matter experts, using the document structure to help focus them on filling in the gaps in my own knowledge about a product. Once the main body of the document is completed, I'll add an executive summary,