Reclaiming the Architect’s Role in the SDLC

Over the past decade and a half, following the general shift away from the waterfall model, the industry has increasingly underutilized the expertise of software architects. The pendulum swung almost to the point of making any design work feel redundant.

Strong software design and continuous architecture validation are essential for building efficient and reliable systems in real-world applications. Development teams should embed these practices in every iteration of the software development lifecycle (SDLC) — dynamic enough to guide architectural decisions yet lightweight enough not to slow development down. The same goes for documentation: it’s a valuable part of design work, but many modern engineering teams struggle to create and maintain it effectively.

Based on their training and designation, the architect’s role is to own these aspects of the software, but they’ve largely phased out of the day-to-day process.

With new systems and methods, such as architectural observability tools, architects can reclaim responsibility for system design and architecture while also delivering the right level of documentation at every stage of development.

The Software Architect

The practice of software architecture began as part of software development in the early 80s and evolved into its own discipline by the early 90s. As software development practices evolved, so did the role of the software architect. While this role has been diminished in some agile environments, the modern complexity of software systems demands its return. As it is perceived today, the role can be described as a high-level, experienced software professional who oversees the overall design of a system. They are responsible for making decisions that impact the system’s long-term viability, scalability, and performance. 

The recent 2025 Architecture in Software Development report shows that while 63% of organizations say they’ve integrated architecture throughout their entire development process, more than half still run into project delays because architecture isn’t properly aligned. Also, 56% admit their documentation doesn’t actually match what’s happening in production. 

This shows how important architectural alignment is throughout the SDLC. Without that alignment, you end up with frustrating delays and a gap between what you planned and what you actually built. That’s exactly why having a dedicated architect makes a difference. Architects guide these decisions and make sure business goals and technical requirements stay in sync to run resilient, scalable systems.

Key responsibilities include:

• High-level design: Define the system components and their interactions
• Technology stack selection: Analyze business needs and requirements, then choose the right tool for the job to address them. This includes programming languages, development tools, design patterns, off‑the‑shelf products, third‑party libraries, frameworks, and more. Incorporating a brief prototyping phase validates assumptions and guides the final decision. 
• Functional requirements: Work with clients and product teams to translate business needs into technical solutions
• Non-functional requirements (NFRs): NFRs complement the system’s functional requirements. While the latter describes what the system does, the former deals with a system’s performance, scalability, security, and effectiveness in varied scenarios. The architect’s role is both to set the standards and design the solutions for these NFRs.
• Integration: Act as the primary contact for integrating internal and external products or services
• Mentoring: Provide guidance to developers, ensuring best practices are followed and that design decisions are consistently implemented

Given these responsibilities, software architects must not only have a solid understanding of software design principles, patterns, and best practices but also stay up to date with new trends and technologies. They also have to have a deep familiarity with the business domain that their product serves to effectively solve problems. Additionally, soft skills such as effective communication are integral to working with both technical and non-technical stakeholders. Not every experienced developer or engineer can be a successful architect, and these roles are not interchangeable. For further reading on the distinct role and point of view the architect brings to the table, see this piece on software architect vs. engineer.

The architect's distinct point of view and skill set are critical to ensuring the effectiveness and quality of the software development process. As systems become more complex — with increasing levels of internal and external dependencies — their role becomes even more essential.

Software Development Lifecycle

In the modern, agile-oriented SDLC, the stages typically follow this format: 

Though the names may change, the overall process and stages are usually the same. Presented here is our interpretation of these stages and the relevant personas for each one.

Requirements

In this stage, product professionals align input from the field with the organization's strategic goals. They then refine this input into a format accepted by the organization (e.g., PRDs, epics, stories, or other formats). Regardless of the format, the purpose is to define the goals the software is meant to achieve over the next development cycle.

Design

Once requirements are set, engineers break them down into tasks and assess their technical implications. This often includes creating a high-level design for the feature and, in some cases, documenting it. They may also generate a prototype for more complex requirements. Depending on the organization, this is usually performed by the developers and engineers under the guidance of the application architects, tech leads, or engineering team leads.

Coding

