Agile Enterprise Architecture: An On-Going Debate
Considerable energy has gone into showing that Enterprise Architecture (EA) and the Agile philosophy can coexist. AgileEA.com, for example, provides a variety of resources to help organizations implement EA and Agile at the same time. Agile is usually seen as a philosophy of project management, while EA belongs to the domain of enterprise governance. However, many people see EA as akin to the waterfall method of project management, the antithesis of Agile. Info-Tech finds that Agile EA can work, as long as the organization adopts the appropriate level of EA maturity.
Managing the EA Project
Enterprise Architecture calls for a lengthy process of evaluation, in which domain architecture specialists evaluate the current state of the business and IT, and plan the required changes to the organization. The notion of architectural specialists gathering information, disappearing for months, and then reappearing with an architectural document runs counter to Agile methods. As a result, proponents of combining EA with Agile have tended to focus on modifying the timing element of EA. In Agile EA, the enterprise architect and associated domain architects work on an iterative schedule, presenting their intermediate work products to the business and IT leadership and receiving continual feedback (source: Edwards).
The iterative approach, adapted as it is from the Scrum Agile project management methodology, makes it easier for the enterprise architect to integrate with Scrum-based projects. The enterprise architect becomes a participant in the sprint review meetings, ensuring that work products conform to the architectural standards as they evolve. At the same time, project requirements play a part in the evolution of the architectural design, and architects take this into account at their own iteration review meetings. The iterative approach allows EA and Agile projects to remain in sync.
Managing the Steady State
At the end of the day, the EA project will produce a series of architectural documents, which become a comprehensive set of requirements for the projects within IT (and elsewhere). However, comprehensive requirements are precisely what Agile is not about. So in Agile EA, the architectural design phase never finishes (Source: Edwards). Enterprise architects must maintain an on-going engagement with the project teams and update the architecture in accordance with project needs (Source: Rhubart). As part of this, the enterprise architect needs to remain flexible in terms of the documentation and technological standards he or she imposes on the organization.
This need for on-going engagement constitutes a major cost of the Agile EA approach. Instead of moving enterprise architects to new areas of the organization after EA project completion, the IT leader must maintain a staff of architects who continue to update the architecture on a full-time, permanent basis. Given the high cost of architects ($120k and up, more for enterprise architects), this can get pricey. And it rules out the low-cost approach, for small organizations, of hiring an external consultant to design an architecture for the organization on a one-off basis. If the enterprise architect will never really finish the job, then he or she may as well belong to the organization.
Plan for Agile EA at any Stage of EA Adoption
Info-Tech recommends, in the solution set Develop EA to Create An Engine for Growth & Competitive Advantage, a staged approach to EA development. In the first phase, the organization focuses on the rules and standards that will form the basis for architecture (the “Why” section of the Zachmann framework). In later phases, the enterprise architect develops a design that is based around reuse of progressively larger segments of the organization. Info-Tech recommends that smaller organizations pursue only the first or second stage of EA adoption. The later stages are recommended only for mid-sized or large organizations.
As long as the organization chooses the appropriate level of EA maturity, it can make Agile work with EA. Smaller organizations can manage the cost of continually updating standards to stay current with Agile projects. Updating standards will not require the on-going services of an enterprise architect, but rather, a technical staff-person or a business analyst can keep these up to date.
Larger organizations can handle the more burdensome task of updating architectural documents as project requirements evolve. These organizations can afford to keep architects on the payroll, engaged in Agile projects, and the continual upkeep of the architectural documents. In either case, Agile EA lies within your organization’s grasp.
Plan Your EA Roadmap
Use Info-Tech’s Enterprise Architecture Maturity Assessment and Roadmap tool to plan your path to EA adoption. Remember that if your organization uses Agile you will have to plan for on-going architectural iterations as part of your EA project plan.