MEET THE TEAM | RUSLAN BRUMA | DIRECTOR OF NETWORK ARCHITECTURE
Behind every stable and scalable infrastructure, there are people who think beyond configurations and technologies. People who see the network as a living system, constantly evolving, where every design decision has a long term impact.
In this edition of Meet the Team, we introduce Ruslan Bruma, Director of Network Architecture at ITcare. We talk about his journey, the real challenges of network architecture, and the principles behind building infrastructures that are stable, predictable, and ready for the future.
For those meeting you for the first time, how would you describe your journey and role at ITcare?
Over the years, I’ve been deeply involved in designing and scaling network infrastructures, which naturally led me into an architecture-focused role. Today, at ITcare, I lead a highly skilled network engineering team, working across a wide range of complex environments.
What I really enjoy in my role is the exposure to diverse infrastructures and multiple network vendors. It keeps things dynamic and constantly challenges me to think beyond a single approach.
I also value the collaboration aspect, brainstorming designs with the team, solving complex issues together, and turning ideas into practical solutions. At the end of the day, the most rewarding part is seeing those solutions working in real environments and knowing we’ve made our customers’ networks more stable and reliable.
When designing a network, business goals, operational simplicity, and technical constraints often compete. How do you approach architectural trade offs in such situations?
I always start with the business goals, because the network exists to support the business. The architecture should enable what the organization wants to achieve, whether that’s growth, reliability, or faster service delivery.
At the same time, I try to anticipate future requirements. A good network design should be flexible and scalable enough to accommodate new demands without major redesigns.
Operational simplicity is also key. The best architecture is not the most complex one, but the one that is reliable, predictable, and easy to operate.
What are the most common design issues you encounter in customer infrastructures?
One of the most common issues is the lack of clear separation between network layers. Over time, devices designed for specific roles often get repurposed, for example, core routers (P) being used to terminate customer connections like PE devices. This usually happens as networks grow organically, but it introduces unnecessary complexity.
Another frequent issue is large Layer-2 broadcast domains relying on STP with custom costs for load balancing. Yes, believe it or not, there are still networks out there running like this 🙂. While it may seem to work at first, it usually turns into a fragile design that is difficult to troubleshoot and even harder to scale.
Finally, control plane security is often overlooked. Many environments only restrict SSH access but leave other protocols exposed. With modern attack vectors, protecting the control plane is critical to maintaining network stability and resilience.
What recurring mistakes do you see when infrastructure is designed without a long term vision?
One of the biggest issues is missing or poor documentation. When networks are small, a few engineers usually keep everything in their heads. As the infrastructure and services grow and teams change, that knowledge disappears. At that point the business becomes vulnerable, major outages become harder to diagnose and recovery can take much longer.
Another common problem is short-term network design. Many infrastructures start with a design that works for day-one requirements but doesn’t account for future scale. When new business needs appear, engineers are forced to add new protocols or technologies on top of the existing design, which often leads to hardware limitations and costly upgrades.
The most challenging part is not even the upgrade itself, but migrating live services to the new infrastructure. That process carries operational risk, financial cost, and sometimes even the potential loss of customers.
Many infrastructures work well at small scale but fail as they grow. What design choices most strongly influence long term scalability and stability?
The biggest factor, perhaps not surprisingly, is having a good team of engineers. Even the best architecture on paper won’t scale if there isn’t a team capable of maintaining, evolving, and challenging the design as the network grows.
In practice, scalability comes from a combination of strong architecture, clear standards, and engineers who understand the long-term impact of design decisions. Networks evolve constantly, so having the right people who can adapt the design while keeping it simple and stable is just as important as the technology itself.
In your view, what sits at the foundation of a well designed network architecture? Standardization, documentation, and automation.
Standardization ensures consistency across devices, configurations, and topologies, making the network predictable and easier to operate. Documentation captures the design decisions, operational procedures, and infrastructure knowledge so that the team can maintain and scale the network even as personnel change.
Automation ties it all together by automating repetitive tasks, configuration deployment, and monitoring, teams reduce human error, speed up operations, and make the network more resilient to growth and change.
Together, these three pillars, ensure a network is scalable, maintainable, and ready for the future.
When you review an existing network, what signals immediately indicate deeper architectural problems rather than isolated misconfigurations?
One of the most obvious indicators of deeper architectural problems is when devices are deployed outside of their intended roles. For example, routers acting as switches, or switches handling routing functions. A common case I see is a Layer-3 switch in the core handling thousands of BGP sessions and OSPF adjacencies. While this may work temporarily, it inevitably becomes a point of failure as the network scales.
Another frequent issue arises from inappropriate hardware choices. Using switches designed for data center spine roles at the leaf layer, or vice versa, often leads to missing features, unexpected behavior, or performance limitations.
These misalignments are rarely accidental. They typically indicate a network that was not designed with proper layering, scalability, and role definition in mind. Forcing devices to operate outside their intended function increases operational complexity, complicates troubleshooting, and makes the network fragile as it grows.
Where do you see automation fitting into modern network designs, and at what stage should it influence architectural decisions?
Automation is no longer an afterthought, it’s a core part of modern network design. It should influence architectural decisions from day one, not just after the network is deployed.
By designing with automation in mind, teams can implement predictable configurations, standardized templates, and consistent operational workflows from the start. This reduces human error, accelerates deployment, and makes scaling much easier.
Automation also drives architectural choices such as device selection, modular topologies, and clear separation of roles. Networks built for automation are inherently more repeatable, auditable, and resilient, and they allow teams to adapt quickly as business requirements evolve.
Network technologies evolve constantly. Which architectural principles remain stable regardless of vendor or technology shifts?
Simplicity is one of the most important. Simple designs are easier to operate, troubleshoot, and scale.
Another key principle is a clear separation of roles within the network. Devices should operate within well defined boundaries. For example, core routers, MPLS P and PE devices, or data center roles such as leaf, spine, and border leaf should each serve a specific purpose. When these roles are clearly defined and not mixed, the architecture remains stable even as technologies evolve.
Standardization and documentation also remain fundamental. Consistent design patterns and well documented infrastructure allow networks to evolve without creating operational chaos.
What is the professional principle that guides you regardless of the project or context?
Design and build networks so they are stable, predictable, and resilient. If the architecture is solid, you should not have to worry about the phone ringing at 2 am.
What distinguishes an engineer who thinks like an architect from one who focuses mainly on device level configuration?
Designing the right architecture and choosing the right hardware for it.
Outside of networks and architecture work, what helps you reset and disconnect from technical thinking?
For me, the best way to disconnect is spending time with my family and traveling together. It’s a great way to step away from the technical world and recharge.
I also enjoy riding my bike. It helps clear my mind and reset after long hours of technical work.
