A take on solution architecture design
The purpose of this post is to discuss about a mindset that works when designing a software solution.
I wanted to be as less technical as possible here in order to make it reach more people. In an other post, will write about tips specific to cloud/on-premise architecture and choosing tech/tools/considerations etc.
Below is true.
“The software architecture are those decisions that are hard to change
— Martin Fowler”
Decisions are hard to change so how can I make good decisions?
Dont go by Myths
But in the first place, why and when myths exist?
When things are ambiguous. (approach/pattern/practice). Example, different people say different things about SOA, REST, Microservices, GRpc.
When you read and firmly believe something without doing analysis. (can be a book/approach/post. Mostly happens in the reverse order).
When someone has planted it in you. (co-worker/friend/guru/God/God-man)
How immature must-do-architects think or say ?
“We must hit the glory of Rest at Level 4, Richardson Maturity model” (even when there is no reason)
“GRpc is the future. All our projects from now should use this. Lets migrate.” (Wow)
“We must return 40 different types of status codes from my API in order to adhere to a principle.” (no matter how much pain it is for others who consume it. Principle man.. Principle..)
“We must always use redis for caching.” (God bless you !)
“We must always encrypt data end to end” (even when it is not sensitive at all)
“VM’s are baaad. We should always use containers” (whattt..anything?)
“We must implement repository pattern whenever we write a database layer.”
“We must use protobuf over Json all the time” (new stuff. Google stuff !, performance man…)
“We must not use an existing virtual machine to run something it is not designated for. “ (let it be idle, but we MUST not use it)
“We must not use sql cursors at all. It is a performance hit.”
“Lexical scoping is better than closure always.”
“I have a website link which tells what everyone must follow”
“They followed it in their company and worked for them” (Wowww..)
“Let’s do. It is written in Gartner’s Quadrant and forrester’s research paper”
Get rid of notions like these.
Let me tell you how I look at it.
“A solution design is as unique as the underlying problem itself under the circumstances you deal with.”
Think about the options you get when you are open, willing to try, willing to understand the problem, willing to explore, willing to make meaningful conversations, willing to see how existing systems are built and then arrive at a solution based on a number of parameters that matters to your team and organization.
When practices are widely accepted, embrace it but develop a sense of questioning and reasoning before you follow things blindly.
Don’t just act but think like an architect.
A design is the key in managing change and to support incremental development of a system.
Please make sense out of the above. Read. Repeat.
People mostly tend to think Architecture as something to do mostly about
skeleton solutions, vision, nice diagrams, principles, layers, styles,
patterns, cohesion, coupling, abstraction, re-usability, dependencies, scalability, reliability, availability, Failover, DR, tolerance, CAP.
Believe me. that’s not all. There is something more to it.
In my experience, below are the things that separates great architects from book architects.
“They see the problem the way it is and not in the way they like to”
They know the problem well. Very very well. They spend more time on understanding the problem statements rather than jumping at a solution/conclusion at first place.
They know the choices available in order to solve a problem. They keep their tool bag up to date, as much as possible.
They know the constraints they need to deal with (tools, technologies, ecosystem, dependencies, legacy systems, security, geography, policies, politics, BAD Asses etc. what not)
They know what they have got (Skillset of their teams, tools, budget, existing software licences, people and the experience they bring in)
Work like an architect
They work with developers and other stakeholders closely, understand their concerns and include the outcome in the solution weaving process.
They make smart choices (with acceptable trade off’s) which can handle most of the challenges.
They arrive at a point where they cannot think of changing a single thing out of the proposal without making an expensive trade-off.
They arrive at a point where they cannot think of removing a single thing from the solution design.
They know that top management enjoy having a design warranty.
They monitor the system. They learn from mistakes. They mentor
They never make fun of other’s solutions or legacy. They are matured and know why that kind of solutions exist, what might have gone behind the scenes.
They never think they are the BEST. In fact, they always believe that they are not the BEST at all.
This list is fine but .. here are few other things to know..
How to design a solution for the unknown future?
Design your architectural parts for replacement. Design for change.
The architecture of Amazon, Stackoverflow, youtube and facebook are not the same from last 10 years. Isn’t it?. They have changed for a good reason and they keep changing.
People evolve, tools evolve, problems evolve, solutions evolve and so even your designs should. Are you on an agreement with me?
Do not aim to come up with a future proof solution. Aim to make it future ready !.
Things to remember
Don’t try to make it pure. Make it good.
Do not think of 20 yrs. Think of 5 years.
Have more points of extension.
Review the reference architectures
Get your solution reviewed by many and different kind of people.
Utilize what is available and what comes for free. It could be a one year subscription, 10 GB cloud storage or existing software licences in your organization.
If you end up in confusion while choosing between two identical frameworks, prefer frameworks which are more actively developed and widely used. Think about your team skillset too.
Don’t pay for what you don’t need/use.
Should I always use new tools/frameworks? Is Success guaranteed?
Not really. Whatever you choose today could be outdated in 4 years. Remember, you selected Silverlight, WCF, Light switch, VB Script then what happened?
Success depends not just on the solution design but also on the implementation and a lot more factors which could be technical, social, business, people, governance etc. Will write more about it in another post.
It is absolutely OK and we have choosen wrong things many a times but our point is to design a expandable solution than a perfect solution.