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.
Thoughts of a Goldfish by Daniel Brolund 
Jul 12, 2010 @ 11:42:19
I like your definition. It sounds like architecture is the legacy parts of the system and a good system is one that lacks or doesn’t need architecture. But as you say – even better if the concept could be replaced altogether. Maybe “engineering” can go away at the same time!
I have had similar thoughts for a while some of the blogged about as “Software development as mapping” a while ago:
(http://www.highlevelbits.com/2009/05/software-development-as-mapping.html)
Jul 12, 2010 @ 21:13:51
Can’t we try to just reinvent the word to mean something more along the lines of: A brief description of the currently predominant structure. This could for example be used to describe the primary interaction being REST?
I don’t know but there seems to be some value in the older description of the word (pre EE hype) that we would just invent another word for?
What would we say if asking for the basic architecture of the program?
My problem with the term is more what it has come to mean rather than its inherent meaning. Nowadays it is something that someone draws with boxes and lays out as law for all to obey no matter what changes in terms of requirements or needs.
I think that architecture has to be a mere high level description of the current state of the code rather than something static that has to be adhered to.
Jul 12, 2010 @ 21:59:17
I’m definitely having the same problem as you describe in your fourth paragraph.
If we are going to reuse words, why don’t we use the word ‘design’ for that?
What I’m getting at is that ‘architecture’ is generally regarded as something ‘posh’, and ‘design’ is a frowned upon. I think a problem in many projects is that ‘architecture’ do more damage than good. If architecture would be considered the last option rather than the boxes you create first and that everyone has to obey to, more value can be created.
Jul 12, 2010 @ 22:54:50
I work as a ‘software architect’ and have mixed feelings about both my title and the words software architecture. Where I work we have tried to stress the importance developers taking part in defining the architecture for any given product. We have tried to work with a less formal definition of architecture; the ‘architecture’ of a particular software system is the shared understanding of the implementation among the developers currently working on the system.
Living up to that definition and, more importantly, codifying or documenting it has proven the real challange.
Another topic is then what becomes of the architect when the architecture is redefined.
Jul 13, 2010 @ 09:15:57
I do not completely disagree with the previous replys, but in my world the software architecture is the blueprint you create Before you start building the software. In this time of strong agile and lean believers I think it’s a big big mistake to “do the architecture as late as possible”. If the blueprint is missing and you start building, you newer know what you are going to get – and that is not the right way to take for the software industry.
Jul 13, 2010 @ 10:09:02
If you don’t do the architecture as late as possible, you will actively and by will exclude information that should go into the decision of what you will build. That information can be crucial to the architectural decisions. I think it is unprofessional to do so.
I’m not saying that you should just hack away, but you should keep your options open as long as possible and not close them prematurely. The bigger the (architectural) decision, the more effort you should put into deferring that decision as long as possible. In order to know that, you need a rough design that will help you analyze where your critical points are.
Jul 13, 2010 @ 10:39:13
What you are talking about is design, not architecture! Design decisions should be taken by the programmers whenever they stumble into problems that need to be solved.
But the architecture is the “framework” for all the design decisions and all the coding that need to be done to solve the problem at hand.
And you can never let the programmers – doesn’t matter how skillful they are – take the architectural decisions. They should be limited by the architecture, and only work with design elements, decisions, patterns, and so on.
Jul 13, 2010 @ 11:09:19
I think you are expressing exactly the thoughts that I am opposing in this post. Thank you!
🙂
You are distinguishing between ‘programmers’ and ‘architects’ as if the architects are worth more, and I think doing so is disrespectful. You are saying that architecture is more important and should take precedence, and I want to view architecture as the things that are hard to change but at equal value with design.
You say that architecture should be limiting developers, and I think doing so is closing you options to the disadvantage of the company you work for.
You say that architecture is the framework for design decision, and I think the design is the birthplace of the inevitable architecture, an architecture that should be kept to a minimum.
I’m not saying you can’t do it your way, I’m just saying I don’t agree with you. 😉
Jul 13, 2010 @ 11:33:57
I have to agree with @danielbrolund, although I also think that ‘blueprinting’ can be a good thing to get the team talking and get everybody started with a common design platform. However, the blueprint must not be mistaken for a master plan or dogma.
I have so far never seen an architecture that was imposed on a team; that they had no mandate to change; do anything other than cause confusion or act as a roadblock in the long run.
Furthermore, it is my experience that enforcing a (hierarchical) difference between ‘architects’ and ‘programmers’ generally only makes developers grumpy and passive and architects aloof and out of touch with the implementation work. That is of course a broad generalization.
Jul 13, 2010 @ 23:56:13
Hello.
Sorry, my title says I’m an architect. Although, I do teach architecture fundamentals at university, so I should know what architecture is and what is not. I may blog about architectural myths, meanwhile you can read my position about Owning the Architecture here http://wmp-archi.blogspot.com/2010/06/owning-architecture.html.
Now, my last paragraphs states it like this: “Owning the architecture means being responsible of its construction, taking care of all the complex processing that development requires. ”
As you can see, an architect is not only a decision maker, not only a coder, not only a manager. Architecture is not a blueprint. Architecture is not design set in stone.
Architecture is the actual structure of your solution, documented or not, visualized or not, being aware of or not. It is just there, you can’t just not have it.
Architect is the one that is responsible for the construction of a solution, that oversees the architecture as it is built, not as it is imagined. Architect ends its job when the solution is in production, not before, not with a blueprint.
Architecture start building when you write the very first line of code. Architect’s job start far before that, with stakeholders concern’s analysis.
If you think and feel what I’m saying is correct, then you can reread all comments and see we are not talking about architecture in many of them. Granted, that is the real world in many occasions, but that is because someone that didn’t understand what architecture really started doing things like that (meaning, writing BDOF and making early decisions).
BTW, decisions are made as soon as feasible, and that is as soon we have all the information needed to make the best decision. Not as late as possible. Those are two points in time, and during that period you can make adjustments. If you wait to the latest possible time, you end up without time for reaction. If you don’t wait and make a decision at the beginning, you lack the information needed to decide correctly.
Cheers.
Jul 14, 2010 @ 07:51:29
Hi William,
Don’t be sorry, you seem like a sensible guy, at least from reading your post. 🙂 What I still don’t get is why it’s not just design, all together? Why do you need to call someone an ‘architect’ to do ‘architecture’, if it is about designing software to fit the needs of a user, which is a job of the team?
I’m trying to provoke a little in my post (seems like I did a decent job at that), but I believe in the collective (code) ownership. Giving someone the title ‘architect’ takes you a step away from that.
And BTW, I’m not saying you shouldn’t do anything before ‘as late as possible’ (last responsible moment), I’m saying that you shouldn’t give up your options until then.
Jul 14, 2010 @ 18:03:16
Yes Daniel.
All is based on the view you want to accept. Look at this one:
1. You have a problem. To communicate that problem, you should describe it. You can do it using plain text, nice to understand detail but it is hard to work with. You can describe it with a simple diagram, nice to capture the global problem, but lacks details. Both descriptions are using different languages, both have different detail level, but both describe the same problem.
2. Now, you have a solution. Copy paste all point 1 here, and replace problem with solution. Same thing! The description at high level or low level serves different purposes. High level will help you understand the whole solution and make decisions, low level helps the machine to execute.
3. Now, there is a myth about architects being the stealing gods of knowledge work. You have three programmers working on a solution, and they are doing fine, until an architect comes and without looking at code decides something different, that may or may not work. If does not, coder’s fault. If it works, Architect’s triumph. In any case, the architect is a disruptive element, an alien to the working group.
4. Well, that myth becomes true sometimes. There are other like me that thinks development is far beyond just coding (which is micro designing, description at operational level). Even more, beyond Design (which is description at tactical level). Architecting is an strategy level where you look at other things apart from localized problems, to interaction with other systems, integration, stakeholder concerns, and other things that cannot be analyzed from the code point of view.
5. Now to your question: Why don’t we call all that “describing” or “design”. Well, I agree. I would call all that development. In development you have many different tasks, including management, coding, documentation, testing, analysis, refactoring, etc. You need to put a group of people to do all that, coordinated. So, what is wrong by having guys with experience or skills doing some things, doing those things in the group? If you have a Java expert, I guess you will put her to code Java. Architect’s should have some particular skills to be able to assume that role in the group. The solution, not only the code, will belong to all the people in the group. That is the idea.
Cheers.
Nov 14, 2010 @ 13:15:57
Much talk about architecture but nobody mentioned why it is. I mean high level and longer change cycle hints but what is it for?
In my view, *system* architecture is what determines many of the systems qualities.
Take availability for instance. How would you go about to achieve that? Introduce some active redundancy, perhaps?
Such things I like to think less about when I write code.
With my architect’s goggles on, I think about qualities while when coding I think about function, completely orthogonal to the former.