The essence of architectural work - Part 4
Home
About
Services
Blog
Resources
Categories
Contact
View more posts
The essence of architectural work - Part 4
In the previous post, we discussed the economic purpose of architecture. The economic purpose is probably the most emphasized facet regarding the Why of architectural work, yet hardest to grasp in its entirety and the hardest to get right. However, this does not mean that the other facets would be of less importance. But as they do not immediately emphasize time and money, they are often pushed aside in our highly commercial environments. Nevertheless, depending on the situation, getting these facets right can have an even bigger impact on time and especially money than the economic facet. Hence, let us discuss these other two facets of the purpose of architectural work in this post:
The cognitive purpose
The humane purpose
The cognitive purpose of architectural work
At a very basic level, software development is a mapping from a problem domain to a solution domain.
The problem domain consists of all the needs and demands that define and constrain the solution. Many stakeholder groups frame a vast amount of immediate and contextual requirements. This comprises not only the functional requirements but all explicit and implicit requirements that shape the solution. Additionally, the problem domain consists of myriads of facts as well as interconnections and dependencies between them that define the problem domain and in which all the aforementioned requirements are embedded.
Ideally, we would take all these needs and demands and directly translate them into a solution implementation, taking all the encompassing facts and their interrelations into account.
Drowning in problem domain details
The problem is the sheer mass of details on either side of the mapping. We are confronted with thousands, if not millions, of facts, interrelations, requirements, explicit and implicit wishes, demands, whims, and more on the problem domain side. What makes things even more complicated:
Many of the demands contradict each other. Sometimes the contradictions stem from different stakeholders. Sometimes, it is even the same person not realizing (or caring) that they created contradicting demands.
Many of the demands do not fit into the existing solution design (if a solution already exists). Most people only care about their current demands. They do not care about how their demands fit into an existing solution. They only care that their demands get implemented.
Many of the demands are never spoken out. They are just silent expectations that will be held against you later (“It should be obvious that …”) if you fail to elicit them from the respective stakeholders. Good architects develop a sixth sense for these kinds of demands over time.
And so on.
It is an art in itself to make all relevant needs, wishes, and demands explicit, resolve the contradiction and organize them in a comprehensible way. Personally, I doubt that AI agents will become good at that because all this has to do with the “messiness” of humans, their egos, and more 1. But this is a different story, I do not intend to discuss here.
Let us simply assume we would be able to gather all the required facts and interrelations, elicit all needs, wishes, and demands from the stakeholders involved, resolve all contradictions, and organize everything in a comprehensible way. These would be many more details than any human can grasp and consider simultaneously while designing and implementing a solution.
Software engineers drown in an abundance of problem domain facts and details.
Drowning in solution domain details
It does not look any better on the solution domain side:
We need to understand the details and intricacies of the programming language used.
We need to understand the possibilities and intricacies of the language’s ecosystem.
We need to understand the frameworks and libraries used.
We need to understand the runtime infrastructure, middleware, and environment, its products, tools, and applications.
We need to understand the development environment, its options, challenges, and quirks.
We need to understand the existing solution: what is put where, how the former facts and requirements were translated into code.
We need to understand the APIs we need to connect to, their commands and data structures, and how to access them.
And so on.
It is not only that we need to know where all the already implemented facts and requirements are located in the solution. We also need to understand everything else that shapes the solution domain. These are many more details than any human can keep in their head at once. In short:
Software engineers drown in an abundance of solution domain facts and details.
A losing game
Now, let us assume we would try to map all the requirements directly onto the solution with nothing...