How to transition into IT architecture without starting your career from scratch

Developers, analysts, engineers, and IT consultants can transition into architecture by leveraging their accumulated experience. Laura Salam, author of The Tech and Enterprise Architect, explains how to choose a specialization, gain initial practical experience, and prepare for a new role without unnecessary steps.

Laura Salam, city — Almaty, Enterprise Architect, co-founder of the Kazakhstan IT Architects community Arch Connect, co-founder, leader of the Education&Science Women in Tech Kazakhstan direction

Recently, more and more people working in IT have approached me who want to develop in architecture but do not know how to structure the transition. Many start with courses, study frameworks, and prepare for certification. Training helps systematize knowledge, but one usually becomes an architect through work experience, when the nature of tasks changes and the zone of responsibility expands.

But before choosing training, I usually suggest looking at the current job. What decisions one already has to make, how far they go beyond the boundaries of a single team, and what a person is truly responsible for. This makes it clearer what experience can be relied upon and what is still lacking for the transition.

What changes when transitioning to IT architecture

In short, an IT architect links a business task with a technical solution. They see the dependencies between its parts, compare possible options, and help choose the one that can be implemented, operated, and developed considering the company's constraints. An architect does not replace developers, analysts, or engineers of specific areas; they are responsible for ensuring that their work forms a cohesive solution and that changes in one part do not create problems in another.

Transitioning to architecture primarily changes the scale of tasks. Instead of responsibility for a separate component, function, or technology, there is an opportunity to influence the entire solution, the work of several teams, and the development of the IT landscape. In Enterprise Architecture, this scale can encompass the transformation of the entire company. Along with the scale, the nature of work also changes. In architecture, there is rarely a single correct answer. Decisions must be made with incomplete information, comparing cost, timelines, risks, and consequences for future operations. A significant portion of time is spent discussing options with people who have different goals and constraints. Therefore, architecture should be chosen not only for the next position or income growth. This role suits those who are interested in working at the intersection of business and technology, expanding their influence, and being responsible for the consequences of the decisions made. At the same time, architecture is not a mandatory career continuation for every experienced person in IT. If it is more interesting to maintain deep technical specialization and directly create the product, an engineering or expert trajectory may be more suitable.

People come into architecture from various areas of IT, so there is no single path. Some already perform part of the architectural work, although their job title is different. There is also the reverse situation, where the word "architect" is in the role title, but the person finds it difficult to define their direction and boundaries of responsibility.

How to determine your direction in IT architecture

When discussing a transition, I would start not with the name of the future position, but with two questions — what level of solutions are already familiar to you and in which domain the main expertise has been accumulated. The answer to the first question helps understand whether you are ready to work with a specific solution now or already have experience with changes affecting the IT landscape of the entire company.

When an architect is responsible for a solution for a specific business task, this is closer to Solution Architecture. Such work rarely is limited to a single IT system or team. It is necessary to link business requirements, data, integrations, infrastructure, and cybersecurity, consider possible options, and choose the one that corresponds to timelines, budget, and possibilities for future support. The task of a Solution Architect is not to independently design every component and be the best at understanding all technologies. They are responsible for the solution as a whole, attract expertise in specific areas, and assess how changes in one part will affect the others.

Enterprise Architecture goes beyond the boundaries of a single solution and works at the level of the entire company. The focus of an Enterprise Architect is on the IT landscape, its current and target state, and the transition between them. They see dependencies between initiatives and help determine which IT systems and technologies to develop, which constraints to eliminate, and from which solutions to gradually abandon. This work becomes especially important during transformation, when a company simultaneously changes business processes, implements new platforms, revises data approaches, and modernizes infrastructure. A solution that looks correct within the framework of one project may create constraints for other areas or lead the company away from the target architecture.

Solution Architect and Enterprise Architect are not mandatory steps of one career ladder. These roles have different zones of responsibility and planning horizons. A Solution Architect can develop in their direction and work with more complex solutions without transitioning to Enterprise Architecture. Working at the level of the entire company requires different experience related to target architecture, transformation programs, and dependencies between several initiatives.

The second question concerns the domain in which the main expertise has been accumulated. This can be data, integrations, infrastructure, cybersecurity, or business architecture. Depending on experience, one can develop in Data Architecture, Integration Architecture, Infrastructure Architecture, Security Architecture, or Business Architecture. At the same time, the same domain can be represented at different levels of architecture. For example, a Data Architect may be responsible for data within a specific solution, several related initiatives, or at the level of the entire company. The same applies to integrations, infrastructure, and cybersecurity, so it is difficult to understand what an architect actually does by job title alone. It is important to look at both the area of their expertise and the level of decisions made.

Therefore, when choosing a direction, one should not rely on the image of a universal architect who understands all domains equally deeply and is responsible for the entire company's architecture. In practice, this model does not work. One person cannot simultaneously work out solutions in different areas, participate in all initiatives, and support them during implementation. The more complex the IT landscape and the more changes occur in parallel, the faster such an architect becomes a bottleneck, and part of the solutions begins to depend on the boundaries of their experience and availability. Architectural responsibility is usually distributed among several roles and domains, so it is not necessary to cover everything at once for a transition. It is important to determine the level of solutions you are ready to work with and the area in which you already have a strong foundation. It is at the intersection of these two parameters that the most natural direction for further development lies.

How to transition to architecture from different IT roles

