By Priya Patra, Sr. Manager at IGATE Global Solutions
I have been an Agile Practitioner for years now, have been in many successful Agile executed projects. But as an Enterprise Architect I am somewhat skeptical about the fact how the eXtereme Programming and other Agile methodologies dismiss the value of analysis and design.
In this write-up I will try to blend in the flavors of Agile along with Enterprise Architecture to bring in the concept of Agile Architecture.
Enterprise Architecture is good, but when we make it agile to embrace change, it is great. Let’s see how we can embark on the Good to Great journey of making an Enterprise Architecture and Agile Enterprise Architecture.
Emerging and Intentional Architecture
SCRUM and XP have seen broadest adoptions in the enterprises. These methodologies are based on the assumptions that the architecture emerges out of the iterations of delivery of value driven user stories and continuous refactoring, this is what we call Emerging Architecture. What if we have to scale this to the enterprise, will it stand up to the test of scalability, here comes in the Intentional Architecture.
Intentional Architecture is a practice which is designed to produce robust architectures in an Agile fashion. The objectives of Intentional Architecture are as follows:
- Build Application Architecture vision
- Alignment of Application Architecture with Enterprise Architecture vision
- Leverage Architecture patterns, implementation strategies and best practices – Build robust Architecture Principles
- Sponsor innovation and continuous Improvement
Agile Architecture – Looking beyond the current Sprint
With the foundation laid for an intentional architecture, we will now look to see if we can make the enterprise architecture Agile.
Characteristics of an Agile Architecture
- Intentional Architecture, rather than an emerging architecture
- Integration points to facilitate Agile Development rather than hindering the same
- Embrace change without over building
This does not happen by accident but by design.
Role of an Agile Architect
There are substantial benefits when we effectively apply the intentional architecture, provided the iteration is not slowed down. An Agile Architect is a role in an agile team who provides inputs and technical direction based on the Architecture vision to the enterprise and ensures that the design and architecture of an individual application is in conformance with enterprise architecture vision.
Let’s see how an Agile Developer and Agile Architect embrace change?
| Agile Developer | Agile Enterprise Architect |
| Works to satisfy the customer and business | Balances needs of all stakeholders and knows when to say “no” |
| Embraces change quickly assuming change is inevitable | Plans for change, embraces it, by understanding it and through a flexible design |
| Follows “YAGNI” principle of XP | Follows “Separations of concerns”, plans and designs for scalability and reliability in conformance with Enterprise Standards |
| Uses quick solutions to solve problems | Implement Long tern solutions to reduce technical risk / debt and improve maintainability |
Evolution Strategies – Good to Great
Build strong foundations: Agility depends on strong foundations; we can never be agile, if we keep spending time in fixing the core or Architectural building blocks.
Establish Implementation strategy: Implementation strategy to be aligned to the Architecture vision and communicated to the Agile team to ensure alignment to the vision.
Adopt a layered structure: Layer data as well as the software. We need to separate out things with specific purpose or which changes with different rates than others. Separate the core from the business rules, loosely couple components and apply abstraction for growth and scalability.
Practice change continually: Being great at anything requires practice. Agile teams needs to use tools and techniques which support constant change e.g. Continuous Integration, testing and refactoring
Bottom line “Think long term and act short term “. Understand the agility the business needs, understand what helps you to align to the Enterprise Architecture Vision and choose design wisely!
Priya Patra is Sr. Manager at IGATE Global Solutions. She has extensive experience in managing and executing product / framework development and Technology CoE projects. She is a Certified Scrum Master, a certified TOGAF® practitioner and a member of the Association of Enterprise Architects (AEA).
Architecture from all the architecture domains of TOGAF with focus on adaptability for future business changes (process, rules, semi-static data) and future needs on scalability, deploy-ability, other QoS and Governance are the needs of an agile architecture blueprint. However, EA comprises of few more than this. Project Portfolio and IT Portfolio management through DevOps and the likes could possibly support agility in these remaining areas.
TOGAF having the ADM phases for continued governance, impact analysis and optimization is inherently Agile, if practiced in right manner. The only new thing that could be is to accommodate rooms for future agility in early phases of architecture vision and implement optimization cycles to exploit those rooms.
Exactly !!! Future Agility is the key here, and these architecture principles and should be laid down during the planning phase and keep the vision in mind while accommodating business agility.
On the other hand TOGAF as you rightly focusses on business adaptibility..in fact I read an interesting article where the author rightly points out that “Agile and TOGAF are made for each other”.
Priya,
I think you are on to something here in moving architecture beyond sprints and products towards an emergent framework for the future agile business. As you note, getting beyond good means the architect must develop and adhere to a clear set of principles, and be able to hold that set (your pyramid) in mind through various evolutions of multiple business products. This will bring your company to good and better, but that there is still another step up to great.
Once a framework is clear, the architect needs to convey that to multiple teams. And not only convey, she must convince the teams and external stakeholders to make some hard decisions and avoid many simply expedient choices, such as ungoverned big data. In your diagram of “Evolution Strategies – Good to Great,” what is Driven, on the right-hand side, is not a pyramid, but a funnel. To be agile you need a proper set of constraints much more than a complete and comprehensive set of artifacts (or documentation), that your modelers, stakeholders and developers all agree to.
Thank you Priya. Very impressive.