Skip to main content

Enterprise architecture for uncertainty: 3 factors to consider

For an enterprise architect, preparing for uncertainty starts with rethinking your usual practices. And we’re not just talking about technology.
Image
Toolbox with everyday tools

Photo by Maria Kraynova from Pexels

We often hear phrases like "change is a constant" or "the pace of change and the threat of disruption creates tremendous opportunities," as Steve Case said. Even though we know this to be true, many practitioners seem to design and develop business applications and systems to a fixed set of point-in-time requirements.

Software development invites the need for continuous redevelopment of business applications to address new opportunities. Yet a hidden side effect of continuous integration/continuous delivery (CI/CD) is that it can give developers permission to create bad solutions and continually fix them as an accepted best practice. However, the approaches that agile software development teams and squads typically use aren't the only approaches available. Architects can and should do better at addressing how we design for change.

We recently led a workshop at The Open Group's Enterprise Architecture Practitioners Summit about employing architectural thinking for uncertainty. We believe that preparing for uncertainty starts with rethinking typical practices for developing code and crafting databases. Technology is not always the only issue that needs solving. Solving through thinking or, in our case as architects, architectural thinking, encourages architects to rethink the discipline of creating a business application.

Don't be afraid to think outside the box

We urge architects not to give in to adopting best practices that aren't serving the IT practitioner and the organization for the long term. So many best practices are best practices in name only.

[ Learn more strategies to gracefully make changes to teams, processes, and tech for a successful digital transformation. ]

We believe that architects already have the credentials and capabilities required to help address this challenge for organizations, and architectural thinking is a way they can showcase their mettle and value to the organization. However, architects also need to ensure they don't overly constrain themselves by leaning back too heavily on some of their existing coping mechanisms, including:

  • Setting a hard scope boundary
  • Reducing scope coverage to a minimum
  • Simplifying the constituent components of the solution to basic common constructs
  • Reducing the time horizons for planning
  • Redacting content to allow simple comparisons

These are, however, all extremely valid as coping mechanisms—they allow us as architects to consider and work on solutions effectively. But the point to be made here is they are also self-imposed and can constrain both the way we work and the outcomes if we adopt them through "muscle memory" without consciously considering the consequences.

Three ideas about uncertainty to keep in mind

You'll have to open more than your eyes to see clearly. Here are a few key points that help architect for change:

  • Uncertainty is not a primary concern or interest. Architects can demonstrate their mettle by leading the way forward in critical thinking by unwinding unnecessary constraints within the organization.
  • Uncertainty is complex. IT practitioners invariably like to work with requirements. Working with something definitive is easier. Discussing a change that someone in the business needs next year can be abstract and daunting. The activity may even appear fruitless. But, if change is inevitable, we must begin to provide the space for change and start to use adaptive techniques.
  • When you learn how to address uncertainty, you'll always be one step ahead. It's easiest to think of an organization in a stochastic manner, as if it's another number in a larger equation, not a predictable sequence of events.

For instance, your favorite software project, solution, or app, is probably no longer on version 1.0. That implies that every business application has been revised. A revision shouldn't have to mean a code change. A new version or dot-release is the result of a code change. Other techniques can be used to reduce the amount of coding revisions. Thinking about addressing uncertainty starts to bring some of these techniques to the forefront.

[ Learn how tech leaders are rethinking work to maintain momentum on digital transformation. ]

Reevaluate how you approach uncertainty

We hope this helps you rethink how to approach uncertainty and practice some self-evaluation by ensuring you aren't redacting beyond usefulness.

What to read next

Author’s photo

Neal Fishman

Neal is an IBM Distinguished Engineer and a Distinguished Open Group Information Architect. He is a CTO in IBM Consulting covering government, education, healthcare, and life sciences. Neal has a deep level of experience in creating adaptable software solutions.  More about me

Author’s photo

Paul Homan

Paul is a Distinguished Engineer & Chief Technology Officer for industrial-sector clients in IBM Consulting. More about me

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX