This text is not written with AI nor inspired by what others have said on the Internet. It is a personal and imperfect story.

The idea for this series of articles emerged one day while I was sharing with Anca, our new Marketing Manager, how I came to do what I do, and generally what unites all of us colleagues in the same place, enabling us to perform so well as a team. Maybe clients would like to know as well, Anca said later. Maybe there’s something to learn from all this collective experience.

Career in IT

When I started my career in IT, engineers entered the field out of curiosity and passion. It was this passion, along with the context, that led each person down a different path, as if the Sorting Hat from Harry Potter had spoken. In an IT company, some sought the adrenaline of troubleshooting, others the structure of planning and designing—or simply the ambition of sales. Some were made managers by the corporation. I had the chance to wear multiple hats, allowing me to develop laterally. Thus, I formed a consultant mindset rather than a line management one.

A significant aspect was that neither I nor most of my current colleagues ever worked directly for the end-user of the technology, allowing us to frequently see different technology stacks and ways of doing things. Similarly, like most of my colleagues, I went through a telecommunications company, seeing technology applied on a large scale. In short: a path with exposure, frequent context changes, and structure and large-scale thinking.

On the other hand, our clients are the end users of technology. A competent IT architect or expert wouldn’t constantly work at full capacity, and for the client, it wouldn’t make economic sense. In other words, while it makes sense for a systems integrator to have experts at all stages of the IT lifecycle, it doesn’t make sense for clients.

System lifecycle

To understand the various roles an IT integrator needs, one must consider the system lifecycle perspective. Cisco views it as: prepare (identify objectives), plan (assess initial state versus requirements), design (based on business objectives and technical requirements), implement, operate, and optimize. An architect is involved throughout the lifecycle (plan, build, manage). Although the general perception is that an architect only designs, their role is to eliminate assumptions and bring focus and clarity to the project throughout its duration (what is important and right to do and how feasible it is), both for the business and technical sides. Moreover, an architect must know their options and have experience with them.

An architect works with a temporary project organization but considers the long-term evolution of the infrastructure, ensuring that deviations are kept in check (positioning themselves as a trusted advisor to the client). However, not every project needs an architect. Often, where the project is based on a single technology and requirements are clear, an expert engineer can take on this role. The architect was and still is an expert in one or more areas (otherwise, they couldn’t argue their technical opinions). Where they are not, they rely on the work of other experts, both among colleagues and partners, but still need to evaluate the options.

Architect interaction with other roles

Throughout the system lifecycle, the architect interacts with colleagues in other roles, the longest being with the project manager. Although roles can sometimes overlap, this is a different person from the architect. The architect is the project’s technical leader, while the manager tracks time, budget, and resources (keeping the pace). However, it is the architect’s responsibility to foresee risks, initially estimate costs and resources, and be clear about the order of operations and dependencies so that the project manager knows how to track them. In the operation phase, a service delivery manager will take over the project manager’s role, as the project will be transformed into a process.

The architect interacts with project sponsors to understand objectives and economic constraints, especially in the planning phase. A sponsor is a management person (both from the executor and the client) most interested in the project’s successful execution and who makes important business decisions related to money and risks. Then, starting with the design phase, the architect interacts with technical experts. In the implementation phase, the architect coordinates technical work, understands logistics, and may participate in execution with their expertise. Lastly, they guide necessary corrections in the operation and optimization phase based on feedback from the client and colleagues. Importantly, the feedback loop exists not only in the operation phase but starts from planning! A successful project will involve many discussions before implementation, and documentation should also begin before.

An architect should be able to ask relevant questions, test, synthesize, present, and write. In this capacity, they can assist pre-sales, marketing, or sales activities as needed.

An architect is not an operational manager. The technical team is part of a permanent organization that lends experts or implementation engineers to the project, unlike the project team, which is a temporary organization. Therefore, there is a separate management role for the implementation team. Project managers also have their permanent organization (PMO), just as architects can have (AMO), depending on the organization’s size, the diversity of covered technologies, and the balance between design versus implementation and operational activities. The pre-sales organization doesn’t fully cover architecture either, as it doesn’t follow the entire system lifecycle and focuses more on delivering equipment without being part of a project.

On a final note

If I were to give some advice based on my gained experience, here are a few important ones:

• Don’t assume, ask.
• Be open, don’t ignore information that doesn’t fit or contradicts what you know.
• Always keep the context in mind while looking at details, otherwise, you get lost in the details. Every generation of engineers loves context.
• Ask questions candidly, not worrying about what others might think.
• Don’t set your own limits.
• Theory (courses on how technology works), testing, structured thinking, and order of operations are important.
• Imagine the project in its dynamics and think it through to the end.
• Plan a lot and gather feedback.
• Don’t complicate things (KISS*), know your options, follow best practices. Primarily, the infrastructure should be easy to troubleshoot and extend. If it’s something exotic (corner case), you’ll likely open a long-term case at TAC**.
• Delegate! You won’t be able to do everything yourself and need to keep your mind free for important matters, not micro-management.
• Rely on the team’s experience but continue to be an expert in your area. This applies to juniors too: focus on excelling in one thing before adding the next layer of knowledge.
• Don’t ignore juniors, keep the door open, and invest time to know them. It will keep your thinking fresh.

* Acronym for Keep It Simple, Stupid 

** Technical Assistance Center