Two things come to mind when you hear the phrase Cloud Center of Excellence:
- Cloud financial management. You have invested lots of money but are you getting value and cost optimization?
- How good are those people at cloud adoption and cloud management? Excellence is a big goal.
You can answer those questions when you work with the COE. If you are allowed to interact! Too often, a COE becomes a central governing body with a one-way interaction. This limits its effectiveness and cloud maturity. And gets everyones back up.
Central management of cloud initiatives is key
The CCOE needs to be a central body of knowledge to drive cloud and product in the right way. Effectiveness is based on disseminating that knowledge across the rest of the org. If this is done to a high level then your organisation can competing on a level playing pitch with Amazon, Google, Open-Source, the internet and other successful cloud organisations.
When a Cloud Center of Excellence is badly established, you will provoke a negative reaction. Dev teams rarely react well when “the experts come to show them how it is done”.
Why is Serverless adoption different for a Cloud Center of Excellence?
Many companies have started on their cloud services journey. They have gathered information and carried out some deployment. So don’t move backwards and ring fence a whole department to “figure out cloud transformation”. You are beyond the skunkworks.
The cloud journey moves too fast for development teams to disconnect, pause and restart the process. You need to get comfortable with engineering teams solving their problems in the moment. Serverless is incremental. Knowledge and developer experience is acquired and built on the job.
Pioneers, Settlers and Town Planners
Simon Wardley describes how different talent is required depending on what stage of innovation you are at. He defines them as Pioneers, Settlers and Town Planners. For Serverless, you are going to need pioneers.
For serverless, you are going to need pioneers
As Simon describes:
“Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder but they fail a lot. Half the time the thing doesn’t work properly. You wouldn’t trust what they build. They create ‘crazy’ ideas. Their type of innovation is what we call core research. They make future success possible. Most of the time we look at them and go “what?”, “I don’t understand?” and “is that magic?”. In the past, we often burnt them at the stake. They built the first ever electric source (the Parthian Battery, 400AD) and the first ever digital computer”.Simon Wardley
The Cloud Center of Excellence experts need to be on your team. Do you need to treat them differently? They are learning, exploring and experimenting. So do you need to lead them differently? What guardrails should you give them?
This depends on your organization. Maybe you treat every team as experimentation innovators? If so, good for you! I’d be surprised if you are not Serverless already.
How do we share knowledge over time?
It comes back to knowledge, as it often does in technology. The correct advice at the right time can save millions of dollars for your org.
Knowledge management becomes a problem when your org has over 100 people. Team A figures good practice based on their project. Team B is doing something completely different. But there are shared patterns. Teams will talk and spend time sharing ideas, but you can’t share everything, all the time. You will start to hear the phrase “I didn’t know you did that” more often.
Reams of documentation won’t help either. One critical part of Team Topologies six principles is the enablement team.
What are the six principles?
Watch the Team Topologies talk. It explains what I have laid out here in detail:
Team of Expert Enablers, Early Wins and The Ambassador Role
- Team of Expert Enablers are typically teams of experts in a specific area that collaborate with stream-aligned teams to help them gain the capabilities that they are missing. It can be anything from test automation to build engineering architecture stuff. They have an enabling role. They bridge the gaps that the stream-aligned team have in the way they build and deliver software.
- Early wins are the best way to convince stakeholders, partners and peers in your organisation as well as your customers. It’s very hard to describe this approach with principles, statements and diagrams. You need to actually do something. And the results will be much easier to talk about. Plus, you will get unexpected benefits.
- The Ambassador role is critical as you need to link the executive narrative to engineering practices. The teams will start moving really fast. So you need someone to ensure the rest of the organisation is comfortable. A key group here is security. As the old methods will not work.
Reusable Patterns, Engage and Evangelise and Scale
- Reusable patterns are a game-changer. Sometimes a Cloud Center of Excellence will advise on reference architectures. But Serverless moves too fast. Something like www.cdkpatterns.com has to be the starting place. Once you give your engineers a bunch of accelerators or lego blocks, they will go fast.
- When you have the structures in place, you must Engage and evangelise. At this point, you have lowered the bar to entry, so you help other teams make the leap. Using hands-on sessions with “show and tell” is very effective.
- Finally, the ability to Scale the approach is crucial. As many teams start to use Serverless, you need to think about how you can help and support without creating a bottleneck. One approach worth looking at is AWS Well-Architected – Serverless Lens.
You can create a serverless Cloud Center of Excellence
You can create a serverless Cloud Center of Excellence. But don’t imagine it as a swanky office, in the new part of town, full of scooters and bean bags. Some of your teams will lead by example and start to push ahead. Encourage and support them. Then bring everyone else along and invest in making it happen. The critical part is the investment. Don’t cross your fingers and hope it happens by accident. And don’t hire it in. You already have the people – support them.