In the past, analysis paralysis and enterprise architecture had gone hand in hand causing bottlenecks in new initiatives.
It’s natural that you want to be accurate and your work correct. But it’s very easy to become so focused on having every last detail 100% perfect, that it results in delayed decisions and business outcomes – or, “Analysis Paralysis”.
In this article we lay out actions that you can follow to help avoid analysis paralysis pitfalls using “just enough” enterprise architecture, and look at the tools and techniques available to build, analyze and communicate it effectively. First off, here’s a definition I think explains the concept quite well:
“Analysis paralysis or paralysis by analysis is an anti-pattern, the state of over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome.”
In today’s business environment, the actions (or inactions) of an individual have an impact on those above, below and beside them. Determine the timeframe in which your analysis or recommendation MUST be completed to avoid a stalemate situation where others are waiting on you.
Enterprise Architecture specifics:
Often organizations have long timescales for analysis and get embroiled in building complex models when what is really needed is to understand the objectives and key initiatives in the business. Once these are clearly understood then change campaigns can be designed to deliver an architecture that fits the business.
Including others in your work process improves the likelihood of an effective outcome. Diversity of thought gives you a broader context by which to build, analyze and communicate information.
Enterprise Architecture specifics:
Look to incorporate multiple stakeholders either directly or by using output from any IT innovation campaigns that exist within the business.
Collaboration is about asking people to help directly in the architecture process. This is key to not over analyzing the model, but focus on what needs to be done. An example would be to collaborate directly with the security team should a model component have a security impact.
It can be easy to lose oneself in a rabbit hole of information. Whether that be out of an innate curiosity to learn, or a paranoia that there is significant, and increasingly important information just a little deeper.
It’s undoubtedly a tough cycle to crack. Yet it’s solution unfortunately draws a line between frustration and simplicity. That’s because, simply put, the answer is just strict self control and regulation. Limits should be set and adhered to, so that you can efficiently establish what you’re trying to understand in the present, and what you’d like to accomplish in the future.
Enterprise Architecture specifics:
Avoid detail by focusing on how to make strategic changes rather than a focus on how a solution is going to be built. Thus, we should pay more attention to delivering capabilities, and not the configuration of solutions. This means we need to model by capability and look for high level architecture patterns.
Waiting on optimal decisions carries many of the same problems as getting lost in information. Whether or not a decision is optimal is completely subjective to circumstance.
Meaning that if you do wait, and the opportunity passes, you’re then waiting for the next horizon of peak opportunity, looking out for similar signs as before as to point it out. However, as you’ve waited, the likelihood is that the circumstances would have changed around you, meaning that those same indicators will no longer be relevant.
This creates a perpetual cycle of waiting – waiting… waiting. A better approach is to make decisions in optimal ‘moments’, quelling the stagnation of perpetual waiting. After all, decisions can be tweaked and changed in the future, it’s indecision that stays the same.
Enterprise Architecture specifics:
Make optimal decisions based upon SMART objectives, focus on building the architecture to deliver the capability at a point in time. This is what is at the hub of just enough architecture.
Goals and capabilities should be broken down into components and we should focus on delivering an architecture to support them. A series of small iterations, whilst collaborating with the key people will build an actionable architecture. Use Kanban to manage the process, roadmaps to validate a particular solution against the required capabilities and goals.
One of the reasons people find making decisions so difficult, is the weight of the decision in question. For example, the decision to perform a 180° turn on a plan you’re currently actioning might seem infeasible. 18, incremental, 10° shifts? Not so much. Smaller decisions and the smaller shifts in action that they carry are a great way of wriggling out of analysis paralysis.
Enterprise Architecture specifics:
Use all the tools available – Kanban to manage the process including collaboration, use diagram tools to see architectural dependencies, roadmap goals, capabilities, applications and infrastructure.
If we keep the models at a high level answering goal based questions then we can build just enough architecture.
The core purpose of Enterprise Architecture can be outlined as follows:
(Source : Gartner)
What do we find? Complexity in presentation of data; detailed design models instead of stakeholder based outputs; and the mixing of Solution Architecture and Enterprise Architecture. Additionally, it can be impossible to make decisions unless you abstract upwards.
Doing just enough is a case of focusing on outcomes and not building detail. It means focusing on goals and how to address them. Incorporating existing Innovation initiatives.
Creating Capability based models to represent the business. Associating with Application and Technology layers to understand solution patterns rather than the exact solutions need to make key decisions.
Choosing to focus on just enough architecture that focuses on high value business outcomes, gives the architect the best chance to deliver the core purposes of EA. All this adds up to increasing time to market, and quite simply – less headaches.
