I once had an interesting debate with fellow developers over a software performance concern, which prompted us to revisit our architecture. Some argued that we needed a new architecture and indeed some of that work was underway. I had raised a few concerns over some of the architectural decisions that had been made in the past when I first joined the team but for entirely different issues. My particular concerns centered on testability. More precisely, it was practically impossible to test the system without having everything connected. From the UI down to the database – everything had to be running.
The first architectural decision made was Angular. This clearly struck a chord in my spine as I wrestle the idea. I thought to myself, Angular is a detail. Moreover, a detail that ought to remain hidden from an architectural perspective. The architecture of a system shouldn’t deal with how it is delivered – in my view at least. It is almost like describing the architecture of a house by the types of bricks and cement used. To architect a system is to carefully draw boundaries around the various components that make up that system and connect them in a thoughtful manner, i.e manage dependencies, without revealing the details. The delivery mechanism is a detail.
But what about agile, you may ask? Didn't we abandon the idea of big upfront designs? Is this what I'm suggesting? The answer, of course, is no. Good architecture is revealed slowly over time as the system grows. It is not something that you and I can craft over the weekend and be set for the remained of the system's lifetime, but rather something fragile - Hence the idea of keeping details hidden. I find it helpful to think of what to keep out rather than what to include when dealing with architectural design. The more I can keep out, the better.
Top comments (2)
Lefting out, or an explanation I like more is: "an architect delays all the decisions as long as it can". And usually this means the technology/frameworks/languages are chosen among the last decisions, the advantages are many, but mainly when you have to take a decision later in t he design you have more details&info so it will be a better decision.
Speaking of angular, choosing a framework may have many factors (technical and business), including the team knowledge, how many devs can you hire on that technology, the community (a nice article about this , testability and tools ...
I was going to comment along these lines as well. To me the best software designs build in the idea of making decisions as late as possible. The reason being that this will be when you have the most information possible to make the decision. Another one is that you want to mitigate against bad decisions as much as possible.
Of course this then lends itself to talks of trade offs which I think are also important. To meet the 'late decisions' prerogative might mean abstractions that are harder than talking directly to a chosen framework. How to use a native RDBMS feature might provide 100x performance whilst still keeping the ORM flexible etc.