In traditional waterfall development, the architect’s primary responsibility was to think through and design all of the major technical decisions and system components before development began.

Waterfall is a phase-gate based Software development methodology. It drives the development in phase wise – Requirements, design, development, testing, final verification and support.

Since it is purely based on phases, the respective work is expected to be done in that phase only. Hence, Architecture and design is expected to be complete before the software development phase.

Architects would create comprehensive specifications, robust technical diagrams, and extensive documentation to detail their upfront designs.

This “Big Design Up Front” (BDUF) approach was rooted in the belief that architects needed to solve and finalize all the major architectural questions early.

Teams would then implement the specifications and plans defined by the architects before writing a single line of production code. Changes were costly once the big upfront design was “locked-in” and signed off.

The challenge is “Cone of Uncertainty”. In the long term, architecting the product / solution with a point solution, with 1 clear architecture was a challenge because of the cone of uncertainty.

While logical in theory, this BDUF approach resulted in several major drawbacks:

The architects’ initial assumptions were rarely correct or comprehensive, leading rework down the road.
Extensive documentation led to significant overhead without producing working software.
Rigid plans and specifications made the system hard to modify as new learning emerged.
Architects became bottlenecks trying to make so many big decisions up front.
Teams lost autonomy to make decentralized technical choices.
Fast feedback and course correction wasn’t possible.

In summary, BDUF led to protracted analysis and design phases that delayed working software. The big upfront plans also lacked flexibility, limiting agility and innovation once development began. This rigidity proved unsustainable in modern dynamic environments.

Emergence of Agile Methods

In response to the shortcomings of waterfall development and BDUF, new lightweight software development methods emerged in the mid-1990s. These included Scrum, Extreme Programming (XP), Crystal, and Dynamic Systems Development Method (DSDM).

These approaches embraced iterative development, frequent feedback, and an incremental design approach referred to as emergent design. They valued responding to change and customer collaboration over strictly following predefined plans.

Out of these methods arose the “Agile Manifesto” in 2001, prioritizing:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile methods empowered teams to drive decisions, innovate, and continuously improve based on rapid feedback loops. The role of architect evolved into a more collaborative, emergent approach.

Some key enablers of agile architecture include:

Iterative Development: Features are built in small batches and increments enabling faster feedback. Errors can be caught early.
Continuous Integration: Having a working build always available reveals integration issues quickly.
Test-Driven Development: Writing tests first leads to more modular, testable code.
Pair Programming: Writing a code by two people as a pair.
Mob Programming: The entire team writes a code together with driver and navigator roles
Code Refactoring: Improving existing code without changing its behavior prevents accumulating technical debt.
Regular Retrospectives: Reflecting on how to improve after each iteration quickly fixes processes and team issues.
Customer Collaboration: Working closely with business stakeholders and users ensures the right solutions are built.

Agile architecture leverages these practices to embrace emergent design and empower teams to drive technical decisions collaboratively as systems are built iteratively.

As given in the below picture, in Test Driven Development, design emerges as the feature / user story gets developed and it is continuously architected.

The agile philosophy represented a seismic shift from rigid BDUF approaches enabling faster value delivery and flexibility.

Continuous Architecture

In the Agile world, the industry is moving towards “Continuous Architecture”. Unlike traditional architecture, where the design is separated from construction, in software how something is built influences what is built, and vice versa. Software architecture is about decisions, not structure.

MVP needs MVA

Creating a Minimum Viable Architecture as part of an MVP helps teams to evaluate the technical viability and to provide a stable foundation for the product that can be adapted as the product evolves. Creating a Minimum Viable Architecture (MVA) as part of an MVP helps teams to evaluate the technical viability and to provide a stable foundation for the product that can be adapted as the product evolves.

Architects as Collaborators, Not Pre-Planners

With agile methods, the architect’s role shifted from isolation to collaboration. Instead of pre-planning specifications, architects became more embedded in the development process.

Rather than making all technical decisions upfront, agile architects engage continuously with cross-functional teams to explore options and make just-in-time decisions.

Some key ways agile architects collaborate:

Iteration Planning: Architects provide technical guidance and design assistance during planning to ensure user stories are understandably defined and achievable within the iteration.
Daily Standups: Architects attend standups to stay synchronized with blockers teams are facing and provide timely solutions.
Getting Hands Dirty: Architects actively participate in development tasks like writing code, tests, and configurations as hands-on technical leaders.
Code Reviews: Architects contribute valuable design insight during code reviews without being prescriptive or bottlenecks.
Retrospectives: Architects participate in retrospectives and embrace feedback from teams on how to improve collaboration.
Modeling Sessions: Architects facilitate modeling sessions with teams to explore alternative designs and technical options.
Spikes: Architects guide teams on exploratory spikes to research technical options and unknowns.

This high degree of participation, communication, and availability allows architects to guide the architecture’s evolution without impeding agile teams. Instead of predefined specifications, architectures emerge through regular inspect-and-adapt cycles.

Architects relinquish strict control, trusting skilled teams to collaborate on architectural decisions as development progresses. Their emphasis shifts from planning to enabling continuous value delivery.

