System’s Design — Getting Started
Often we do a System’s Design as an Abstract art. As an Artist, a natural instinct is to depict a visual reality or convey a message or portray a situation, but why not do it with some fun ? And Voila!, Abstract art.
A lot of times System Architects and Technical leads do the system design as a piece of “Abstract Art”. Yes, it has some details, lots of colors, shapes and forms. Just as an observer of an “Abstract Art”, everyone is free to their interpretation of the “Art”, sometimes this has become the point in case of “System’s Design”. When we do a System’s Design and document it, there has to be only one interpretation, because, “System’s Design” is not equals to “Abstract Art”. The System’s Design should provide more answers than questions to its reader. System’s Design cannot be “my interpretation” of the problem. The design cannot be “Please implement this, the way you see fit”. The design should clearly call out it’s merit and demerits as well.
In this first article of mine, I want to kick-start your journey for “System’s Design” with my learnings and best practices. Of course, as in case of “Art”, everyone has their way of representing the “Observation”, this is just my take on “How to System’s Design ?”.
Getting Started : “Let’s start at the very beginning. A very good place to start.”
A very good place to start is the problem statement itself. As in case of Artist, who looks deep into the subject before getting on with canvas, A System’s Architect has to spend enough time on the “Problem Statement”. This can/should be an iterative process. Until problem is well understood by the Architect and agreed by stakeholders, it doesn't make sense to go to next steps.
Tips:
#1 Be Patient. Ensure the entire team is on-board on the problem statement.
Document it well and get it reviewed and approved by all Stakeholders.
#2 Always ask, “How would this benefit the customer ?”, “How would this benefit the Organization ?”, “Is this my priority #1 ?”
Once you have the problem statement as mentioned, get it reviewed.
Stake Holders: “Can I bring my friends to the party?” “Of course, the more the merrier!”:
While more the merrier is true, “too many cooks” spoil a dish as well is true. So what is the sweat spot in choosing the number of reviewers ?
Always draw a matrix of stakeholders who would be impacted. Make a bucket.
#1 — Early impact.
Identify the folks who would be immediately impacted. Example a “Product Manager”, “Product Owner”, “Engineering Owners”, “Module Leads”. They are a must reviewers. Ensure they actively participate in the discussion. Preferably get into a meeting room and agree on this.
#2 — Passive Impact
These are the cross functional team. Like a “Services Team”, or other “Adopters” of this design. These are passive approvers. Send them out the design. Ask them to read at their leisure and socialize in their groups.
As the design closes to approval -> Implement, onboard these folks.
Tips:
#1 Leverage Collaboration tools like Confluence, Sharepoints, Jira’s.
If it’s a live document, go for Confluence, example a “Design Document”.
If its a place to store approved documents, go for Sharepoint or OneDrive. Example Product Requirements Document or Minimally Viable Product.
#2 Once you get the discussion, never leave your audience/participants out cold. Ensure the discussions and decisions happen quickly over an agreed period of time. More time this goes, more disengaged the team gets to.
Bermuda Triangle — “Technical Debts”
The Bermuda Triangle, also known as the Devil’s Triangle, is a loosely defined region in the western part of the North Atlantic Ocean where a number of aircraft and ships are said to have disappeared under mysterious circumstances.
A bad design ends up creating more “Technical Debts” which is ultimately a “Bermuda Triangle”. More the Technical Debts, less efficient is your design, and as case in example of these aircraft and ships, You and the product are bound to disappear. At least in this case it is not a “mystery”. :)
#1 Problem Statement — One of the reason why we end with Technical Debt is the Problem Statement was not broken down well enough. Which means as a System Architect, we did not cover the entire impact areas and design. So introspect on “Getting Started”.
#2 Stake Holders — As mentioned above, know your Stake Holders and involve them from Day 1. Another reason why we end with a Technical Debt is because of an oversight. Someone who needed to part of the “Early impact” list were not. So we never took their input and put together a flawed designed. Few months later when the stakeholder who originally was part of “Passive Impact” folks get involved, red flags the flaws and you have a Technical Debt. Revisit your Stake Holder list.
Disclaimer: I claim no ownership rights to the images posted here. The origin of the images are hyperlinked to the subtext of those images.
The Content presented is personal opinion of myself(Author). The text presented here are my(author) original thoughts and view points. This meant to give general idea on “How to get started” and not an exhaustive guide on “System’s Design”.
