Architecture Thoughts about Fancy Schemas

Today, I’m considering doing some Software Development projects from scratch. From where to start? The very first thing which needs to be done: is to convince management to add your extremely profitable project to their enormous, but surprisingly unreachable, budget.

I’m always going with schemas. Initial schemas, describing basics. Post-factum schemas describing the existing effort. Doesn’t matter. Usually, I go with one of the following five types.

• Business. Colourful and Simple. Yeah, I know, maybe a little kiddish. But you literally should think about the time of people who are going to read this.
• Technical Generic. Just a schema. Terminology involved.
• Technical and Business. Colourful, but slightly more technical to understand the implementation details.
• Technical Domain: AWS. They should be understandable for AWS Architects from the first sight. So, in general, look to the AWS Architecting framework. They have specialized icons for every purpose. But the most important part is don’t forget about the non-domain people, schemas should be still readable but the «common folk».
• Technical Domain: Project Management. Normally, I’m just using Jira workflow to represent the project idea.

Okay, enough talking. Let’s do the project. Something with the microservice architecture. Let’s say it’s some cloud-based file synchronization services, like Dropbox, Google Drive, or OneDrive. I’m using yEd and Draw.io.

Business

Technical Generic

Technical and Business

Technical Domain: AWS

Technical Domain: Project Management