The ultimate goal of good architecture is cost reduction. If your architecture is causing you to spend more time developing and maintaining code then the architecture has failed.
It's always a balancing act. The corollary us that there is no one right architecture, the choice depends on circumstances, and should sometimes be re-evaluated.
Another corollary is that flexibility is extra useful, because it allows to evolve and tweak the architecture to.some extent, maintaining its efficiency in changing circumstances.
It also doesn't always have to be a dedicated architect in a proverbial ivory tower. It can be an informal meeting of developers around a whiteboard. Don't get scared by the word "architecture".
IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently.
Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.
Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: all of you thinking you can use waterfall to figure it all out up front are deluded. By getting started right away, you make mistakes and you avoid working on non-problems. I can fix the mistakes with refactoring but you can't ever get your time back.
Most teams live in his world now. Few do too much up-front design, most suffer from piled up tech debt.
I hope you give architecture another chance. Focus on the abstractions themselves [2] and divorce that from the process and team roles [3].
[1] https://news.ycombinator.com/item?id=40616966#40624446
[2] Software Architecture is a Set of Abstractions, George Fairbanks, IEEE Software July 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
[3] JESA section 1.5, https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft... "Job titles, development processes, and engineering artifacts are separable, so it is important to avoid conflating the job title “architect,” the process of architecting a system, and the engineering artifact that is the software architecture."
Even if you clone us, our gut feel doesn't transfer to our clones. So, we can recognize under- and over-engineering in our guts, but how can we help someone else? Is there a better way than the risk-driven model?
1. Identify and prioritize risks
2. Select and apply a set of techniques
3. Evaluate risk reduction
It's not true, there are architectures that are a waste of time today, and a waste of time in 5 years, too.
Generally, clever architecture at the right stages can beat clever code and leave flexibility to pivot.
>> cost reduction
> fulfil the quality goals
I’d word it as “keeping the cost of changing software low over the long term”.
I don’t think you can reduce that to a quality goal of “modifiability” because it’s not negotiable like other quality goals.
I don’t think you can say it’s just cost reduction, but that is closer.
It’s an existential thing. Architecture is about retaining the ability to change your software (avoiding the big ball of mud). If you lose the ability to change within time and resource constraints then the project, product or startup is dead.
But, have you seen this kind of mistake / failure? A system is built so flexibly that it can handle all kinds of future needs, but it's slow. Maybe it's a shopping cart that takes 5 seconds to update. So start with modifiability as the primary heuristic but keep an eye out for other failure risks.
Meta-commentary:
This is an example of why it's so hard to discuss architecture. My book talks about "failure risks", which is pretty abstract or generic. There's no easy heuristic for avoiding "failure risks" like there is for web / IT systems.
Software architecture is a discipline that's bigger than just web / IT systems. Some systems must respond with X milliseconds, otherwise the result is useless, so the architecture should make that possible -- and preferably make it easy.
1) Not all qualities are requirements. Requirements tend to be pass/fail, either you meet them or you don't. Latency is a quality and typically lower is better, not pass/fail (though sometimes it is).
2) "Nonfunctional" in other contexts means broken. If you saw a machine with a sign on it saying "nonfunctional" what would you conclude?
At one point I tried to find the origin of the term "quality attributes". It's way older than the software community. I found it being used in the 1960's by the US National Academy of Sciences. If anyone knows the origin I'm interested in learning more.
"The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: “What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?” The risk-driven model can be summarized in three steps:
1. Identify and prioritize risks
2. Select and apply a set of techniques
3. Evaluate risk reduction
An example of "architecture" is using the Client-Server style, where servers never take initiative and simply respond to client requests. That might be a good or bad fit to the problem.
[1] https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
"It democratizes architecture. You may have software architects at your organization — indeed, you may be one of them. Every architect I have met wishes that all developers understood architecture. They complain that developers do not understand why constraints exist and how seemingly small changes can affect a system’s properties. This book seeks to make architecture relevant to all software developers, not just architects."
In hindsight, my book hasn't been very good at that but perhaps it was a stepping stone on the path. Michael Keeling's book Design It: From Programmer to Software Architect does a better job of saying how developers can engage with architecture ideas. I'm a personal friend of his and a huge fan of his work. His experience report [2] on how to democratize architecture is what I aspire to do.
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] Keeling and Runde, Agile2018 Conference. Share the Load: Distribute Design Authority with Architecture Decision Records. https://web.archive.org/web/20210513150449/https://www.agile...
"I’m not ready to argue against Brooks’ Law that adding people to a late project makes it later. But today, when developers are working on a clean codebase, I see lots of work happening in parallel with tool support to facilitate coordination. When things are going smoothly, it’s because the architecture is largely set, the design patterns provide guidance for most issues that arise, and the code itself (with README files alongside) allow developers to answer their own questions."
[1] Scale Your Team Horizontally, George Fairbanks, IEEE Software July 2019. https://www.georgefairbanks.com/ieee-software-v36-n4-july-20...