Part 1: Solution Design — Introduction and First Principles

1. Overview

I like to think about solution (or software) design using the following metaphor. Imagine you are required to play a game governed by the following rules:

The game’s objective is to build a system according to the rules below:

We add the following constraints to make the problem more interesting (and closer to the real world).

2. Solution Design

Drawing parallels between assembling building blocks under well-defined constraints and software project implementations is relatively easy. Let’s articulate this further.

2.1 Building Blocks of IT Solutions

We can imagine building blocks as abstractions of lower-level, physical entities such as lines of code, modules, or applications that can be combined according to computer science and technology rules.

The set of possible combinations is practically infinite, and the system architect must select the optimal one from a vast design space.

While on the surface, this may seem like building a LEGO structure, there are significant distinctions.

The main distinction lies in the following:

1. The maturity (stable, proven, time-tested) of the individual building blocks (implementations, applications, or modules)
2. The issue of requirement volatility, which we discuss further below
3. The integration within an environment that predates the new system and is much larger

These variables will determine the best design (top-down, bottom-up) and project delivery (Waterfall or Agile) approaches. We will say a bit more about that later.

2.2 Software Products and Design Optimization

Design is an optimization process aiming to produce a viable solution within the limited time and material at the organization’s disposal.

A viable product or solution can be sold to many customers within a market niche or dedicated for internal use. In both cases, the investment is justified by anticipating a positive Return-On-Investment (ROI).

When discussing optimisation, we generally refer to the well-known engineering problem of minimising a cost function. 

In this exercise, independent parameters are varied, and the cost function is calculated for every permutation. The permutation producing the lowest cost would then be adopted.

In IT, design optimisation, however, works differently. Architects and senior engineers combine technological assets in multiple ways (to produce various candidates) before selecting a suitable candidate.

The optimization process relies on heuristics (like ranking decision criteria). The final design must be technically feasible and satisfy various requirements, some functional and others non-functional.

The technological assets can be the following:

1. Technology stack
2. Persistence (structured, unstructured), database engine
3. Deployment method (cloud, onsite, client/server, distributed)
4. Redundancy, backup and recovery mechanisms
5. Hardware capacity
6. DevOps or cloud-friendly software architecture

Optimisation can be particularly challenging because there are no rigid rules for constructing the cost function; the weight of the different parameters is context-specific and can vary between organisations.

In this case, optimisation is conducted using heuristics and good practices that allow variations to be considered according to the organisation’s business needs.

The obvious decisions are made first, sometimes based on first principles and axioms of technology (like selecting C++ if you value speed, Python if you value productivity), and others on the subjective preferences and biases (familiarity, experience) of the decision-maker.

Further decisions are then built on top according to reasonable technology practices and the constraints of previous choices. The design can be tweaked further if the benefit-to-cost of change ratio is high enough.

Generally, it is considered good practice to avoid over-committing to critical decisions early on. Experienced architects prefer delaying consequential and binding technical choices as long as possible until more information becomes available.

2.3 Balancing Constraints

Producing an ideal product is possible only in trivial cases. In contrast, most circumstances require difficult decisions and tactical (but not strategic!) compromises.

The conflict will most certainly arise from the desire to go to market as soon as possible and the opposite (but equally valid) desire to produce a sustainable and technologically superior product.

The business usually champions swift time-to-market, while the developers support long-term sustainability and technical superiority.

Tactical compromises are essential to benefit from any market window of opportunity. Still, the general direction, the strategic orientation, must be towards achieving both in the long run.

You can accumulate technical debt to beat the competition and enhance your value proposition on condition that you invest the necessary resources to keep it under control.

In summary, designing the perfect product is an antipattern to be avoided since it requires (theoretically) an infinite (and attainable) amount of information to consistently predict the client’s ever-changing preferences. A more pragmatic approach is preferred.

3. Solution Design Under Uncertainty

3.1 Requirement Volatility

If you think selecting an optimal setup from the infinite possible permutations is hard, consider how harder it can get if the requirements evolve with time. Imagine the cost function you are trying to optimize has weights that evolve with time and parameters that drop in and out spontaneously.

Seasoned engineers know that requirement volatility is integral to software delivery and is unlikely to be eliminated by any method at our disposal. We can either ignore this fact until it hits us or transform our processes to handle it effectively.

