A perfect software architecture — an oxymoron?
Software architecture refers to making a set of strategic technical decisions related to a software product, documenting them and ensuring their implementation”
Strategic decisions are those decisions who:
- affect more people
- for a longer period of time
- are difficult to change
The above clarifies the reason why it is difficult to change the language or framework further down the line. Such changes have an impact on all the above points, i.e. the change:
- Affects the entire team
- Takes longer to complete
- Difficult to change
And that is why it is recommended to have lesser “difficult to change” elements. Instead, have more flexible elements while developing software. Modularisation and right abstractions help one to achieve the same.
The questions we usually hear about architecture are:
- What is a good architecture for X?
- Should I switch to Functional Programming languages?
- Should I use NoSQL or RDBMS?
- Should I use Kubernetes or Docker?
I wish the above questions could have been answered easily. If it were, all the software products we develop would have architected in the best way.
I was attending a session by James Lewis— Betting On Evolutionary Architecture: A Note on Software Architecture as Code — during Agile India ’18. The word that caught my attention was “betting”. Can you bet on architecture?
The high-level summary of the talk is, the architectural decisions are bets that we make on a variety of available options. How do you make the best bet?
We may have a lot of decisions to make the architecture to evolve. And while evolving the architecture, we defer a lot of decisions to the last minute. We make a choice that is right for the current context. We make the feedback loop tight to understand the impact of the decision. If we think the decision has no negative impact, we stick with it. Otherwise, we move on to another bet, and the cycle continues.
The following techniques, along with continuous delivery, help us to evaluate our options:
If you want to evaluate a language or framework, rather than making it as an architectural change, develop a part of the application using the same. Monitor it for a while and try to answer the impact of making it as an architectural decision, by answering the questions:
- How many people does it impact?
- How long will it take?
- How difficult is it to change?
So the summary is, there is nothing called a perfect architecture. Architecture is contextual to a team. But follow the guideline — make every decision easy to change.
Mark Richards refers to Three Cs of architecture — the soft skills every architect should develop:
- Communication — ability to communicate ideas or solutions to stakeholders, including the developers.
- Collaboration — Collaborating with stakeholders and solicit ideas and feedback.
- Clarity — In communicating the architectural decisions to stakeholders
The architect cannot come up with great architecture by sitting in a room and by creating architectural diagrams. Diagrams can be used as a communication mechanism. But for the diagrams to convey the message, clarity and collaboration are required.
Domain Driven Design is about actively listening to the stakeholders and domain experts and asking them the right questions. Domain Driven Design helps for evolutionary architecture along with evolving the product and the team.
Software Architecture Fundamentals video series by Neal Ford and Mark Richards talks in detail about evolutionary architecture and the skills required by an architect in detail.
