Software architecture journey: the profession (Chap 1.)

Colleagues often asked me, why is architecture so important? Why is the solution so complicated? Is there any way to really implement it? Should it even be implemented?

In this chapter, I will try to focus on the following:

• What is software architecture?
• A simple analogy: a client wants to build a house
• What are the tasks of a software architect?
• What are the possible architect types you can encounter?

What is software architecture?

What does wikipedia say?

"Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations"

And in the "characteristics" section, it says it serves for:

• communication with multiple stakeholders
• improve quality
• doing separation of concerns
• ensuring recurring styles
• ...

There are several key elements here:

• Communication
  • Enough information, in the right format, needs to be communicated to the stakeholders for them to approve the solution. Later on, they also need to acknowledge the different achievements and what it means for them.
  • Technical information needs to flow to all the experts for them to build the different blocks of the solution.
• Quality
  • It needs to be clearly defined with the stakeholders and reflected by the experts.
• Software element
  • A piece of code with a functionality that can be encapsulated.
• Structure
  • How are the software elements defined, why and where?
  • Is there any hierarchy?
• Relations
  • How do they interact with each other? Which value does it generate?

What would "my definition" be?

"Software architecture is the process of transforming complex business goals to solutions we can interact with."

Software architecture tries to harness the complexity by decomposing it into smaller blocks. The software architecture:

• shall be as agnostic as possible in its approach (your coding preferences or pattern preferences should not influence your decisions)
• contains many tradeoffs that need to be documented (some decision are really tough to make because the different options seem to do the same. This is wrong. Every solution tries to resolve slightly different problems. Variances in the understanding of the options or understanding of the problem also play a role here. A simple comparison matrix could help you with "visualising" the "slight differences")

A simple analogy: a client wants to build a house

What are the influencing factors?

• features <-> what your house should contain
• constraints <-> ground, regulations to respect
• quality goals <-> should it stay standing for life? Could I later add a room? How many levels should the house eventually contain?

An architect designs the house based on the above information! Like in software, some constraints or quality goals can dramatically increase the cost of the house.

When you approve the house and the material used, the build can start.

Craftsmen are in contact with the architect to make sure they build it correctly (or not, in case of mis-understandings or errors).

At the end, you get the house with the feature you wanted and the issues that were created in the process of building it (door opens on another door, wrong electrical outlet location, ...).

What are the tasks of a software architect?

He is the executor of the architecture process; defends it and communicates it to all persons involved.

What is "architecture process"?

Here are the names of some famous architecture processes that exist:

• BAPO - https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/
• Arc42 - https://arc42.org/overview
• Domain Driven Design - https://en.wikipedia.org/wiki/Domain-driven_design
• microservice architecture decomposition - https://microservices.io/articles/applying.html
• C4 Model - https://c4model.com/

Depending on the target solution, one or a combination of several processes should be chosen.

Arc42 contains all necessary steps to create a great architecture: (1) requirements, (2) what is the system that needs to be built and (3) how to decompose it. I would recommend you to read through it.

When the project has a certain level of complexity (e.g. you feel the scope is too broad and you may need several teams to work on it), the Arc42 decomposition may become more tricky to do. The reason is, you will need to have many abstraction levels to construct it. Each of these levels need to be coherent with the others. A lot of effort will be put there. Additional to it, all the teams need to understand it and understand how they will contribute to it.

Therefor, I prefer using the Arc42 process when it comes to small or middle-sized projects. For bigger one, DDD or microservice architecture may be more adapted because it enforces the divide et impera principle. After such a decomposition, I can apply Arc42 within a sub-domain or micro-service context.

Sometimes it also makes sense to apply the beginning of BAPO to extract the quality goals from the business capabilities.

Remarks

What does divergences in the architecture mean?

Discussions about divergences usually occur when the "first thought" or the "simple approach" on how to integrate the new feature is not covered by the current architecture. Nevertheless, accepting such divergences will (in mid and long terms):

• Increase maintainability effort.
• Increase the solution complexity.
• Usually negatively impact the quality goals. It is measurable.
• Also raise questions like "Does the architecture needs to be adapted?"

I also want to add to this remark: there is a distinction between "architecture" and "design". An architecture pattern can contain one or many design patterns to realize it! An architecture pattern has a macro influence where design patterns may have a more local one. Therefore architecture decisions needs to be applied very strictly, but a certain level of freedom is given when it comes to the choice of the design patterns.

What does it mean to change an architecture driver?

• It generates major costs that are not visible to the client.
• Current architecture strategy is derived from the quality drivers, architecture driver changes may mean that the chosen architecture and anything built on top of it is wrong. Major refactoring are the consequences of such decisions and need to be understood by the stakeholders.

What are the mis-conceptions about architecture?

• It's about building the best solution. This couldn't be further from the truth. The "best" is subjective. It is about building a solution optimized for the influencing factors.
• Architecture resolves everything. Architecture defines the frame to resolve a specific problem. e.g. if reliability is not a quality goal, the architecture may not contain mechanisms to ensure reliability. On the contrary, the solution may still be unstable if the "core" that is supposed to stabilize the system is still buggy and may not work as expected!
• It is static, one time defined and never touched. An architecture is a living thing and becomes more detailed and precise every new iteration. Technical decisions shall flow into it!

Additional remarks:

• Quality goals shall always contain scenarios so that you do not forget what they are supposed to resolve! e.g. What does testability mean? What should the solution do?
• Technical context definition is critical! Understanding the interface of the system may resolve major dependency issues later on!
• Any decision that potentially generates a conflict should have a technical/architecture decision document!

What are the possible architect types you can encounter?

Mindset

There are indeed many architects with different mindsets out there.

• Purist - https://automationpanda.com/2017/09/26/purist-vs-pragmatist/, this link explains it perfectly.
• Pragmatic - Check the link above 🙂
• Centrist (learned its lesson)
  • "Big picture" is a guiding frame but the source of truth is the code.
  • Business prevails, architecture and all the solutions need to carry it.
  • Academic has some truth to it and can help when it comes to abstraction of the problem.
• Ivory tower (did not learn his lesson)
  • Forgot that technique evolves faster than what he can learn.
  • Believes he is the source of truth.
  • Does not compromise anywhere.

Methods

I have accounted 2 ways of thinking by architects:

• Visual
  • Drawing, drawing, drawing helps to understand everything.
  • A good pictures is better than 1000 words.
• Book
  • Writing, writing, writing is the only way to transfer information.
  • We did it academically for the master and PhD, and it works.

References:

• https://en.wikipedia.org/wiki/Software_architecture
• https://arc42.org/overview
• https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/
• https://en.wikipedia.org/wiki/Domain-driven_design
• https://microservices.io/articles/applying.html