Crafting the Cloud Native Organization

This is an excerpt from my series on getting your cloud strategy right. I have a webinar covering this part (how to transform your IT department) on Dec 15th, and you can also check out the full text on the topic if you prefer just reading.

The traditional way we think about structuring the IT department is different than how Cloud Native IT departments structure themselves. To massively simplify it, traditional IT departments are oriented around working on projects, where-as technology companies are oriented around working on products.

Traditional thinking tends to focus on service delivery, responding to requests as they come in. Granted, the request may be a large project, but the idea is to have the requester more or less know what they want. The IT department delivers on that and then keeps the service up and running. This is great for the exploit mode of thinking where requesters know what they want and don’t change requirements around too much. However, there are drawbacks to the exploit mind-set. First, it can lead to over-thinking each problem, often called analysis paralysis or solutionizing. In essence, you can end up doing both too much planning and then over-service (doing too much!) to solve an otherwise simple problem. However, there is a big problem with this approach. It is not always appropriate for the type of problem being solved. When the nature of problem is largely unknown, a project mind-set often results in poor solutions.

An innovative, product centric approach is what’s needed in the explore mode—where people don’t know what they want and are often (at first) completely wrong about what they want. Teams in this setting should be more closely attached to the software being written rather than parachuted in as needed. The team’s understanding of the problem being solved, approaches tried in the past, and the overall tribal knowledge will be invaluable in figuring out the right product to build. These integrated teams are not only important for product management continuity but also for ensuring that the product is resilient in production. As outlined back in the greenfield journey post, these teams needs to be kept small small—somewhere between 6 and 12 people—and you want them to have all the skills needed to for the full life-cycle of the product, including development, testing, design, and operations.

When it comes to operations, this is where DevOps plays an enabling role in Cloud Native enterprises. If the team that wrote the application code is also responsible for keeping it up in production, that team will make sure they write resilient code. The team will seek to add operations staff directly to the team rather than leaving that as “someone else’s problem.” Setting up an organization like this requires, not only developers and operators comingled on teams, but creating an organization that supports the cloud platform. This introduces two new roles in IT, the platform operators and the platform developers.

Platform operators are responsible for keeping the cloud platform up and running along with updating the software and infrastructure. Early on, they may be responsible for consulting with the application teams as the organization learns Cloud Native development and operations practices.

Platform developers work on the evolution of the cloud platform itself. They focus on adding in new services like databases, integrations with partners and third parties, and otherwise adding in industry and business specific business logic to the cloud platform. These platform developers are creating a product, one that’s targeted at the company’s developer teams.

As the illustration above shows, the amount of staff in each of these layers reduces as you go “down” the stack. This is because you’re focused on applications as the primary point of customer value, and the most staff are there, exploring and perfecting your software. Next down, especially at first, the platform developers will be a smaller pool but well staffed. The platform operators, in practice, tend to be a shockingly small number—from single digits inr smaller organizations to 10’s or 20’s in very large organizations. Finally, if you’re running all of this on your own— as many Pivotal customers do— you’ll need staff to take care of the raw infrastructure, from the hardware all the way down to the dirt under the datacenter. This is based on the early days of the Cloud Native approach and may evolve, but, so far, this is what has been panning out in organizations that I’ve observed.

This is an excerpt from my series on getting your cloud strategy right. I have a webinar covering this part (how to transform your IT department) on Dec 15th, and you can also check out the full text on the topic if you prefer just reading.