For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Ben Halpern -
Abraham Romero -
Jaime -
Ewerson Vieira Nascimento -
Top comments (8)
Architecture is a way to say 'systems design' in one big word instead of two medium words. As a discipline, it invites thinking of software in big-picture terms as a network of discrete but interdependent moving parts which acts on and is in turn acted upon by external entities and factors. Architecture can be done well or poorly but it's always done as soon as you move past the trivial. Devoting effort and consideration to it helps produce flexible, efficient, maintainable code. Devoting so much effort and consideration to it that your architects don't even touch the systems they nominally work on is probably a bad idea.
Ruth Malan has some interesting thoughts on the role of the architect in modern software development.
Origin - from arkhi- ‘chief’ + tektōn ‘builder.’
Construction = Putting pieces together to form a structure
Architecture = Construction with someone in charge of the work
In modern use, any organized intentional form of construction is architecture. It is nearly impossible to create working software without architecture (the planning/design steps).
When comparing the terms with civil engineering I wonder if the same principles apply in software.
Unlike software, civil engineering requires big design and planning upfront and that design is very difficult if not impossible to change.
With software however change in design is possible at any time and there are no hard restrictions that prevent this change.
Another difference that i notice when comparing civil engineering is the puropse. In civil engineering the goal and purpose are predefined and static. A bridge will always be a bridge and a design for a 10 story building will never change to support 10 more half way through the construction phase.
In software the requirements change so much that a software building might end up with double the planned storys AND connecting two river banks.
This being said i wonder if the parralel applies at all. I have seen teams that struggle with adapting to changing requirements because of constraints in the architecture, but never challenge or chqnge it.
And while classic architecture applies for civil engineering I dont see it working in software.
The book "Antifragile" is a great start for examining modern planning concepts. The book didn't focus on software, but it was received well in the software community. In short, planning for change doesn't have to be a burden, it can be a source of strength.
en.wikipedia.org/wiki/Antifragile
Structure / Design?
Is it the rules that keep the order in our system?
Is it an excuse for sticking to a hardcoded tech stack? An excuse for sticking to the same programming patterns regardless of the complexity or efficiency?
Is it an obsticle that prevents us being agile? Is it open for change and improvements?