There's been a lot of good conversation about well architected and the well architected framework. And we've written about this in the blog: well architected and SCORP or SCORPS, which is the five and now six pillars of well architected.
So we figured we'd do operational excellence first, the AWS pillar breaks down into three areas. Each area has five or six questions. So the three areas (in the operational excellence pillar) are prepare, operate, evolve.
It's great to go in new areas and teams to asking these questions: Do you know who your users are? Do you know what what the purpose of your team is? Do you know what your highest priority thing is? If you are in a safe space with the whole team involved you can get a really good conversation. It's a good conversation to tease out if you are aligned with the strategic direction? Do you have a prioritisation framework or are you making it up 'on the hoof'?
You have got to prepare to move onto post implementation and hand off to different team or place where you're bringing on new engineers or whatever. Do you have the runbooks for the operations in a particular workload? Do you have the playbooks that are linked to observability in your dashboard, so that when things go wrong, there's a solid set of instructions to deal with that problem and they don't have to go in and unpack what you've built out.
It checks simple stuff like: do you have enough people to meet the challenges? Do you have assigned owners who are going to be responsible for processes, practices and operations. If you can get these foundations in place early, you evolve, go down through the lifecycle and start applying the other well architected pillars. Your chance for success greatly improves because your operational excellence pillar has set the foundation.
The next pillar is operate. So you start with prepare and then move to operate. I like operate because there's a lot of observability. I like thinking of a workload as an asset, how to understand the health of that asset and how to monitor it to make sure it's working well.
It's about getting the team ready for production. There's always something that is going to go wrong, something you haven't predicted or an alternate path has been missed. So when those things happen, have you got the correct procedures for learning what that defect teaches so you can bake it in and toughen up your operation going forward. It's an holistic way of thinking and you need those mechanisms to show you how your workload performance by product.
If you have proper observability you can show the C suite the team working on a particular capability, feature or value stream and how it relates to our vision and strategy. That's proper operational observability across everything including not only the health of your workload, but the health of your team. Door key metrics should be part of how you operate with a sustainable pace for the team.
The last one is evolve. You go through prepare, operate and then evolve. And it's quite simply about how you evolve operations which doesn't mean cutting costs and reducing the budget!
We're big into mapping and evolution is a cornerstone of Wardley mapping. If you don't take these signals from your systems and your workloads on board and use them to evolve improve and get better than there's no point having observability and dashboards.
Your operations are going
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube
Serverless Craic Ep8 Well Architected Operational Excellence Pillar