Hola! In this post, I will put flesh on the practical steps when designing software architecture. When building a software architecture, it is not necessary to follow all mentioned steps, but it’s necessary to understand the importance of each phase. I don’t like long introductions, so let’s go.
The job of the architect
The job the architect has to do is designing and proper communication of software architecture. Taking decisions is the staff of life of architects. Among decisions, we not only have typically technical things but also others like skills in team, available technologies and organizational rules. Communication is even more difficult because architect often meet resistance, misunderstanding, in unhealthy teams also criticism. In this area, the job of the architect is also preparation of good arguments, doing research and comparing chosen tools with other tools that do the same or similar job.
Structure is something that tell which building blocks are used and how they cooperate with each other.
Building blocks in software architecture
A building block can be a subsystem, part, component, package, namespace, class, function, configuration file, etc. A building block can have two types: white box and black box. The white box reveals implementation details and the structure inside, whereas the black box hides its details. When talking about types in one diagram, some building blocks can be white box and on other black box. It depends mostly on context and the audience whom we are going to communicate the solution.
Both white and black boxes should have correct and meaningful naming and description. Additionally, the description of the white box building block should explain the reason it’s structured in a given way. This explanation is called a design rationale.
Decomposition of the black-box
Following the top-down approach mentioned in a previous post, we sometimes need to decompose a black-boxes into white-boxes. We just gradually break down the next parts in smaller part, going straight into the details. This approach is call a stepwise refinement, because step by step going down, architects reveal the structure of the sub-blocks.
Identifying risks
Looking at the software architecture from different perspectives can decrease the amount of disappointments and costs in the future. This is first thing architects have to take into account as their responsibility is identifying and reducing risks.
Software architecture is the play of trade-offs. Architects all the time have to juggle the decisions based on certain requirements to meet all expectations in the most efficient way.
Some decision can be risky. Among them lie:
- deciding to innovative approach (new unknown technologies, new patterns),
- no necessary experience in team,
- choosing costly noneffective resources,
- Being forces to any solution because of any organizational rules.
Summary
That all for today! I think any huge summary is not needed. In this post, I noted the most important things that I’m going to go through when doing my last exam preparation.
Let’s go to next topics!
Ciao!