I've observed fundamental differences between struggling with the overall stability and performance of a production ERP system and trying to optimize the output quality of an AI model in my side product. Years of experience in system architecture and operations have given me a different lens when approaching AI solutions. Both roles require building complex systems and solving problems, but their approaches, focus areas, and challenges are vastly different. In this post, I will examine the anatomy of these two roles based on my own experiences.
As a system architect, I typically have to consider a wide spectrum, from the very bottom of hardware and software layers to the end-user interface. Network topologies, server infrastructures, database optimizations, and application integrations are my daily bread. However, on the AI solution architecture side, the problem space shifts. While the underlying infrastructure is still important, a large part of the work revolves around concepts such as data quality, model selection, prompt engineering, and the reliability of outputs.
The Depth of the System Architect Role
For me, as a system architect, the work often begins in the invisible layers. When designing a company's network architecture, I need to consider every detail, from VLAN segmentation to firewall policies, routing decisions, and VPN topologies. For example, in a client project, when I defined different VLANs to separate production and office networks, sometimes even network engineers could overlook details. This is where switch hardening techniques like DHCP snooping and DAI come into play. Incorrect cabling or configuration can cause a switch loop in seconds and paralyze the entire network. Last year, on April 28th, an entire production line stopped for an hour due to a wrong port configuration; the root cause was a simple Spanning Tree Protocol (STP) error.
