Skip to content

stevegrossi

software architecture

Tended 1 year ago (1 time) Planted 1 year ago Mentioned 0 times

Contents

The art and practice of structuring software to maximize its habitability, primarily for those who work on, since it If software never needed to be changed then architecture would be unnecessary. Software architecture differs from programming (i.e. code design) in scope rather than kind: while the programmer or API designer may be concerned with putting functions and arguments in the right places and the architect on modules and capabilities, many of the same principles apply at both levels of abstraction and those in between.

The goal of architecture is to preserve optionality

A common idea is that software architecture is concerned with things that are hard to change, perhaps because that’s what architecture in the built environment seems to be about (though Stewart Brand’s How Buildings Learn refutes that misconception). This would make sense if software were as hard-to-change as buildings. But Martin Fowler’s classic article “Who Needs an Architect?” makes an important counterpoint that because software not only can but must change over its lifetime, that good architecture is less about predicting the future and making the right decisions up front, and more about preserving the ability to change software in response to a future fundamentally unpredictable. He gives an example:

It’s commonly believed that if you are building an enterprise application, you must get the database schema right early on because it’s hard to change the database schema—particularly once you have gone live. On one of our projects, the database administrator, Pramod Sadalage, devised a system that let us change the database schema (and migrate the data) easily (see http://martinfowler.com/articles/evodb.html). By doing this, he made it so that the database schema was no longer architectural. I see this as an entirely good thing because it let us better handle change.

Resources