IT Architecture Reviews, reviewed

Like a dark ritual passed down through generations of tech leaders, the architecture review can be a beacon of hope or a harbinger of doom. And remember: We can and we will try to explore the topic of our chat in full depth, so get ready for a deep story in the old magic 2500 word count!

But just think of a scary story without any turns and spins! Never would one work! So let us move towards the core of our tale!

Let’s illuminate this process through a narrative lens, reminiscent of the slow, building dread. We’re in the realm where technology meets terror, the domain of questionable decisions and unforeseen consequences. In this realm it is quite crucial that any story follows this path: clear purpose, compelling character, conflict, turning point, and a strong resolution.

Our protagonist, the Architect, finds himself amidst the decaying architecture of a digital beast that should have soared. But how well have those architectural reviews helped, and if they missed, what the reason for the missed issues?

Three Fates

Imagine an application, let’s call it “Project X”. It was designed to streamline operations, a digital heart pumping efficiency through the veins of a corporate giant. Project X had passed every checkpoint with flying colors. The Enterprise Architecture Review gave it a gold star for aligning perfectly with the business’s grand vision, fitting snugly into the IT strategy like a hand in a (slightly-too-tight) glove. All boxes were thicked, and all questions were answered appropriately.

The Solution Architecture Review was, just that! The SA review was performed meticulously. This Solution Architecture review had scrutinized the blueprints, confirming that the selected technologies were not just suitable, but could have come directly from a technology magazine. We can picture our Solution Architect happily dreaming about the day his work is mentioned in one of those top-tier publications. But what if they mentioned it in relation with the catastrophe it eventually becomes?

Everyone agreed on this architecture, as it would be reliable, resilient, performant, and scalable. All good stuff, certainly nothing sinister on the horizon! Or?

But beneath the surface, lurking in the custom code and database designs, a malevolence festered. We now reach our conflict as it would be described in Stephen King’s work.

It reminds a little bit on the great works on Edgar Allen Poe! Just remember what he once said: “”Words have no power to impress the mind without the exquisite horror of their reality”

And exactly this exquisite horror will happen soon!

The team went through their “usual” reviews, so when the system groaned under even moderate load, the echoes of failure resonated far and wide, a monstrous cacophony, indeed, the people responsible quickly began to point fingers. The once-lauded architecture reviews were now cast in a demonic light. So many eyes and heads working for all those reviews! Was there now any chance the project would escape destruction? And how?

Why did a project, once hailed as the paragon of digital efficiency, crumble like a sandcastle before a tidal wave? Because in their hubris, our protagonists had conducted many “Architecture Reviews” (mind those air quotes), all singing the same deceptive tune without diving deep enough into the software’s blackened heart.

The Project X software team made one vital and tragic mistake! As their architect, they did not conduct a proper Software Architecture Review. This would be one of the key measures of success to achieve our “compelling character”! We must understand that person and his role to be able to enjoy what follows!

Imagine our Architect. Envisioning our person with an appreciation for design, structural integrity, and above all performance! A software architect deeply cares about custom code, database integrity and all of that “boring” bits and bites. In that dark little server room! Alone. At night. And the air condition blows some extra cold air on him as he steps on a few lose electric wires!

But, just thinking about that situation, our hero knows about the differences! And if we ask our software hero “what is an architecture review anyways”, you quickly see this difference in action:

An Enterprise Architecture (EA) Review. What are they really trying to achieve. This isn’t just any architecture review, and as we go on it should be absolutely no surprise why! You know, Enterprise Architects, and, I hate to say this here because this review really should serve its vital purpose, all you get it some box-thicking exercises with the very people you should try to look at much closer.

With an EA review you, and I cannot repeat this too often, just check on whether there is an “alignment with the overall business and IT strategy.” Nothing more, nothing less, but it is more than meets the eye. An EA might “…review the app against some key principles and standards.” They may find some bits to enhance it here and there, and I really want to underline that word “some”! An EA should touch the big standards of your overall business — but it will fail to see many little (and very bad!) implications. And those can ruin your entire day — and the rest of your life (working for this company, at least!)

And so we are arriving at the Solution Architecture (SA) Review. We know already: the “Solution Architecture review” digs more deeply into a software and solutions architectural decisions. So they also “look … more closely”!

A SA reviewer will “look at the solution architecture to ensure it is robust, scalable, performant” and do a myriad of checks (or at least should they!). But they won’t challenge the core principles. “Why are you building the app this way?” would not be asked. It goes against their inner being! So do not count on them to ask questions of that kind of critical nature!

And, here it comes, we arrive at that one single review to save them all. That one review that just stands apart: The Software Architecture (SO)! This software architect will not leave a stone untouched: SO reviews “look even more closely at the underlying software (custom code, database etc)”

That one SO reviewer makes all the difference — at last in theory!