With tasks now defined and designed, software engineers/developers (coders) can begin implementing them. They write the code as well as conduct unit and integration tests to verify the implementation. This stage typically consumes the lion’s share of resources in each cycle.

Testing 

At this stage, developers deliver the task to quality assurance (QA) engineers to design and perform acceptance tests. They validate both the functional and non-functional requirements, including performance, scalability, etc. 

In parallel, product managers, along with other relevant outbound-facing team members, validate that the solution solves the problem it was meant to address. Even if developers build a feature exactly as defined, it’s always possible the root problem was not properly addressed, requiring another iteration.

Deployment

Once the software is officially released, DevOps engineers deploy it and make it available to end users, monitoring it to make sure it performs as expected. 

Feedback

In this stage, product teams, along with other user-facing roles, collect feedback on new and existing features. They record and prioritize this feedback, using it to generate new requirements as the cycle begins again.

The Current Role of the Architect in the SDLC

Notice, the software architect appears just once in the agile SDLC — during the design stage — and even then, only in a “supporting” role.

Without an active architect guiding the design and implementation, systems can experience architectural drift, a term that describes the gradual divergence from the intended system design, leading to a fragmented and harder-to-manage system. In the absence of architectural oversight, development teams may optimize for individual tasks at the expense of the system’s overall performance, scalability, and maintainability.

The 2025 Architecture in Software Development report also found that architecture misalignment has business consequences. 50% of companies report facing security or compliance challenges, and 46% report scalability limitations. Without architects ensuring that both design and documentation remain aligned with the actual operational environment, the business faces heightened risks.

About 10 years ago, I started working as a systems architect at BlackBerry. My startup had just been acquired by the company, which was in the process of transitioning from a phone manufacturer to a security-oriented software company. Several other companies were also acquired and integrated into our business unit at that time. To help define the integrations of all these products into a cohesive system, a forum of architects from different branches was formed. 

This was envisioned as a very large project, set to start in a few months and take up to a year to complete. As I got to know my peers in the architects forum, I was surprised to learn how different our roles and responsibilities often were. I was the only architect for our product and was involved in every aspect of our SDLC. The other products, however, had multiple architects working on them, but their contributions were mostly limited to designing and prototyping integrations with new technologies as part of the larger, long-term project. 

The result was a growing chasm between the architects and the engineers. The former were designing and prototyping features that were months away from actual development, while development teams focused on adding new features to existing products. In the end, both efforts suffered. The quality of the existing products deteriorated, development cycles grew longer, and simpler integrations failed due to a lack of proper planning. Meanwhile, the high-level, complex integrations kept getting postponed because the development teams were getting “stuck in the mud” from their individual efforts.

The Software Architect in the Waterfall vs. Agile models

In comparison, we’ll examine the system design stage in the waterfall model. 

For the uninitiated, the waterfall model was the de facto standard for software development until the early 2010s. Note that we refer to it as a software development model and not a lifecycle (as in SDLC) as it was not cyclic. In this model, the design stage was a lengthy phase, often lasting several weeks or even months, during which software architects rigorously designed the solution in great detail. They often involved developers as “subcontractors,” but the responsibility and accountability rested with the architects. Architects had well-defined deliverables, including graphical and textual documentation (e.g., UML), which they updated throughout development. 

In the agile model, the architect’s role is less defined, often leading many organizations to pass design responsibilities to team leads. While not necessarily a bad thing, it often reflects a mindset that design work is a luxury or even irrelevant. Over time, this may significantly impact software quality, especially in large, complex systems that evolve without architectural guidance. 

From the architect’s point of view, they have the option not to assume any accountability over the quality of the system and its design. Although some may find this appealing, allowing themselves to focus on other aspects of the role, specifically around tech stack selection and integration with external products, by not participating in the SDLC, they are essentially making themselves redundant.

The vacancy left in the design stage by the architect is often filled by developers. However, this has some inherent flaws. Not all developers have the breadth of experience to consider an entire complex system when designing for a specific task. Moreover, developers are typically measured on how quickly they deliver code, which incentivises short-term solutions as opposed to the best overall in the long run.

