Introducing system architects into the company

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 how systems architects can be introduced into the company. Good systems architects are not easy to find and are a rare breed. It makes sense to establish the holistic approach of systems architects as a specialized skill within a company and utilize the advantages. But how do you do this, and what should you consider?

If you are reading this article, you are probably already familiar with the role of the system architect. If not, please be sure to read the article System architects – why we need them and what they should be able to do?

The system architect is a role in a development project, like a software developer, a tester, or a project manager. The role can be filled by a single person. However, it is also possible for a single person to represent multiple roles. For example, the software developer can also be the requirements engineer, or the project manager can also be the system architect.

To clarify the role of the systems architect for your company, it's a good idea to create a job description. What are the responsibilities of the systems architect in your company? Discuss the role description within your company. Development managers, team leaders, project managers, quality managers, and people who have already gained experience in this area or are already performing similar activities can provide valuable input. You can also find information about this online (e.g., on my blog).

In the project, I see three roles at the same level. These are the project manager, the system architect, and the quality manager. These three roles pursue different goals, but they complement each other very well:

• Project manager → Project goals
• System architect → Product goals
• Quality Manager → Process Goals

Introducing system architects into a company is a learning and change process. Changes often lead to resistance within the company. What is the point of this role? We haven't needed it for the last 20 years, so what's the point? This skepticism can come from management or even from experienced developers. And in principle, a healthy skepticism isn't a bad thing. You don't have to follow every trend. But if you're convinced of the change, it's important to engage employees and bring them along with the organizational change. There's nothing worse than organizations and processes falling from the sky and suddenly being expected to be followed. In most cases, this doesn't work or is very difficult. Therefore, it's important to communicate your plans early on and also to seek and consider the developers' opinions. When implementing changes, it's important to proceed in small steps and not change everything at once. You should focus on the benefits and proceed in many small steps. It's best to initially deploy a system architect in a pilot project. It shouldn't be too big or too small, and it shouldn't already be under a lot of pressure. A troubleshooting project isn't suitable for such experiments. In that case, you should appoint a systems architect. If this person doesn't have sufficient experience, it's a good idea to assign them a mentor. A mentor is someone who already has experience in the field and supports the mentee. The aim of this support is to help the mentee get to where the mentor already is. In comparison, a coach is something completely different. A coach supports someone in self-reflection and self-improvement. It is essential to ensure that the mentor has experience in this area.

The following is about applying the methods and generating work results. Not everything will run smoothly at first, but you should master the introduction of system architects in your company step by step. Take your time and work on continuously improving. If you are introducing tools (e.g. ALM tools, requirements engineering tools or SysML tools), be aware that implementing tools also takes time. Be sure to plan for this. Especially in the beginning, you will slow down and have to go through a learning curve. It takes time for the tool to make you faster. Also make sure that the tool suits your process and not the other way around. There is no point in using a tool that hinders you rather than supports you in your work. It may then be the wrong tool or it may need to be configured differently.

In connection with the introduction of the role of system architect, I can only appeal for further training within the company. Exchange sessions, in which keynote speeches are given and mutual training takes place, are a good option. Standup meetings in the style of Scrum (5-10 minutes daily) are also a good method for exchanging and sharing knowledge within your company. This can be a forum for exchanging experiences. It is also useful to define keynote speakers who are knowledgeable in a topic. Such people exist in every company, regardless of whether they have been appointed or not. It is important to only select people as keynote speakers who truly deserve the name and are recognized as experts in this area. Otherwise, the keynote speaker method quickly becomes a farce and falls asleep. Keynote speakers are also required to actively pursue further training in the field, document knowledge, and help others with problems.

Documented knowledge can be in the form of presentations, instructions, wiki pages, video tutorials, or blogs. You can also simply create best practice templates or be available to answer questions and help others (like during office hours). I think there are a multitude of opportunities for continuing education these days. From books, audiobooks, blogs, podcasts, webinars, and YouTube videos to courses and training. Networking with other system architects (e.g., through Systems Camp) or Xing can also provide valuable inspiration.

If you have any questions about this topic, I'd be delighted if you'd contact me. Feel free to send me your questions, and perhaps I can share the answers with others through the blog. I welcome feedback. You're also welcome to leave a comment on the article. If you know someone who might also be interested in the blog, I'd be very happy if you'd recommend it.

Best regards

Goran Madzar