Could you survive a cloud architecture walkthrough?

I’m always on my best behavior when I review someone else’s enterprise cloud solutions. It’s bad form to call their baby ugly, and there could be a good reason why the baby is ugly. I never jump to conclusions, and I leave my own bias at the door until I understand the complete picture. 

The importance and potential impact of the technologies selected, why they were chosen, and how they are configured loom large for the business. In my line of work, it’s not unusual to find a business that spends double what they should, with inefficiencies that hinder some of the core business features. I’ve even seen businesses go under because they stood by their poor technology decisions while their competition disrupted their market and ate their lunch.

And so the architecture walkthroughs (aka architecture audits) begin. To no one’s surprise, the CEO or CFO typically requests these walkthroughs and sometimes the board of directors. The CIO, CTO, or others in enterprise IT rarely originate these requests. 

Here are a few tips for both auditors and auditees to successfully navigate an architecture walkthrough.

Don’t play the blame game. Understand that the objective is not to find fault but to find ways to make the current solution more cost- and technology-efficient and thus produce a greater business benefit.

Understand the context of why these decisions were and perhaps are still being made. For instance, a security solution may have been picked for its ability to support automated compliance, even though its overall features may fall short as a security solution. 

Explore alternative technologies as well as the cost and risk of leveraging these alternatives. In many instances, the selected technology is not optimal, but the cost of switching it out far exceeds any potential benefit gained.

Realize that either party might be wrong. Imagine that the architecture evaluation recommends that the encryption level be enhanced to lower the risk of data breaches. However, this recommendation does not account for the resulting performance hit that will make the database nearly unusable. That fact could easily shift or eliminate the recommendation. Making architectural decisions in the narrow can result in architectural mistakes made in the wide. 

Finally, learn to work together. This is the tough one. Everyone needs to put forth a unified front at some point even if there is disagreement about the evaluation and the recommended changes. At the end of the day, both sides should have the needs of the business in mind. Figure out a way forward that creates an architecture strategy, technology solution set, and practices that will never be 100% optimized but come very close. Have a plan in place to make incremental improvements. 

A good architect accepts notes from others, either from inside the organization (such as a peer) or from outside the organization (often in the form of an architecture walkthrough). In my younger CTO days, I viewed evaluations from outsiders as a huge distraction. Now, I realize that getting input from as many smart people in my orbit as possible was a key to my success, as was understanding that I still had to make the tough calls at the end of the day. 

For an architecture walkthrough, my advice is to seek out help from talent you trust and listen to all the advice from others who have “been there and done that.” Knowledge is always a useful tool.