Architects Architecting Architectures

For years, I have known developers who designed beautiful architectures. A lot of them are questioning the need for a software architect role.

It’s never too much to repeat – What I mean when talking about software architecture is: components, their responsibilities, and relationships.

ARCHITECTURE = COMPONENTS + RESPONSIBILITIES + RELATIONSHIPS 

This questioning may stem from a bureaucracy-intensive process, adopted by “diagrams-only” architects. Fortunately, it is not what I am talking about.

Team roles, work processes, and artifacts could (and should) be analyzed independently. Let’s see:

• Team Role: Architect – A lot of organizations adopt a dedicated position responsible for the software architecture. Some architects DO WRITE CODE; others DO NOT. I have seen both fail and succeed.

• Process: Architecting – There is no code when we are starting a new project. Right? There is a running system when the project is done. Between these two moments, we have a team performing some tasks. Some people will prefer to think about the entire system before to write any code. Some people, like me, will prefer to have an emergent architecture. Anyway, when the software is up and running it is impossible to determine which method was the adopted.

• Artifact: Architecture – Just observing a running system, it is easy to infer a lot about the related architecture decisions (layers, collaboration model, persistence) – every software system has an architecture, even when that one was not properly designed.

So, let’s try to answer some questions:

Do we need someone with the “Software Architecture Role”? 

Sometimes yes, sometimes no! How big is the project? What is the domain complexity? What are the associated risks? The greater the design, complexity or risks, the more necessary will be the presence of an architect. Someone with experience and with some failing histories to share.

How should the architect behave?

Personally, I think the architect should behave as a maestro. The architect should listen to the team, customers, domain specialists, business people, and sponsors. The architect should make explicit the project strategy and ensure that the strategy is respected in all decisions.

PROJECT STRATEGY = COHERENT DECISION-MAKING PATTERN

What about the diagrams? Are they needed?

Yes! They are needed. The diagrams are communication tools. They are important to communicate the architecture to everyone.

Isn’t the code enough?

No, it’s not. Not every people knows how to read the code. The diagrams are not targeted only to the technical team. Like I said before, the diagrams are communication tools. Some diagrams are created before any code. Diagrams could express different levels of detail.

We do not have a software architect role. How to proceed?

For each project, it is a good idea to have someone – with experience – to perform this task. There are people defending architecting as a shared responsibility. I don’t believe in this.

Questions or comments? Let me know your opinion.