❗The myth of cloud services - it is not the silver bullet for Information Technology
The leading discussion from every vendor and service provider these days is cloud. Cloud is a big INFRASTRUCTURE deal but not an Information Technology (IT) deal. Cloud solves some problems, creates others but is not the mythical IT silver bullet.
Let us start at the beginning and look at the IT landscape. Here is a simple representation.
This is a representation of IT into its main components of People, Processes and Technology. However, when we look at the risks associated with the IT landscape we have a second dimension of Confidentiality, Integrity and Availability. In more simple terms these can be described as loss, error and fault.
As can be seen the IT landscape thus consists of a matrix of 9 overlapping areas and each one has associated risks and mitigations and a Chief Information Officer (CIO) needs to plan to have controls that cover all these areas.
The following are available for CIO to address the IT landscape.
Thus, in the people’s column, governance is used. In the process column, service management is used while in the technology column, a combination of operations, business continuity and data protection is applied.
If we look at operations more closely, it has two components:
- Infrastructure operations, typically the hardware used for IT.
- Application operations, typically the software used by IT.
The technology needs to be recoverable from disaster situations and protected from breaches of security. This latter area, referred to the area of Information Security operations, can be broken down even further as follows:
The cloud operates as an alternative to privately hosted enterprise infrastructure and applications in a local data centre. However, this might also be termed as private cloud, where the tools of the public cloud such as provisioning and virtualisation are also used.
To be termed as cloud a service typically requires the following attributes:
- On-demand provisioning. The ability for an end user to sign up and receive services without the long delays that have characterized traditional IT provisioning models.
- Ubiquitous network access. Ability to access the service via a range of access mechanisms and devices.
- Resource pooling. Resources are pooled across multiple customers.
- Rapid elasticity. Capability can scale to cope with demand peaks.
- Measured Service. Billing is metered and delivered as a utility service.
There are several cloud related services available to an enterprise in the technology column of which the primary ones are:
- Software as a Service (SaaS) applications are designed for end-users, delivered over the web
- Platform as a Service (PaaS) is the set of tools and services designed to make coding and deploying those applications quick and efficient
- Infrastructure as a Service (IaaS) is the hardware and software that powers it all – servers, storage, networks, operating systems.
Additionally, there are several specialized derivatives such as:
- Recovery as a service (RaaS), which is a category of cloud computing used for protecting an application or data from a natural or human disaster or service disruption at one location by enabling a full recovery in the cloud. This addresses the full computing stack.
- Backup as a service (BaaS) is an approach to backing up data that involves purchasing backup and recovery services from an online data backup provider. Instead of performing backup with a centralized, on-premises IT department, BaaS connects systems to a private, public or hybrid. This address the data stack.
Thus, cloud has started to address a significant part of operations and requirements in the technology column. However, data protection and functional requirements of information security is still an enterprise oversight as is governance and service management.
Governance and service management is also an enterprise oversight even though a cloud tool can be obtained to address operational requirements. As an example, a service desk tool might be available as a cloud service bit that does not automatically address integration requirements into an enterprise’s service management directives. Fundamental IT oversight problems within the areas of governance, service management and data protection cannot be solved with changing infrastructure and application operations to cloud based services. This is one of the fundamental myths of cloud.
Building blocks of a service catalogue
Before an enterprise engages the services of a cloud provider it requires its own documented service catalogue of its existing services. This service catalogue is often populated from an enterprise configuration management database (CMDB). A CMDB is a repository that acts as a data warehouse for IT installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items (CI)), as well as to descriptive relationships between such assets.
At a basic level a defined service is supported by applications and associated with IT infrastructure such as the servers hosting those applications. This is the core building block of a service catalogue.
Next the inter-relationship between the services needs to be clarified as some might have dependencies on each other. In an enterprise, this is more often the case and not the exception.
Each service needs to be fully documented and the functional architecture of the service described and represented in a diagram. The how, why, when, what, where and how needs to be addressed by the functional architecture.
The service catalogue also defines the support and delivery attributes of each service. Without going into depth on each the main functions relevant to the above is change and capacity management. These have special relevance to cloud.
A big problem for a CIO is IT infrastructure capacity and cloud does address this. There is requirement for resource usage, a buffer for peak and then increased requirement for future needs. Cloud is a simple means of addressing capacity problems. However, the flip side is change. The cloud has its own concept of change to an enterprise and for an enterprise to integrate to cloud it needs a strong existing change policy and process. If not the existing problems migrate to the cloud and amplify in magnitude.
Defining the baseline and target IT architectures
The existing service catalogue that has been defined and documented is used as the primary input into defining a baseline architecture. This baseline architecture describes the full functionality and operations of IT.
It is now possible to define a target IT architecture and this captured view can be compared to the baseline to identify gaps and form the basis of a migration plan.
If the target IT architecture has attributes of cloud, then detail required in the migration plan are significant. In many cases a significant hurdle is to address a business continuity process that includes a disaster recovery plan. Another myth is thus exposed. Cloud does not automatically address data protection or disaster recovery. The enterprise needs to have these in place as well as TESTED before dipping their toe into the cloud.
Governance
Governance is the King Kong gorilla of cloud. It must be addressed directly by the CIO and is not addressed by planes hired from cloud providers to shoot it down. The aspects of governance that are relevant are:
- IT strategy;
- Group delivery and execution management;
- Cost management; and
- Risk management.
IT strategy includes policies, standards and practices, innovation, and IT / business service delivery.
Governance insight was provided by Malcolm MacDonald, CEO of Clientele, who contributed the following views:
IT Strategy has several elements to it: IT Business unit strategy ( How IT runs and operates); IT Infrastructure strategy ( What sorts of technology do we need to operate this business), and IT Project roadmaps ( What sorts of projects do we need to do, to take the business where it wants to go).
Some organisations may attempt to link the IT Strategy directly to a business strategy, strategic objective, by strategic objective, but another approach could be to rather assimilate the business strategy, and ask “What sort of IT department do we need to support a business with this business-strategy, and what will it take to get there?” This is like creating a business strategy for the IT Department, given the knowledge of who its customers are.
The Group delivery and execution management element of governance again, can take many forms and follow many different methodologies. “Agility” is a keyword used a lot do describe desirable delivery and execution approaches. It is regrettable when in the light of this, so many organisations still define multi-year, multi-billion rand projects. Agility implies that you have a long-term view, but you commit resources to a short enough time-frame that the business can respond to its environment as soon as the end of that time-frame is reached. For example, let us say that a business decides it must be able to respond to changes after 3 months.
This requires a closer look at how projects are defined; They should: deliver incremental, usable value within each 3-month period, so that if the project were stopped completely at the end of any given 3-month period, what was delivered should be able to stand on its own and be used; and have a defined minimum viable product, so that we know, if the project is stopped before that MVP is delivered, we will not realise any value at all; and have defined measurable outcomes to determine project success or failure, so that we know when the cost/benefit is starting to diminish (as we start to deliver the lower value features).
Some governance features of such an Agile Delivery and execution management approach would be: Quarterly project re-prioritisation (including all relevant executives); a way to measure the capacity and output of the project teams so that all executives are easily conversant with size and scoping concerns, and one can easily distinguish what can be achieved in these 3-month periods; and a traceable project backlog where nothing ever gets lost, and project decisions are tracked.
Although there are some innovations in the cost management and risk management aspects of IT Governance, these are the well-established aspects where slightly less may be gained through governance process innovation.
The Governance processes set the tone for much of what happens (or does not happen) in an IT Department and finding the right processes to fit the organisations needs for formality, tone, and agility can determine whether the business sees IT as a successful partner, or an inhibitor. Therefore, copying and pasting IT Governance approaches, policies and procedures from one organisation to another can be dangerous, and spending time on getting them right is key to the organisation’s effective use of IT to meet its business strategy. Stated conclusively, governance cannot be a template paste from the cloud.
An enterprise that is considering or is in the process of migrating to the cloud would thus be advised to consider the following checklist of its maturity before actioning a cloud project.
- Development of IT policies, standards and practices using identified frameworks.
- Creation and population of a service catalogue including implementing a workable CMDB
- Building and impending a workable change management methodology
- Determining capacity usage and projecting future requirements
- Identifying current risks and recommending mitigations and associated controls.
- Defining the current IT baseline architecture
- Creating a suitable target IT architecture
- Identifying suitable cloud providers that match target IT architecture
- Service level Agreements (SLA) requirements
- Provisioning requirements
- Platform requirements
- Addressing parallel environments for devops in the cloud
- Developing and testing a disaster recovery plan
- Implementation of business continuity
- Execution of IT migration plans to the cloud
- Monitoring compliance of data protection including vulnerability
Please comment or drop any myths below!
👍Driving SD-WAN adoption in South Africa 🇿🇦
6yReposted on the Thinking Problem Management blog.