analysis paralysis Archives

The concept of ‘agility’ has permeated almost every inch of the enterprise. It’s not hard to see why either. The promise of faster time to markets, better management of change and disruption, and leaner, more efficient operations is clearly an appealing.

Enterprise Architecture (EA) is no exception to the rule. It might have been, for a time – when EA only really concerned itself with ‘keeping the lights on’. But now that the domain has found itself aligned more closely to the center of the business EA has to be concerned with agility too.

Some Enterprise Architecture practices can struggle to really achieve agility because of various reasons. We’ve put together 5 best practices to help architecture teams deliver greater business agility and also become more agile in their own approach to EA.

Just Enough Enterprise Architecture, Just in Time

One of the most common barriers to agililty is doing too much. The complex nature of Enterprise Architecture can lead to some architects building many rabbit holes where too much unnecessary information is captured and modeled that work is never ‘done’. This state is known as ‘analysis paralysis,’ as it effectively slows down the process and time to market of EA business-outcomes. Architects should stay focused on delivering Just Enough EA to support business outcomes, instead of documenting every last detail of the organization.

Of course there are times when very deep EA is required, but as a general rule it is better to focus on Just Enough Enterprise Architecture. Whether through curiosity to learn more, or paranoia that something will be missed, attempting to model and analyze everything is fundamentally at odds with agility.

To help focus on Just Enough EA and avoid getting lost in the detail, architects should:

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

A lean and agile approach to Enterprise Architecture allows architects and non-architects alike to access the information they need much faster too, since EA modeling and content is no longer weighed down by a lot of unneccessary detail. EA is more likely to secure investment this way, too – as stakeholders are more likely to invest when the business outcomes can be translated more clearly and quickly.

Engage and Collaborate with Business Stakeholders

Another hurdle to EA agility is approval. Architects often reach a point where they can’t continue without the approval and buy-in from business leaders. The quicker you can get your stakeholders on board, the faster you can move through the strategic planning process into execution. This efficiency is essential to the agile mantra.

The ivory tower perception of Enterprise Architecture that has traditionally plagued the discipline makes this even more of an issue. Stakeholders are more likely to be reluctant to invest (be it time, money or resources), if the business outcomes aren’t completely clear.

One way to solve this is to help stakeholders get a better understanding and view of enterprise architecture. Getting them engaged and collaborating on the applications, processes or business capabilities they are interest in via an easy-to-use EA tool is ideal. We can also borrow ideas from Just Enough Enterprise Architecture (mentioned above). Your stakeholders shouldn’t have to learn how to do Enterprise Architecture in order to provide input and see its benefits.

Organizations with a collaboratively driven tool can provide stakeholders direct links to specific assets in the architecture. This negates any learning curve stakeholders might have needed to navigate the tool itself, gets them straight to their point of interest, and saves them time.

Giving stakeholders the ability to view and contribute directly within the EA tool itself, negates the need to go back and forth with static diagrams and reports. Instead of printing out PDFs and the like (which is actually just sharing), EAs can collaborate with stakeholders in realtime allowing them to see the impact of different changes on the business and to guide investment decisions.

Ensure Your Content is Stakeholder Focused

Although it’s best to engage and collaborate with stakeholders in EA, in some cases, the stakeholders can only really take a passive role. In this case, making sure what you present to the stakeholder is tailored to them, is another great way of removing stakeholder concerns as a hurdle to agility.

View managers are a great quality of life data management system, that can help EAs achieve this. They’re already commonplace in many Business Intelligence tools and CRM Systems, but can be just as useful in EA.

The purpose of a view manager is to streamline both the visulaization and navigation of data. They take a set of user defined parameters, and act as a filter to show only what’s relevant to that view.

Much of this ties into the concept of showing ‘just enough’ EA and can help users and the wider business stay agile by trimming the irrelevant data that can slow down decision making.

View Managers could also be used as a tool specifically purposed to improve agility and efficiency across the business. For example, a view could be created to always display all business capabilities or perhaps all applications that you own. It could then be sorted to show the most critical capabilities – based on their importance to the business – first.

This helps provide architects with a clear view of their own priorities but similarly which organizational priorities should be tackled first.

A business capabiltiy view is just one possible example. In terms of agility, the view would help improve the efficieny at every stage in strategics planning process, increasing agility and time to market across the board by improving systems and processes.

Kanbans

Kanban Boards are a common form of task management in business. In short, they operate as a visual representation of the current state of a specific task(s). The typical parameters are “to do”, “doing”, “done” and “parked”, but many businesses choose to define their own parameters to better suit their needs. For example, a Kanban board that follows the different stages of the TOGAF ADM.

In relation to agility, Kanbans are a great way of organizing and prioritizing your own and your teams activities. This structure is the basis for any credible attempt at a truly agile operation. Without it, organizations often find themselves wasting more time deciding what should be done, that actually doing.

Kanban’s are versatile enough to be used at almost any point in the strategic planning process – including Enterprise Architecture. In EA specifically, Kanban boards could include cards representing business capabilities, or application components, providing a work in progress view of the architecture.

Get the Right Tool

Most organizations start small with EA, repurposing tools such as Powerpoint, Excel and Visio.

This budget approach to managing EA can most definitely get you off the ground. But as the architecture grows, the silos created when fragmenting the architecture across multiple programs and file types stifle progression.

It becomes difficult to work collaboratively, as multiple team members struggle to keep aligned. In many cases, there will be multiple different versions of the architecture that don’t fully corroborate with one another.

The most direct impact on agility though, is the fragmented state of information and assets. The dispersed nature of the data makes it extremely hard to find the information you need, making the EAs day-to-day job harder, as well as introducing further complications when presenting the architecture to stakeholders. EA can be complicated enough for the experts, let alone the stakeholders that are only involved sporadically. These are complications it can do without.

The right tool would be one that unifies the Enterprise Architecture, as well as the architects – allowing them to work collaboratively within one tool, with real time feedback and comment systems across the diagrams, roadmaps, pivot tables, impact analysis and capability models.

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.