This is the first part of the series “Become a Software Architect”
Software Architect is a way of thinking. Every developer should look at the bigger picture and develop architectural thinking. To understand what it means, let us get into the mindset of a Software Architect. They find the answer to the question, “When and how is the software delivered ?”
A Software Architect is a person who can wear Red, Blue, and Green hats.
1. Define the Problem from an Engineering Perspective
While solving a problem using software, the solution space is vast; all the input, output, time, and space possibilities need to be considered.
A problem is like an un-rideable horse, so first, we need to control it to enclose it in a limited boundary.
2. Partition the System and Assign Responsibilities (Strategically)
Architects partition (a fancy word for divide into pieces) the software system so they can develop a strategy for achieving quality attributes and other system requirements. Architects control the complexity of the system by turning it into simplicity. Breaking down the complex system into simple parts is an art that comes from experience. Then the relatively less complex stuff can be thought out into the execution.
For Example, Someone can write Database layer and Backend APIs, and someone can write middleware APIs, someone can write UI, someone can write external APIs and, someone can work on validations.
3. Keep an Eye on the Bigger Picture
Software design is a constant struggle to find the right balance between the things you want and the reality you must accept. This means you must think about and make trade-offs.
Every software needs to be thought out within its specific context. Context is formed by people and things affected by or from that software. Therefore, one attribute that is important for one software might not be necessary for another software. For example, the context for banking software will differ from that for security software.
4. Decide Trade-offs among Quality Attributes
It is common in software development to give up something you want to get something you need. Architects identify the trade-offs and work with stakeholders to decide which compromises make the most sense.
For example, The software needs to handle millions of requests. To achieve this, we might need to employ multiple servers across the globe. Here, we are trading off the cost to achieve scalability.
5. Manage Technical Debt
Technical debt is the gap between your software system’s current design and the design you need it to have so you can continue to deliver value. Sometimes ( probably most of the time) As Software Architects, we might choose an easier solution instead of a better one, which might take longer. This might require rework to be done later on. Over time, this cost of rework ( technical debt) grows.
This is Architect’s job to make this visible and help stakeholders decide which actions to take to manage it.
Over the period, developing features on top of the existing software should refrain from hammering the value delivered by the software.
6. Grow the Team’s Architecture Skills
As the architecture expert on your team, it is your responsibility to share your knowledge with your team so they can successfully develop an amazing software system. The more people share architectural thinking, the better the software gets.
The most important thing you can do to grow the team’s architecture skills is to include them in the design process.
JB's Blog 