From my experience, readiness for transition depends not so much on the current position as on the level of tasks that are already within the zone of responsibility. Current experience determines the most natural direction and shows what knowledge and practice are still lacking.

For a developer, the most natural direction is often Solution Architecture, but one technical depth is not enough for such a transition. Readiness for this role appears when a developer goes beyond the boundaries of a separate component or a single team, participates in working out a business task, links several IT systems, and considers not only implementation but also data, integrations, infrastructure, cybersecurity, and future support of the solution. At the same time, the transition does not necessarily begin with appointment to a separate architectural position. Within the current role, a developer can simultaneously participate in development and architectural work. For example, comparing implementation options, defining interaction between IT systems, coordinating solutions with other teams, and supporting them until launch. Gradually, the share of such tasks may increase, and the zone of responsibility may go beyond the boundaries of technical work of one team, and this is often how the first architectural experience appears.

A systems analyst already knows how to work with requirements, connections between IT systems, and data flows. If this experience covers the entire solution, a natural continuation may be Solution Architecture, and deep work with contracts and data exchange may lead to Integration Architecture. Often, additional technical depth is required, necessary for assessing performance, fault tolerance, security, infrastructure constraints, and operation.

Business Architecture may be close to a business analyst who participates in changing processes, business capabilities, and the operational model. Transition to Solution Architecture is also possible, but it will require a much deeper immersion into the technical side of solutions.

For those who work with data, infrastructure, operations, or cybersecurity, the most natural continuation is usually the corresponding domain direction. However, deep knowledge of one's own field is not enough; one needs to move from performing individual tasks to forming architectural solutions and being responsible for their implementation.

IT consultants, participants in implementation teams and presales are often close to Solution Architecture, as they work with business tasks, suppliers, and customer teams. Concept preparation provides experience in architectural work, but without participation in implementation, it remains incomplete. Consulting related to target architecture and transformation programs can eventually lead to Business or Enterprise Architecture.

From testing, product, and project management, there is usually no direct transition. Such experience can become part of the path if the work already includes non-functional requirements, design, process changes, or participation in transformation. Quality assurance, product management, or project coordination themselves do not replace the experience of making architectural decisions.

What you can start doing right now

At the current job, it is worth finding an initiative where you can take on the architectural work of a solution or its significant part. Based on it, you need to determine the boundaries and connections with the current IT landscape, collect functional and non-functional requirements, document constraints, and prepare several implementation options. For each option, it is important to assess technical consequences, cost, timelines, risks, and future operation. The result should not be just an architectural diagram, but a justified solution in which it is clear which options were considered, which had to be abandoned, and why. The proposed option must be passed through architectural approval with those whose areas it affects. The goal of such consideration is to find dependencies, contradictions, and risks that were not initially accounted for, and then adjust the solution.

After approval, you need to stay in the project and support the implementation. It is here that initial assumptions are tested and deviations appear, requiring new decisions. After launch, it is worth returning to the original architecture and assessing what was confirmed in practice, which constraints manifested, and what should have been changed.

If the transition is planned within the company, it is better to discuss with the manager or an existing architect a specific initiative that you are ready to take on. At the same time, it is important to determine the boundaries of responsibility in advance and agree on who will review the proposed solutions and provide feedback. If it is impossible to gain such experience within the company, you can consider positions in the external market. For this, you will need two or three anonymized cases in which the task, constraints, personal contribution, decisions made, and the result after launch are clear. When evaluating a vacancy, it is important to assess the actual content of the work, not just the word Architect in the title.

How to relate to certification

One of the first questions people ask me when discussing a transition to architecture is which certification to pass. Often, it is expected to confirm readiness for a new role, although by itself, it does not show this. Certification confirms knowledge of a certain approach or terminology, but not the ability to make architectural decisions and be responsible for their implementation. Therefore, it is important first to gain practical experience, and then choose a program that will help systematize it or confirm knowledge necessary for a specific role.

For Enterprise Architecture, the most well-known are TOGAF Enterprise Architecture Foundation and Practitioner. If architectural modeling is used in work, ArchiMate Foundation or Practitioner can be an addition. For individual architectural domains, there are their own programs, but they should be chosen based on a specific direction and employer requirements. It is indicative that the Open Certified Architect program is built not around a training course and exam. A candidate confirms experience on real architectural projects and undergoes expert review. This approach well reflects the essence of the profession. Knowledge of terminology can be checked with a test, but the ability to work as an architect is confirmed by practice. Therefore, certification can help systematize experience or pass formal selection, but it should not become a replacement for tasks in which architectural responsibility is formed.

How to understand if you are ready for a transition

Try to describe two completed work cases and answer five questions for each:

«What task needed to be solved?»
«What options did you consider and why did you choose one of them?»
«What IT systems, teams, and constraints did the solution affect?»
«What were you personally responsible for?»
«What happened after implementation?».

If you cannot show two such cases, it is too early to transition to an architect position, so you first need to gain experience in independently working out solutions. If your solutions are currently limited to one system or one team, you can start taking on separate architectural tasks. If you have several times independently worked out a solution affecting several IT systems and teams, justified the choice, supported the implementation, and were responsible for the result, you have a practical foundation for a transition.

For a more formal check, you can use SFIA recommendations, but you should compare not the name of your position, but the actual tasks and level of responsibility. Self-assessment is not always objective, so it is useful to discuss your experience with a practicing architect or turn to communities where people meet, exchange opinions, and analyze architectural cases.