Cloud Architecture Diagram Development
There is more to Architecture than creating pictures. You need to understand the goals of the system, the components and how every thing fits together. However, The best place to start is a great architectural diagram. We use diagrams to visualize a database design (ERD). We use them to understand a class (UML use-case). The cloud is coming along and now we have tools like this great one from cloudcraft.co. There are others and I’ll put together a Top 5 Tools later this summer.
The following post is a quick Top 5 best practices for Cloud Architecture Diagraming (Along with a few screen shots from cloudcraft.co). Enjoy!
Top 5 Best Practices for Cloud Architecture [Diagrams]
1) Just Start Drawing… [ white board, paper, tablet – preferably not a napkin ]
It’s easy to get hung up and talk yourself out of (or be talked out of) using specific components or features. When your not sure where -or- what something is … just put an empty box (or circle or triangle) there and move on. The point, Keep drawing and try to get a great system overview. Know that you can drill-up or drill-down specific parts and pieces.
2) Choose Broad Overview – OVER- Minutia (caveat see #5).
Try to show the “Over-All” system end to end. There are lots of places in the Diagram where you will be temped to annotate code and edge-case handling. Don’t. These tools are not full CASE Tools, yet. They are feature rich and include things like “Infinite Grid” and “Live Connect”. Instead, Use your Kanban tools and Issues system for capturing your Minutia.
3) Remember your Audience.
Overcome the temptation to make the Diagram overly technical. Remember, There are non-technical stake-holders that put in the extra time to understand our “Tech Jargon”. Balance it out, Spend extra time to Annotate “Why” a component needs to be implemented and “How” it will enable the Enterprise.
4) “Tell the Story”, The Diagram is combined with your system knowledge to tell the story.
Example: You can see the Redshift EDW, Analytics App and Aggregate Pipeline in this Diagram. Use those annotations to explain how things are connected together. What the user can expect in the EDW – Enterprise Data Warehouse. How the Analytics App will “Automatically Handle” features like anomaly detection and root cause analytics. How the App can scale in the AZ… How Kinesis enables streaming … etc. And Remember, Non-Technical stakeholder probably won’t know an M4 from a ELB – and that’s great. Just make sure they know more about what the High-Level components “do” – rather than what they Are.
5) Ultimately, Your Diagram will Include Everything (especially live connected tools).
When your done (lol, you’ll always be tweaking something). Your Diagram should include every major component in the system including the ones that Auto-Scale and/or Up-Cluster : Down-Cluster. This is where features like “Infinite Grid” and “Live Connect” become very important as they dynamically allow you to add component to the system and display them in Real-Time.
These are best practices for Diagrams that I’ve developed over the last several years – use them more as guidelines more than hard-fast rules. I always tell folks to “use what works best for you”. I have to say, ” I can’t imagine building any world-class system without System Architecture Diagrams”. Its a great tool that enables all stake-holders to find Unity on system design and truly understand why something takes longer than another thing and/or cost this or that.. Have Fun!
If you have questions about your IOT, EDW, AWS or Analytics project, Please Email Us – We’ll will respond ASAP.
Thank you, – Gus Segura
Please Contact US or Subscribe to our Blog if you found this interesting or would like more information.