In summary, agile turns architects into technical leaders and change agents deeply engaged with teams – not isolated planners removed from the process.

Frameworks Define Agile Architect Roles

As agile methods scaled to larger organizations and systems, frameworks emerged to provide structure and define best practices. These include:

Scrum of Scrums
Large-Scale Scrum (LeSS)
Nexus
Scaled Agile Framework (SAFe)

These frameworks organize agile teams and describe various agile architectural roles.

For example, SAFe defines these core architect responsibilities:

Enterprise Architects – Develop technical strategy and architectures across multiple portfolios. Guide coordination of systems and teams.
Solution Architects – Define architectures for large products/systems and work with multiple agile teams.
System Architects – Collaborate with individual agile teams to guide architecture and technical decisions for features.

While specifics vary, frameworks embrace architects as technical leaders and coaches within agile teams – not isolated planners.

Some key responsibilities defined for architects:

Guide teams on exploring technical options via spikes and prototypes
Facilitate modeling workshops focused on emergent design
Provide guardrails and patterns without over-prescribing solutions
Prioritize and sequence delivery of architectural improvements
Promote best practices for quality, security, performance
Support measuring and monitoring architectural metrics

Frameworks enable architects to develop overall architectural vision while empowering teams to collaborate on fit-for-purpose designs iteratively.

Architects provide technical guidance but relinquish top-down control over all decisions. Their emphasis shifts from specifications to continuous delivery of value.

In summary, frameworks embed architects within agile delivery – enhancing collaboration while providing architectural leadership across multiple teams and systems.

Architecture Emerges via Code, Not Documents

A key tenet of agile architecture is that the architecture is embodied in the code, configurations, and technical practices of teams rather than static documents or specifications.

Some ways this is achieved:

Executable Specifications – Tests, prototypes, and spikes encoded in code convey design intent and constraints.
Continuous Refactoring – Regular refactoring evolves the architecture incrementally as teams learn and enhance existing code.
Architectural Standards – Coding standards, naming conventions, design patterns, and frameworks guide emergent design.
Infrastructure as Code – Scripted infrastructure and configurations encapsulate architectural decisions.
Monitoring and Metrics – Dashboards, logs, and metrics reveal architectural quality attributes like performance.
Customer Feedback – Continuous customer input guides architecture evolution based on real needs.
Retrospective Improvements – Retrospectives drive architectural enhancements from lessons learned.

With this approach, the architecture naturally emerges as agile teams implement features incrementally, learn from feedback, and improve the system over time.

Rather than static documents, the “living architecture” is embedded within the active development environment, enabling rapid change as business needs evolve.

Agile architects facilitate this process by providing technical guidance, defining architecture principles, establishing standards, reviewing designs, and upgrading existing code. But the architecture is not predefined – it forms organically.

This emergent design process requires deep collaboration between architects and agile developers. But it delivers architectures optimized for flexibility, usability, and delivering continuous customer value.

In summary, agile architecture emphasizes working code over comprehensive documentation. Architects enable architecture to emerge from iterative development rather than trying to specify it entirely upfront.

Architects as Embedded Leaders

The transition to agile transforms the architect’s role from isolated planner to embedded technical leader. Architects become actively engaged with agile teams through daily collaboration, modeling, mentoring, and coding.

Some key ways architects lead in an agile context:

Promoting Agile Values – Architects model agile principles like feedback, simplicity, courage, and transparency. They help teams embrace agile architecture practices.
Coaching Teams – Architects provide regular coaching and mentoring to developers and testers to grow their skills and capabilities.
Leading by Example – Architects write code, tests, and scripts alongside teams to exemplify hands-on practices and attitude.
Removing Impediments – Architects quickly remove architectural roadblocks and dependencies that could limit team productivity.
Enabling Innovation – Architects encourage experimentation, spikes, and controlled risks to drive learning and innovation.
Decentralizing Decisions – Architects delegate and trust teams to make appropriate local architectural decisions when viable.
Knowledge Sharing – Architects promote workshops, communities of practice, and mentorships to disseminate architectural knowledge.
Customer Focus – Architects maintain strong customer empathy and reinforce building the right solutions over perfect architectures.
Continuous Improvement – Architects champion retrospectives, metrics, and process improvements to constantly raise the bar.

–> Attend our SAFe Agile certification training and become a certified SAFe Agilist and create a culture of continuous improvement

With this leadership orientation, architects avoid operating as isolated planners or ivory tower designers. Instead, they are deeply engaged, hands-on leaders enabling team and architectural excellence.

In summary, agile architecture is fundamentally about culture change. Architects embrace servant leadership helping teams deliver greater value more rapidly through emergent design – not top-down control.

Conclusion

Architecture should evolve and not be finalized upfront before the development starts. Since the Agile product development and delivery is incremental and MVP is built incrementally, the Architecture should also be Minimum Viable Architecture.

Architects should align with thinking and bring right Engineering practices like TDD, Pair Programming, Mob Programming etc to evolve the architecture over a period.