The Shiny New Agile Architect


Recently there has been a lot of talk on whether we need an Architect on agile teams or not. There have been never-ending discussions on various forums both inside organizations and out in the public questioning the value that an architect can bring to the agile project where the architecture evolves with every iteration. This has led many traditional Architects to scramble for cover and opened gates for a new breed of architect, the Agile Architect. The traditional ivory tower Architects are gradually proving to be the weakest link in the chain for agile projects. 

So who is an Agile Architect? How do you identify if the Architect on your team is an Agile Architect?

Well, the answer is not that simple; however there are some definite traits that point towards an Agile Architect. The interesting part is that an Agile Architect has to juggle these traits as a part of his daily work. If the architect on your team portrays all or most of the following traits, and you see him juggling them, then he is surely a good Agile Architect.

Let me warn you that the descriptions below may sound a bit idealistic, but they definitely form the goals that any Agile Architect would shoot for.

Primary goal of an Agile Architect: deliver a working solution with optimal quality.

There are two important aspects here. First, the solution should be of optimal quality . Ideally, within an agile project, the quality requirements (also called non-functional requirements) are a part of every iteration. Aspects like security, performance, code quality etc. are implicitly included as a part of a story or explicitly as a separate story in the iteration. However, many times the team working on the iteration gets so involved with the business functionality that the quality aspects take a back seat and slip through the cracks. The Agile Architect makes sure that the team has a feedback from the continuous integration environment which provides static code quality, performance statistics, etc. with every build. He keeps an eye on these statistics and quality attributes and continually brings them to the team's attention.

{sidebar id=1} Second, thesolution has to be a working solution . The Agile Architect evaluates various options with the team and works with the team to deliver a solution which works and generates business value. He makes sure that the solution not only works in isolation but also integrates well with the entire enterprise stack which is already in place at the client location. It is robust enough to be changed and extended over time. He focuses on the working solution, not on documents and management deliverables which don't contribute to the solution.

An Agile Architect maintains conceptual integrity.

He makes sure that, in the heat of the battle, the mission doesn't get lost. Working under the pressure of implementation schedules and technical hurdles, developers sometimes make decisions that cause a project to veer away from the business goals. The architect must make sure that the mission isn't undermined at any point in the development process.

Conceptual integrity is achieved when the system exhibits a consistent and unifying theme: everything seems to fit together seamlessly. It is the presence of uniformity and the absence of radical designs in different parts of the system. An example would be the drag-and-drop metaphor found in most operating systems. If the system was design with conceptual integrity then drag-and-drop should just work everywhere. For instance, opening a file would just involve dragging it to the appropriate application; deleting a file would involve dragging it to the trash. In short, conceptual integrity creates an easy-to-use and easy-to-maintain system with little surprises.

An Agile Architect works on the team, literally.

He is involved during the entire duration of the project. He signs up for programming tasks and implements stories just like any programmer. Implementing stories may not take his entire work day, but is a definite portion of each day.

He applies his experience throughout the project and directs the architecture through its evolution. The architecture is not completed during the first few iterations but it keeps evolving with each iteration, which means that unlike traditional architects,


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.