I could not agree more with Nick Malik[1], that wrote: “Agile architecture. It not only can be done, but it is an essential skill for Digital Transformation.[2]” Agile architecture is necessary for dynamic and competitive environments, agile corporate planning ecosystems, and highly iterative initiative deliveries. Yet, agile architecture does not mean free for all. Far from it! Agile architecture requires collaborative discipline in all five steps of an Agile Strategy Execution, where architects iterate with the entire planning ecosystem of their organization.
Five Steps of an Agile Strategy Execution
For an organization to become agile, “all aspects of organizations now must become agile, from software development to business models. And enterprise architecture (EA) is certainly not an exception.[3]” There again, I could not agree more.
With its five Agile Strategy Execution Steps, Figure 2 below illustrates concretely how business and enterprise architects need to become more agile within their organization and learn to interact with their entire planning ecosystem to successfully deliver initiatives that matter to their organization and their clients.
In step 1, architects need to extract or corroborate goals and objectives from business managers and head office strategists often in collaboration with change managers. In step two, using either product architecture, customer journeys, or customer-driven value streams, architects need to extract enabling capabilities, required business objects, and participating stakeholders. Architects also need to assess these enabling capabilities and find those that are problematic with subject matter experts, product managers, marketers, data architects, etc.; that is more precisely finding business capabilities that are of high priority and performing low.
Once problematic capabilities are identified, it is now possible in step 3 to focus on priority capability-based initiatives. Here, the architect will work with CIOs, program managers, IT portfolio managers, applications/system architects, IT architects to build initiative roadmaps with business outcomes set to improve the identified problematic capabilities identified in step 2. If the first three steps of an agile strategy execution are completed correctly, executing step 4, the planning of an agile solution delivery becomes easier. This way, delivery teams will not start anymore with a blank page to plan and describe requirements, epics, and user stories, but will instead use detailed artifacts elaborated by architects in steps one, two, and three. Using architecture artifacts, suddenly delivery planning becomes easier, more precise, and less risky. If all four previous steps are executed appropriately, odds are much higher that in the fifth step, Measuring Success, strategies, goals, and objectives set by business managers of your organization will be met, and that your digital transformation is a success.
Agile Architecture Does Not Mean Free for All
Agile architecture does not mean free for all. Far from it! Just like traditional EA, it requires a lot of discipline and handling a higher dose of adrenaline, as shown in Figure 1 above.
Agile architecture is a necessity in a dynamic and competitive environment. The planning scope of an agile architect is focused on the organization’s priorities based on assessed business capabilities. Strategic planning for agile architects has a short to medium horizon (two years being the maximum extent of their planning) and will concentrate almost entirely on customer-driven areas, including product architecture. Planning efforts need to be set at a rapid pace and will be subject to frequent changes. Agile architects are not really interested in long-term detailed descriptions of their target states.
Agile architects’ design focus involves concentrating their energy on priorities or more precisely on problematic capabilities that are of high priority but not performing well enough. Their architecture design is iterative based on comments from the planning ecosystem of their organization and also based on new information and changes that may occur in the organization’s environment while planning and architecture are occurring. Only for identified priority initiatives, agile architects will crisp summaries and extensive designs underpinning formal business cases complete with key financial ratio calculations and providing well-thought-out project implementation. Therefore, the budget process stops being at yearly intervals and becomes continuous, where projects are constantly reassessed.
Agile architecture governance will never be limited to verbal agreements, which is too often the case right now. Verbal agreements will often lead to major misunderstandings and even conflicts. Like traditional enterprise architecture, agile architecture will include written decisions, but at a much quicker pace than in traditional enterprise architecture.
Agile architecture is not about lowering the number of architects. This approach can only lead to siloed agile teams that fail to consider conflicting deliveries from other agile teams, to a high number of redundancies, and to unintended and unwanted impacts on the organization. A sufficient number of agile architects need to focus their efforts on initiatives that are of high priority and where the organization cannot afford to be late or miss its strategic target and forget about stable business capabilities that are not of high priority or are performing well enough.
Agile architects will focus as much as possible on the most common standards. Most organizations have a history. Agile architects will take this into account and tweak standards and traditional frameworks to fit the reality, workforce, and history of their organization. Finally, agile architects will not be slaves to their complicated and laborious enterprise architecture tools. Instead, enterprise architects will tend to use simple and modern software applications that require a little amount of training and that use common data that can easily be synchronized in real-time.
As well explained by Svyatoslav Kotusev[4], an enterprise architecture researcher at the University of Melbourne, “All in all, organizations and architects should stop fruitless ideological debates for or against the so-called ‘agile enterprise architecture’ and start thinking more realistically and pragmatically, i.e. determine the desirable degree of flexibility in different dimensions of their EA practices based on the sober understanding of the genuine needs of their organizations. Put it simply, companies should adopt planning to the extent to which it pays off in their unique circumstances, i.e. when the benefits of planning outweigh its overhead.[5]”
Agile architecture is now more than ever an essential skill for Digital Transformation. Agile architecture is vital in competitive environments, agile corporate planning ecosystems, and highly iterative initiative/project deliveries. Yet, agile architecture does not mean free for all and a lower level of discipline. Far from it! Agile architecture requires a set of collaborative disciplines in all five steps of an Agile Strategy Execution, where architects iterate with the entire planning ecosystem of their organization. This is in fact a level of discipline that has rarely been reached by traditional enterprise architects.
Author: Daniel Lambert
______________________________________________________________________
[1] Here is the profile of Nick Malik: https://www.linkedin.com/in/nickmalik/.
[2] Quote extracted from the article entitled “Yes, Agile Architecture is Real” written by Nick Malik and published on LinkedIn on November 3, 2021.
[3] Quote extracted from the article entitled “What is agile enterprise architecture?” written by Svyatoslav Kotusev and published on https://www.bcs.org/ on June 30, 2020.
[4] Here is the profile of Svyatoslav Kotusev: https://www.linkedin.com/in/kotusev/.
[5] Quote extracted from the article entitled “What is agile enterprise architecture?” written by Svyatoslav Kotusev and published on https://www.bcs.org/ on June 30, 2020.
