I recently read the book “Software Architecture — the Hard Parts” by Ford et al. It’s good stuff. You should read it! Yet, in my experience, they are 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 this three-part series of articles, you have my top 4 list of the hardest parts and six patterns that I’ve found useful when struggling with these vicious problems. Let's start with the bottom two from my top 4 list.

This article series was originally published on Medium.

🤬 3. Business model clashes and corporate politics

In my experience, at least the following kinds of clashes are common:

1. Clashes between the old service and the new products and services. For instance, on the other hand, you should work on new products and services to ensure market position in the future, but on the other hand, currently, the money comes from the old ones, and you must recognize them too.
2. Bias due to the power centers. For instance, it’s common that in multinational corporations, the headquarters country’s business model dominates, and that will harm subsidiary countries’ business initiatives and architectures.
3. The clash between the needs and services of different business areas. For instance, self-service e-commerce vs. premium expert services. Often, IT development is centralized and services multiple business areas that fight limited development efforts.

Architectural patterns and practices are often practically ignorant about the impact of corporate politics, business models, and decision-making patterns. If and as one of the main distractors is corporate politics, architecture should address it. Single-eyed focus on solution-related aspects such as ease of development, best practices for the technical solution (e.g., SOLID principles and clean architecture), maintainability, performance, security, scalability, and so on, is naïve and inadequate.

A good software architecture should extend beyond technical details and purely technical patterns and practices. It should outline strategies to (1) address the conflicting needs of stakeholders and (2) minimize the risk of wasted work due to the volatility the power struggles cause. For instance, if there is a business model clash between new and old or different business areas, the tech experts should always prepare for changes in priorities and goals. In such a case, it is a question of time when the priorities will change, and taking them for granted will lead to suboptimal results.

🤬 4. Conflict and misunderstanding due to diverse expertise, experiences and knowledge

Whereas the clashes at the business model level make priorities and goals volatile, there is another source of epistemic bias in decision-making: The conflicts and misunderstandings that arise from differences in expertise, experience, and knowledge. They will increase accidental complexity and decrease motivation and willingness to take responsibility.

The conflicts are not only a negative thing. It is good that the team has diverse backgrounds and expertise. Consequently, you will have misunderstandings sooner or later. The challenge lies in the patterns of resolving these conflicts and learning from them.

You naturally emphasize patterns, practices, and technologies you’re familiar with. At the same time, this bias may have a high price. If you have an architect or a tech lead on the team, they often over-emphasize their experience, expertise, and knowledge.

For instance, it’s common for an architect to be versed in application logic written with object-oriented programming (OOP) languages such as Java, C#, or Python and a lot less on SQL. They tend to prefer ORM mappers without considering other alternatives for a large-scale and performance-critical data pipeline logic. On the other hand, experts with strong SQL backgrounds tend to ignore or undervalue the need for Dependency Injection and versioning. Standard SQL schemas, views, stored procedures/functions, and linked servers (in MS SQL and foreign data wrappers, e.g., PostgreSQL) allow you to implement dependency injection and versioned interfaces with pure SQL and offer alternatives for coordination on the application logic layer in some use cases and provided significantly better performance if you have a lot of data to work with.

Another typical example is from the front-end world. The new CTO, architect, or architect team wants to change or consolidate the frontend framework company-wide. In my experience, the benefits you can gain by changing the framework you’ve used for years are marginal compared to the costs of a complete rewrite of an app.

The series continues...

Read the second article of this series – my top 2 hardest parts of software architecture here. And the conclusion, six patterns that I’ve found useful when struggling with these vicious problems here.