Role of the Application Architect

“Architect” is one of the buzzwords sometimes used just to name an important person working in the software development department. In other cases, we will only call this way people who understand how given software works. For some people it will be another level of software developers’ career ladder. Sometimes the word ‘architect’ describes a person who draws lines and rectangles on whiteboards.

All in all, saying „architect” most of us does not actually know what they want to express.

In this article I will try to provide classification of architects’ roles and describe one of them more deeply.

Not just one type of architect

There is a great number of words that specifies Architect e.g. Enterprise, Systems, Software, Application. However, a lot of books and articles define those roles differently and sometimes those definitions are mutually exclusive. To provide context for further considerations, I’d like to present a simple model of architects classification.

These roles differ from the point of view of abstraction level used to perceive software. The names listed below may vary depending on the source.

1. In large organisations, with their own systems supporting external processes, there is a role of Enterprise Architect. This person looks globally on systems within a company and helps to design business processes. Then, he selects the best software to support those processes or determines the development of dedicated solution. This role requires some technical knowledge, but the most important thing here is the ability to understand business needs of the organisation.

2. Going down in our ladder of abstraction, we come across a position of Systems Architect. A person who designs the interaction between systems, imposes restrictions on the use of platforms and tools. What is more, he sets global standards shared between supervised systems. This ensures that all solutions, usually composed of many infrastructure elements and software, works well with each other.

3. Reaching the bottom of the architects’ ladder, we can notice that architect’s role is starting to mix with programmer’s one. Rectangles, which sometimes appear on the boards can be more frequently transferred into components, libraries, layers or even classes and methods. Application Architect or Software Architect is a person usually operating within a scope of one application (system). His main task is to monitor the whole system, understand all interactions between components on a given level of abstraction, as well as to define limitations and requirements for source code.

As I have already mentioned it, this is just simplification. My goal is to show that saying “architect” in terms of software development is not enough. There can be multiple architects with different responsibilities in one organisation. Also the same type of architect can do different things in different organisations. This probably is the source of most of ambiguity when it comes to the word “architect”.

Closer look on Software Architect

The above paragraph discussed perspective of companies whose business requires software development, but do not sell it. As in an outsourcing company, here in Future Processing we develop software for our clients. Sometimes, this is a single application, sometimes an entire solution, consisting of smaller projects, for a particular company. This means that architect roles, with the most abstract look on project that require constant cooperation with business, so Enterprise architect, are usually covered by our clients. The roles that are closer to development, such as Application and often Systems Architects, usually lays on our side.

I observe Application Architect role is heavily debated, how it differs from senior developers, where his responsibility start and ends. For this reason, I’d like to devote the rest of this article to my vision of that role based on over 20 years of experience of Future Processing.

What does architect know?

As I have mentioned before, the primary responsibility of the architect is a holistic look at the system. He knows things such as:

• What are the non-functional requirements to the system and how does the architecture reflect them,
• What are the stakeholders development plans for the application and why the architecture do not hinder this development in the future,
• What components are in the system and what are their responsibilities,
• What are the interfaces and available connections between components,
• What kind of technologies, standards and limitations are used to create the application.

For instance, he can clearly tell where to find a certain functionality of code, as well as which components may communicate with database and how.

What does Architect do with his knowledge?

Understanding the system is only a mean to achieve an architect’s goal, which is to create a technically good and useful software. The second, complementary measure is communication. It is not enough that architect knows something, the remaining team members have to know it too. Their work focuses on the lower level of abstraction and sometimes it is hard for them to see what happens in other parts of the system, or what kind of changes are planned there to implement. That is why we need an architect role to ensure that every developer knows the context and understands influence he has on the rest of the system.

How does the communication look like? Usually, there are the views of architecture in the form of diagrams and of course verbal communication. It is important to understand that the architecture is not diagrams. They are only derivatives from the abstract, multidimensional and multifaceted vision of the system, existing in architects and team members’ minds. They help to express and unify understanding of architecture in a team.

What are other Architect’s responsibilities?

• Architect doesn’t have to or even is not supposed to create architecture on his own. He is supposed to motivate the team for discussion, make decisions regarding architecture and keep the team on their toes.
• He should have a wide knowledge of available tools, popular standards and work techniques. Such knowledge is indispensable to make right, strategic decisions for the project that are difficult to change later.
• He should understand and take into account needs of all roles involved in the project. In particular: end users, the project sponsor, UX designer, programmers, QA etc. Making decision or imposing any restrictions he has to consider their impact on the work and their needs.
• He is able to predict what decisions have to be made immediately, because otherwise it can lead to incoherency and duplication, and which in turn can lead to postponing decisions to the moment that better data are available to take on the more accurate ones. Contrary to popular belief it doesn’t concern only details, but also the most difficult decisions e.g., the choice of the database may be postponed, it only requires suitable abstraction layer for accessing it and some temporary solution. Maybe in 2 months it will turn out that it is enough.
• He should take care of the soft aspects of working in a team: providing a breath of freshness in applied technologies and techniques, mentoring developers in a team, splitting appropriate challenges for everyone in a team.

Summing up deliberations regarding the role of the architect I would like to quote Magnus Mårtensson:

The architect must be part architect, part listener, part organizer, part psychologist, part visionary, part humanitarian, part friend, part leader, part stickler for detail, and always willing to make a critical change in the design while not being a pushover.

Should Architect write code?

Yes. But. The majority of sources screams the architect has to write code and cannot be completely isolated from the implementation details. He cannot be, because he will start to think too abstractly and will try to force solutions which are like chalk and cheese to real problems. He should at least write a Proof of Concepts, which validates approved decisions.

But. To perform well the roles described above, the architect cannot be a fulltime programmer, because he will simply run out of time to take abstract look on the system. It is hard to say what the proportion should be, it probably depends on the size of the project. For medium sized projects I would start with the proportion: 50% operational work e.g., programming, 50% strategic work, and observe which gives more value to the Development Team and stakeholders.

Architect in Agile teams

I imagine that many Agile dogmatists has already clenched their fists in annoyance while reading the above paragraphs. In agile team we do not have division into roles, members are multitasking, there is a collective code ownership. The Team is responsible for architecture and communication, not „archiwhoever”.

I have never liked dogmatism and I know that all the practices connected with agile are just practices and they are not always right. Let’s suppose that we have a perfect agile team with only experienced people. Every member has the same, very good competences, exactly the ones needed in the project. The whole team understands the need for communication and does it perfectly; everyone knows enough about the project and work of others, but does not waste too much time for that. Do we still need an architect in a team? We need a role but not a dedicated person, in this case all team members take the responsibilities of an architect. Everyone knows enough about the current situation. They have appropriate competences to make decision independently and communicate it to others. Architecture grows on its own, step by step, emerging from the homogenous thinking of the Development Team.

However, if we step down to reality, the more diversified team in terms of level of competences, the more communication problems it has and the more it needs a dedicated person in the role of an architect. He should not impose his solutions, but control the emerging architecture, correct the direction of development and be able to make hard decision when the rest of the team does not feel competent enough. He should be a member of the Development Team.

Check out our Architect job offers.