IT Architects – do we really need them?

The role of the IT architect appeared in Poland broadly just over 10 years ago. In my career, I have had met different kinds of architects: enterprise, solution, infrastructure, systems, security, integration, business, data, domain and cloud architects. Do we really need them all? Do architects provide something of value, or are they only expensive pictures painters? These questions continue to arise, and increasingly.

What is the role of the architect?

There are probably as many descriptions of the architect role as there are organisations, or perhaps even as there are people in organizations. I do not want to go into the details of particular types of architect, but rather focus on what is most important in the role of an architect.

In my opinion, in any organisation, small, medium, large or huge, someone always acts as an architect, perhaps without even knowing it. This happens for a simple reason – someone is always making decisions about how to solve business problems, in other words what should the architecture of such a solution look like.

Simon Sinek wrote the book "Start With Why". The problem of recent years is that everyone took this advice to heart and too literally. Anyone at any moment can ask questions about the sense of doing something, and it is very difficult to imagine a more unconstructive behaviour than repeatedly challenging assumptions (undermining their legitimacy) after 4 months of analysis. On the other hand, the question “why" is actually the most important question an architect can ask at the beginning of her work on a problem. It is impossible to think of a good solution to a problem (unless it is an accident), if you do not understand the problem well. In particular, "I need a system" is not a well-defined problem. According to the Ishikawa concept, it should be enough to ask the question "why" 5 times at most (and receive a satisfactory answer) to get to the core of a problem.

What distinguishes an architect from an analyst? The way of thinking. An architect should synthesise more than analyse. She should draw general conclusions on the basis of detailed analysis. She should think broadly and forwardly; broadly means in the context of all currently ongoing and planned changes; forwardly means predicting the future in which the designed solution can still be used, and in particular, how the solution will be ready for change, because as we know the only constant is change.

A good architect should not be seen as someone who tries to force organisations to adopt expensive technology because it seems nice. In particular, an architect should be the one to say that certain processes should not be automated because it would not be profitable.

What is crucial for an architect?

To be successful, an architect needs one thing – credibility. As everyone knows, credibility is extremely difficult to build, but it can be lost very quickly. There are many methods to build credibility and everyone does it a little differently, but there are some common elements among the major approaches.

First of all, an architect must know what they are talking about. This does not mean that she has to be the best specialist in a given technology, in claims management or in the investment banking. Rather, she must understand the essence of the subject she is dealing with – otherwise he will be treated just as a necessary evil.

The degree of individual hard competences (knowledge of a specific technology or business) depends largely on the type of architect we are talking about. Soft skills are key, however. One of the crucial tools of an architect is dialogue. Without having a dialogue, it is not possible to receive an answer to the question "why", or explain and convince customers about ideas and concepts; architects get stuck in their ivory tower.

The additional important element in architect’s toolset is keeping one's word and delivering value. These two matters are absolutely essential, especially at the beginning of cooperation. Talking unrealistically and not being able to demonstrate reasonable outcomes mean that an architect will be pushed aside.

Who really needs architects?

As already mentioned, each organisation has architects, even if they are not aware of their role. When an organisation grows, aware owners recognise the moment they cease to be involved in everything that happens, and the complexity of the work begins to grow faster than the size of the organisation. Unexpected problems start to appear and decisions have many more dimensions than before – a signal that there is a need for tools to ensure that such complexity can be managed. It is also a signal that apart from the people who manage the organisation operationally, people are needed who can and even must break away from operational issues and manage the organisation conceptually and strategically.

Importantly, if an organisation decides to have architects must choose to trust them and pass on the relevant decision-making powers. Otherwise, almost certainly the organisation will fall into one of the most common pitfalls.

Pitfalls awaiting architects

The pitfalls that await architects, as in life, are many. The most important of them is called the ivory tower syndrome – a detachment from the rest of the organisation and from reality. The organisation often creates this situation (and more specifically its managers) itself. An overview of job advertisements for architects shows that there is one element of responsibility that appears in all adverts – a definition of architectural standards and compliance with them. At first glance, it sounds very reasonable – if you want to do something effectively, especially in the long term, you need to do it in an orderly way. In the end, experience suggests that a conveyor belt is cheaper than a craft workshop. However, if you put standards in first place, the architect’s work immediately becomes antipragmatic.

The primary goal of the architect should not be nicely arranged architecture. Nicely arranged architecture can be one of the means to achieve an objective, which must be the goal of an organisation. If an organisation is a commercial company, the goal will be associated with generating the greatest profit. And, of course, a broad and long-term architectural view will always beat a cheap solution. But without the ability to justify a solution and link it to the objectives of the organisation, an architect will begin to lose credibility.

The other pitfall affecting the credibility of an architect, especially an IT architect, is becoming cut off from the home organisation (i.e. IT). An attempt to cut away from the IT delivery that provides a solution and having the attitude that if they cannot cope with it then it is their problem generates the question - what is the point of having such knowledge. In business organisations, most people are involved in operations and their time is valuable (it is never enough). A business that presents a problem expects achievable proposals to solve it. Cutting oneself off from implementation issues can effectively kill the credibility of an architect – “I have lost a lot of time talking with architects and nothing come of it, beyond pretty pictures, which is not what I wanted”.


In summary, the role of the architect, a good architect, is difficult, challenging and often generates a lot of frustration. In the articles yet to come I will try to explain how an architect should deal with different roles in an organisation - the management board, project managers, developers and administrators.


IT, architect
Paweł Kot

Paweł joined ITMAGINATION in November 2016 after leaving PZU Group where he held the role of IT Architecture Director. In ITMAGINATION he focuses not only on insurance but on the whole financial industry acting as Enterprise Architect and Product Manager responsible for the product portfolio for FSI clients.

Would you like to learn more? Contact us.