The Life Cycle of Agile Architecture

11 mayo, 2017

Any process that is designed to be “agile” in nature will have longer sustenance.

Overview:

If software architecture is a key business asset for an organization, then architectural review/analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal review /analysis process, the organization cannot ensure that the architectural decisions made are sufficient and don’t pose any significant challenges to quality attributes associated with the project.

Why do we need?

As the saying goes in the medical field, “The prevention is better than cure”. In similar lines, the modern enterprise applications are very complex in nature and require reviews of the software architecture blueprint on a periodic basis. The architecture review helps the project teams to align architecture vision throughout the development cycle. Otherwise, the mistakes around architecture would become very costly and can lead to catastrophic failures during application maintenance / or its life cycle. In addition, review during inception phase would help to establish the early feedback loop to respective stakeholders before engaging in development with a full-fledged team.

How can it be performed?

Any process that is designed to be “agile” in nature will have longer sustenance. Any rigid/formal ceremonies will have less buy-in from teams. So keeping this in mind, the architecture artifacts that are developed and analyzed in the form of sketches, decision trees, technical spike resolutions etc…would become primary communication channels for the review. The simple iterative workshops containing high-level steps as outlined below would be sufficient to complete the exercise.

Step-1: Project Manager / Scrum Master invites external architect [Outside person] for the review

Step-2: Product owner the / Project Manager / Scrum Master / BA would provide high-level business context/business drivers associated with the project

Step-3: Architect would present the artifacts that solve business drivers

Step-4: External architect would engage in discussion with team – primarily with the product owner and project architect.

Step-5: Workshop will be completed with recommendations and suggestions / risk mitigations to improvise the architecture blueprint [If any] with notable rational behind such amendments.

This cycle would last in a single day with multiple workshops. Can be scheduled typically every 3-4 sprints once, to re-look at original decisions and identify any gaps in the implementation for better alignment. This kind of exercise is better suited for complex application architectures that would require at least 10+ sprints for realization.

Challenges:

The architecture review is not an easy job, as it requires a lot of maturity among the people involved in this process. There are many challenges organization might face when trying to implement this practice. Among them are some key considerations one must be aware mentioned below-

1. The organization's architecture practice is very novice; leading to little or no information found on architecture decisions on the application that is under review. This makes an extremely complex endeavour for external experts to review the architecture, as there is no contextual information available.

2. Lack of architecture experts to understand the business/technical complexity and provide meaningful feedback that brings value-add to project stakeholders

3. Open-mindedness of project teams to receive, acknowledge and implement the feedback in right spirit

Conclusion:

As companies embark on high stakes of enterprise applications and integration initiatives, often the results will be in question. Appropriate investments in the form of periodic architecture reviews would result in a better risk mitigation safety net and prevent costly mistakes post project realization. Thus, periodic architecture analysis/review would help project teams to receive honest feedback on the current state of the project and helps to develop a roadmap to actionable items, for future iterations for better alignment on stated quality attributes and initial architecture vision.