Tuning enterprise architecture to cope with accelerating change
In the realm of enterprise architecture, real agility starts with architectural simplicity. Learn how businesses can reduce complexity -- and boost organizational dexterity.
By
Peter McElwaine-JohnnGuest Contributor
Published: 30 Jun 2022
Change is not a constant: it's far worse than that.
Accelerating rates of change mean that businesses can no longer plan years ahead. Rather they must continually adjust and readjust as new threats and opportunities emerge. And to do that, they must be agile. We commonly think of agility as a measure of how quickly, cheaply, safely, accurately and repeatably businesses can adapt to unexpected change. What's less appreciated is that agility operates at two different levels, much like economics, and to succeed, businesses need to excel at both microagility and macroagility.
Microagility is what most people think of when they hear the word "agility," as it's what gets the most attention today. It relates to the business and technology change activities of individuals, teams and product or projects units, and can be improved through the application of techniques such as iterative software development, DevOps, service automation, the use of cloud-based utility computing or robotic process automation for prototyping. In short, it comprises all the things that are usually brought up in discussions about agility.
The problem is that microagility can only be effective when the teams or individuals have sufficient autonomy and independence to enable them to do their work without continual reference to other teams for information, permission, approval, or for delivery of some of the work. This is where macroagility comes in, and it is at least as important, yet it's not often discussed.
Macroagility applies to business and technology change activities on the larger scales of platforms, programs, business units, divisions and of the entire enterprise. It is enabled in part by an organization's culture -- the degree of autonomy it delegates to business units and its attitude toward innovation -- but mostly by its operating model and technology architecture, both of which are designed at the macro level by business and enterprise architects.
In short, macroagility creates the environment for an organization's microagility to thrive and to deliver change quickly, cheaply and reliably. Without it, businesses will still struggle to deliver change quickly, no matter how much they invest in DevOps and agile delivery methods. But with it, significant structural change such as acquisitions and divestments, and major innovation such as the launch of a new brand or product category, can become almost routine, instead of requiring Herculean efforts to achieve.
Barriers to agility at the macro level
What hinders agility at the macro level of the enterprise? In a word: complexity, or what a lot of organizations call technical or architectural debt -- everything that makes systems or processes hard to understand and, therefore, also makes them hard to change. And the greatest controllable source of complexity is: dependencies that cross system or organizational boundaries.
Take the case of one large retail bank that had over 600 software applications involved in the selling and servicing of mortgages. There were thousands of interconnections, each one of which contributed up to a dozen interdependencies, and each one of which had been designed by an architect at some point in the preceding decades. None of them had intended for this level of complexity eventually to emerge, and yet it had. Why?
The problem is that enterprise architects, unversed in the causes of complexity, can unwittingly add dependencies without even realizing it. Every arrow drawn on a whiteboard to indicate a new system interface, every database shared between applications, every additional handoff in a business process, every new governance forum, in practice, adds dependencies which, as well as having an implementation cost, add friction whenever something needs to change. And not just linearly, because of the "starburst effect," whereby an intended simple change to one system ripples out through many interconnected systems. As changes proliferate, exponentially more coordination and regression testing are required. Agile this is not.
The job of the enterprise architect should be to understand the causes of complexity and to deliver simplicity, because the simpler the system, the faster we can change it. Yet instead of minimizing complexity, many enterprise architects measure their success using metrics such as level of reuse, or conformance with standards, or a reduction in duplication of capabilities. Real business value, however, is created when architects partition the enterprise in a way that maximizes business agility.
Fortunately, there are proven actions that enterprise architects can take to reduce complexity and thereby promote agility.
Reducing and minimizing dependencies
Fortunately, there are proven actions that enterprise architects can take to reduce complexity and thereby promote agility.
The first is to remove complexity in the same way that it was originally introduced -- one architecture decision at a time. But in doing so, architects must observe a new constraint: The best solution option is the one that minimizes the complexity of the resultant architecture. This may involve relocating some existing functionality, perhaps by carving it off to a new microservice. With a relatively small initial investment, applied to a change "hotspot," such an initiative can become self-funding in just a few months, as changes in this area become easier and cheaper to deliver than originally planned.
The second involves the excision of large amounts of complexity by replacing significant subsets of the architecture as part of a wider transformation. Typical examples would be core banking replacements or renewals of ERP platforms. Whilst significant transformation programs such as these are usually initiated by business leaders rather than architects, enterprise architects can help to make them successful. For example, architects can specify the use of proven façade-based patterns, such as the strangler fig, that enable incremental transformation. This approach delivers incremental business value and reduces the risk of business disruption, decoupling the systems that surround and depend upon the ones that are being replaced.
The right kind of enterprise architects
The defining feature of a great enterprise architect is a passion for simplicity, of the kind described above. They are someone who understands, as Fred Brooks did as far back as 1975, that the secret to making change happen faster is to partition the problem -- and thence the solution -- in such a way that adding more people speeds things up more-or-less linearly.
Product-based organizations and microservices-based architectures epitomize this philosophy, and the extraordinary agility and scalability of the tech giants are testament to their superiority relative to the traditional operating models and monolithic architectures of yesterday's corporate Titans. But for everyone else, the challenge is how to undo the pernicious effect of past architectural decisions on their business agility, and in the process enable them to compete vigorously in their chosen markets.
If you are looking at how best to drive agility in your organization, these three key actions are a great way to start:
Firstly, have your enterprise architects set guardrails for engineers that reduce and minimize architectural debt at the component level.
Secondly, while your engineers continue to improve their microagility, encourage your enterprise architects to focus on macroagility and see where simplifications can be made at the next level up that will increase the engineers' autonomy.
Finally, start to measure enterprise architects on reducing the dependencies inherent in your business and technology architectures.
By taking these three steps, companies can set their enterprises on the path to a more agile future and ultimately be better equipped to cope with constant ever-accelerating change.
About the author
Peter McElwaine-Johnn is a principal director in Accenture's Technology Strategy and Advisory practice, based in London, U.K. He specializes in technology strategy and architecture, and advises mainly banking and government clients on digital transformation and architecture simplification.
