Can Agile Methodology Co-Exist with Enterprise Architecture?

Introduction

There has been a fair amount of debate in recent times about the marriage of Agile and Enterprise Architecture. More so, because both the topics have been gaining traction over the last couple of years and we are seeing increasing adoption of these by companies across the software development spectrum. The discussion ranges from questions like a) can both of them really co-exist in an enterprise or b) are there any commonalities at all between the two to worth a discussion. To set the perspective of this discussion, let us go through quick snapshots of what Agile and Enterprise Architecture are all about.

Agile

It’s about Agility – in managing the (changing) requirements, in developing and testing the product and in delivering the final product. The iterative and incremental nature of Agile is inherent and common-sensical. Without getting into the Agile Manifesto or the specific methodologies (Extreme Programming and Scrum being the popular ones), let’s just understand that Agile is about involving all the stakeholders all the way and delivering quality product increments in specific timeframes – so that the final product is never away from the “big-picture” envisioned. In simple words – “It’snot the big that eat the small but the fast that beat the slow”.

Enterprise Architecture

The understanding of the term Enterprise Architecture (EA) is ambiguous at best and differs based on how EA is viewed from the perspective of different stakeholders in an organization. Enterprise Architecture is more about organization-wide structures and processes (not just technical but business as well) and how they interact and integrate with each other. EA includes all the domains commonly classified in an organization – business, information, applications and technology. Enterprise Architects model through various artifacts the current architecture and future vision of an entire organization.  Among the popular EA frameworks are TOGAF and Zachman. More often than not, Enterprise Architecture is confused with Solution Architecture. A common analogy to differentiate the two is the case of city planners and building planners. While a building planner is concerned with architecting and raising a quality structure, a city planner needs to look at it at a scale of a city – which would include the buildings as well as planning a city around these buildings.

The Real Debate

At their core, EA is about the detailed study of an organization, evolving the architecture and envisioning the organization’s future in terms of architecture while Agile focuses on project delivery, though both work the iterative and incremental way in order to account for and address the shifting nature of business requirements.

Organizations adopting Agile typically have ‘Iteration Zero’ where the architectural strategy is laid out, with the low-level design being part of every iteration. This is one of the places where the two – Agile and EA – can cross their paths. During Iteration Zero, the Agile team can be made aware of the EA goals, EA repositories, shared infrastructure – which could be the base from where the high-level architecture for Agile implementation can be derived at. This will prevent the Agile team from ending up creating vertical silos, creating individual applications, which though might be successful but pose serious challenges in integrating with the rest of the applications in the company’s portfolio and impede the future direction of the organization from both technical and business perspectives.

Again the EA governance can span across the entire iteration, where the Enterprise Architect can play the role of ‘architecture owner’ during software implementation and deployment. TOGAF, an EA framework, refers to a term called ‘transition architecture’ – a stepwise implementation of the target architecture – which is an apt place for Agile implementation. Another area where EA can learn from Agile is how the EA artifacts can be kept as simple and as concise as possible so that these artifacts become useful to the Agile team as well and not too much effort is spent on creating costly artifacts, knowing these artifacts could become outdated by the time those are planned to be used.

Conclusion

Agile and EA differ on the scale of their respective operations. While Agile is at a Function/Process level (though Agile might have been adopted across Functional/Process levels in an organization), the level of Enterprise Architecture is rolled-up to an organization level. Also, while EA is a top-down approach, Agile is bottom-up. As it stands today, the adoption of the two will remain strong at their respective levels and the two will adapt principals from each other and leverage the best lessons from the other approach. Both Agile and EA can and should be adapted to fit organizational needs. As mentioned earlier, EA practitioners will benefit by working in an Agile way, by following principals that Agile Manifesto is based on. At the same time, Agile will gain by keeping the big-picture Enterprise Architecture in perspective during multiple iterations.

The clarity about co-existence of Agile methodologies and Enterprise Architecture sets in if both can be thought of working hand-in-hand in furthering the organization’s long-term objectives, with both being people-oriented, iterative, incremental and focusing on Business stakeholders.