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, he does not move to a new project after the so-called architectural phase.
An Agile Architect writes system-level tests that stress the architecture.
He writes the infrastructure tests to test the architecture of the system. If there is an architectural hole then the failing test would point to that hole. Since agile promotes testing first, he writes tests to make the system fail on quality attributes and then makes relevant changes to the architecture to make the tests pass. In rare cases where testing is not practical, he thinks of other ways in which he can "test" the architecture. This ensures that effort is not spent around unproven design. The tests confirm the viability of a good design on which effort should be put. Any design decision, however small it may be, is preceded by a test case.
For example, if the system is supposed to meet the desired quality of service at a load of 10000 users then he writes JMeter or equivalent stress scripts to generate adequate load on the system to make sure that the system is performing under that load. If this test fails, then he refactors the architecture to make sure that the test passes. Now after refactoring when the test is executed again, it should be green.
An Agile Architect participates in intense collaboration.
He does not make design and technical decisions alone; these decisions are collaboratively achieved with the team. He has an open mind for ideas and is a firm believer of the fact that he does not know everything and is never protective or defensive about his own ideas. The best ideas come from the team when members brainstorm together; anyone may have a good idea or valuable insight. Open and honest communication helps people to make better decisions based on better information. The Agile Architect is a people person who treats everyone with respect, and promotes every opportunity to learn from each other. He promotes consensus and allows everyone on the team to contribute to the solution.
If a business sponsor explains the goals of a project and the architect proposes a single solution immediately, you're probably not working with a true architect.
An Agile Architect is a rock solid mentor.
This is a trait which has no bounds. He constantly works with the team to improve its decision-making abilities. This eventually helps in giving the Agile Architect better leverage than being the sole decision maker on the project. He utilizes his team better by guiding the team on new technology, building and providing support for technical frameworks. He makes sure that the team doesn't simply reject a design due to lack of experience or discomfort with the techniques/technologies. If that is the case, he bridges the gap for the team so that they can make informed decisions.
As Martin Fowler puts it "This leads to the satisfying rule of thumb that an architect's value is inversely proportional to the number of decisions he or she makes."[i]
An Agile Architect is a deft mediator.
Agile teams include skilled and passionate team members. Frequently, there are differences of opinion on a design decision, the best way to implement a feature, ways to improve the development process, etc. These differences of opinion may lead to heated exchanges and may result in hard feelings if not handled quickly and effectively. On these occasions, the team members need a mediator who has more experience, maturity, and knowledge to help the team and break disconnects. The Agile Architect is a perfect fit with his level of maturity and experience.
An Agile Architect never does Big Modeling Up Front (BMUF).
He generally does not use heavy CASE tools for modeling big designs and decisions. Usually, all the modeling is "just enough" modeling and is done on white boards. The simple model grows and is enhanced with every iteration. He follows the concept of Agile Modeling and for him "the code is the model." If there is a need to generate a model for documentation purposes, then the model is generated from the code using a suitable reverse engineering tool.
The models, documents, content, and style of communication are kept as simple and as brief as possible. The idea is to focus on content, not representation or "polishing," which add little business value.
An Agile Architect looks for large scale refactorings.
He is always on the lookout for issues that could become serious technical impediments and damage the architectural concerns of the project. As the system grows, he makes sure that the architecture keeps pace. He is constantly on the lookout for big changes that have bigger payoffs. As an example, if the application is not utilizing enough CPU, and this leads to lower performance, then he might try to introduce multi-threading so that idle resources are adequately utilized to deliver better performance. He starts with the simplest working solution first and then constantly refactors the solution to meet the changing quality and functionality requirements.
The Agile architect also helps in partitioning the system. Instead of a divide and conquer approach, he recommends conquer and divide. Initially, a small system is implemented with the help of a small team. Eventually, with the experience of the Architect, the team divides the system along its natural fracture lines, keeping the big picture in mind, and adds team members for each partition.
An Agile Architect is a super glue.
He acts as a super glue between the team, various vendors, and stakeholders by communicating incremental architecture, design decisions, any technical impediments, etc. He is an intermediary between the business and technical worlds. He has the ability to see business issues through a technical lens and technical issues in a business context. He is able to explain the value proposition of current technologies in terms of business value which would be realized for the stakeholders. For example, when there is a choice of one technology over another, he would be able to explain the business value realized in terms of people utilization, faster turnaround, money saved, etc. He thinks in terms of "why" as well as "how" when working on a project to answer both business and technical concerns. Most traditional architects would focus on how to implement the solution without giving a thought about why the solution the best option. The agile architect tries to work with business and find out why a particular solution is needed, could there be a simpler way of solving the issue at hand than what the business is proposing?
Last, but not least, an Agile Architect embraces change.
He embraces change for both architecture and the role. True architectural agility is the ability to undergo change quickly and easily without degrading the architecture, and with as small as possible an impact elsewhere. To ensure this he starts with a good design and keeps evolving it throughout the project. He always abstracts out common elements and encapsulates those which may change behind stable interfaces thus minimizing the impact of change.
True role agility is playing multiple roles. He works as a programmer, system tester, mentor, mediator, team member, glue, and potentially a manager, potentially all in a days work.
Conclusion
The foundation of the ivory tower for architects has been shaken. The new breed of architects called Agile Architects is stepping up, working, and contributing to the team. They are truly living by the Toyota Principle #12 which says "Go and see for yourself to thoroughly understand the situation." They are first class citizens of the development team and they do not work for the team but work within the team. Thus, to qualify as an Agile Architect one needs maturity, experience, and above all the capability to juggle various important traits while working within the development team.
Do you have an Agile Architect on your team yet?
About the Author
Vikas Hazrati has over 10 years of experience as a developer, technical architect, and project manager working on various enterprise applications for Finance, Manufacturing, Pharmaceutical, Healthcare and Government clients. Currently he is working as a Principal Consultant with Xebia, which is a specialist software house devoted to enterprise Java architecture, middleware, portal, and integration technologies. Vikas has been involved in setting up Agile-based effective and efficient development processes and environments in various organizations. He is a regular presenter at agile conferences in India and actively blogs about process and technology. His current interests include evaluating tools and techniques for effectively applying agile in distributed teams.
[i] See martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
