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.

Architecture and Communication

My post today is going to talk about how software architecture can be a vehicle of communication.

What is Architecture?

Wikipedia defines architecture as the structure or structures of system, which comprise software components, the relationships among those components, and the relationships between them.

When software engineers think architecture, they primarily think of architecture and documentation and diagrams of the above-mentioned structure. And the popular “architecture” sites support such notions.

For example, Wikipedia lists the Common language infrastructure architecture as this:

The documentation suggests that all the code of the different languages get compiled to Common Intermediate Language. However, it does not say some significant things: Does the compilation support the full-fledged language or does it apply restrictions on the languages for compilation? Can the languages communicate with one another? And most importantly, what quality attributes does this architecture support, and why?

Any such diagram can raise these questions, and it is important that the development team is knowledgeable about the answers. Without architectural knowledge, the team may not have a good big picture view of the system.

This "lack of big-picture view" happens in both small and big companies. Roni Burd, a program manager at Microsoft, discovered this issue with his Bing development team. He had to take action to raise the architectural awareness of the team. I have noticed this also at my new job, where the software is too large to comprehend without proper architectural perspectives. Without good architecture documents, the team members each get familiar with parts of the system, but no one can really talk about the system as a whole.

It is the architect's job to ensure that the development team is adequately knowledgeable about the answers to these questions. S/he can share this knowledge through documentation or architecture workshops or through any other means.

We used the following activities in Spring and Summer to raise architectural awareness:

ACDM architecture reviews:

We conducted architecture reviews throughout Spring. In these reviews, the architect would present a partitioning of the system, and explain the rationale for that partitioning. Then the team would raise and record issues with that partitioning.

What we could have done better:

We should have been more upfront about giving feedback on architecture. We all had different ideas and impressions on the architecture, and we could have done a better job at harmonizing those differences. We could not relate how the pictures and diagrams of the architecture related to the actual product. If we implemented parts of the application, that would have given us a concrete mental model of how the architecture and the actual software were connected. With that mental model, we could have been better at communicating our differences of opinion about the architecture.

Architectural documentation:

Architecture documentation was our key way to communicate in Spring and Summer. These were up-to-date diagrams of the system, with design rationale relating them to the quality attributes.

What we could have done better:

Since we were implementing the product in summer, we could have improved architectural communication by printing out the architectural diagrams and posting them in the cubicle. This would have allowed the team to question and verify the architecture as they were implementing the system.

Topic of the week:

We did have some verification of the architecture at our 'topic of the week' sessions. 'Topic of the week' was our way of addressing misconceptions. Each week, at the status meetings, we budgeted some time to talk about a topic that we needed to communicate across the team.

At the architecture sessions, we addressed the following questions: how the architecture decomposition related to the implementation, and how were the quality attributes supported.

What we could have done better:
We could have addressed more architectural topics. There were questions on how did our package structure relate to our static architecture, and why were packages decomposed the way they were. These could have been better addressed early in the project to clarify the responsibilities of each package. That would have reduced some architectural refactoring work.