EA used to be all or nothing. It used to be the norm that an EA engagement lasted six months and would occupy at least half a dozen architects, creating EA-related artifacts (for example A0 Excel sheets detailing all possible connotations of business services or cross-reference sheets, etc). By the time the EA was completed, the business had moved on and some, if not all, of the artifacts became surplus. Putting the wasted effort aside, this is clearly not a satisfactory position; we need an agile EA approach.
We are living in fast world that is gathering pace. What was acceptable yesterday, will not necessarily still be accepted tomorrow. Business are shifting and so is the market. Business expects that their IT can support their new business model, adopting changes at an ever-increasing frequency. EA as a capability is an ideal way to meet these challenges by providing clear guidance and direction. While it is true that we do not have the novelty of spending three months (or longer) with four people to define an enterprise architecture in detail, there is still a need to plan and to structure – otherwise chaos would result (see VUCA in ).
So, if things are speeding up and we don’t have time to develop a “soup to nuts” EA, what are the options? As outlined above, not creating an EA is not an option (see page 6 in  for the value of architecture) so we need to apply an agile and MVP (minimum viable product)-based approach.
The challenge of an enterprise architecture …
…is to know when to stop – when it is good enough. When designing an architecture, it is easy for it to become an end in itself, rather than something that is there to help the business. As a result, it can be difficult to assess when to stop designing the architecture.
In fact, the reality for a majority of businesses is that, due to inevitable cost and time constraints, changes to business objectives or strategy mean that the architecture will rarely be 80% complete, perfect, or even fully achieved!
Architecture represents the aspiration (or target to reach) and provides the support framework to make decisions along a journey. The deciding factor revolves around when the architecture is “good enough” for its scope and objectives (more on that later) to ensure that results deliver expected business benefits. And this is even more important when we are working in an agile mode
A number of ways can help an organization to understand when it has a “good architecture,” much of which is commonly understood as leading practice for architecture frameworks. These include/are related to:
- Providing clear traceability back to the business objectives within the architecture
- Understanding the scope and objectives of the architecture work, to know when the results are “good enough.”
- Understanding of the business (and IT) context, including external facts (regulation, etc.) that may affect the results.
- Formalized and traceable business objectives and principles, driven by the business mission and vision.
- Looking at the solution or enterprise in a holistic manner across disciplines to understand the impact of decisions.
- Understanding and/or delivering the functional and non-functional requirements.
- Documenting the rationale for all architectural and design decisions, ideally reflecting the principles/business needs.
- Investigating solution alternatives to ensure that decisions are made in a holistic manner and not in isolation.
- Capturing, validating and managing any assumptions and constraints that affect the architecture.
- Proactively managing risks and issues, both process and results.
- Have a clear and sensible plan/roadmap to achieve the desired business outcome(s).
An agile approach to EA
As my colleague Randy Potter in  outlined, “it’s clear that enterprise architecture is evolving through agile methods and anti-fragility to help the enterprise address the current challenges and the disruptions ahead.” And in order for an EA to be agile, we have to be more flexible with the artifacts that have to be developed. This means making sure that we test and define beforehand what artifacts are needed and what artifacts are optional.
Following an architecture approach and designing a solution can be done, as a team, in one day. Of course, the level of detail will not be as deep as one that takes months to produce, but it could be sufficient to make the necessary decisions to move forward (it is also dependent on the type of architecture – see ). Frameworks such as the Open Group Architecture Framework (TOGAF) and Capgemini’s Integrated Architecture Framework (IAF) – see , help achieve the correct balance by giving guidelines for what needs to be created and considered.
However, one thing that cannot be overlooked is experience. It is crucial to have an architect with experience and who understands best practices and knows the major pitfalls.
Thanks for reading.
About the Author: Gunnar is a certified Master Architect, a certified IAF (Integrated Architecture Framework) Master and a member of Capgemini’s Global Architecture Board. As a senior leader within Capgemini’s Global Architecture Community, he plays a key role in the direction of the architecture profession across the Group and developing our future talent. Gunnar also sits on the global Group DevOps Board, represents Capgemini at The Open Group IT4IT Forum as well as is Judge for the 2018 Data Centre (DCD) Awards as well as 2018 Datacloud Awards.
 Randy Potter, Nov 2018, https://www.capgemini.com/2018/11/agile-ea-and-an-approach-for-antifragile-architecture/
 Gunnar Menzel, Mar 2016, the new role of the architect central to growing your business in todays digital world
 Gunnar Menzel, May 2018, Architecture in a VUCA World
 Gunnar Menzel, Jan 2017, The different types of Architecture in 60 sec/
 Capgemini’s IAF : https://www.capgemini.com/resources/architecture-for-the-information-age/