Over the years, I have observed many organizations enthusiastically establish an enterprise architecture (EA) function, fervently embrace EA practices, meticulously develop myriad architectural models and diligently govern compliance to architectural standards. Yet in the majority of these organizations, EA has been a failure; within only a few short years, the function is disbanded.
EA concepts have been around for decades. The first version of The Open Group Architecture Framework (TOGAF®), which is widely adopted by enterprise architects all over the world, was published in 1995. So, why does enterprise architecture still prove so challenging?
Three enterprise architecture challenges
The purpose, goals and disciplines of EA are sound, but it seems the practice has not lived up to expectations. Arguably, the fundamental reason why EA has failed is that businesses do not see its value for three key reasons:
Enterprise architecture does not solve real customer and business challenges Enterprise architects are expected to be experts in understanding business and technology. Through their insights, they should be helping to solve customer and business challenges by guiding the business in making informed decisions such as technology direction, prioritizing capability areas for change, defining solutions to meet long-term objectives, formulating transition plans, and overseeing the delivery of their solutions. One of the challenges with enterprise architecture is that most EA functions are too inwardly focussed and struggle to relate and engage with the business.
Enterprise architects are perceived to waste time defining the whole organization’s current state and target state architecture models instead of concentrating their efforts on solving real business problems. Sure, the architecture models may be accurate and even elaborate, but so what? The business is not interested in ‘pretty diagrams’. They want results, outcomes, customers and benefits.
Worse still is when the EA function is focussed on managing change to architectural compliance. This is where bureaucratic processes and review boards are established to ensure that proposed changes are designed and delivered in a way to comply with architectural targets and standards. It’s not that having architectural models or managing compliance with architectural standards is wrong, but there needs to be a strong emphasis for enterprise architects on solving real business challenges For enterprise architects to solve business challenges, they need to have an in-depth knowledge of the business and its customers. Most EA functions are centralized and far removed from the front line, which leads to a logical understanding of the business in the form of architectural models. But very few enterprise architects have even been to the front line or spoken to the customer. I know several enterprise architects working for a multi-national oil and gas company right now who have never been to the production operation facilities. Their understanding of the business is purely based on information from a third party.
Another challenge with enterprise architecture is that, since it’s common for the EA function to sit within the Information Technology function, its scope and point of view to a technology bias is naturally constrained. Consequently, this leads to less focus on the business, which in turn leads to the business perception that enterprise architects are not solving business challenges. As a result, the business engages less with enterprise architects, and so enterprise architects stay focussed on just the technology.
Enterprise architects are too rigid and not adapting fast enough EA frameworks such as TOGAF® have been around for a long time, and over the decades, progressive organizations have rapidly adopted the new ways of working that have emerged. Approaches like Lean Startup, Team of Teams, Agile, Product Thinking, Design Thinking, and Human-Centred Design have challenged the value of EA.
Organizations are now challenged to inject innovation by adopting a customer- and product-centric approach, where the norm is to understand the customer, test ideas, fail fast, productize and scale up. These concepts conflict with traditional EA thinking and methods, which are primarily concerned with gathering business stakeholders’ needs, lengthy architectural modelling exercises, and thorough planning.
Enterprise architects and industry groups like The Open Group have been slow to adapt to these new ways of working. There have been lots of discussions but not much action in terms of how enterprise architects can incorporate these techniques to increase their success.
Enterprise architecture is not understood Enterprise architects invest a lot of effort into modelling the business with esoteric diagrams (such as with ArchiMate® notation). Frankly, the business customers and stakeholders do not care whether the arrow from one box to another is a diamond shape or a triangle shape. They just want solutions to their challenges.
Most enterprise architects have struggled to communicate meaningfully with the business, which leads to the business not understanding the value proposition of EA.
While we can’t solve all the challenges with enterprise architecture, there are some immediate practices that we can adopt to demonstrate value to the business and its customers— particularly for major business initiatives such as digital transformation.
Five keys to success with enterprise architecture
Solve business challenges by firstly understanding the business context, strategy and challenges
Apply techniques such as Design Thinking, Human-Centred Design, and Product Thinking to improve your understanding of the customer problem, business needs and challenges. The customer can be either an internal business stakeholder or the actual business customer.Answer questions such as:
Who is the customer?
What is the customer profile?
What are the moments of truth for the customer?
What are the challenges (problems or opportunities)?
What are the objectives required to address the challenges?
Demonstrate value early by applying Lean Startup and Agile thinking to EA
TOGAF®’s architecture development model (ADM) is intended to be executed iteratively, but this is seldom practised. There is a lot that we can learn from Lean Startup and Agile thinking in this respect.
Take, for example, Lean Startup. Lean Startup takes an idea and hypothesis, then creates a minimal viable product to quickly test the hypothesis and viability of the idea. This enables us to determine whether to pivot the idea or persevere. Only when an idea is proven do we invest in scaling it.
This approach is well suited to how enterprise architects can work with the business to demonstrate value early:
take a business challenge and hypothesis
create a minimal viable architecture to test the proposed solutions with the business
determine whether to persevere or pivot
When the architectural solution is agreed or proven to be viable, then invest the effort in further in-depth elaboration or implementation.
The key here is “minimal viable architecture”. This implies developing or modelling only just enough to test with your key customers and business stakeholders, gather feedback and adapt accordingly. “Just enough” here can mean having some simple diagrams in a slide deck rather than in a complex EA tool that will take way too long to model, or just a photo of a sketch on the whiteboard.
Show linkage to your business strategy with a strategic roadmap and build consensus
Adopt an approach that provides substantiated linkage between your designs and the recommended solutions with the business strategy, strategic goals and challenges. A good approach will help you traverse from your set of challenges to objectives, capabilities, actions, initiatives and roadmap. Along each of these steps you are tasked to narrow your list of options and drive to a very targeted and explicable roadmap.
Engage the business to co-develop the strategic roadmap and use this as an opportunity to build consensus with your stakeholders or customers along the way. Your chosen approach must be simple enough that your business stakeholders and customers can understand.
In line with the previous section, we should develop minimal viable strategic roadmaps to test and gather feedback in order to determine whether the strategic roadmap is valid. From this, we know whether to apply further refinements, or completely pivot.
Don’t waste time and effort modelling the whole enterprise
Instead of developing detailed architectural models (whether application, information or technology architecture models) for the whole organization, just focus on elaborating the targeted capability areas that need to change or are impacted by the change. Granted, you may need a whole-of-organization view in order to gain a contextual perspective, but this should be developed only at a very high level. You should not dive into detailed modelling for all areas of the business because as soon as you have completed the model, the business has changed; therefore, you’ll probably have wasted effort modelling irrelevant areas.
Make your visuals relatable
Enterprise architects are great at creating architectural models, but the customer and the business stakeholders usually do not care for complex and esoteric diagrams. So, translate these into simple and easy-to-digest visuals that the customers and business stakeholders can relate to. Using infographic-style one-pagers, set in business terminology, is a great way to get your message across. In the end, it’s all about the message you want to communicate.
Enterprise architecture doesn’t need to die out in the face of new ways of working, but it does need to adapt. Embrace the shifts in thinking that are happening and don’t let the EA function get rusty.
Show linkage to your business strategy with this free tool
We’ve talked at some length about the importance of adaptive thinking, feedback loops and visual communication. These aspects contemporary ways of working are combined with the best of enterprise architecture techniques (capability-based planning) in our free app for building strategic roadmaps: Jibility.
.png)