System architects – why we need them and what they should be able to do?

More and more companies in the medical technology sector are recognizing the value of systems architects. And this trend will only intensify in the future. I myself work as a freelance systems architect and would like to write today about why, in my opinion, systems architects are needed and what requirements they face.

Why do we need system architects?

The complexity of products and systems is constantly increasing. While in the past a few developers from the areas of hardware, software, and design were enough to develop a product, today teams of over 20 developers or far more are quickly required. Complex and distributed systems are leading to increasing specialization. This specialization is certainly very important today and indispensable for high-quality products. But this is precisely the reason why developers lose sight of the "big picture." While in small projects everyone knows what is being built and how the overall system is supposed to work, this is no longer the case in large projects. Here you need someone who understands the overall system and keeps an eye on the big picture. The system architect is tasked with managing complexity. They assume technical responsibility and look after the overall system. They see the big picture, even if it is a little blurry in one place or another. The specialists in the specialist departments bring this clarity to the table.

Another reason we need system architects is the increasing prevalence of distributed development. Today, development often no longer takes place at a single location, but is spread across multiple sites. The developers are often located abroad and don't speak the same language. The reasons for this are the need for specialization and the shortage of engineers in Germany. A system architect is particularly important for distributed development.

Companies that claim technological leadership require systems architects. A systems architect focuses more on the customer benefits of the product than other roles in a project. Therefore, it is absolutely essential for companies that are technological leaders to employ systems architects.

System architects are mediators between the worlds, and I like to call them "development lubricants." They are the technical caretakers in a project and mediate between the subject matter experts. Therefore, it makes sense to establish the holistic approach of system architects as a specialized skill within a company and utilize the advantages.

What does a systems architect need to be able to do?

Good system architects are not easy to find and are a rare breed. This is partly because the role is not yet as established as, for example, that of a software or hardware developer. It is also because system architects require strengths in various areas. They must possess broad knowledge. This inevitably means that they do not have as deep an understanding of all areas as the respective subject matter experts. However, they must be able to speak the same language, understand the subject matter experts, and clearly convey their points and wishes. In the following, I would like to discuss the points that I believe are important for system architects.

Technology

System architects must have a very strong understanding and good knowledge of technology. Even if your studies or professional career have made you strong in one specialist area (e.g. hardware, software, construction), you must also understand the other areas. This is very important, as a system architect must be taken seriously by the subject matter experts. Otherwise, why would you talk to someone who doesn't understand you anyway? System architects must not be afraid of specialist areas in which you are not yet so strong. Knowledge comes with time. It is important, however, that a system architect also knows their limits and develops a sense of when to hand a topic over to the expert. The system architect is technically responsible for all technical questions and their documentation, which they create themselves or are responsible for, depending on the scope. They are responsible for monitoring the technical results through reviews and approvals.

Methodological knowledge

What a toolbox is to a craftsman, methodological knowledge is to a systems architect. If a craftsman only has a hammer, he cannot solve many problems effectively. The same applies to the systems architect. It is very important for the systems architect to be familiar with development processes. A development process is like a car. If you use it correctly, you can move forward quickly. If you use it incorrectly, you have to push it and would rather be out and about without a car. It is important for a systems architect to know and understand development processes. Background knowledge from standards and laws is also helpful here. It is important that you understand the processes not just on paper, but from practice. Only then can you know whether you have truly understood them.

Another focus of the system architect is to capture and evaluate customer requirements. This can be done by reading and evaluating a specification and the associated reference documents (e.g., standards). There's a lot to read here, and speed reading is definitely an advantage :-) However, it may also be necessary to determine the requirements together with the customer in a workshop. It's useful to have knowledge of methods for determining customer requirements.

The system architect is responsible for formulating the system requirements. To do this, the system architect must understand how requirements engineering works and what to consider. They must be able to describe requirements from a problem perspective as conceptually as possible without overly restricting the solution space.

One of the most important tasks of a system architect is creating the system architecture. A system architect must know how to create an architectural specification and distribute requirements among the components. Knowledge of SysML is very useful for this. It is also helpful for the system architect to have templates and patterns to create the specification. The system architect also takes care of traceability and participates in the testing process. An understanding of testing is very important for this.

It's advantageous if the system architect is familiar with agile methods such as Scrum or Kanban. These methods can be used very successfully in development and have proven their worth. In my opinion, however, one must be pragmatic and consider what is useful for the project and what isn't. The methods must be adapted to the specific circumstances of the project. This requires an understanding of the methods.