Today's software landscape demands the return of the architect, not as a relic of the waterfall era, but as a vital force for navigating modern complexity and building resilient, scalable systems that enable continuous innovation. The rise of distributed systems, cloud-native architectures, and AI-driven development has introduced new layers of architectural decision-making that can no longer be left to chance or handled in isolation. Without active architectural involvement, development teams may optimize for individual tasks or features at the expense of the system's overall health, leading to architectural drift, technical debt, and inconsistent design patterns. The result is slower delivery, rising maintenance costs, and an increasingly brittle application that is difficult to evolve, ultimately limiting the business's ability to scale and compete.

The Future of the Software Architect

To move the role and practice forward, organizations must ask themselves:

1. What can engineering organizations do to improve overall software design and quality?
2. What can we do to insert more value from the architectural discipline in our organizations?

These questions are two sides of the same coin. To answer both, we need to redefine the roles and responsibilities of the architect in the modern SDLC to meet the demands of modern software systems. 

The architect is primarily accountable for the overall design and ensuring the system’s quality, performance, scalability, and adaptability to meet changing demands. However, relying on outdated practices, like manually written and updated design documents, is no longer effective. The modern software landscape, with multiple services, external resources, and off-the-shelf integrations, makes such documents stale almost as soon as they’re written. 

Consequently, architects must use automated tools to document and monitor live system architectures. These tools can help architects identify potential issues almost in real time, which allows them to proactively address problems and ensure design integrity throughout the development process. These tools are especially useful in the design stage, allowing architects to reclaim the role they once possessed and the responsibilities that come with it.

But the architect’s job should extend past design. With the right automated tools, they can validate the design during the testing stage. Just as product managers who defined the functional requirements perform their acceptance testing, so should the architect for the design. This goes beyond ensuring the implementation matches the design; it confirms the design solves the original problem. 

It seems like the best way to avoid this cautionary tale of software development. The risk of which increases ever higher with the rapidly growing involvement of AI agents generating more and more code based on often flawed requirement definitions.

Lastly, we’ll discuss the architect’s role in providing the guidelines for the design decisions made by software engineers. The goal is to create uniformity and consistency in the way these decisions are made while maintaining the ability to distribute them between multiple stakeholders and functions within the organization. Some examples the architect would provide guidelines for include:

1. Selecting external resources, such as databases, queues, and identity providers, to employ in the project
2. Defining policies over the creation and interaction of microservices
3. Establishing auditing policies based on the business domain of the product

These create the basis for the architectural governance policy, which can be monitored and verified through the use of automatic architectural observability tools.

Addressing Tension Between Architects and Coders

At times, questions will arise and cause friction between architects and coders.

Who Does the Work in the Design Stage? 

This is the big question, and the answer is somewhat elusive. As a whole, it’s the coder’s job to create the design and the architect’s role to guide them through it and ultimately approve it. However, the involvement of the architect may need to be more hands on, depending on several factors.

If the task is simple enough, an architect may not need to be directly involved. The general guidelines they’ve provided for the project should be enough for the developer or engineer to make the relevant decisions. 

Then again, even a simple task can have broader implications if the application is very complex. In this case, the developer should consult the architect to ensure they’re not missing hidden impacts on the system at large.

For complex features involving new external dependencies or microservices, architects should take an active, leading role. 

Consider the team’s composition when handling the implementation: developers or engineers? This distinction goes beyond job titles — it’s about their experience, training, and depth of knowledge. With a more experienced software engineer, the architect can step back and rely on the policies and guidelines they set. With a relatively inexperienced developer, they will probably want to take a more active role and influence the design directly.

As with most things, communication is key. When in doubt, relevant parties should simply have a conversation and decide, based on the aforementioned parameters, whose involvement is required and at what capacity.

What Documentation Should We Produce? 

That is another charged question in the modern world of software engineering. Some may ask why produce documentation if it is destined to immediately get stale. However, it’s hard to deny the value of accurate documentation, especially for facilitating discussions pre-implementation or making sense of a working system post-implementation. To strike a balance, we suggest splitting documentation into two separate goals: 

