I've worked with many internal and external customers, and I think I'm finding a common thread with service delivery practices in all of them. Most of them appear to struggle to find a balance between fighting fires; focusing on small, specific work items or improvements; and ensuring that the work they are doing is also achieving their high-level goals or strategy.
It's easy for teams to get lost in the day-to-day, focusing on the most burning issues or the highest priority project items and getting them done with the lowest possible effort (read cost) so they can move onto the next thing. I'm not sure if this equates to complacency with how teams deliver services, but I think it does lead to outcomes that aren't providing the highest value for those teams, and most teams wouldn't even be aware that they are missing out.
Credit: https://hbr.org/2000/07/stop-fighting-fires
From my observations, it's common for operational teams to suffer from endless break-fix issues or specific low-level maintenance activities like software updates but never get to work that might reduce the overhead of actually performing those tasks. The latter is what I would consider being high-value work because your team's time is much better spent on customer-focused work or kicking goals for your company.
So why is this a problem? Mostly I think it comes down to a choice made by stakeholders. Small tasks and maintenance aren't as sexy when you're telling your boss or customer what you've achieved, especially compared to delivering some shiny new product or feature that's likely to make money. Those kinds of tasks also are never as important as putting out a fire.
So how do we get to do all the small things? Well, I think there are many ways to achieve this, but I think most involve large-scale cultural change and broad buy-in from stakeholders. You could strategise to adopt managed services or mandate your teams undertake automation to achieve that kind of goal - both pretty good ideas! Adopting those kinds of changes can be very challenging, so today, I'd like to discuss an approach we're adopting using the Well-Architected Framework.
Hello, Well-Architected Framework!
For those not familiar with the framework, I'd like to introduce you. The Well-Architected Framework provides teams with consistent guidance, and best practices across five pillars (focuses or domains) learned from AWS and its customers over the years. Users can use the ideas conveyed in the five pillars to frame how they design, build, operate and improve their workloads, and we've been doing this at Modis since well before our AWS practice started.
In my view, a crucial part of adopting the AWS Well-Architected Framework is making use of the review process. AWS provides questions that speak to each of the pillars (and lenses), which can help you understand where there might be room for improvement in your workload's implementation or your operational processes. AWS provides a tool in the console (and a set of APIs) that can help you integrate reviews into your processes and mark milestones, which allows you to see your improvements over time.
Additionally, many AWS Partners (like Modis) are experienced in conducting Well-Architected reviews and can bring substantial knowledge to boost the value of the review process. I like to recommend customers use both the self-assessment approach and engage a partner because it helps balance their internal and external knowledge of a workload. I think of partner reviews as providing some diversity of thought but for architecture!
Before each review, you should prioritise the pillars according to what you want to improve on for that workload. After a review, you will likely have a set of findings that allow you to direct your focus. If you don't, then that's awesome (see here), but it's these findings that are the key to finding workload balance without needing immense change.
Where the backlog meets Well-Architected
Once you've picked which findings from the review are the most important, I'd implore you to have a look at your backlog and talk to the teams who own those workloads. I'm sure there's overlap between tasks in the backlog or things your teams want to do and those findings.
As I mentioned before, those tasks are probably in your backlog because they don't sound sexy to your stakeholders. Using the Well-Architected Framework to collect and group those tasks, though, can start to sound good. It is easier to articulate the value of a workstream to stakeholders in the context of the framework than just the task.
Using the review process to help bucket your tasks together isn't an obvious way to use the framework, but it should help you get the work to be of a size that your stakeholders will accept.
OK, but how is this different from just bucketing the work together?
I'll accept that it's not hugely different. I've worked in many teams that do precisely this; save all the small items up and make a project of it. I think the big difference that I see in using the Well-Architected Framework to do this is two-fold.
Firstly, your stakeholders are most likely already bought into the reviews at the strategic level. Because of this, the bucket of work is more likely to be aligned to their goals. Your stakeholders are much more likely to approve work that's perceived to be meeting their goals than work where it's harder to draw that link.
Secondly, and more importantly, if you use the framework as an incremental review tool (not one-and-done), it will guide you, long term, to architectures and processes that reduce the amount of this bucketing you need to do in the future. The less of this bucketing you are doing, the more time your team has for the shiny stuff!
I hope I'm convincing you that using the review as the yardstick for your backlog bucketing doesn't need to change how your teams are working and can help you get traction where you aren't getting it.
A shameless plug
I work as the Well-Architected lead for Modis. If any of what I've talked about resonates with you, please reach out. We're well-positioned to help you conduct a review and structure an improvement plan to address the findings. If you've not thought about it before, we can assist you in integrating the Well-Architected Framework into your strategy or operational practices.
As I mentioned earlier, if you aren't getting to that work because it's not shiny enough, one other helpful strategy is to bring a partner in to help you deliver it. As an AWS Partner, we've been using the framework to ensure our customers' workloads are secure, reliable, performant and cost-effective for a long time; it's baked into our DNA.
Wrapping up
I hope that I've shown you a different way to use the Well-Architected framework to add value to your workloads and maybe kick a few extra goals.
I should say, while I focused on AWS (because that's right in my wheelhouse), many other cloud providers have adopted the frameworks and what I've covered isn't strictly an AWS only topic.
For those of you who've read this far, thanks for reading! I appreciate it. If you have feedback, please send it to me!
Oh, and for those that don't have any findings - please consider reaching out. I'd love to talk to you about how you can go further and get even more benefits! That's a post for another day.