Tools and methods often make work easier. Over time, you'll discover tools that simplify or speed up the work. A good systems architect knows tools and methods that are helpful in development (SVN, XMind, www.trello.com, Enterprise Architect, etc.). I'll certainly cover some of these tools in more detail in future blogs.

Soft skills

Soft skills are no less crucial for a good systems architect than knowledge of technology or methods. In my view, they are even more crucial and often the biggest hurdle for good systems architects. The systems architect is a leadership role. Leadership and communication are very important skills that a systems architect must possess. They are responsible for the technical management of individuals and teams. They must understand subject matter specialists and be able to clearly and understand their point of view. In doing so, they must be able to engage people and set goals. They must be able to listen and recognize the needs of the other person. Communication must be active to ensure that what is said is correctly received. To do this, it is a good idea to ask the other person whether they can repeat in their own words what they have understood, or conversely, to repeat what you have understood and whether it is correct. Managing people also requires regularly visiting people and having short conversations ("management by walking around"). I've often found that I'm able to solve people's problems quickly or connect the right people with each other. You can also see very quickly where risks lie or what people are struggling with. This type of management also improves the relationship with the developers. I can't understand it when a manager just sits in front of a computer. You don't get anything out of it and you can't contribute. I've had very good experiences visiting my colleagues from time to time and talking to them. This way I'm always well informed and can help people quickly if they're stuck. I'm usually really productive during my "short breaks" and make progress on the project! Plus, a short walk is good for your back and you can concentrate really well afterwards.

Team leadership is often also about team composition. Here, the system architect should have a feel for what a good team composition looks like and where there might be weaknesses in the team composition. The team does the work, and therefore it is very important to ensure that the team can work optimally. In my opinion, this is still considered far too rarely. What seems obvious to everyone in football somehow seems not so clear in development.

The system architect is also in demand when it comes to communication with the customer, management, or suppliers. In my experience, the system architect and the project manager can often represent each other in this regard. The system architect must be able to represent, present, and explain the system independently. It is important that the system architect can present or simply explain and outline solution ideas.

The system architect must often be able to quickly grasp complex issues and respond to them. They must be able to distinguish between important and unimportant aspects. They must prioritize. They must structure and simplify issues and introduce new perspectives. This allows problems to be identified and contained, or even resolved. The system architect must also be able to make decisions based on their experience and the facts available to them. In doing so, they must consider overarching relationships and the impact on the overall project. These activities often require a great deal of creativity and improvisation.

The ultimate discipline, however, is troubleshooting. As long as a project is running well, it's not difficult to take on leadership responsibility. But it can also happen that a project gets out of hand, or that as a systems architect you end up on a project that's already running into trouble. That's when the wheat is separated from the chaff. These situations are often not easy, and it's hard to stay calm and keep a cool head. I try to stay calm when troubleshooting. I compare this situation to an emergency room where a seriously injured patient is brought in. It's no use if the emergency doctor starts to get hysterical. They have to try their best and use their methods to get the patient back on track. I handle projects the same way. In my opinion, this is the best method for escaping a vicious spiral and getting the project back on track. To do this, however, the systems architect must have confidence in themselves and a high level of self-confidence. Otherwise, they'll be bagged by the next manager.

Organization and planning

This point may seem a bit strange to some. After all, there is a project manager who takes care of organization and planning. But that's only half the truth. The system architect also plays a role. The effort estimation is often the responsibility of the system architect, especially for technically complex systems. The system architect, together with the business experts, determines the effort and creates a release plan (what needs to be available by when and at what maturity level). This data is then sent to the project manager, who takes over detailed planning and controlling. The project manager and the system architect work together on progress monitoring. The system architect also supports the business experts in planning their tasks and coordinates with them. Technical aspects often play an important role in determining the next work packages and the planning. This information is also made available to the project manager.

Developing systems is a lot of fun, and as a mentor for system architects, I'd like to teach the skills necessary for their daily work. That's why I decided to write this blog. I'll be writing about many of the skills mentioned here in my blog. If you're interested in the topic, it's worth checking back from time to time. I'm also looking forward to giving a guest lecture at a university on this fascinating topic in about two weeks. Perhaps I can introduce one or two students to the extremely interesting field in which system architects work. As always, I'm very happy if you would like to share my blog and get in touch with me.

Best regards

Goran Madzar