Grady Booch is a fantastic software architect who has done a lot of pioneering software engineering. One of his latest messages says that it's a good thing that AWS, Azure and Google are offering guidance on building with well architected. But he also warns that when cloud providers talk to you about well architected, it comes with a bias towards their products.
There is an inherent bias among providers who are investing in these frameworks. They lean towards their own ecosystem and services. But 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.
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.
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.
When you compare all three Cloud Providers, they roughly have the same stuff. But AWS is driven by principles or tenets. A lot of the principles in the framework are applicable elsewhere. Azure is almost like a wizard as it takes you on a path, which is good 90% of the time. And Google sets the bar was quite high with hardcore SRE. The culture of each of the providers comes through. But they are all really good frameworks.
A cloud provider writes a framework in their own language. And it will have a bias towards their own products. If you ask a cloud provider to do a well architected review on your product, a solution architect from that cloud provider to will 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.
The lesson to learn is that it's not the framework that's important. 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 to learn, measure and improve. 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.
When you use Clarity of Purpose, which is Phase 1 of the Value Flywheel, with the well architected framework, you can combat that 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.
It should not be 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.
Grady Booch Search for 'Grady' 'Well' 'Architected' to find that
Hi folks. Welcome to the next edition of Serverless Craic with Dave Anderson, Author/Contributor at The Serverless Edge and Technical Fellow for Bazaarvoice.
Mark McCann:
Hi everyone. Mark McCann, Architect at Globalisation Partners and Author/Contributor at The Serverless Edge.
Mike O'Reilly:
Hello! Michael O'Reilly, Architect with Globalisation Partners and Contributor at The Serverless Edge.
Dave Anderson:
Something we talk about a fair bit is well architected. It is something we've been using and speaking about for a while. 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. I have seen him speak at conferences and he is absolutely brilliant. I'm a massive fan. He says that it's a good thing that AWS, Azure and Google are offering guidance on building with well architected. But he also warns that when cloud providers say well architected, it comes with a bias towards their products. Folks, dissect
Mark McCann:
I think you have nailed it. There is an inherent and discuss! 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 we'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.
Mike O'Reilly:
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. I'm not saying there are traps in well architected. Because I think it is fairly balanced. But 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.
Mark McCann:
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.
Dave Anderson:
I agree with Grady. He makes a really good point. There are two things I looked at from the start. First of all, I remember having discussions with people who were asking what is architecture? They weren't quite sure what architecture was and were trying to redefine architecture. That sits uncomfortably with me. For people like Grady, that's not even a question. It's like, hello, what are you talking about? With less technical colleagues, you need to give them a definition of what architecture is. The second thing is the comparison between the three cloud providers. I remember presenting the comparison to prove that well architected ss a thing and just something I made up! And from the comparison, I found that all three cloud providers had roughly the same stuff. But AWS is driven by principles or tenets. 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.
Mike O'Reilly:
I think the statement of being aware 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 its 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. Google perhaps believe that customer success is driven through proper SRE and operational excellence.
Dave Anderson:
A lot of the SRE principles came from Google. We've met people who put original work together while they were at Google. What is interesting is when you ask one or two things, a cloud provider will write a framework in their own language. And it will have a bias towards ther own products. So you need to see that and see the 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 the 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.
Mark McCann:
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 we can learn, measure and improve? The great advantage of doing this yourself is that your feedback loop 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 teams 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.
Dave Anderson:
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.
Mark McCann:
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 the 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. And the process of enabling teams to do it themselves with a little guidance and advice.
Dave Anderson:
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.
Mark McCann:
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.
Mike O'Reilly:
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.
Mark McCann:
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.
Mike O'Reilly:
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. No matter what cloud you are in seek out their well architected
Dave Anderson:
Give Grady Booch a follow on @Grady_Booch 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. And there's a good chapter in the book on how to apply well architected with a set of instructions. And 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 ambiguous for lots of people. 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. Thanks very much, everybody.