The other day I got a nice LinkedIn email from graduate student asking me if architecture can evolve from continuous refactoring. There were a couple of questions about where it worked and where it didn’t, and I started wondering what was really meant by “software architecture”. Well, at the bottom of the email was RUPs definition of software architecture:
“The set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.”
WTF? What does that mean? What are they trying to say? That architecture is everything? If architecture is the significant decisions, what are the insignificant decisions?
I really dislike the word “software architecture” as well as the role/person “software architect” as it is used today. It is probably because it implies that things can’t be changed, “it’s architecture!”, and that only some people can make the decisions, “the God-sent Architects!”. I also think the housebuilding metaphor for writing software is crap, so that might be another reason.
But still, I think that the term “software architecture” is here to stay, so I’ll try and give another definition of it:
“Software Architecture is the part of the software design that takes more effort to change afterward than to initially implement”
Some interesting consequences of this definition:
- If you refactor your code so that replacing an “architectural part” requires less effort than to initially implement, that is now software design, not architecture.
- There is a temporal component to it, in that a design decision becomes architecture if it requires more effort to change than it initially took to implement.
From a Lean perspective you want to decide as late as possible, or keeping you options open and defer commitment to the last responsible moment. Since by this definition architecture means that you have limited your options, you want to do as little architecture as possible, do the architecture as late as possible, and try to push things that are architecture to being open decisions again.
This way of looking at software design makes architecture more fluent and, I think, more in touch with reality.
This doesn’t mean that everything should be “configurable” or “flexible”. That is a problem in itself. It merely means that you shouldn’t let anyone, including “architects”, carve parts of a solution in stone before there is no other way of doing it or the cost of not doing it is too high.