Whenever I pick a technical topic to learn and talk about, I start with the problem that I would like to solve.
I have to be honest. There are days when I’m really frustrated with my profession. I have been writing code since I was 16 years old. Professionally, it’s been about 20 years. Despite all these years of experience, here I am, still doubtful if there is a right formula for designing and delivering a technical solution that just works well.
Somehow, most of them turn out problematic. Perhaps, not at first. But as features grow and more people use it, then more problems appear out of nowhere.
Well, as it turns out, it’s not out of nowhere. It’s from somewhere. Lurking within the depths of an intricate mesh of numbers, semiconductors and electricity. It’s in the code. Or across the wire. On the disk. From the signals?
Frankly speaking, the problem is often not from somewhere, it’s from someone. And that someone is sometimes me. Us.
And I’m supposed to be a Solution Architect not a troublemaker. A developer, not a destroyer. This thought pinches my heart every time.
One thing I discovered over the years is, whenever these problems present themselves, a single word seem to take the blame.
Architecture
Data breach? Bad security design. Poor performance? Inefficient code. Unexpected downtime? No redundancy. Misconfiguration? Unguarded deployments. Ridiculous cost? Wrong choice of technology.
These problems happen A LOT. And it’s not just within small companies, it’s prevalent in enterprises, and even within tech giants. It’s costing our society an insane amount of money, and draining us of our limited source of cognitive energy.
I find myself wondering. Is it really that hard? Architecting a solution? If that is the root of the problem, can we solve it?
The truth is lots of people have. Great architects and engineers walk amongst us. We see their thumbprint in every digital product that powers our mundane lives. If they can build great solutions, so can we.
But how?
Perhaps this is not the first question to ask. What we should be asking is, What is a great solution? And for whom?
Being a cloud architect, this pursuit lead me to the landing page of the Azure Well-Architected Framework. It’s a comprehensive body of knowledge that guides us into delivering great solutions on the cloud.
Released back in 2020, the contents continue to evolve to adapt to the ever changing state of the platform. Its content is focused on the most important architectural pillars that a great solution must balance on: Reliability, Security, Performance efficiency, Operational Excellence and Cost optimization.
Used together with the Cloud Adoption Framework, which is best for companies that are starting their journey to transition into cloud-native or hybrid landscape, the Well-Architected framework is helpful for designing new solutions, as well as assessing existing workloads, and not only during adoption but at any phase in your cloud maturity.
To get an insight on how well your application is designed according to the well-architected framework, you can complete the WAF review. It’s an assessment tool that gathers the current state of your solution and recommends actions for fulfilling your target. You can choose to measure a specific pillar, or combine several of them. Just remember that targeting all of the 5 pillars may look good on the drawing board, but it is impractical and most of the time, unnecessary.
While these 5 pillars are all essential to building a great solution within any type of workload and industry, understanding the trade-offs is the real challenge. It’s not about designing the best solution, but finding the most optimal combination of building blocks that is the least problematic. That’s why the framework also includes guidelines for a specific industry or workload, to consider insights and best practices gathered from customers from different verticals that share common targets.
Another vital, but complicated, aspect of a great solution is sustainability. The Well-Architected framework provides design principles and a methodology for building a sustainable solution. It gives us the tools and implementation guidelines that can help us understand the impact of each solution component to our carbon footprint and energy consumption. I believe this should be paramount in our design process.
The Well-Architected Framework is not unique to Azure. All the major cloud vendors have their own. And while the reference architectures are specific to the services that the vendor offers, the underlying concept of the pillars apply to any modern application running on highly distributed and heterogeneous environments. Therefore, it’s important for architects to be aware of the portability of their applications and understand the long-term implication of committing to a specific technology.
Does simply adhering to the framework solve our root problem of bad architecture? Maybe not. But it certainly leads us in the right direction. Designing any dynamic artifact, such as digital solutions, that need to adapt to volatile preconditions, is never trivial. It’s good to have a framework for which the structure can be built on. But remember it’s not an instruction manual nor a bible.
In solutions architecture, there is no such thing as a formula for success. Everything is a mere trade-off.