Why is it so hard to talk about Architecture?

Through my experience in the program I have revised various software literature about architecture. And I have noticed tremendous advancement in the area of Software architecture and a huge effort to unify concepts. However, I have also perceived that software architecture is still young field of study. That is not yet well spread in many parts of the world.

My opinion is that the majority of the ambiguities in software architecture are mainly caused by the following factors: vocabulary, representations, abstractions levels and unawareness of factors that impact architecture.

Vocabulary

Vocabulary is important for communicating in any area of study. However, in this abstract world an architectural term could mean thousand words, just think in architectural pattern name and see how many words you can write about it. Having said that now just imagine an architectural discussion with several colleagues interchanging hundreds of these types of loaded terms. What is the possibility at the end of the meeting that the participants are in the same page? The point I want to make is that we need to be careful with the terminology we use. The architectural flaws have proven to be really expensive when these are caught at advanced stages of software development [Watts Humphrey]. So it will be worthwhile agreeing in terms and definitions as the SQUARE process does in its first step [Nancy Mead].

Here are small examples of some terms I find to cause confusion:

o What is the difference of these terms Software Design, Detailed Design and Software Architecture? Isn’t the size of the system affect meaning of these terms?

o MVC Pattern – Does this means the same thing to everyone? If you were going to express this pattern would it be in static perspective or dynamic perspective?

o Layers vs. Tiers – Are these the same? Why people used them interchangeably?

Seems like in different part of the world in both industry and academy there are continuous effort trying to come out with the most popular architectural dialects. As future software engineers we should be aware of this reality and be aware that when we go out there we should be careful how we communicate and introduce terms, because as in any change there will be resistance. Note that more important than the term itself, we should be worried about the meaning behind it. We see this clearly with the quality attributes names like reliability, maintainability, and which could mean anything if not defined.

Representations

As seen before, terms in the context of software architecture could mean thousands words. So, what can we expect about pictures or graphics trying to represent aspects of a system? My answer would be, even more implicit words than terms. As mentioned by Tony Lattanze in his book Architecting Software Intensive Systems, a picture could mean thousand words, but it will not be the same thousand words for everyone. That is why I consider representations a huge source of ambiguities when communicating architectural topics.

To help solving these ambiguities, it is important when providing graphical architectural representations that these should be accompanied with good legends specifying the different elements in the picture and their relations. However, this is not enough we should always write explanatory prose to complement and explained any underlying assumptions and responsibilities of the elements. Another important part when presenting documentation is to explain what is the perspective of this diagram and make sure the perspectives are use consistently.

It should be easy to determine whether it is it static, dynamic of physical perspective? Knowing the perspective of the provided structure is critical to know what properties of this structure assess when revising the diagram. For instance, knowing that a diagram is in the dynamic perspective will help reasoning of attributes such as performance and availability, which is not possible in the static perspective.

Abstractions levels

The nature of software is already considered abstract. And making abstraction of something that is already abstract is challenging. This show us that software architecture is not easy, and it is even harder if we do not speak the same language.

It is also important to know that additionally to perspectives to reason about structures. We also have within perspectives different levels of abstractions. These levels of abstractions are used to remove unnecessary details, which facilitates the reasoning about certain properties of the structure in context.

For instance just think in Google earth we can see the planet earth at different levels such as continent level, country level, city level and even street level. As you zoom in you will get more and more details. We can thing of this as abstraction levels when comparing this when representing the structure of the system. The problem in the architecture world is that we do not count with the “altitude” which helps Google earth to maintain consistent levels of abstraction. Knowing what is the “altitude” of our models is one of the biggest challenges to keep a consistent level of abstraction. Mixed perspectives and mixed level of abstraction is a huge source of ambiguities.

Factors that can impact architecture

I consider this point very important because, even before the project is conceived there are many decisions made that will have considerable impact in the final architecture and therefore a big impact in the project. If upper management knew a bit more how can business decisions such as deadlines, resources and team collocation affect architecture they will include an architect from the creation of the business case. However, in the majority of the cases there is not much to negotiate with the business that is why these are thought as constraints, but at least showing red flags at the beginning will contribute to avoid big surprises later. I do believe that a good management will appreciate knowing this upfront.

Another, type of decisions that have huge impact are technical constraint, generally seeing when there is the need for integrating with existing systems. Also, it happens a lot that companies constraint their self through technology selection. It is important to be aware that this decision will have an impact in the final structure. We should be critical about what quality attributes the selected technology will inhibit or promote and see if this is aligned with the system goals.

In short, it is obvious that requirements and quality attributes will affect the architecture, but is not always obvious that business and technical constraints will.

As mentioned by our architecture professor Tony Lattanze these are like loaded bearing walls because they are constraint and are not negotiable having a huge impact in architecture, so we should be aware these and communicate their importance at early stages of the project.

In conclusion, knowing the critical roll of software architecture in software projects and also knowing the high probability of miscommunication when communicating it due to factors mentioned above vocabulary, representation, level of abstraction and unawareness. As Abin mentioned in his post is crucial to be proactive to and try to surface ambiguities. I will recommend focusing in these areas because they a huge source of misunderstandings.