IT Architecture: From Monoliths to Microservices and Systems Thinking
The shift into architecture often isn’t planned—it emerges from project growth. When one team can no longer handle the load, and decisions must be sustained for years, a developer naturally evolves into an architect. Philippe Delgado, a fintech architect, began in the 90s with system maintenance; just six months after his first job, he took full ownership of the project. This forced him to think beyond immediate requests and focus on long-term evolution.
Higher education provides a foundation for managing complexity: math teaches abstraction—moving from ideas to implementation. While universities rarely teach architecture directly, they cultivate systems thinking. Books by McConnell, GoF design patterns, and Fowler’s work lay the groundwork through refactoring and code structure.
Conferences like Highload++ since 2007 bridge theory and practice—discussions with developers across different tech stacks reveal the gap between ideals and reality.
The Architect’s Role in the Team
An architect is a role of coordination, not just a title. In the 90s, chief architects managed global alignment. Today, it’s more about principal or staff engineers—responsible for the entire system, not just a module.
In complex projects like card processing or early versions of Yandex.Money, architects anticipate scenarios, balancing performance and domain constraints. Pride comes from seeing production systems survive real-world stress. Startups teach adaptability, but many never ship.
Key challenges:
- Disconnect between theoretical architecture and real requirements.
- Adapting to change without rebuilding.
- Balancing speed and scalability.
Architects face repetitive tasks, not always delegated. Focus is essential: 2 hours to grasp context, 3 hours to reflect, sometimes days to resolve.
Monolith vs Microservices: Context Determines the Choice
The monolith vs microservices decision depends on project stage and team dynamics. Monoliths suit early stages when one tight-knit team works together. Microservices make sense when requirements conflict and independent deployment is needed. There’s no universal answer—choices evolve as complexity grows.
Architects must understand implementation: a 'beautiful' diagram fails without stack knowledge. A solution architect may skip code, but a software architect needs hands-on framework experience—to foresee implementation costs and risks.
Skills and Tools of the Architect
Systems thinking sharpens through practice—seeing the system from above and multiple angles. Enjoy the responsibility and independence: making choices that impact quality for years.
Dislike turnover: less code, more routine. Switching projects is hard—depends heavily on domain familiarity.
Top skills for mid/senior roles:
- Moving between abstract levels.
- Forecasting system evolution.
- Accounting for implementation cost.
- Managing conflicting requirements.
- Focusing on complex problems.
Books are preferred over videos: text allows revisiting and building linear logic. Videos are great for code demos, but not for deep understanding.
Recommended Reading for Architectural Thinking
For developing architectural mindset:
- Harry Potter and the Methods of Rationality (Yudkowsky) — rationality and probability.
- TRIZ books, e.g., A Month Under the Stars of Fantasy.
- The Prometheus Paradox (Mesterházi) — critical analysis.
- Lotman’s works on semiotics.
- Sun Tzu with Conrad’s commentary.
These texts train analytical thinking unbound by technology.
What Matters Most
- Architecture is about managing complexity, not drawing diagrams.
- Transitioning from coding to architecture happens through growing responsibility.
- Stack experience is mandatory for software architecture.
- Systems thinking improves through practice and reading.
- Monolith or microservices? Choose based on project context.
— Editorial Team
No comments yet.