The Heart of Architecture

Posted September 16, 2020 | Technology |
The Heart of Architecture

Your vision will become clear only when you can look into your own heart.
Who looks outside, dreams; who looks inside, awakes.
                    — Carl Jung

An architecture is designed collaboratively. Architects are also, sometimes, part of the collaborative process. Yes, “also, sometimes, part of.”

Sometimes, it is only when we invert something do we see a reality that is somewhat different from the way we assumed it to be. Incorrect assumptions arise because the words get in the way of sound thinking. So, when we say, “X is the architect,” it may mislead us into thinking that X alone is doing the architecting. Any architect engaged in complex enterprises would confess that it is not he or she alone who drives the architecture’s shape. If you have an off-the-record conversation with an architect, you may even get an acknowledgment that architects sometimes are left out of the loop in major architecture decisions! The softer assertion of an architect’s role that this Advisor began with may therefore be more helpful in understanding and dealing with the reality on the ground rather than a clear “X is the architect” assertion.

This collaborative nature of architecture in enterprises is what makes it so challenging, intriguing, and even vexing to those who are entangled in what is a very multidimensional process.

Architecting in a Multidimensional World

Problems are multidimensional. We know that, of course. We can lay these things out as clear criteria along rows of a spreadsheet that we can then use as measuring sticks to calibrate different ways of doing things that we array along as many columns as we would like. Alas, spreadsheets are nice, regular, and geometric — but human beings are not. They are highly irregular, asymmetric, and, sometimes, not so nice.

Decision making can be a difficult task even when it is undertaken by a single individual, if there are multiple factors that might have influence on the direction of the decision. The issue is not so much the ability to enumerate all the factors; it is the relative emphasis that is placed on different factors. We can weight the factors on the spreadsheet, of course. But that can cause illusions. When we say that cost has a weight of 10, but reliability has a weight of 7, can we have confidence that that does justice to the actual nuances of what exists in the real world? And in our preferences and priorities?

Decision making is a “weighty” process, and when the weights are distributed across multiple heads, normalizing these weights and aggregating them is not a task for the faint of heart.

Architecture in Heads … Or Hearts?

“Be data-driven!” is the rallying cry in enterprises that seek to be objective and rational machines rather than to capitulate to being victims of human fickleness and whimsicality. But organizations are not fully peopled by machines – at least not yet. So a clearer awareness of “who we are” is important in a world that is a mix of the digital and the physical, the rational and the irrational, of spreadsheets and “head-sheets.” Or more correctly, “heart-sheets.”

An incident comes to mind. I engaged a group of young and eager MBA students to innovate for a few weeks in a complex enterprise. The executives were excited and supportive of this initiative. There was at least one idea that came out of this “free thinking” project that was considered brilliant and significant by the management committee responsible for vetting these ideas. But it didn’t move forward. One of the committee members said it best: “I love the idea! But I can’t take this to the people upstairs. They won’t get it.”

The Architecture “Solution” Is Not the Solution

It is easy enough to see actual demos and proofs of concepts that show what it is that can be accomplished by implementing in a certain way and to use these as inputs into the scoring process that accompanies architecture trade-offs across different solutions. While these activities can help surface issues and gaps that were not well understood, it is less clear that they help us in weighting what matters more and what matters less. The weights are assigned to the dimensions of the problem, not to that of the solutions that are arrayed as paths to address the stated problem.

The right architecture solution is rooted in getting the enterprise focused on the right architecture problem that includes the right weightings of the dimensions of the problem and having the right dimensions in the framing of the problem in the first place.

The discipline of architecture is not in the artifacts, the spreadsheets, and the diagrams. It lies in the hearts and minds of the people who collectively make the decisions and in how they frame and weight the problem to be solved. The definition of the problem is a complex negotiation that is conducted in the background, as “solutions” are posited and examined, and as new information is discovered, and as hearts and minds move during the process of “solutioning.”

There are methods and artifacts that can help in staying focused on this critical part of the architecture process. One of these is explicitly called out, for example, in the TOGAF’s “stakeholder management” section. But more than such artifacts, what is more important it is the deeper recognition that something of this nature is needed at all to getting the architecture right.

Do you think your enterprise does more than pay lip service to this “heart of architecture”? Tell me what you think. Post your comments at the link below, or send email to

About The Author
Balaji Prasad
Balaji Prasad is a Senior Consultant with Cutter Consortium. He is President of the strategic architecture firm, Eminnode LLC. Previously, Mr. Prasad served as an EA leader within Cognizant’s Global Banking and Financial Services Practice and as CTO and Chief Architect for various large enterprises, including EDS (now HP Enterprise Services), General Motors, OnStar, and The Hartford Financial Services. With 30 years’ experience in IT leadership… Read More