Many enterprises claim that The Open Group Architecture Framework (TOGAF) is a waterfall model that does not meet their expectations for modern Enterprise Architecture. Instead they adopt a Scaled Agile Framework (SAFe) methodology to design their enterprises.¹
To note, the three pillars of Enterprise Architecture are: Alignment, Insight, and Quality.
Alignment: Enterprise Architecture (EA) aligns strategy to operations, business demand to IT supply, and ensures that the changes are in line with enterprise strategy and goals.
Insight: EA provides insight into current and desired states of the organization, information systems, and technology.
Quality: EA helps to improve the quality of individual solutions and simplifies their development and maintenance.
And as background, each are used to tackle the largest challenges that enterprises face today, such as:
- Becoming Agile
- Globalization and digitalization
- Increasing complexity of systems
- Product-type development
- Market competition
Pitfalls in EA Adoption
Based on this author’s recent experiences as an Enterprise Architect, the following typically pertain to Enterprise Architecture adoption:
- Organizations focus on the technical aspects of EA, as most of the EA initiatives are driven by a CIO or IT directors.
- Enterprise Architecture teams spend more time selecting an EA framework and EA tools than customizing and using it to develop Enterprise Architecture.
- Enterprise Architects are frequently dragged into operational activities, or into routine project work. This means that while they are appearing to be productive, they are actually doing little to solve the problems of the organization at an enterprise level.
Cross-industry perceptions towards Enterprise Architects are changing, however. To win respect in organizations, Enterprise Architects are expected to code while also be involved in strategetizing plus end-to-end implementation. Today’s Enterprise Architect now needs to work very closely with defining the business strategy of an enterprise. In addition, Enterprise Architects oversee how to realize the business strategy in the form of implementation.
![The Enterprise Architect of Tomorrow [White Paper]: Practical insights on how to become data-driven, agile-minded, and forward thinking. »](https://no-cache.hubspot.com/cta/default/2570476/49fd1c31-67ad-464a-9aae-3ed5e866a24e.png)
Based on the above issues, there is a need for Agile best practices in defining Enterprise Architecture. The following sections demonstrate the link between Agile methodology and Enterprise Architecture. Also explained in detail is the role of the Enterprise Architect in Agile development.
Agile Enterprise Architecture
Agile is a methodology used for software development and project management. In Agile methodology, individual projects are broken down into smaller, more easily managed segments to speed up design processes and produce quality products as quickly as possible.
Agile Architecture is collaborative, lean, and adoptable. It supports innovation and the adoption of all potential digital technologies perhaps conducive to making enterprises more agile.²
Agile EA Framework
With Agile, the focus of an Enterprise Architect is to:
- Satisfy the customer through the early and continuous delivery of valuable software;
- Accept requirements (no matter the stage of development);
- Deliver frequent working software, ranging from within a couple of weeks to a couple of months (the shorter the better…);
- Maintain continuous, daily collaboration with business divisions and software developers throughout projects;
- Chart efficient and effective methods of conveying information to and within a development team (quite often via in-person meetings);
- Measure progress with ongoing development of working software; and
- Give continuous attention to technical excellence and good design.
The Agile EA Framework (AEAF) depicted below is arranged as such to break barriers between IT and business so to increase levels of co-location by unit and via fast-forming teams that coalesce for new projects. It functions to evolve and iteratively improve Minimum Viable Products (MVP) based on real-time customer feedback. An AEAF similarly helps digitalize enterprises by implementing the necessary architectures to support Cloud, DevOps, Microservices, Data Analytics, Test Automation, and APIs.
The AEAF defines architectures by using an iterative life cycle to allow the architectural design to evolve gradually as various problems and constraints become clearer. The architecture and the gradual building of the system must move hand-in-hand, and its subsequent iterations must address or implement any and all issues and decisions to contribute to a truly flexible architecture.
The AEAF covers the details of each activity, purpose, and associated architectural relationship in the following manner:
(a) Agile EA Planning
This step covers the Architecture Vision and all upfront architectural planning. At this stage, the objective is to address the central business problem and the concerns of the stakeholders.
Efforts during an Architecture Vision provide the documentation necessary to proceed with further target architecture development. It covers the entire scope of the problem while also addressing stakeholder concerns, priorities, and preferences.
The Architecture Backlog covers the value, complexity, dependency, and urgency of the product.
(b) Agile Architecture Definition
This step covers the defining of domain architectures in regards to business, application, data, and technology. It establishes a set of stakeholder-approved domain architectures with an agreed upon list of gaps and the corresponding ways to clear them. It also addresses the changes that enable the enterprise to meet the preferences of stakeholders. As part of an agile architecture definition, iteration planning will occur with daily “stand-up” meetings and “burn up/burn down” charts.
Daily stand-ups and self-organizing teams work together to develop architecture during this planning.
(c) Agile EA Taxonomy
Agile EA Taxonomy covers artifacts like Agile Architecture Principles and Agile Values to be adopted across an enterprise. It also covers the best practices, guidelines, and checklists to help those adhere to the Agile Architecture domain artifacts.
A Sprint delivers useful parts of a working product. The core of the EA backlog is a properly limited EA Landscape.
Working Software articulates expected outcomes without labouring in details over how something has to be developed and executed. It limits work to relatively short-time intervals to minimize the amount of work in progress. Further, it identifies all predecessor and successor packages. The work product is traceable to an objective, so that if its delivery is delayed (or fails), the enterprise faces the consequence of altering the target architecture.
(d) Implementation
Instead of a big bang approach where decisions about an entire program’s architectural needs are made, agile teams take an incremental approach to ensuring that design is extensible and aligned with the vision while detailing and catering to enterprise needs. In order to be most effective, it helps where the Architecture group continues to look at the bigger picture while the team(s) focus on their sprint-based deliverables. All decisions should be made together to ensure the right balance—whether it’s an 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, focus should be placed on:
- Intentional architecture (Architecture-as-a-Collaboration);
- Building the simplest architecture that can possibly work (established design principles);
- Coding it or modeling it (spikes, prototypes, domains, and use case models);
- Building it, testing it (designs for testability); and
- Implementing an architectural flow (architectural epics and the portfolio Kanban).
(e) Agile EA Organization
EA practices need correspondingly agile environments to flourish. Architecture teams must be comprised of Enterprise and Solution Architects, and a Business Architecture team must match Enterprise Architects with business experts. EA teams need to work closely with agile teams on a daily basis to ensure a vision is successfully executed while incorporating the challenges and feedback from the teams and customers along the way.
Agile Lead Architect: An Agile Lead Architect promotes the Agile approach across the enterprise. This position acts variously like a servant, leader, and facilitator to enable smooth execution and remove possible roadblocks. Agile Lead Architects are the best product owners for an organization’s Enterprise Architecture program. As a product owner, the ALA identifies the architecture required by an organization. The ALA owns the acceptance criteria used in EA development sprints.
Enterprise Architects: Enterprise Architects are components of Agile teams that help to develop, improve, and sustain Enterprise Architecture. Agile Architects are active members of development teams. They develop software where appropriate, and act 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 resilience levels.
![An agile framework to implement TOGAF with LeanIX [Poster]: A step-by-step illustration of how to follow TOGAF’s principles with a lean EA tool. »](https://no-cache.hubspot.com/cta/default/2570476/5475fa44-f844-4c8e-ac88-c8cb0dce7432.png)
(f) EA Repository
An EA Repository helps in storing Agile Architecture and development artifacts.
(g) Agile EA Governance Model
Agile EA Governance is all about creating value across an organization—not just within an individual project. Agile Governance creates a bridge between upper management and the teams that are completing projects.
An established Agile EA Governance Model supports:
- Self-dependent decisions of agile teams;
- Capabilities amongst interdisciplinary agile teams to deal with complex topics;
- Reducing administrative overhead of Enterprise Architecture; and
- The purview and impact of Enterprise Architecture.
Summary
Do not look at all of this as EA versus Agile.
An Agile EA Framework plays a major role for any enterprise transformation. This transformation has four dimensions: Functional; Technical; Operational; and Business. In each of these four dimensions, EA and Agile support the aims of the other.
In Agile, architects need to stay invested with the team throughout. It is important that they be visionary and at same time manage change and complexity. Agile Architects must be involved in the project come the definition of all functional specifications while jointly reviewing the functional specifications with the business team to understand the expectations and make sure that what is written is what is expected.
Continuously check with stakeholders and teams to make sure they are not deviating from the stated design. Architects must, at many times, protect teams from unwanted bureaucracy.
The product owner, Agile Architect, and team shall jointly decide the scope of sprints. Architects should intervene only in case of issues during the scoping (or when changes are introduced at the last moment).
Demo the sprint output to business for customer feedback, accommodate all necessary changes, and ensure that the team has a mixed composition of experienced and fresh engineers. And lastly, though agile does not explicitly recommend documentation, it does help to create documentation as much as required for easing the life of support teams in future.
References
1. Scaled Agile Framework, http://scaledagileframework.com/
2. https://philippe.kruchten.com/2013/12/11/agile-architecture/
Acknowledgements
The author would like to thank Hari Kishan Burle, Raju Alluri of SCA Practice of Wipro Technologies for giving the required time and support in many ways in bringing up the article as part of SCA Practice efforts.
Author
Dr. Gopala Krishna Behara is a Senior Enterprise Architect in the SCA Practice division of Wipro. He has a total of 22 years of IT experience. He can be reached at gopalkrishna.behra@wipro.com.
Disclaimer
The views expressed in this article/presentation are that of the authors, and Wipro does not subscribe to the substance, veracity, or truthfulness of the said opinion.
