When I first heard the term Cloud Center of Excellence, I’m pretty sure I scoffed derisively. It struck me as similar to things like Six Sigma or ITIL, i.e. a process heavy construction that impeded any actual work from being done. My opinion of ITIL is fairly low, in no small part due to a project I worked on when I was consulting where the organization was ostensibly ITIL compliant. As far as I could tell, it didn’t make them any more efficient or well organized. It simply created a LOT more documents that no one would ever read unless they were trying to make a scapegoat out of someone else for not following procedure when things went south. Turns out I was wrong. About the Cloud Center of Excellence I mean, I’m still fairly certain ITIL is garbage.
In episode 98 of Day Two Cloud, we talked with Fred Chagnon about what it means to create and run a Cloud Center of Excellence (CCoE). Fred was candid about who might need a CCoE and what types of organizations could safely forgo the enterprise. At its core, the CCoE is all about establishing standards and best practices for the rest of the organization to use. But those rules are not unquestionable edicts chiseled into stone tablets stored in an arc of the covenant replica. Daring to defy the CCoE will not result in your face melting into a pool of silly putty.
The CCoE is best applied in organizations that are largely decentralized. Fred talked about a government body that had many departments all with their own IT group and unique needs. My experience with a similar type of organization was higher education. I worked for a decent size university for two years in their central IT department. While we were ostensibly in charge of technology for the entire university, each college had some type of IT department that satisfied the unique needs of their group. The law school in particular ran its own servers and maintained a totally separate Active Directory forest and Exchange org. Central IT couldn’t exactly force any group to get in line with what we wanted them to do, rather we could make recommendations and provide guidance. For instance, the astronomy department had their own set of servers running an ancient version of Linux with no process for patching or performing backups. We had to gently prod them into updating their OS and software to a supported version and add hardware to backup their data.
Would the university benefit from a CCoE? Signs point to yes. We were a decentralized organization with disparate groups that needed technical guidance, but the central IT group couldn’t force them to do anything.
As Fred explained in the episode, the CCoE is there to create and and maintain guidelines for the rest of the organization. As such, the membership of the CCoE should be composed of a representative from each group, department, business unit, etc. in the organization. Each member can bring their unique perspective and business needs to the table and that can be used to inform what goes into the recommendations. As new situations arise, the corpus produced by the CCoE can be updated to include the findings and lessons learned from each member’s team.
The CCoE serves two primary goals. First, reduce redundant learning across the larger organization. Second, document best practices and lessons learned for future use. In a large organization, there may be several groups all trying to solve the same problem independent of each other. For instance, there might be four groups all trying to implement a backup solution for Azure VM deployments. A fifth group may have already figured out an approach that meets the organization’s needs, but the other four groups will never know unless there is cross department communication. If there is a CCoE where this information is documented, now the other four groups can follow the approach pioneered by group five and reduce the amount of time it takes to implement a solution. Sometimes the recommended approach won’t work for one of the groups due to differences in their requirements, and in that case the information in the CCoE docs can be updated to reflect an approach that meets those unique needs. The CCoE is really about formalized knowledge sharing across the organization.
Information doesn’t just come within, a CCoE can also invite outside experts to present potential solutions or best practices. Then they can deliberate whether the external solution makes sense to include in the CCoE recommendations. Once again the idea is knowledge sharing and allowing each group to determine their own path based on guidelines laid out by the CCoE.
Fred also made the point that for a smaller or centrally managed company, the CCoE doesn’t make sense. But I think the principles behind it do. The idea of collecting accumulated knowledge and turning it into a living document has merit. For a smaller organization, they might not have the internal breadth to create such a compendium, but there are plenty of external folks that are willing to share their experience. If I ran an IT department for a small lawf irm, I would try and seek out IT managers from other law firms and see what they are up to. Their successes and lessons learned would inform my approach where applicable.
I didn’t just choose a small law firm out of the air either. While I was consulting, I ended up doing work for several law firms, and I discovered they all chose similar solutions for their common business problems. After chatting with one of the CIOs, I discovered there was a loose network of law firm IT execs who all shared information on a regular basis. They had created a hybrid CCoE that extended beyond their single organization. I didn’t think of it as a CCoE at the time, rather I thought of it as a professional community. Maybe that’s all a CCoE is, an internal professional community composed of individuals looking to share their knowledge and learn from others.
That’s the sort of thing I can get behind!