On Architecture

Architecture is about understanding.

I am reposting a post I wrote back in October of 2011.

Architecture is about understanding. This is a realization I have come to after wrestling with the question “what is architecture?” for quite some time.

I have worked in IT for over 15 years and there is no clear or common understanding of what exactly architecture is. It doesn’t help that we have a vast array of different types of architects, such as software architects, system architects, data architects, network architects, infrastructure architects, application architects, integration architects, server architects, business architects, process architects, enterprise architects, … and that’s not even an exhaustive list. These different types of architects span vastly different areas within an enterprise. What do they have in common? What is it that makes them architects?

The most common approach to make sense of architecture is to compare it with “real” architecture, i.e. building architecture. In the construction world, an architect is the person who is responsible for the overall solution, the one who creates the drafts and blueprints for what is going to be built. Drawing parallels with the field of building construction is tempting because we understand it (or at least lay people think they understand it). However, architects within an enterprise are not limited to only creating new “buildings”. Within IT our “buildings” don’t stay the same, they change all the time. Since software is the building material it is possible to make just about any kind of a change. This is a double edged sword, with incredible flexibility also comes the ability to create very complicated systems.

Taking the changing nature of the IT “buildings” into account and it turns out that city planning may be a better analogy. The city planning analogy is also a common approach to explain IT architecture. A city with its buildings, roads, electrical grid, water mains, and neighborhoods continually change over time. A city might not change as quickly as IT systems within an enterprise but it does change and the City Planner plays the role of the architect.

But whether we talk about building architects or city planning architects, we still haven’t talked about what exactly architecture is? We have some idea about creating architecture which is typically captured using blueprints or city plans. In the IT world architects create diagrams. So a simple interpretation would be that architecture is creating pictures to describe something. The important point is not that a picture is created in and of itself, but rather that it is created in order to describe something. A picture or a blueprint is just a more effective means to describe something than writing. Clearly using pictures is not always the most effective way or you would be looking at one right now … but there is truth in the saying “A picture is worth a thousand words.”

To just describe something does not in and of itself add any value. Documentation for the sake of documentation is a waste of time and effort.

The reason architects describe something is to make it understood by many different people so they can work together on accomplishing a shared goal. This is the value of architecture, it captures understanding.

To sum it up. An architect creates architectures, consisting of pictures, diagrams, models and descriptions, to describe some thing so multiple different people can share the same understanding in order to work together towards a common goal. The thing being described will materially affect what kind of architecture is best suited to create shared understanding for the people involved. The people involved, the audience, will also materially affect what kind of architecture is best suited to create shared understanding. Using a highly technical blueprint drawing is meaningless if the audience is a buyer who has never seen a blueprint before.

The goal of architecture is to create shared understanding.

Leave a Reply