a) Agile EA Planning
This step covers the architecture vision and upfront planning. The scope addresses the business problem and concerns of the stakeholders.
Architecture Vision provides the documentation to get permission to proceed developing target architecture. It covers the scope of the problem and stakeholder concerns. It also addresses Stakeholder priority and preferences.
The architecture backlog covers the value, complexity, dependency and urgency of the product.
b) Agile Architecture Definition
During this step, the definition of domain architectures covering business, application, data and technology are covered. A set of domain architectures approved by stakeholders for the problem being addressed, with a set of gaps, and work to clear the gaps understood by the stakeholders.
It also addresses the changes that enable the enterprise to meet the preferences of stakeholders.
As part of definition, conduct the iteration planning, daily stand-ups. Generate Burn up/burn down charts. Daily stand-up and self-organizing teams work together to develop architecture.
c) Agile EA Taxonomy
Agile EA taxonomy covers the artifacts like agile architecture principles, agile values adopted across enterprise, etc. It also covers the best practices, guidelines and checklists that the Agile Architecture domain artifacts adhere to.
Each sprint delivering useful parts of a working product. The core of the EA backlog is a properly limited EA Landscape.
Working Product articulates the outcome expected without going into the details of how something has to be developed and executed. It limits the work to be performed to a relatively short time interval, to minimize the amount of work in progress.
It identifies its predecessor and successor packages. The work product is traceable to an objective, so that when its delivery is delayed or fails altogether, the enterprise faces the consequence of altering the target architecture.
Instead of a big bang approach where decisions are made about the architectural needs for an entire program, agile teams take an incremental approach - ensure design is extensible and aligned with the vision while detailing out and catering to enterprise needs. In order to be most effective, it helps when the architecture group continues to look at the bigger picture while the team(s) focus on their sprint-based deliverables. Decisions should be made together to ensure the right balance – whether it’s agreement to the phases of the project from a business value standpoint, acceptance of new technical debt or the design details for a particular framework or a component.
As an enterprise architect of an agile architecture implementation, the focus should be on:
- Intentional architecture. Architecture is a collaboration.
- Build the simplest architecture that can possibly work (established design principles)
- Code it or model it (spikes, prototype, domain and use case models)
- Build it, test it (design for testability)
- Implement architectural flow (architectural epics and the portfolio kanban)
e) Agile EA Organization
EA Practice needs to build with the agile enterprise environment. The Architecture team must comprise Enterprise and Solution Architects from the agile teams too. The Business Architecture team is the combination of enterprise architects and business experts. EA Team needs to work closely with agile teams on a daily basis to ensure successful execution towards the vision while incorporating the challenges and feedback from the teams and customers along the way.
Agile Lead Architect: Promote the agile approach across the enterprise. Acts like a servant leader, facilitator. Helps the team in smooth execution and removes any roadblocks. Agile Lead Architect (ALA) is the best product owner for the enterprise architecture product. As a product owner, the ALA identifies the architecture required by an organization. The ALA owns the acceptance criteria used in the EA development sprints.
Enterprise Architects: Part of the agile team helps to develop, improve and sustain enterprise architecture. Agile architects are active members of development teams, developing software where appropriate and acting as architectural consultants to the team.
Agile Team: Services are small and developed by small teams. Agile makes it possible to release frequently in small chunks and hence show business progress. Follow CI/CD to increase the level of resilience.
f) EA Repository
This helps in storing all agile architecture and development artifacts.
g) Agile EA Governance Model
Agile governance is all about creating value across the organization, not just within an individual project. Agile governance is to create a bridge between an organization’s management and the teams that are completing projects.
An established Agile EA Governance Model:
- Supports agile teams to make architecture decisions in a self-dependent manner
- Leverages the capability of interdisciplinary agile teams to deal with complex topics
- Reduces the administrative overhead of enterprise architecture
- Improves the reach of enterprise architecture
It is not EA versus Agile. Agility plays a major role in enterprise transformation. This transformation has four dimensions: Functional, Technical, Operational and Business Transformation. In all four dimensions, EA and Agile complement each other.
In agile, the architect needs to stay invested with the team throughout. He/she needs to be a visionary and at the same time, manage change and complexity, get involved in the project right from the definition of functional specifications, jointly review functional specifications with the business team to understand expectations and make sure that what is written is what is expected.
Continuously check with the team to make sure they are not deviating from the stated design. Many a times, an architect will have to protect the team from unwanted bureaucracy.
The product owner, agile architect and team shall jointly decide sprint scope. The architect intervenes only in case of issues during the scoping or changes introduced at the last moment.
Next, demo the sprint output to business for customer feedback and accommodate necessary changes.
The team needs to have the right combination of experienced and newbie engineers. Though agile, he/she does not recommend documentation explicitly, but creates the documentation as much as required to ease the life of support teams in the future.