Could you survive a cloud architecture walkthrough?

I’m always on my best behavior when reviewing someone else’s cloud business solutions. It’s rude to call your 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 get the big picture.

The importance and potential impact of the technologies selected, why they were chosen, and how they are configured are important to the business. In my line of work, it is not unusual to find a company that spends twice what it should, with inefficiencies that hamper some of the core functions of the company. I’ve even seen companies go under because they kept their bad technology decisions while their competition disrupted their market and ate their lunch.

And so begins the architecture tours (also known as architecture audits). To no one’s surprise, these tutorials are usually requested by the CEO or CFO, and sometimes by the board of directors. The CIO, CTO, or others in enterprise IT rarely originate these requests.

Here are some tips for auditors and auditees alike to successfully navigate an architecture tutorial.

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

Understand the context why these decisions were made and perhaps are still being made. For example, a security solution may have been chosen for its ability to support automated compliance, although its overall characteristics may be insufficient as a security solution.

Explore alternative technologies as well as the cost and risk of taking advantage of these alternatives. In many cases, the selected technology is not optimal, but the cost of changing it far outweighs any potential benefits gained.

Be aware that either party can be wrong. Imagine that the architecture assessment recommends that the encryption level be improved to reduce the risk of data breaches. However, this recommendation does not take into account the resulting performance impact that will make the database almost unusable. That fact could easily change or remove the recommendation. Making architectural decisions in the narrow can result in architectural mistakes made in the width.

Finally, learn to work together. This is the difficult one. Everyone should present a unified front at some point, even if there is disagreement about the assessment and recommended changes. At the end of the day, both parties must consider the needs of the business. Find a way forward that creates an architecture strategy, a set of technology and practical solutions 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 within the organization (as a peer) or from outside the organization (often in the form of an architecture tutorial). In my days as a young CTO, I viewed external evaluations as a huge distraction. Now, I realize that receiving input from as many smart people in my orbit as possible was the key to my success, as well as understanding that I still had the tough decisions to make at the end of the day.

For an architecture tour, my advice is to seek the help of talents you trust and listen to all the advice of other people who “have been there and have.” Knowledge is always a useful tool.

Copyright © 2021 IDG Communications, Inc.

Leave a Comment