Software Architecture and Design in Agile World - Part 4

Software Architecture and Design in Agile World - Part 1

Part 4 - Key factors

How can architects and designers add value in agile projects? Architects and designers can apply their experience to create an architectural vision and roadmap. Forward vision and roadmap will provide adequate clarity to team members. Architects can add value by contributing to architecture planning and sharing their ideas, suggestions and recommendations with team members. Their architecture-driven approach will help agile teams discover risks and problems early. Architects can create a learning environment and improve the productivity and job satisfaction of individuals. Above all, architects and designers can become a role model for the values in agile manifesto.

Architecture approach in software projects depends on four key factors. The first one is the architecture or design competency of the team members who perform the job. The second one is project complexity. The third factor is the familiarity of technology – the most likely technology to be used in the project, and the fourth one is the familiarity of problem domain. When your project has all these factors on the positive side, you can define and implement architecture with ease. You are going to deliver features early. Otherwise, it is wise to spend one or two iterations on architecture (architecture definition, architecture prototyping and creating the building blocks of the architecture). While doing this, it is important to keep in mind the ‘bare minimum’ or ‘just enough’ to avoid waste.



Let me give you two examples. When a corporate IT team wants to deliver an attendance management application on an existing technology platform (on which several other applications are functional) it is most likely that these factors are on the positive side. Why would a team on this project spend weeks or months in defining and constructing the architecture? I am sure you agree that a team on this project could start delivering features early as there must be adequate clarity on the architecture and there must be reusable architectural elements unless the CIO decides to revamp what is available. Later when the application is developed and delivered, they can write or specify the architecture and designs, if such artifacts are going to add value to downstream life cycle activities.

The next example is from the other extreme. It is a highly complex project. This is about developing a product that involves integration of multiple sources of intelligence to help commodity traders across countries. Let us assume that this project involves emerging technologies not known to team members and the problem domain is new to team members. Where do we start? What features do we deliver? Is it a good idea to follow pure agile? Or should we rely on BUFD? I don’t think pure agile or traditional approach (BUFD) will help. It is good to spend one or two or three iterations in defining the architecture and delivering the essential basic building blocks before we attempt to deliver user stories or features. Also, it is good to revisit the architecture at regular intervals and deliver technical stories.


<<<<<< Part 3                                     Software Architecture and Design in Agile World - Part 1