This article continues my series inspired by the book “Software Architecture — the Hard Parts” by Ford et al. In my experience the book is missing the hardest and the most challenging parts.

The hardest parts of software architecture are, ironically, the softest ones. They relate closely to the organization’s power structure, history, culture, and sources of uncertainty.

In the first part of this series I introduced two of my top 4 actual hardest parts of software architecture. In this article I will introduce my top 2 of that list.

This article series was originally published on Medium.

🤬 2. Language & local regulation and policies

US-based IT companies seem to have big problems understanding Europe’s cultural and lingual fragmentation, let alone the rest of the world. If you work in a small country, such as Finland, the problem is even more significant. Even if an IT system does not need to support many languages officially, you still usually need to operate with two languages: English and Finnish or Swedish. I’m not talking here about localization but something more fundamental — the shared domain model.

The best practice is to be consistent with the language. Hence, the code is usually written in English. In many cases, the language of business is not English, and occasionally they do not even know what concepts should be used in English. Sometimes, there are no good translations.

Let’s assume you’ve created a shared language for the domain model. Good start. Then, you expand your business from Finland to the rest of Europe and North America. Suddenly, your domain model must cope with the policies and regulations of Germany, France, Italy, Sweden, Spain, the USA, Canada, and dozens of other countries besides Finland. Sometimes, this is not an issue — you’re lucky. Yet, fragmentary and inconsistent policies and regulations significantly increase complexity in many other cases. In addition, you need to cope with localization and culture-related differences, and you’ll waste a lot of time with inconsistent representations of time, numbers, metrics, and measures. This complexity is social by nature, and it drastically impacts the architecture, the need for coordination, and the team topologies.

Even worse, the current tools and services with multiple overlapping domain models could be better. For instance, there is no good way to define family resemblance in code. Take company types as a simple example: company types are very similar in Western countries but still partially different. The language of the data yields another layer of complexity. Used units of measurement and definitions of the used and needed metrics yield another. And so on.

While architecture patterns and practices provide ideas on how to minimize risks and problems, the root cause of many issues remains unaddressed: that is, there are, in fact, multiple overlapping and inconsistent domain models, data models, and languages.

You may have similar problems if you’re building an IoT (Internet of Things) system and have a variety of devices from different vendors. Devices will provide different APIs and yield various kinds of data, and you’ll have problems consolidating the data, e.g., for ML applications or reporting. Consistent IoT data is an easier problem because you don’t have a political and social layer to cope with, and sometimes you can solve the problem with money. The problem in IoT is purely technical, and logic, math, and pragmatic engineering take you far.

🤬 1. Overlapping, inconsistent domain models and multiple sources of truth

When you start a new business, everything is easy. You choose the tools, decide where to put data, and so on. Good options are abundant. The situation is entirely different when two mature companies merge and try to align their IT systems. You have a lot of partially overlapping data and IT systems. In addition, you often have a badly over-optimistic plan to merge data and IT systems.

It is common to pick the low-hanging fruits and accept that you have some overlapping systems. It makes sense, but it also costs a lot in terms of complexity. Consequently, you will have multiple sources of truth. Most likely, you cannot solve that problem with technology, and even if you can, the solution will be complex, error-prone, and hard to maintain.

On the other hand, you can try to harmonize all the IT systems and operations. This is also a suboptimal solution because now you need to spend a lot of time on work that customers do not care about, and all that work is away from items that add customer value.

Mergers are just a shock that messes up good plans and ideas for keeping things clean and tidy. Changes in policies, partners, and regulations are another common source of chaos you cannot adequately prepare for. The bigger and older the organization, the more likely you need to cope with multiple overlapping and inconsistent domain models and multiple sources of truth.

From the software development and architecture perspective, there are two hard things to do: (1) minimize the damage due to the lack of shared understanding and facts, and (2) justify temporarily plummeting capability to deliver more value to customers. This will be especially challenging if the reasoning behind the change (e.g., a company merger) is to increase customer value and improve efficiency. Modern architecture patterns and practices give limited tools to manage expectations and risk after a radical change in the fundamental assumptions and when you don’t have a shared epistemic foundation to build on.

Don't fret, there are some ways to work with these challenges

In the last part of this series, I will introduce six patterns that I’ve found useful when struggling with these vicious problems.

You can find the first article of this series here.