For all the others, “some are probably thinking well that’s code reviews, not really an architecture thing, it’s the responsibility of the dev team and scrum master / tech leads to get that right. Even the best architecture in the world can’t survive bad code.” But we now know: they might not do a good job — and even an exceptional architecture could end up getting ruined by its execution (in more sense of the word, actually). And our architect would, very sadly indeed, also see the need to agree. “In this particular case there was some gray area where software architecture decisions buried deep down had caused the issues, but you wouldn’t have realized that without going very deep into the design docs or the code itself.”

And thus, this horror story teaches a truth universally acknowledged: A proper Software Architecture review. It’s not enough to align with strategy or to validate the basic tech design; someone must venture into the guts of the machine, where the gremlins of bad coding practices play, making sure the heart won’t fail or ruin whatever infrastructure and software setup you spent all this money on!

Our Project X — as real as it ever gets! Our project passed everything with flying flags, so we can now understand the dilemma easily:

The Project X Team, was good, as “It fit with the strategy very well, it was standards compliant, and the basic design (on top of a well known vendor platform) certainly seemed like it would be reliable, performant and scalable”.

But the code itself — just read through it and you can almost see the ghost of all those poor overworked project teams members that all lost time to some silly mistakes that everyone could have prevented!

And now we start seeing those turning points, the conflicts and those little cracks on the wall from which monsters can peek through at the poor members of the project and operations team!

A Lesson Learnt

And then, after many countless hours of re-doing code, patching here and there, and of course meetings with all those executives, one question should ring at the back of everyone’s head: What did we really, really do wrong?

And to our great relief, and the surprise of many readers that wonder about the magic of our 2500 word count, we arrive at the turning point of our “Power of Storytelling” architecture story. And yes, there is not one “thing”, there were many things involved, indeed.

Just take a peek, and please do not hesitate to shiver slightly as those “cracks” will never get fixed ever again: “it is important to define what “review criteria” are in play for a particular review. This is of course helpful for the reviewers and the project team, but also for leadership, so that everyone understands what kinds of issues will be caught during the review, and what kind will not”. And yes, everyone involved in architecture shall listen up! Those little steps make sure all the world’s greatest enterprise will live up to their own standards and ambitions! And to keep the magic of “a well structured story” up (remember our earlier description) we add an element to that section by having a character who brings a sense of wisdom and closure (that person certainly does not need to be the same person we already referred to!).

We all need closure — to conclude! And what would any architecture story be without it?! And to ensure to not give a way all those hard gained secrets so easily, the following is structured in riddles and allusions and metaphors of the old ways:

In a dark little room of one very powerful software vendor it reads (and, to the horror of many “modern” software vendors and developers they need to bring out some dust cleaning cloths):

1. The true horror lies not in what is seen but in what is overlooked. For the monsters of our tale were not of flesh and bone but of misplaced scrutiny and undefined criteria. Our wise elder in this narrative, perhaps a wizened CTO or a battle-scarred veteran of countless system failures, understands this implicitly. “It’s not enough,” they might grumble in a King-esque Maine accent, “to just check the boxes. You’ve got to lift up the hood and stare into the engine until it stares back.”
2. In the land of technical design, not all reviews are created equal, they cannot be. Nor shall they be! But, how could any project achieve its maximum results with any deviation! Our review process should at least touch any and all of those areas: enterprise, solution and most importantly (not necessarily last!), Software.
3. This is the riddle of scope, the turning point, and understanding: If they really could turn that clock back they had illuminated that distinction, showing a world were everything runs much more smooth! But there must be light! Only darkness and turning all those monsters back into dust is the final part of the story, so please stay strong!
4. Here we get very very dark again, in a true moment of reflection: Consider recent statistical insights into IT project failures, not as mere numbers, but as epitaphs on the tombstones of poorly reviewed projects. The Standish Group, known for its annual CHAOS reports, highlights that a significant percentage of IT projects fail or are challenged due to inadequate design and architecture oversight. Imagine if they had applied our story, we might only have 2 percent now, not, maybe 15 percent! It’s always important to note how relevant and big those numbers are! But wait, did they? Let’s quickly re-assure all our readers to not fall into that trap and show them one final insight:
5. And as we reach the climax, our wise elder reveals the moral of our macabre masterpiece: “Always define your darkness”. It is absolutely key. A proper review criterion!” Only that can guide your steps of success.

Into The Light

And we do, with the dark, alluding wisdom of Friedrich Nietzsche (we could have gone to Arthur Schopenhauer as well!), as only our 2500 words can end:

Only then, our architects, and enterprises architects and those few “pure” solution architect can all breath much, much lighter.

Behold the abyss, for if you gaze long enough, the abyss gazes also into you. It would certainly be beneficial to all of our architects and software vendors to heed this advice and, to venture courageously into the core of software’s dark intricacies, without any “quick tick off the boxes” but “full, deep” investigation! The rewards will more than be worth it.

Find more ways that benefit understanding of enterprise architecture and all those deep bits and bites at https://platformeconomies.com — and get my book on everything IT Architecture now, while you are at it: https://a.co/d/bOqXOoB