Software Architecture Notes
Software architecture is important because it is very hard to change later.
The software development ecosystem changes and grows for the better. We don’t use the technologies we used a few years ago. So as a software architect, you have to deal with constantly changing technologies. Software architecture is a blueprint of the system that we are planning to build.
Role or job description or responsibilities of an (Effective) Software Architect
Guiding teams about the latest technologies instead of specifying the technology choices. Examine and Analyze Architecture, continuously track the latest technologies and trends, and recommend solutions to teams. Ensure structure compliance with architecture decisions and design principles.
Having good domain knowledge, interpersonal and communication skills, and patience.
A software architect must feed the development team by estimating difficulties and mentoring them to find better solutions for specific problems, with frequent POCs. But while doing that we have to write a clean code because developers will use it as a guide.
Understand and navigate politics, in every decision we will probably face disagreement with ideas. So we need approval, especially from developers, stakeholders, project managers, etc.
Technical dept is important for software developers (A deep knowledge about a programming language Ex: Java).
Technical breadth is important for software architects (Knowledge about 2 or 3 frameworks) Java, Go, Python.
Architects must iterate on component design to improve it. A software architect and developers should work together. An architect can prepare the draft but it shouldn’t be taken as the final component design.
SSOT (single source of truth ) is a concept used to ensure that everyone in an organization bases business decisions on the same data.
Organizations must have a central repository for data storage, collection, and analysis. Benefits of SSOT include better data for decision-making, less time searching for correct data, and overall increased productivity. As a software architect, it will help us to make decisions.
Unknown unknowns are the enemy of our software. And when we start up a project, unfortunately, we have those. With agile we can overcome many of these problems.
For a software architect, every decision must take into account many opposing factors. So the trade-offs are very important here. And also we should never forget “Why is more important than how”.
Frozen Caveman AntiPattern: I have to be on the safe side and use maybe some older technologies because of poor design or unexpected occurrences I had in the past. Instead, we have to be realistic and we can't get stuck in the past. We should look at the future.
In architecture, there are no correct and wrong paths that we should follow. It depends on the budget, company culture, time, developers, environment, servers, etc.
So we have trade-offs and the correct design is choosing the least worst set of trade-offs.
The Warship Vasa: A short story about a Swedish warship. It was the most magnificent warship, built by the command of the king. The king wanted the ship to be used for troop transportation and also for gunship. By the time ships sailed to salute; a cannon fired from one side caused the ship to sink, because of its heaviness. Shortly, we can not have everything in our solution.
A software architect must create ADRs and use fitness functions.
Architectural Decision Records (ADR) This document describes our architectural context, decisions, and their consequences. ADRs are immutable and when accepted changes require a new ADR.
Context: Description of problem and alternative solutions
Decision: Stating the chosen solution with a detailed justification of the decision
Consequences: Consequences after the applied solution (Pros, cons, mitigation of risks )
A template ADR can be downloaded from GitLab
Documenting the decision is very important for the architecture. An architect should implement fitness functions to maintain the internal structural integrity and make the architectural characteristics stable.
Code reviews are important, but a better choice for the architect is to write a fitness function to detect the cyclic dependencies between components, component inventory, finding duplicate functionalities, etc. Architectural fitness functions protect important principles and operational architecture characteristics.
In software architecture, DevOps has a great impact. With automation DevOps, we can do more code reviews and write fitness functions to maintain compliance with the architecture.
Reporting should be broken apart according to our graphic.
We can find duplicated functionalities throughout the application. Fitness functions could be part of a CI/CD pipeline and could be automatically triggered on deployment.
Notification can be managed by a single module.
MECE List: Mutually Exclusive collectively exhaustive
Mutually Exclusive: Each group is distinct and there aren’t any overlaps between groups.
Collectively Exhaustive: The sum of groups covers all possible options.
Winter, Spring, Summer, Fall the list is mece
Ex: comparing high-performance message queues but not Kafka. As an architect, we should cover all possible options. If we can not decide which technology to choose we can use Trade-off analysis for a few solutions
Architects should use trade-offs explaining the advantages and disadvantages according to business needs. As everything changes quickly in the marketplace, not to lose competitive advantages, the business must be agile so the underlying architecture must be agile as well.
An Architectural Kata is a workshop where several groups practice discussing and designing their architectures. The aim here is to improve software architecture design skills.
A minimal kata sample can be found on GitHub
The architecture worksheet can be downloaded from Gitlab
The architecture characteristics can be found on Github or Gitlab
References
