Think Like An Architect, Part 3: Architects Look For Causality

Updated: June 30, 2020 Updated: Architecture

This post is the 3rd part of a mini-series titled “Think Like An Architect”. See also Part 1: Famous Architects Sketch and Part 2: Architects See More Dimensions

If you enjoy these posts, you’re likely going to enjoy my latest book:

You’ve surely seen the press releases that describe how company XYZ used product ABC and achieved 90% cost savings, cut cycle times from months to minutes, and transformed itself into an agile organization. How could you not want the same kind of unbelievable success and look like a star in front of your boss, the board, and investors? And all you need is product ABC! It’s almost like those late-night TV commercials where a person started using a magic piece of exercise equipment and went from chubby to Arnold-esque in a matter of weeks by exercising just 10 minutes per day. Hold on for a sec! Those commercials are usually bogus…

Software Runs the Business

Technology can do amazing things. Machine learning can finally reliably distinguish blueberry muffins from chihuahuas. Likewise cloud platforms and other enterprise software products can perform a wide range of useful tasks such as checking user-submitted images for compliance (as my buddies at REA Group in Malaysia recently did), detecting fraudulent behavior and transactions (pretty much any Fintech does this), or manage and optimize whole supply chains.

When evaluating software, it’s good practice to look at what other customers have achieved - at least that tells you that the solution is working and delivers benefits. Hence, vendor slides routinely feature customer references and case studies that report the benefits of their solutions in action. This gives the customers some frame of mind where to use the solution and what benefits to expect. Often presentations even start with a slide full of customer logos, perhaps to induce some sort of herd instinct.

Inputs, Outputs

Now, architects are special elements in the IT universe, so when they see a case study or a related claim, in their mind a picture starts to form. This picture has a black box in the middle with inputs coming from the left and outputs going out to the right. Most initial case studies leave the picture quite basic with one or more product being the inputs and results achieved as outputs:

Architects aren’t satisfied with this picture. They would like to add two important elements to their mental image:

• Additional inputs: most likely the existing implementation did more than just swap one product to another.
• Context: likely the results were not just influenced by the visible changes but also by the overall situation.

Now, a more complete picture forms. Perhaps, the customer also re-architected their application (a major new input into the equation), was already using other services from the same provider (this avoiding data transfer cost), or had enormous data volumes that exceeded the capacity of other solutions (and hence remaining on the current product was no longer an option):

Opening Up the Box: Causality

Now, architects are hard to satisfy. After having added missing inputs and context, their mind next wants to peek inside the box so they can understand which of the inputs or context properties have led to the specified outputs. They are looking for causality to understand which benefit is generated by which property. Imagine it like a wiring diagram - if you push some buttons (inputs), a subset of lights illuminates (output). Architects want to reverse engineer the wiring diagram. With such a diagram they can reason about whether the product will bring comparable benefits in their environment, which is bound to have different inputs.

Architects look for causality - rather than be content with a black box, they want to see which inputs are wired to which outputs.

If a large data set of inputs and outputs was available, one could perhaps build and train a neural network to do the architect’s work. Sadly (or luckily for us architects) that’s hardly ever the case for enterprise software products. Therefore, architects employ the neural networks in their brain to do the job.

For example, the cost benefit might be the result of the large data volume, the fact that the customer re-architected their solution, and that data already resided on the vendor’s platform. Likewise, agility and velocity achieved might have nothing to do with the product choice but with the better integration of the product into the environment:

So, if your data volumes are less and you aren’t yet on the respective platform, you are unlikely to achieve the cost benefit. On the upside, you might achieve better agility and velocity by better integrating your current product without the need to migrate.

Because limited data sets are available, architects develop mental frameworks to narrow down the wiring options. Because architecture is all about decisions (see “Is This Architecture?” in The Software Architect Elevator), a good strategy is to break the inputs down into the fundamental decisions behind them. For any reasonably complex product, the set of possible decisions would be huge. Hence, architects need to abstract away the noise to distill a small set of fundamental and relevant decisions (see Part 1: Famous Architects Sketch). They generally do this based on heuristics or past experience.

If this effort reminds you of thinking in systems, then you are of course on to something. That’s why I recommend books on systems thinking, for example Donella Meadow’s Thinking in Systems or Peter Senge’s Fifth Discipline to most architects.

Reverse Engineering Causality

Sadly, the inside structure of the box isn’t something you’re going to find in a marketing brochure. If you are very lucky, you can get significant hints from a vendor conversation, assuming you are talking to the right person (see “The IT World is Flat” in The Software Architect Elevator). That’s why this is the critical work that architects need to do.

In enterprise settings, deriving the key choices that shape a product and highlighting their ramifications is the architect’s critical task.

Now, when traditional IT teams look at products, they also don’t believe every word in the brochure. So, they conduct a product scoring based on a list of requirements they compiled. Checking (or rather anticipating) which product best fulfills a set specified set of needs is different from “opening the box” and has several limitations:

• First, it takes a static view of the world although we know that things are constantly moving (see “Architects Live in the First Derivative” in The Software Architect Elevator). A single snapshot in time is therefore a poor indicator of suitability over time. For example, if all you need to do is tighten one nut, a simple wrench will outperform a crescent wrench because it is lighter and fits more tightly. On the other hand, if you need to deal with changing equipment that is likely to have different bolt sizes, the adjustable crescent wrench is the way to go.
• Second, most score cards assume that more is better, often ignoring aspects such as the complexity of the solution.

Feature matrices therefore give only a partial view of the product’s fitness for purpose. Architects can do better than this. They understand what’s inside the box and which decisions lead to which outcomes.

From Capabilities to Benefits

Tracing architectural properties to capabilities is a great achievement for architects. But the story doesn’t end there. Not every capability translates into a benefit for the enterprise. A car with a top speed of 300 km/h should not be selected over one that maxes out at “only” 250 km/h in a country with a 100 km/h speed limit, unless there are other factors at play.

My favorite bad example is an opening slide proclaiming that a vendor’s platform can support billions of active users . While perhaps impressive, such a statement also hints that the vendor understands (or cares) little about the needs of a typical enterprise or the government of a country with 10 million citizens.

Opening Pandora’s Box

Interestingly, opening up the box and looking for causality isn’t always welcome. You may run into resistance from several sides:

• Most vendors rather have you take the press release at face value, perhaps appealing to herd instinct or FOMO (fear-of-missing-out) instead of nuanced architectural considerations. My advice is to have these kinds of conversations with senior technical people, ideally from the product group.

• Many IT folks will call opening the box “academic” and claim that is slows down the decision. Aside from the irony that most of these folks hold academic degrees (why would they diss something they invested years into?), finding causality is mostly a thinking exercise. And thinking is actually quite fast, especially when compared to waiting for lengthy steering committees that wade through endless slide decks with many words and little information. Causality models also make great sketches and don’t need to be overly formal.

• Sometimes management is looking for an “easy answer”, somehow having become convinced that the higher up you are in the hierarchy, the simpler things should be. My advice is to find the right level of management to speak to - it’s often the middle(wo)men who want things to be simplistic. In contrast, most top executives are highly intellectual people who understand causality quite well. Just omit excessive jargon and focus on the relationships between inputs and outputs and you’ll be appreciated.

So, opening Pandora’s Box bears some risks. But then, architects would not have it any other way.

Next up: Part 4: Architects see Shades of Gray, Look for Balance