Something we talk about a fair bit is the well architected tool. It’s starting to gain popularity in the software industry. Grady Booch tweeted about it a short while ago. He is a fantastic software architect who has done a lot of pioneering software engineering. He says that it’s a good thing that AWS, Azure and Google are offering guidance on building with their well architected tool. But he also warns that when cloud providers talk to you about well architected, it comes with a bias towards their products.
Cloud provider bias and applying the well architected tool
There is an inherent bias among providers who are investing in these frameworks. They will have a certain leaning towards their own ecosystem and services. There’s a big but here! I think you’ll find that they are broadly applicable.
The interesting thing about the AWS framework is if you squint at it sideways, you can extract the implementation details. And focus on the principles and values behind delivering a well architected solution. You can abstract a huge amount of value from them, even if you don’t embrace the services aligned to that cloud provider.
You can run the well architected tool independently
I have run well architected framework pillars on non AWS. I work primarily with AWS. But I’ve run pillars, like the operational excellence pillar with squads who are not working directly in AWS. It’s the collaboration, questions, mindset and thinking that are good. And they are fairly consistent across whatever tech stack or platform you’re leveraging.
There’s always going to be bias towards the cloud provider. As you’re going to be working within certain constraints or conditions when you are working on one platform. The questions are very similar. And the answers may be a little bit different. But even just asking those questions is hugely valuable. And as long as you apply it to your context, you can get a lot of value.
Helping non technical colleagues to understand architecture
I remember having discussions with people who were asking what architecture is? They weren’t quite sure what architecture was and were trying to redefine architecture. With less technical colleagues, you need to give them a definition of what architecture is.
Also I remember presenting a comparison of the three cloud providers to prove that well architected is a thing and not just something I made up! And from the comparison, I found that all three cloud providers had roughly the same stuff.
However, AWS is driven by principles or tenets. But a lot of the principles in the framework are applicable elsewhere. It is a clean framework that you can reuse. Azure is almost like a wizard as it was taking you on a path, which was probably good 90% of the time. But I always worry about what happens if that’s not right for you. And Google was really nice, but the bar was quite high. It was pretty much be hardcore SRE, or we don’t want to talk to you. The culture of each of the providers came through with the framework, which I thought was interesting. But I thought they were all really good frameworks.
If you leverage AWS you are going to be EDA
I think the statement that well architected comes with a bias towards our products is fair. With AWS, if you leverage a lot of AWS services, you’re going to be EDA. So that is going to bias you towards operating in certain ways and leveraging certain ways of communication. Whether it’s Kinesis, EventBridge or SQS SNS to connect things together. It’s just a statement of fact.
If you’re going into these spaces, you’re going to be working in a certain way. If you are leveraging AWS in the cloud, you need to be working in EDA, and you’re going to be biased towards leveraging those services. With Google, I am interested to see why they’re focusing so much on SRE. Maybe there’s a requirement on squads to look after resources when they are up, because it’s more container oriented. The folks at Google perhaps believe that customer success is driven through proper SRE and operational excellence.
A lot of the SRE principles came from Google. We’ve met people who put original work together while they were at Google.
Should you ask a cloud provider to do a well architected review?
A cloud provider will write a framework in their own language. And it will have a bias towards their own products. So you need to see that difference. The second thing is, if you ask a cloud provider to do a well architected review on your product, you will get a solution architect from that cloud provider to come in and do it. And all they know is their products. So if you get an AWS solution architect to review your product, they’ll start recommending AWS products.
That was a big learning for me. Because I thought, I would like to use this, but I don’t want to have to keep asking the solution architect to come in to sell AWS stuff. The lesson is that it’s not the framework, it’s the process that you put around it. And the process does not need to involve the cloud provider. We can run that ourselves. And we can apply the framework ourselves. It is a big shift, to use well architected as a benchmark to self assess.
You need to be brave and apply your own context. Let’s ask these questions and run this process against our workloads and see what lessons we can learn. And where can we learn, measure and improve?
Establish your own feedback loop
The great advantage of doing this yourself is that your feedback loop is established. So you’re actually seeing what works, what doesn’t work and where your gaps are across all the different pillars. And where you should be investing your time and your team’s time across the org. if you bring in somebody external, they don’t have the context. And they’re not going to be part of that feedback loop.
Plus it is quicker. Last week I was talking to somebody about ‘well architected’ and we decided to do it that afternoon. You just sit and do it. You don’t need to bring some person in and then get them up to speed. And end up with a big delay.
The accessibility of the frameworks
One great thing about these frameworks is that they are out there and publicly accessible. They are not in a secret magic book on a vendor’s desk that only high paying customers get to read. These things are moving to commodity status. They’re commodity capabilities that you can google. And you can enable and empower teams to do this themselves. They can ask these questions because they are freely available.
And you can read about it in our book. Along with the process of enabling teams to do it themselves with a little guidance and advice. That’s important because if the team needs help, somebody senior in the company can come and help them. If you need more help, you can bring the cloud vendor then, because you’re working on the same framework. In other words we’re doing this pillar, and we’re having problems with these three questions. The cloud vendor can go straight because there’s a benchmark there.
Common language is critical. Because the org are delivering well architected solutions, the cloud vendor can figure out what that means for them and their colleagues.
How can you combat cloud vendor bias?
When you use Clarity of Purpose, which is Phase 1 of the Value Flywheel, with the well architected framework, you can combat bias. Your focus will be on solving the problem with the tools you’ve got at your disposal. And you’re able to leverage tools faster and more efficiently. So the bias actually works to your advantage.
It isn’t something that your architect does to you. This is something that the team should be embracing themselves through an iterative and incremental process. We’ve written about this a lot in our SCORPS process, which is in the book as well. It doesn’t need to be a big, scary thing that an architect from on high comes down and imposes on you. It can be a very useful learning and enablement tool.
The well architected tool becomes your benchmark
You need to constantly self assess. Small continuous improvement paves the way to significant gains. Well architected is the benchmark we baseline ourselves against. And we revisit that every couple of weeks to check how we are against it. That’s how you build world class squads, teams and outcomes.
Give Grady Booch a follow on Twitter. Search for ‘Grady’ ‘Well’ ‘Architected’ to find that tweet and discussion. Our SCORPS process is in our blog on TheServerlessEdge.com. There’s a nice post that Mike put together. There’s a good chapter in the book on how to apply well architected with a set of instructions.
It’s based on that continuous improvement idea. And again, it goes back to the Long Term Value phase of the Value Flywheel. I’m glad that Grady Booch is getting some attention, because it is a really important topic. There’s a lot more we need to do to educate people on how important this concept is. Because architecture is ambiguous for lots of people.
No matter what cloud you are in, seek out their well architected guidance. Don’t custom build your own approach. This stuff’s been hardened and proven across 1000s of implementations. It has been battle proven and road tested. You’re getting learnings from hundreds of solution architects in the field who are on that framework.
So that’s the craic. Those blog posts are on TheServerlessEdge.com and in our book The Value Flywheel Effect, which will be published in November. So follow us on Twitter @ServerlessEdge and at Serverless Craic on YouTube.