Modern trends and environmental pressures have changed the landscape of information ecosystems, technologies, and those who develop them. But what hasn't changed since the dawn of industries is the role of the Architect. Over time, we have seen a great number of architects: builders, business architects, IT architects, bio-ecosystem architects, landscape designers, and now we've reached compliance architects, cybernetic and AI system architects.
Modern Challenges
Recently, the trend for architects has only grown, while the demand for ordinary rank-and-file engineers (builders, marketers, copywriters, etc.) has sharply fallen. Why? The answer lies in automation and mechanization. And every high-tech enterprise is trying to find the one who will "solve all their industry problems". Even from my memory, many tests and metrics have been invented for choosing the "right architect", and none of them gave any guarantee that the design of the future solution would meet the requirements of the business model and the industry (domain) while passing through a series of complex filters:
- Contextual Relevance Filter: Is the solution suitable for the company's culture, scale, and existing constraints?
- Cost of Adaptation Filter: Will implementing the new idea cost more than the potential benefit?
- Hybridization Filter: How to integrate the new concept with the existing architecture to avoid conflicts?
All this led to star architects or architects who successfully passed even the most difficult interviews failing in ways the client paid for:
- creating designs and solutions ahead of their time – systems and tools turned out to be unnecessary now.
- projects with underestimated requirements, creating double spending during work and maintenance.
- highly effective solutions efficient here and now, but which turned out to be unsuitable for modification during a sharp change in the external environment.
While ordinary self-taught individuals or architects who failed most interviews created brilliant things: Nikola Tesla, Linus Torvalds, Bill Gates and Paul Allen, Steve Jobs, David Heinemeier Hansson, John Carmack – the list is huge.
Every client, manager, and even HR is concerned with just one question: How to choose the right one? My personal (like many others I know) and sometimes dramatic career experience and search for projects as an architect (in the early years of the war) made me ask the same question: what's wrong with me? This question bothered me for several years (but apparently not enough) until at some point I myself started looking for architects for projects and asking: How to find the right one? What is the criterion for correctly evaluating an architect's effectiveness?
The Evolutionary Perspective
I found the answer. It was derived from years of observation and a constructed hypothesis: "IT Systems also obey the laws of convergent evolution". Adapted for an IT System, it would sound like this: IT systems solving similar tasks under similar conditions, regardless of the initial architecture and technology stack, evolve towards similar structural solutions and organizational patterns, dictated by the objective constraints of the environment (performance, scalability, reliability, cost) and universal principles of information processing.
In terms of biology, this is evolutionary selection, where the "architect" is Nature itself, injecting a random factor of diversity into different life forms under the same pressure of "environmental factors". Moreover, a very interesting effect of lateral gene transfer and useful behavior models between species is observed – this is the realization of the injected diversity factor, which makes an organism viable due to adaptability in the future.
Lateral Transfer as a Source of Innovation
In the case of man-made forms (house, device, landscape, IT system) and their diversity, the actor is Man, and this is already "managed evolution", which proceeds tens and thousands of times faster; In this case, the "environmental factors" are:
1. Business and user (market) needs: Requirements for speed, availability, security, ease of use.
2. Technological capabilities: The spread of clouds, containerization, microservice architecture, API, AI.
3. Economics: Competitive pressure, the need to reduce costs (CAPEX/OPEX), scalability.
4. Regulatory environment: GDPR/DORA/Cloud Act/AI Act, cybersecurity laws, data residency requirements, etc.
At this point, I'd like to note several observations of successful horizontal transfer of structures, models, principles, and behavior logics from other worlds unrelated to IT:
- Ford transferred the model of a slaughterhouse to the automobile assembly line.
- DARPA created the Internet by transferring the physics of distributed systems into TCP/IP logic.
- AWS borrowed models from power grids: availability zones are independent load circuits.
- UNIX borrowed the philosophy of tools from mechanical workshops: one tool – one task.
- Event sourcing borrowed from accounting (ledger).
- Microservices – from organizational theory and Conway’s Law.
- Kubernetes – from biology (container is cell with a membrane and invariants).
Behind these brilliant solutions, Someone stood and continues to stand - these are Solution and System Architects, capable of performing lateral transfer from other, unrelated domains. Thereby creating new ecosystems capable of survival through adaptation.
Why is this so effective? Because it's someone's systems thinking.
An Architect drawing ideas only from IT conferences optimizes the system within the local maximum of the existing paradigm (trend). Meanwhile, an architect capable of borrowing can make a leap to a new optimum, bringing time-tested patterns from other, more mature disciplines and domains into the system. Such transfer gives the system unique and advanced capabilities for survival or adaptation of the information system to an aggressive environment ahead of others. De facto: behind the transfer decision always lies life experience.
But what physically creates diversity in man-made forms, despite convergent evolution? - The simple DRY principle: avoid repetitions and duplication of functionality wherever possible. Yes, but how to make this principle work? How should this principle "reside in the mind" of an Architect?
In reality, the life experience, transfer, and DRY are the source of non-standard solutions and explain:
- why two architects with the same experience of failures will create different systems.
- why one engineer can create a machine, and another – an imperial starship.
- why systems created by "techies without broad experience" are stillborn.
- why some architects become "evolutionary accelerators."
This leads to another question: what makes an architect choose the right or wrong "gene" for transfer into the IT ecosystem?
The answer lies in human nature to focus on traumas and their unique life experience. Essentially, an architect is an engineer-collector of unsuccessful career and life experiences.
The Paradox and Limitation of the "Personal Path"
If Lateral Transfer explains some aspects, then how do we explain the emergence of Zero Trust (the principle of "never trust, always verify"), Principle of Least Privilege, Circuit Breaker, Immutable Infrastructure? They arose not from theory, but from someone's pain and real failures, philosophical values, or simply a social circle outside the IT Domain. An architect who has accumulated this experience consciously or unconsciously embeds it into the "DNA" (Architecture) of new systems, and this is the driver of a random architectural decision, which can be detailed:
- Traumatic Experience (Lessons Learned): An architect who has experienced a large-scale failure due to a single point of failure (SPOF) will forever build in redundancy and distribution. Their "immune system" as a creator is strengthened by this experience.
- Accumulated Pattern Matching (Pattern Recognition): The more systems, problems, and solutions an architect has seen, the better their "evolutionary intuition". They more quickly and accurately match the current task with successful solutions from the past. This is their personal library of evolutionarily stable strategies.
- Philosophy and Values (Architectural Philosophy): Experience forms deep convictions: "everything fails" leads to a culture of fault tolerance; "requirements change daily" leads to fanatical modularity; "security is critical" leads to "Zero Trust principle" as a foundation. This is their evolutionary doctrine
- Social Circle and "Mental Ecosystem": Community (colleagues, conferences, open-source) is an analogue of horizontal gene transfer. The architect adopts successful solutions from others, enriching their toolkit.
However, not all experiences are negative; very often it's positive experience that forms the paradox and limitation of the "personal path". Its danger lies in the fact that "the personal evolutionary path can become a trap":
- Cognitive Biases: Success in a past project ("it worked!") can lead to architectural dogmatism and the application of a familiar solution to an unsuitable task. This is an "evolutionary dead end" – specialization that hinders adaptation to a new environment.
- Experience Obsolescence: The technological environment changes faster than one person's career. Experience working with monoliths from the 2000s can become a burden if not rethought. "Successfulness" has an expiration date.
It turns out that an artifact or design detail explicitly or implicitly added to the system based on personal experience can play a key role in the successful adaptation of the information system in the future, where the deciding factor is not the "ideal" architecture, but "the most adaptable possible within the given context and given vision".
This gives rise to a very interesting and profound definition of "Successful Architecture": it is an architecture in which the subjective evolutionary model of the architect (their "life path") is projected as accurately as possible onto the objective evolutionary challenges of the environment of the current and foreseeable future of the project. At the same time, the architecture itself has the ability to correct course by new creators when their models become more relevant to the changed environment.
Critical Skills of an Architect
The most interesting and important observation in my IT career, and in general across all projects, including large public projects (outsourcing, etc.). A good Engineer cannot become an Architect by their own or someone else's decision, as many have tried to become Architects:
- studied a bunch of trendy technologies (Kubernetes, microservices, GraphQL, serverless)
- obtained prestigious architect certifications from Sun, Microsoft, AWS, Google Cloud
- successfully implemented many trendy (but similar) projects in the same industry or domain
- attended conferences and workshops, studied best practices and design patterns
- read books on architecture (Clean Architecture, Domain-Driven Design, Enterprise Integration Patterns)
And still, the solutions ultimately "misfired" in the form of operational problems, unpreparedness for changes in the external environment – for which, naturally, the Client paid.
Why does this happen? Because architecture is not a set of technical knowledge, but the ability to see a system through the prism of business (needs, environmental pressure), while lived experience of failures and diverse life experience create the conditions and tools for horizontal transfer – so-called technological intuition. Meanwhile, certification and extensive technical materials simply form a synthesis of solutions, not the semantics of problems.
The paradox is that "past project success" can become a strategic trap for a project: it creates an illusion of competence but does not develop the main thing – the ability to foresee unique risks of a new environment. One becomes an architect not through accumulating victories, but through reflecting on defeats and the ability to transfer lessons from completely different domains.
This leads to a key conclusion: an architect is not someone who "knows more technologies", but someone who "has lived through more contexts". Their value lies in a unique "collection of scars" and the ability to apply lateral transfer: seeing in biological evolution a pattern for distributed systems, in a startup's failure – a lesson on fault tolerance, in philosophy – the Zero Trust principle.
Hence the practical question arises: what skills should we look for in an architect and how to evaluate them? The path to architecture lies not through certification, but through three key components:
Here are the skills of an architect, sorted by criticality and importance:
1. Systems Thinking and Holistic Vision – the fundamental ability without which all other skills lose meaning.
2. Observational Skills and Reflection on Failures – it is through reflecting on failures that true architectural competence is formed.
3. Ability for Lateral Transfer – the key to an architect's uniqueness and a source of innovative solutions.
4. Foresight and Strategic Thinking – distinguishes an architect from just an experienced engineer.
5. Diversity of Experience – the foundation for forming all other skills.
6. Pragmatism and a Sense of Compromise – ensures the real applicability of architectural solutions.
7. Communication and Influence – without this, even the best architecture will not be implemented.
8. Humility and Willingness to Be Wrong – creates conditions for the evolution of architecture.
9. Curiosity Beyond IT – enriches the toolkit and can be developed in parallel.
The Danger of "Favorite Questions" and the Power of a Heterogeneous Core
There is a subtle but destructive paradox in how we usually search for architects. A leader who has experienced the pain or success of past projects involuntarily asks interview questions that filter candidates according to their own, already established worldview. "How would you build a microservices architecture for our X?", "What DevOps practices do you consider key?" – such questions seek not an architect, but an executor to confirm one's own worldview.
A candidate who passes such a filter successfully reproduces the interviewer's past, not the company's future. They strengthen "cognitive inbreeding" – a situation where the same thoughts, patterns, and, more importantly, the same blind spots circulate within the team. This is a path to creating a fragile, overspecialized system, incapable of handling unexpected threats.
Imagine the alternative: a team of three architects – a former military logistician, a PhD in bioinformatics, and an ex-pianist who worked in game development – sketches out a fault-tolerant system design in a week. The logistician sees supply chains and failure points, the bioinformatician sees principles of adaptation and the cell membrane, the pianist sees the harmony of independent modules and improvisation during a failure. Their solution turns out to be deeper and more resilient than what "profile" specialists couldn't devise in a year. This is the power of a heterogeneous core.
A system (product, vehicle, house – it doesn't matter) created by a homogeneous team will be well protected from past problems but will prove fragile in the face of new, unknown threats. This is precisely the case where a successfully interviewed candidate brings nothing new but merely cements old, possibly dead-end, paths.
Conclusion
Instead of a typical conclusion, I want to point out once again a universal fact: Modern society is already accustomed to 90% of business projects (whether it's a vehicle, coffee machine, or razor), as well as information systems, not living more than 2-3 years, after which everything is rewritten from scratch. Endless expenditure of resources; and again, for the mistakes, not only the Business pays, but the end Consumer – i.e., Us.
This is not because the World is changing quickly – it is because projects (things) lack strategic continuation, and ideologies of "here and now" and "if you are successful, we are doubly successful" rule the roost. Such decisions are created by techies, marketers, not Solution Architects.
In a world where the market has been divided many times over, to earn more you need... to spend less, and a Solution Architect can solve this problem. This is how investment in long-term sustainability and business preservation works.
Stop looking for the "ideal architect". Build a team of complementary architects and engineers whose evolutionary paths and accumulated lessons do not duplicate but reinforce each other. Instead of "favorite questions" in an interview, create a dialogue with the existing team, allowing you to evaluate not the alignment of views, but the candidate's ability to expand the shared vision, challenge inertial patterns, and propose transfers from their own unique "universe of experience."
While competitors tune homogeneous teams to yesterday's trends, your diverse group will quietly and imperceptibly create a system capable of withstanding tomorrow's crisis – the one no one suspects today. This is where the true value of the architectural approach manifests: it's not about finding the perfect static construct, but about cultivating a living, self-learning, and diverse "genetic" system that has a chance for long-term evolution.