My Architecture Drivers
My Architecture Drivers êŽë š
I donât feel like an authority or an expert. I prefer to think about myself as a practitioner. Our industry is filled with self-proclaimed experts; we need more doers.
For similar reasons, I was reluctant to call myself an âArchitectâ for a long time. Somehow, it became pejorative, but should it be? I changed my mind thanks to Jarek PaĆka (jpalka), who says that âwe all are architectsâ. Itâs a simple line but multidimensional. That means (to me) that we all are responsible for making our systems work as they should. Itâs not about bragging but accountability.
Still, I never feel comfortable being asked about Software Architecture Drivers. How do you give someone a checklist for good software? Yet I had to answer this time, as Maciej JÄdrzejewski (jedrzejewski-maciej) asked me if I could write my thoughts to his new book. How could I reject the offer? Actually, I could, as it surprised me, but hey, maybe my few words will help others fight their impostor syndrome. Or it was just too flattering. Nevertheless, here they are!
Itâs funny that we called our industry SOFTware, but itâs all about making HARD decisions. Usually, we make them when weâre the dumbest: we donât know the business domain, we donât know the user needs, and we are unsure of technology choices. Plus, even if we do, our changing environment is open to proving us wrong.
For me, architecture decisions are more a process than a set of specific rules. Itâs a process of answering the following questions:
WHY? So, understanding the product vision and business model. Consider where the money flows: who the client and the user are. Thatâs an important fact, as we should care about all users but optimise for clients, especially those who bring money. In the end, our product should bring money.
WHAT? Understand what we actually need to build. Set a mental model of the business workflow. This is an excellent moment for collaborative tooling, brainstorming and modelling practices like Event Storming, Domain Storytelling, etc.
HOW? Think about the requirements and guarantees you need to have. Find architecture patterns and class of solutions that will fulfil your requirements. So, the type of databases, deployment type, integration patterns, not the specific technologies. Consider tools like C4 and other tools to structure your findings.
WITH. Select the tooling based on the outcome of the previous point. It has to fulfil requirements, but also non-functional like costs, match team experience, ease of use. Then rinse and repeat.
Architecture is not created in a vacuum. Talk and collaborate with business, users and your technical fellows.
Consider the team you (can) have. Most of the time, the best technology is the one that your team knows. Weâre building new tools, but to be true, rarely sophisticated ones. Most of them are regular lines of business applications.
And hey, let me share the secret with you: your decisions will be wrong. Mine also. And thatâs fine. We donât need to be flawless; our system also doesnât need to be. Expect the change; itâll come.
So donât be afraid to make decisions, but donât rush yourself. Always consider alternative solutions. Record your decisions together with thrown away ideas. Provide the context and explain WHY, WHAT, HOW, WITH. Provide the assumed limits. Suggest how to evolve if, e.g. your system will be a huge success and becomes overwhelmed by traffic. Some problems are good to have. But donât need to be solved immediately.
We should optimise not for maintainability but for removability. If our system is built so that we can relatively easily remove pieces from it, then we can drop bad ideas and move on to new ones. Also, by accident, weâre getting a system thatâs easier to maintain.
What are your architecture drivers? Or better, whatâs your process?
Check also Maciejâs book âMaster Software Architecture Bookâ. Iâm still in front of reading it till the end. But I like what I see so far; the outline and range of topics show the holistic, actionable vision of building software. And, most importantly, itâs not pompous.
I think getting more books/talks like that would be great. We need more books in the spirit of âthis is my story, this is why I think itâs important and worked out for me. â. Itâs good that itâs from a personal perspective, allowing us to compare or benchmark it to our vision and experience.
If you need even more architecture benchmarks, I have gathered some of my past articles on my general approach to architecture and software design:
- Architect Manifesto
- How to design software architecture pragmatically
- Removability over Maintainability
- The risk of ignoring risks
- Why are we afraid of our decisions?
- What do the British writer and his fence have to do with Software Architecture?
- Follow the money to get a better design
- A few words on communication
- How to successfully do documentation without a maintenance burden?
- The magic is that there is no magic. Or how to understand design patterns
- Not all issues are complex, some are complicated. Hereâs how to deal with them
- On the importance of setting boundaries in team management
- What Dune can tell us about setting our goals
- Stacking the bricks in the software development process
- The Holy Grail syndrome
- Dive a bit deeper, look a bit wider
- What does Mr Bean opening the car have to do with programming?
- What does a construction failure have to do with our authorities?
And check Architecture Weekly where Iâm showing my less-event-driven face every week!
Cheers!
Oskar
