The Importance of Context in Decision-Making

More Than Just Requirements and Qualities

Introduction

Regarding decision-making, especially in technology and business collaborations, there's more to the process than just listing requirements and identifying qualities. While these are essential components, the often-overlooked context element can be a game-changer. This article explores the triad of decision-making factors: Functional Requirements, Non-Functional Requirements (or Qualities), and Context.

Not all companies are the same. Find the differences and respect them. AdobeStock_332827251

The Common Pitfall: Overemphasis on Requirements

More often than not, the context is either ignored or assumed to be a given, which leads to blind spots in decision-making.

My extensive work with clients and partners has identified a recurring pattern: an excessive focus on functional requirements. Qualities are occasionally discussed but often only in nebulous terms. More often than not, the context is either ignored or assumed to be a given, which leads to blind spots in decision-making.

Context is often ignored.

While reading articles, posts, or podcasts, authors often point out specific aspects of decisions made by other, often large, companies. For example, “the decision to migrate from microservices back to monoliths.” often results in the notion that it’s a good idea to do the same in your way smaller company.

This would be an example of how we rip things out of context. The decision-making process is often very long and should respect all circumstances and constraints your business has. To answer the question of whether you should move back to a tightly coupled architecture, it will bring a lot of problems with it, too. Are you able to handle those? Will the benefits of that decision bring you more advantages than the problems you adopt now? Would you have the resources to escape a situation that is too coupled without overstressing your team and budget? I saw a lot of SMBs failing on that.

This specific example, of course, is an entire topic of its own, but it shall demonstrate that an SMB, for instance, has different requirements and context than an enterprise.

“Cloud is too expensive; you can save a lot with data centers.”

This is another example which is closely connected to your context. For a larger company, going cloud-native can have significant overhead in terms of costs, while a smaller company with non-IT-Ops personnel can save a lot of money. The reason is simple: we need to consider the total infrastructure, employees, maintenance costs, effort for certifications, etc.

A single containerized service or managed database is more expensive in the cloud-native as if we host it ourselves when we purely see and discount all other aspects. But if I need to provide IT-Ops personnel or force my developers to maintain infrastructure, it oftentimes creates higher costs and problems than just taking cloud-native read-to-use services.

The decision here must be based on the contextual circumstances

• How much do I need to scale?

• Is my team skilled enough to do IT-Ops?

• Do I have the capacity to run and maintain infrastructure and the people in the cloud?

• Is it in my personal interest to make Infrastructure a capability and responsibility of my company?