It is usual, also for mid-sized Companies, to have the IT infrastructure distributed among at least three data centers, probably located in different countries. And they can be a lot more, depending on the scale and the cloud adoption strategy.
On-premise data centers
Traditionally, a data center is considered an on-premise (meaning being not on the public cloud) facility in which servers running your Company’s services and applications are hosted or simply housed. A Company may own it or rent a part of it (colocation), leveraging on Companies which often operate on a global scale.
Public cloud data centers
But if your Company has also active IaaS contracts with one or more cloud providers, then you’re managing a portion of their data centers too, as you need at least to:
- build a reliable connection to their data center;
- define your network zones (or compartments);
- set-up your virtual (or even physical) infrastructure;
- define security measures;
- define identity & access management solutions;
- set-up monitoring and logging approach.
IT Infrastructure Strategy and Service Models
As CTO, you are in charge to define the IT infrastructure strategy, which also declines the service model for each of your data centers, ensuring their best interoperability, and maximizing the total value for your Company.
Service models define who’s doing what and are described in the contracts your Company signs with service providers.
On-Premise Service Model Strategy
With on-premise data centers, normally you sign full or partial IT outsourcing contracts.
When designing an IT infrastructure outsourcing strategy, there are at least the following factors to be considered:
- decision drivers and desired outcomes: for example, financial (i.e. saving money), service quality improvement, focus on strategic areas of IT and business, cloud journey strategy, or a mix of them;
- which assets the IT organization wish to keep “hands-on”, and why. I believe IT infrastructure (meaning computing, networking and storage solutions) can be more and more considered a commodity, especially when adopting the infrastructure as code pattern;
- infrastructure provisioning model, which can be dedicated to your Company (bought or rented) or shared;
- IT infrastructure resources consumption agreements: APIs exposure and lifecycle management responsibilities become a key factor for speed and standardization when transforming how the IT infrastructure is provisioned and managed (for instance with infrastructure as code initiatives);
- architecture evolution and innovation management positioning: while accountability is for sure on the Company side, a strong partner stimulating evolution and innovation initiatives can be a great asset;
- service model review: how to add, remove, transform services within the contract. Things are moving fast, and in my opinion, you need to be able to change your contract accordingly to catch opportunities as they emerge (such as moving workloads to the cloud, insourcing, developing new integrated/hybrid services, integrate new services).
Public Cloud Service Model Strategy
When looking at public cloud contracts, shared responsibility models apply. Here you can find AWS and Microsoft Azure ones.
Such models define which responsibilities are retained by the cloud provider and which are assigned to the customer. As service models change moving from Iaas to Paas to Saas, responsibilities grow on the cloud provider side.
It is important to fully understand these models before committing to service contracts.
Your cloud infrastructure strategy should consider the topics discussed for the on-premise scope (most are valid) and, at least:
- overall Company cloud adoption strategy (here you find AWS, Microsoft Azure and Google Cloud adoption frameworks) and IT architecture strategy, such as decoupling, microservices, and cloud native principles;
- make-or-buy management model: what your team should retain as directly managed scope;
- how to configure cloud “data centers”;
- cloud providers use cases specialization (IaaS, PaaS, SaaS or technology patterns for instance);
- impacts on the on-premise workloads;
- compliance constraints.
Managing it all
(Photo by Antoine Julien on Unsplash)
So you’ve signed (or you’re going to) one or more of the above contracts. Everything is ok then right? Not at all, unfortunately.
Hybrid and multi-cloud scenarios
Ideally, you could run one or more specific services within each service agreement, but rarely interoperability isn’t needed.
Use cases for hybrid workloads are proliferating: at a minimum, you need good connectivity solutions (ensuring low latency and resilience), but often end-to-end business services rely on distributed workloads between different data centers.
And to make the picture even more complex, public cloud providers are increasingly offering “cloud at customer” solutions, to enforce data-driven compliance and latency use cases for example. Here you can find AWS and Microsoft proposals.
Service Governance
To face such a (growing) complexity, as CTO you need to ensure at least:
- having an end-to-end view of IT processes (such as IT operations, incident management, cost management, compliance);
- ensuring the balance between emerging technology patterns and quality of service and sustainability;
- executing an on-going change management process, seeking HR department support to enforce the “Retained-IT Organization” role;
- establishing a strong contract, vendor and cloud governance frameworks, to ensure continuous service improvement, a smooth decision-making process (e.g. where should be put a new workload), compliance and KPIs measuring and actioning (such as spending, resilience, and performance);
- ensuring a “service excellence” mindset, which leads to challenge the service model constantly and seek for improvements;
- performing regular skills gap analyses and define training and hiring plans;
- ensuring a risk-based action prioritization;
- express strong leadership.
Write your IT Infrastructure Strategy Down
I suggest to write your IT infrastructure strategy document down in a comprehensive format, such as word or alternatives, or even better by using the markdown language, which can be easily shared, versioned and contributed by your teams and peers.
Integrations and dependencies will become clearer while doing it and will probably generate opportunities to integrate and improve the whole IT Strategy.
(Photo on top by Kyle Glenn on Unsplash)