The Optimized CIO

^{The importance of parallel innovation in a cloud-native world.}

Over the last decade, organizations around the globe have been slowly but surely migrating their applications to the cloud. There are a number of reasons for the move, but the ability to move quickly and at scale when unexpected global events arise is, for obvious reasons, one of the most important benefits of transitioning to cloud-based apps.

That said, if your company—like many of the Fortune 500—invested hundreds of millions of dollars in highly customized enterprise resource planning (ERP) software, you know that the process of moving all those workloads to the cloud is painstaking and complex. So you start all app development with the cloud in mind and then use APIs to connect to those straggler custom workloads still sitting in one of the data centers you were hoping to shut down.

Of course, your IT teams still need to ensure the health of your services—both customer- and IT-facing—no matter where they live. So as you go through this, you have to manage multiple worlds that are likely on various public and private clouds. In addition to maintaining your service operations, you need to make sure you’re building capabilities to centrally manage governance, cost, risk, and security. That’s a lot to juggle, and CIOs dealing with this situation are probably feeling less than optimized.

That said, there’s a fourth category we should be talking about: the cloud-native application.

While the lift and shift of workloads to the cloud is mostly about shutting down data centers, the motivation to move to cloud-native is much more focused on optimizing for parallel innovation. From a business standpoint, the goal is to move to distributed teams, Kubernetes (K8s), microservices, and a new software development lifecycle paradigm.

The question is, what is the interplay between the cloud-native software development lifecycle and service operations? Turns out, it’s problematic.

Independent by design

Cloud-native IT teams are independent by design, which has both benefits and drawbacks.

You want your app dev teams to be able to create and scale their services without asking anyone for permission. On top of that, you want them to be able to make thousands of changes, fast. Many teams today deploy between 5,000 and 10,000 times a month, compared to the monthly or bimonthly cadence of previous generations of technology.

This independence is risky and generally out of alignment with enterprise-wide governance.

When the dependencies from those services are unknown, a parallel stream of incidents can pop up. That’s when the confusion happens.

From a service operation standpoint, if the cloud-native teams run off in a different direction, you end up with a lack of visibility into what’s running on a microservices level. When the dependencies from those services are unknown, a parallel stream of incidents can pop up. That’s when the confusion happens.

When the push toward independence and autonomy goes too far, even the most thoughtful policies meant to enforce enterprise-wide governance, security, and risk are tossed out the window. This is especially true of the cloud-native crew.

Does this sound familiar? Don’t worry—you’re not alone.

To contend with the complex, dynamic, and ephemeral nature of a modern cloud-native environment, enterprise organizations—from innovative and mature cloud-native companies to traditional enterprises—need technology beyond tools designed for the “lift and shift” cloud-transition era. And they need it at a scale larger than ever before.

This is where ServiceNow can help. By bringing together service operations and harmonized cloud-native observability in the service operations landscape, CIOs can understand the customer, end user, and spend impact of their microservices. This allows them to align your centrally managed governance policies throughout the org—even cloud-native application teams.

That’s what it means to be an optimized CIO. It may be easier said than done, but it’s the only way to go.