About a year ago, I wrote about what a system architect actually does (https://www.arcticstream.ro/blog/role-of-an-architect-in-complex-projects). Since then, after another conversation where I played the role of a mentor wanna-be, I thought it would be useful to also write about how you can become one. Now, thanks to Anca*, you have the link to that first story, it was something with Harry Potter and the sorting hat. Some engineers end up as managers, others as technology salespeople, or… by chance, they eventually become architects. Seriously though, I believe that to become an architect you need at least two things: exposure and leadership. For me, these started with two traits I had as a child: curiosity and the joy of explaining. And of course, a bunch of lucky choices along the way. Let’s see.

The first step is moving from curiosity to exposure. You need to enjoy discovering, to have the chance to solve problems, to learn the theory behind it (books, certifications?) and then apply it. At the beginning, you don’t really get to choose what you learn, you do what you’re asked to do, but it’s important to start somewhere and do it well. After that, opportunities will appear to learn something else and then something more that connects, just like layers of an onion. If you want this and it doesn’t happen, maybe you’re not in the right place (and no, that’s not the case with us, just to be clear). In the early days, my strategy was to move on whenever I felt there was nothing left to learn or no one left to learn from. When does learning end? Never, you’ll never know everything. But building a solid core of knowledge brings confidence and respect. Anyway, you won’t be able to achieve something great all by yourself (unless you’re a genius). It’s about having something valuable to contribute to a bigger whole. Nope, AI won’t replace your expertise, you still need to know what to ask it and how to check it – otherwise, AI is a guaranteed path to mediocrity.

Technical expertise and experience alone are not enough. After a few years, you need to create opportunities to expand sideways, to gain context. In an architect’s career, context is essential, you constantly zoom in and zoom out and you must understand what matters to others. The first natural extension is towards project management. A system is never static: it starts somewhere, evolves over time and during that transformation it faces constraints in people, time and budget—and management has its own theory to learn. The next stop is with the sales team (yup, you need to understand why the project exists and what each stakeholder’s interest is). Cyber security doesn’t hurt either (it’s a different mindset, but useful to grasp). Ideally, you should meet many clients from different industries (you’ll notice both similarities and differences) and take part in large or complex projects (it’s easy to simplify something big once you understand its complexity and failures, but growing something small in the right way is much harder). Bonus: in today’s AI‑driven world, context beats specialized knowledge – every problem has a context you must understand (and AI simply can’t, no matter how much you try to explain it).

Where could you gain exposure? Not with the end user, because of the lack of variety. At an ISP (Internet Service Provider) it’s harder these days, due to the hyper‑specialization of roles. Maybe at an MSP (Managed Service Provider), but there the risk is the operations mindset (work that’s too fragmented, based on tickets). I believe the best opportunities still appear at an integrator. I mentioned mindset: yes, there are several, cyber security, operations (process‑oriented) and project. In case you were wondering why the companies in the group don’t merge: they wouldn’t be as good if they did. Architecture requires a project mindset, less of a process one, focused on integration and understanding the whole picture.

In the end, exposure brings experience and experience improves anticipation (you already know the many ways something can break and how costly a poorly done or unforeseen issue can become – or, as Florin**, says, two well‑placed mistakes). I’ll repeat myself: systems are not static, they start from somewhere (an existing system, some business requirements), they evolve and over time they may fail or fall short of expectations.

The second parallel path goes from the joy of explaining to communication and leadership (I was a shy child, but I loved to explain). As your knowledge grows, you gain confidence and start taking initiative. In meetings, you need to be able to communicate expectations and intentions (as in any partnership), avoid leaving unspoken uncertainties (don’t assume – ask) and listen (you won’t learn anything if you think you’re smarter than everyone else). You must be able to summarize, remove or add details depending on the situation. In writing, you should express the essentials with as few words as possible and with a clear structure (many of us need to unlearn the “word intoxication” we picked up in school). How do you achieve this? With lots of practice, by rereading, checking the structure and focusing on the reader’s interest. What information is expected? Where does the idea change? What do we want from the person we’re addressing? Nowadays, we all struggle with short attention spans and long texts (especially those generated by AI) don’t help. In longer texts (like documentation), the structure usually starts with presenting the context (what is given and what is required), followed by the order in which things are configured. Here, clear diagrams help enormously.

Later, in the role of a technical leader, you need to make sure that all project members share the same understanding (not necessarily agreeing with you, that’s the point, to discover where the disagreements are and why). Communication, writing, and explaining (it helps if you’ve been a trainer) also bring structure to your own ideas and knowledge.

Leadership means nothing more than taking initiative (because you have confidence, because you want to get closer to the final result, because you want things to be done properly)  so, what you need to do at the beginning is to master your knowledge, take initiative and in general, not be afraid to make mistakes, test your ideas by explaining them and admit when you’re wrong (yup, every senior has made some big blunders before getting there).

In conclusion, experience, anticipation (some call it vision), structure, context, communication and leadership are what make a good architect, at least from my perspective. What value does this bring? It ensures that things are done thoroughly (and what clients wouldn’t appreciate?) while reducing risks (which in turn increases profit margins). At the end of the day, I like to believe that I’ve managed to reduce risks.

And if these perspectives have made you curious about how we approach projects and how we can support the development of your data infrastructure, the Arctic Stream team is here for you. You can reach out to us anytime at [email protected].

*Anca Burgovszky – Marketing Manager, Arctic Stream

**Florin Mărginean – General Manager, Arctic Stream