This section examines the nature of uncertainty in business requirements, while the next will discuss design under such conditions.

There are two radically different sources of requirement volatility: incomplete knowledge and unarticulated needs. We examine these topics next.

3.2 Incomplete Knowledge

Incomplete knowledge may arise in the following scenarios:

Notice that adequate knowledge can be obtained in all the above examples if some effort is liberally invested, or in the last two scenarios, the requirements are locked in contractually, and talent is acquired.

Incomplete knowledge does not mean unknowable knowledge, unlike unarticulated needs, which is our next topic.

3.3 Unarticulated Needs

Dave Snowden, the Welsh management consultant, researcher in complexity science, and developer of the Cynefin framework, thoroughly discussed unarticulated needs in his lectures.

In his view, customers cannot articulate what they want before interacting with the product and understanding what the technology can do for them. Only then would the requirements become evident and existential.

Unarticulated needs are manifestations of a complex system where the rules of interactions between the agent and the system evolve, leading to further evolution of the system and the agent. It’s like a computer algorithm modifying itself based on new information.

So, how do we design a system before we know what the clients want? We will discuss some ideas in the following sections.

4. Product vs Solution

4.1 Term Definitions

So far, we have used the terms product and solution without a formal definition. Intuitively, we know they are not the same, but it’s not apparent how. The following paragraphs will hopefully polish our understanding of these words a bit.

The term product carries the connotation of a consumer product, something you pick off a supermarket shelf. It typically comes with a user manual and can be configured in a few different modes depending on how you want to use it.

On the other hand, a solution can be understood as an offering that addresses distinct business needs. A solution can involve several products or platforms customized according to a user’s preferences and context.

We define product and solution as follows: a solution is designed to address a particular problem, whereas a product is created to perform a specific function.

4.2 Comparison Table

5. Solution Design Methodologies

5.1 Contextualisation of IT Projects

Experience has shown that universal solutions for complex problems are rare, and methods that work in one context may fail in another. Agile and Waterfall are perfect examples of context-sensitive solutions.

Similarly, solution design methodologies will vary depending on the subdomain where they are applied. We will use the following two-dimensional map to survey a proposed model of the IT project landscape and its subdomains.

The above model defines four subdomains with varying degrees of scale and uncertainty.

Scale amplifies existing cracks and introduces unique challenges to the project delivery model. In large projects, interactions will rise dramatically, feedback loops will become longer, decision-making will be slower, and cost overruns will be more significant.

Uncertainty due to unarticulated needs or incomplete knowledge radically modifies the dynamics of the delivery model by pushing teams to move towards Agile, DevOps, and automation and deploying sophisticated risk management practices.

Example of the four types of project contexts:

• Type I: Trivial
  • Routine maintenance tasks or off-the-shelf projects with little or no integration
• Type II: Novel Ideas Or Technologies
  • New solutions to old or novel needs.
  • These might emerge as humble initiatives in startups with the potential of growing into mega-corporations.
  • Examples abound, from social media to search engines.
• Type III: Large System Integration Projects
  • Replacing or upgrading legacy technologies, acquiring new platforms and solutions, and integrating them into an enterprise ecosystem.
  • Technologies and platforms are generally mature, with standard interfaces and designs.
• Type IV: Mega-Projects
  • Megaprojects include nuclear plants, hydroelectric dams, and enterprise IT solutions.
  • They magnify errors and inconsistencies in processes, technologies, and designs.

5.2 Four Design Approaches

The diagram above places IT projects into four categories. Below is a summary of each type and the preferred design approach.

6. Final Words

Business value is generated only in two phases of the Software Development Lifecycle: design and development. All other stages (planning, testing, deployment, operations, and maintenance) are burdens and extra costs to delivery that customers are not happy to pay for.

In addition to skills, tools, and expertise (which all tasks of the SDLC require), solution and software design heavily rely on creativity, innovation, and the ability to anticipate business needs. On this website, we focus heavily on Operational Excellence, whose objective is producing top-quality products. Operational Excellence in the software business (as we define it) is a framework for understanding software delivery and executing projects flawlessly.

We hope this article has brought the core concept of solution design closer to the reader and has provided them with the right intellectual tools to design solutions with excellence.