Architectural Challenges in Agile Practice

Introduction
Agile methodology is getting more and more popular and is getting widely accepted among big enterprises. Though other stakeholders of a software building team like the management, developers and testers have a better grasp of this new methodology there is still a lot of ambiguity about how to apply them to the architectural space. The major issues that Architects are finding is that agile methodology discourages the concept of a detailed end to end solution which was the most value-add artifact in the traditional world of architectural solution. This paper details out some of the real time experience of an Agile Architect and recommends certain architectural practices and team co-ordination techniques which will help to bind software architecture more closely with the agile approach while maintaining the traditional Architecture goals of technical excellence, streamlined development practices, and Business process improvements.

Architectural Challenges in an Agile Practice

1. Unavailability of detailed finalized requirements. The unavailability of detailed requirements in the early stages of the project disables an Agile Architect to deliver the following qualities that are expected out of a traditional Architecture practice.

Creating Architecture models that are robust and reliable enough to fulfill all future business needs. Develop a comprehensive architecture early in a project which will be the guideline for the development and testing team. Well documented and reviewed Architectural models. Architectural solutions are taken through strict review process to ensure quality and mend all loop holes before they can be distributed to the project team.

2. Architecture Ownership Concern

Due to the nature of Agile life cycle the project team is not tightly coupled with the Architectural direction which quiet often leads the solution on a Tactical track. In the waterfall life cycle, we have a well-documented Architecture document which can be referenced in all the forth-coming life cycle phases, like the Technical Design Review, Test Planning Review, Code Review and Implementation plan review. Architects and other project stakeholders can make sure that all project artifacts align with the overall solution in all these checkpoints. Unfortunately, all the life cycles of a waterfall model are encapsulated in a few weeks sprint with the Architecture solution getting evolved in parallel to development. 3. Proving Architecture Solution In traditional world, the best way to stress test your architecture solution is to review and discuss it with group of solution and Enterprise Architects. Solutions are documented and brainstormed with the group to close all gaps, align the solution with the enterprise direction, discuss alternative options to come up with the final solution. In an Agile world, since the solution is evolving over the period of the project there is not enough review or discussion on the Architecture solution to make it full proof.

Expectation of a Agile Architect

The architect is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements. An agile architect must also help the team to work together in an agile fashion, to jointly own the solution, and to interface well with other parts of the organization. There are five main parts to this:

Requirement Elicitation Stakeholder Identification, understanding the current and future business process and identifying the architecturally significant requirements Risk Identification Identification of all the possible architectural risk and bottlenecks as early as possible in the project Solution Creation - creating a solution structure which will provide maximum business benefits, balancing the goals and constraints on the solution. Communicating the solution - making sure that all stakeholders understand the architecture. Different people have different viewpoints, so the architect needs to make sure that the project team is in agreement to the outlined solution.

Supporting Development making sure that the developers and testers are able to apprehend the architecture, by a combination of mentoring and direct involvement. Implementation Signoff ensuring the final software product is in alignment with what business has expected.

Best practices for an Agile Architect

Based on my experience as Agile Architect, we had tailored the development life-cycle to help us to gain the agile benefits while still providing the quality and reliability of the software product.

Involve in the High Level Business need discussion to visualize and articulate the high level end to end system impacts. Next step is to create a sketch end to end Architecture solution document which will help o The management to estimate the project o Developers to get a high level understanding of the Architectural discussion

Since there is not enough time or details available to document a good end to end solution document, the goal is to make sure that we as Architects can convey our idea to all the stake holders. The actual documentation part should be optional and various techniques like white board sessions, interactive discussions can be used to make sure that the project team is in the same page. Work in parallel with the project team to keep updating the Architecture solution document and keep discussing the solution with the team to make sure they are aligning development with it. Sprint Demo at the end of a sprint is a very good exercise where an Architect should get deeply involved as it will help him to make sure that the project is following the guidelines. At the end of all the sprints complete the Architecture Solution Document as it will be necessary for the next set of projects working on enhancing this software product. Present and review the Architecture document with the Enterprise Architecture Committee. It is better to keep discussing the project solution with the Enterprise group just to make sure that there is no surprise. The final software product should be implemented into production only after getting a pre-implementation approval of the architectural solution. This will enable to help us keep all the projects aligned with the Enterprise Architecture goals without compromising on the swiftness of Agile development.

Conclusion
The primary advice I would advocate for an Agile Architect is to Collaborate and Communicate the Architecture solution instead of Design and Document the architecture solution as practiced in the traditional methodology.

References
More on Agile Methodology http://agilemethodology.org/ http://en.wikipedia.org/wiki/Agile_software_development

About the Author

Pranab Pyne is an experienced Architect with Infosys Limited, with over 10 years of experience in Software development and he shares of working in multiple Agile Projects.