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.”
Set a decision deadline
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:
- Set distinct timescales when defining architecture change
- Set change around Time based, Goal Driven initiatives
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.
Ask colleagues/peers for a sanity check
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:
- Incorporate ideation
- Understand the key players and ask for them to collaborate directly in the process
- Avoid building a model in isolation and then asking for comments and suggestion
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.
Don’t get lost in information/Don’t get lost in the detail
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:
- Separate Enterprise Architecture from Solution Architecture, understand that detail does exist where Architecture meets design
- Use a goal based decision process, keeps a focus on what needs to be built and by when
- Concentrate upon interfaces / relationships
- Define the core properties to be collected and implement quality checks
- Harvest and connect to records of source
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.
Don’t wait for optimal decisions
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:
- Use analytics and cost analysis driven by focus on desired outcome
- Focus on goal based analysis
- Just enough architecture to support an optimal decision at a point in time
- Adopting a more agile approach to enterprise architecture, in order to adapt decisions in the future when required
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.
Step towards a decision
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:
- Understand the iterations required to build a solution
- Kanban the iterations
- Use impact analysis to reveal dependencies
- Roadmap by goal and capability
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.
Summary
The core purpose of Enterprise Architecture can be outlined as follows:
- Aligning IT investments with business needs to increase their profitability
- Highlighting weaker, less cost efficient areas of a business and amending them
- Improve the decision making at executive level
- Increasing the benefits from innovation
- Delivering strategic change initiatives
(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.