1. Pre-implementation: The designer should generate just enough documentation to support meaningful discussion and not get bogged down by formalities. It should be dynamic and not forced to adhere to specific formats or protocols. For example, a flow chart may best explain a complex algorithm, while a feature that crosses multiple microservices could benefit more from a sequence diagram.
2. Post-implementation: Manually generated documentation often becomes outdated quickly. To address this, we recommend using architectural observability tools that automatically generate live documentation, charts, and graphs, keeping them accurate over time.

What Do Engineers Gain From an Involved Architect?

Most engineers welcome consulting with someone while designing a new task, dissipating the inherent loneliness of the coding experience. More importantly, they benefit from having routine or structural decisions addressed through clear policies and guidelines. In this way, the architect provides the design infrastructure for engineers and sets the foundation for consistency, clarity, collaboration, and engineering excellence across the organization.

A Day in the Life of an Architect

Below are two likely scenarios illustrating an architect's contribution to a modern, agile SDLC.

Monolithic System

As an application architect for a large, complex, monolithic back-end application, your daily work focuses on two distinct vectors: 

1. Maintain the Existing Monolith

Ensure that new features written in the monolith do not add unnecessary complexity to the existing code base. Use architectural observability tools to create and enforce layering policies that streamline dependencies, typically creating a clear and direct path from the user to the database. These same tools also maintain the proper definition of domains comprising the monolith. This helps engineers decide where each new piece of code should reside, as well as provide a clear sense of the dependencies it should and should not have. Additionally, it’s important to define the relevant refactoring tasks required as part of each development cycle, underscoring their importance to decision makers.

2. Leading Modernization Efforts

Modernization includes modularizing the application for better scalability, removing vendor-specific dependencies for the purpose of cloud migration, or defining business logic parameters for extraction into new microservices. Set policies for creating and interacting with microservices in environments, whether they are completely new or extracted from the code. The same is true for the procurement and integration of new off-the-shelf or custom third-party solutions to drive the system’s evolution.

Distributed System

As an architect for a complex system with multiple microservices, focus on the inter-service layer, leaving most of the hands-on intra-service design work to the corresponding engineering teams. Set policies on the creation of new inter-service dependencies as well as new services. Distributed architectural observability tools help monitor the service dependencies and make sure they are within parameters to avoid unnecessary network-level complexity and microservice sprawl. Define layers in the microservices architecture, ensuring data flows from the user-facing services to the infra-services and not the other way around. Maintain an active definition of the subsystems in the application so that business processes are properly handled by the architecture both horizontally and vertically. Similar to monolithic systems, this helps provide engineers with clear definitions of the services they should alter for any given task, depending on their business and technical affiliation.

How to Get There?

To fully capitalize on the value architects bring, organizations should take a few key steps:

First, and possibly most difficult, some will need to change their culture to further emphasize engineering excellence, sometimes even over immediate delivery times. While it might be cliche to say, “it pays off in the long run,” without proper architectural care, a new codebase can become very difficult to maintain and nearly impossible to innovate on within just 5–7 years.

Although some organizations attempt to mitigate by using code cleanliness tools, the most meaningful contribution to this complexity actually stems from the underlying architecture. That is why, in our company, we have a saying, “You can have very clean code but very bad software.” Design issues raised by engineers and architects should be treated with the same level of importance as bugs raised by QA, and teams should allocate the appropriate time and resources to address them.

Organizations must empower their architects, making it clear that their role is critical to their success. That means offering support, trust, and modern tooling required to do the job. When these principles are embraced, organizations can expect improvements in software quality, stability, and innovation throughout the entire product lifecycle.

Reclaiming the Architect's Role for Scalable, Resilient Systems

As organizations race to adopt AI‑driven automation, cloud platforms, and microservices, they layer fresh complexity onto applications. Effective management of software architecture is essential to building a strong, efficient software development organization. It influences all facets of software development, from scalability and reliability to security, performance, and time to market. 

After years in the background, it’s time for architects to reclaim their rightful place. By combining their system‑wide perspective, combined with the right mindset and modern tools, architects can lead design excellence, enhance software quality, and accelerate engineering velocity across the SDLC, benefiting the entire engineering organization.
The result? Systems that aren’t just built fast, but built to scale: resilient, secure, and ready for whatever the future of technology throws their way.