What is architecture?

 Well, first of all, in software context, the word is a metaphor.

A figure of speech in which a term or phrase is applied to something to which it is not literally applicable in order to suggest a resemblance.

Obviously the suggested resemblance is to the buildings architecture.

So a better question would be:

To what concepts is the metaphor applied?

There are probably many but seems that the outstanding ones are the following three:

1. Culture – The domain of interest and the set of knowledge for a particular person or group.

2. Process – The process/activity of defining the structure of a software system

3. Characteristic – A structural characteristic of a software system.

How well does it work?

Culture

The metaphor doesn’t really work for this concept. It doesn’t simply because the resemblance is not strong enough.

I don’t know much about buildings architecture as culture.

What I do know is that it is a mix of art and science and that there is currently a popular debate in their domain about the balance between art and science.

But the primary reason for which the metaphor doesn’t work for software design as culture is that the buildings architecture is much more a science than software design is. Software design is most, if not all, art. At least this is what it is today.

Building architecture is directly connected to the natural world. It involves principles and patterns but at least some of the theory must be limited by the laws of the real world in which a real building would have to be built. Gravitation, wind, precipitation, earthquakes.

Software design, as culture, is more like the culture of a poet or painter. It does include the principles and patterns that others discovered. As opposed to buildings architecture, most of these principles and patterns have some criticism and most of it is quite fair. When this culture is being used in the process, the degree of freedom is a lot larger as compared to buildings architecture and this mainly comes from the lack of unquestionable limits such as physics. As in poetry or painting, this culture mostly serves as inspiration rather than act as a mandatory dependency.

Process

This is again a concept for which the metaphor doesn’t really work. Again, there is a basic problem of resemblance.

The process is the action for requirements satisfaction, using the culture, talent and imagination. It is a trip on a bumpy road to a destination called “requirements satisfaction”, driven by culture, talent and imagination.

The big difference between the two domains is that the culture plays a vital role in buildings architecture domain (unquestionable principles) as opposed to software design where it mainly serves as inspiration.

By “requirements satisfaction” I mean not only satisfying the primary wishes of the stakeholders. Requirements are both explicit and implicit and besides the ones explicitly stated by stakeholders, a good process should also envision and handle implicit requirements as best as possible.

For software, most of the times (unless explicitly stated by stakeholders) implicit requirements would include performance, security, maintainability, extensibility and re-usability. Some of these implicit requirements are always in a balance with others. (The most common battle is between maintainability and extensibility versus performance). A good process should not aim for perfection in the satisfaction of these implicit requirements but for the best tradeoffs.

Characteristic

This is probably the single concept for which the metaphor works well enough. There are however many views of architecture as a characteristic of a software system.

I will present my favorite one. I’ll start by quoting Martin Fowler who is quoting Ralph Johnson (a post on the Extreme Programming mailing list) in one of the most famous articles of Mister Fowler – “Who Needs an Architect?”

“The RUP, working off the IEEE definition, defines architecture as “the highest level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.”

Johnson responded:

 

I was a reviewer on the IEEE standard that used that, and I argued uselessly that this was clearly a completely bogus definition. There is no highest level concept of a system. Customers have a different concept than developers. Customers do not care at all about the structure of significant components. So, perhaps architecture is the highest level concept that developers have of a system in its environment. Let’s forget the developers who just understand their little piece. Architecture is the highest level concept of the expert developers. What makes a component significant? It is significant because the expert developers say so.

 

So, a better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture’. This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers”

 

This would be a better definition because it makes clear that architecture is a social construct (well, software is too but architecture is even more so) because it doesn’t just depend on the software, but on what part of the software is considered important by group consensus”

What I first like about this view, besides the fact that it completes the R.U.P. definition by adding something vital – the observer, is that it puts the expert developers in the observer role. Architecture, as a characteristic of a software system, was always intended and used as a technical characteristic. Given this, who else would better understand the technical characteristics of a software system then the expert developers that built it?

Secondly I like the fact that it highlights the subjectivism of architecture. Architecture is a structural characteristic of a software system but it is only about the significant components and their relations. It is up to every team to decide what is significant and that will be the architecture of the system they are building.

Two development teams may develop two independent systems using a very similar structure. However the visions of significant might be different in these two teams. Hence the architectures of the two projects are different even if an external observer might be tempted to say that both projects have the same architecture.

There is also something in this view that I would argue about:

Architecture is not necessarily a social construct. It is not necessarily met by group consensus. Well, ideally it should be. But sometimes it is not.

Think about projects developed by a single person. That person thinks about the structure of the system and has a perception on the components and relations that are significant. Doesn’t that system have architecture? It does.

Does it need to work?

This is the real question. Why do we need a metaphor to describe the software design as culture, process or characteristic? The domain to which we suggest a resemblance using this metaphor does not use other metaphors to suggest a resemblance to other domains.

Probably one of the reasons for which it has been introduced in first place was that software was (and still is) such a new culture that its fragility was always a question. People felt more comfortably to use this metaphor in order to make a comparison to a more mature and robust discipline in order to feel safer by association.

But the truth is it doesn’t help. Most of the people that have potential and skills in software domain do not understand anything about the domain to which the metaphor suggests a resemblance. Hence this metaphor is mostly causing fuzziness rather than clearness. We have been using comparisons to more mature fields in order to increase the feeling of robustness on our culture but the effect tends to be just the opposite: increasing the fragility.

Why can’t we just call software design “software design”? At least until a better name will be found. The word “Design” is not a metaphor…

Eric Evans draws a great conclusion in his “Software is (not) like that” article: “Let software be software!”