iSAQB meetup: software architecture decision making in practice¶

Making significant software architecture decisions - Bert Jan Schrijver¶

Software architecture. What is software? Algorithms, code-that-works, the-part-you-cannot-kick. And what is software architecture? The part that is expensive to change, the structure of the system, best practices. The decisions that are important and hard and expensive to change. Software architecture is about making decisions. Decisions that hurt when you get them wrong.

There are bad reasons for architecture decisions:

• We’ve always done it like this.

• We don’t want to depend on XYZ.

• We need to be future-proof. (You often get elaborate complex systems with this reasoning. Isn’t a simple solution more changeable and future-proof?)

• Because the product owner wants it.

• Because the architect wants it. (If the architect wants something without real feedback from the team that has to build it.)

Some input you can use for architecture decisions:

• 5xW. Why, why, why, why, why. After asking “why” five times, you really get to the core.

• Every architecture decision should have a business component. (Don’t pick a fancy framework when there’s no business need.)

• Requirements.

• Constraints.

You also have to look at quality. ISO 25010 is a great checklist for software quality: self-descriptiveness, availability, recoverability, capacity, integrity, modifiability, testability, etc.

The perfect architecture doesn’t exist, there are always trade-offs. Trade-off analysis can help you. Gather requirements, figure out quality attributes and constraints, select potential solutions, discover/weigh trade-offs, pick the best fitting solution. You can look at the book fundamentals of software architecture.

An example? Security versus usability: 2FA is great for security, but a pain to use. Availability versus costs: more redundancy and more servers also mean it costs more. He recommends this video.

Something to keep in mind: organisational factors. What is the developer experience for your idea? The learning curve? IDE support? Does it integrate with the current landscape? How popular is it in the industry as a whole? What is the long-term viability? Will it still be actively developed and is there a community?

And there are business factors. Support. Labour pool. License costs. What are the costs of migration versus the benefits after migration? Productivity. Is there an exit strategy if you want to move away from a provider or technology?

Some trade-offs shouldn’t even need to be considered. For instance when something risks irreversible damage to your business.

Creating effective and objective architectural decision records (ADRs) - Piet van Dongen¶

Nothing is static. People change jobs, business goals change, budgets change, etc. Time goes on and during this time you are making decisions. When a new colleague joins, is it clear which decisions have been made beforehand? Are decisions discoverable? And can the decisions be explained? Are they appropriate?

He asked “did you ever disagree with a decision that involved you?”. Almost all hands went up. Bad decisions might have been made in the past because better solutions weren’t known or available at the time. Or there was time pressure. Unclarity on the requirements. All reasons for decisions to be bad.

Decisions should be made when you really understand the context, which should be clear. And the decision should be objective and logical and clear and well-explained. And they should be made by the right stakeholders: was it a shared decision?

Note: architecture work isn’t only done by official architects.

Some archetypes of wrong decision-making:

• Aristocrats. A decision made by a small group of self-appointed experts. Ivory tower. They only explain why their decision is perfect, but they don’t concern themselves with trade-offs.

• Unobtainium. A theoretically perfect decision, but that totally isn’t implementable.

• Ivory tower dump. Even more ivory tower than the aristocrats. Totally no input from the team.

• Pros and cons. Endless lists of pros and cons.

• Polder model. Consensus-based. A decision made by a huge group. Endless meetings.

Now… how to make decisions in the right way? ADRs, Architecture Decision Records. A structured/standardised document that documents the decision. Structure? For instance:

• Title + state + summary. Handy for easy scanning. State is something like “decided” or “rejected”.

• Stakeholders. Names plus the roles they had when the decision was made. Find stakeholders by looking with a 2x2 matrix: high/low power, high/low interest. A boss might be high power, low interest: keep him appropriately informed. High power, high interest: really involve them.

• Context of the decision. Clear and sharp. What is in scope, what not?

• Requirements. It is easy to come up with 1000 requirements. Stick to what is significant. What is significant? Requirements with high risk. Huge interest to high-power stakeholders. Hard-to-change items. The fewer requirements, the sharper the decision.

• Options. Nicely listed and scored. On requirements. And just don’t give scores, but weigh them by the importance of the requirements. This also helps in understanding the decision afterwards.

  Options should be distinct. Don’t pick very similar solutions. You should have something to choose. And drop options that you know are never going to satisfy the requirements, this clears up clutter.

  But… watch out for tweaking the weights to get to the desired decision…

• Decision. The logical conclusion.

In case the decision turned out to be wrong, you now have a nice document and you can re-evaluate it. Perhaps you missed a stakeholder? Perhaps a requirement was missed? Or a weight should be changed? You can then make a 2.0 of the ADR. You learned from your mistakes.