This presentation explored the importance of service management in the cloud and explore what is needed to build an operating model for the governance, assurance, and day to day operation of cloud services.

1. We’re Migrating to Cloud – Who
Needs Service Management?

2. Agenda
• You need to do this;
• This is why;
• Here’s the inspirational story to back it up;
• If you don’t do it you’ll die;
• Here’s a case study that focuses on what was achieved but gives no insight
into how; and
• This is what will happen in the future – you MUST do this!
No, we are not going to do that!

3. The basics: why cloud?
Reasons can include:
Greatly reduced implementation times
Cost savings
Faster innovation cycle
Resilience
Optimised resource utilisation
Better responsiveness

4. Cloud – Someone else’s computer?
The generally accepted definition of cloud computing
from the US National Institute of Standards &
Technology (NIST):
A model for enabling convenient, on-demand network
access to a shared pool of configurable computing
resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly
provisioned and released with minimal management
effort or service provider interaction.

5. The Five Essential Characteristics
• On-demand self service
• Broad network access
• Resource pooling
• Rapid elasticity
• Measured service

6. Cloud Service Models
• Software as a Service (SaaS) – Using the provider’s
applications running on cloud infrastructure. Perhaps the most
well known service model due to the success of some
providers (e.g., Salesforce, Workday).
• Platform as a Service (PaaS) – In addition to core
infrastructure components, provides the software platform on
which higher component such as applications can be built.
• Infrastructure as a Service (IaaS) – storage, computing
capabilities, networks and other fundamental resources.

7. Cloud Deployment Models
• Public Cloud
⎻ Available to public or large industry group
⎻ Owner by the Cloud Service Provider (CSP)
• Private Cloud
⎻ Operated solely for one enterprise
⎻ Managed by enterprise or a provider
⎻ May be on- or off- premise

8. Cloud Deployment Models (cont.)
• Community Cloud
⎻ Shared by several companies
⎻ Supports a shared mission or interest
⎻ Managed by an enterprise or a provider
⎻ May be on- or off- premise
• Hybrid Cloud
⎻ Combination or two or more deployment models that are
unique entities
⎻ Bound by standard or proprietary technology enabling
data/application portability (e.g., cloud bursting for load
balancing)

9. An analogy with PizzaaaS

10. So how do you do cloud – like this? No!
How much of our technologies are misunderstood?

11. And certainly not like this!
How many governance and management failures can you spot?

12. So why do we need Service
Management?
Let’s ask some simple questions …

13. Who will the business call if there’s an issue with
the cloud service?
Not my problem. Call the cloud
service provider.
How would that work? Wouldn’t
business users expects call the
Service Desk and let IT handle it
from there?

14. What if there’s planned maintenance in the cloud
which impacts one of more of our internal systems?
That’s out of our hands. We don’t
manage the cloud and don’t have
access to their change system.
Surely your internal change
management process should still
be able to account for this
through a change risk & impact
assessment?

15. What if your critical business processes are
impacted by a cloud related problem?
No problem. I’ll hold the cloud
service provider accountable!
Best of luck with that! The
business will still see IT as
accountable.

16. What if the cloud suffers a breach of sensitive
personal data you store there?
No problem. I’ll hold the cloud
provider accountable per the
contract!
Moving a service to cloud does not
absolve an organisation from its
duties of care and accountability to
legal & regulatory requirements.

17. Finally, what about Service Management?
We’ve moved to cloud – we don’t
need Service Management!
Are you sure about that? From the
previous questions it seems you have
some homework to do!

18. Summary so far
• Do your homework
• We still need a Service Management processes
• Cloud doesn’t govern itself – we are still
accountable for governance & assurance
• In short, we need an operating model.

19. POLISM: Elements of an Operating Model1
Processes
• How work is done to
provide outcomes that
deliver value
• Each service process
should deliver an
intrinsic value that can
be measured through
KPIs
• What service processes
do you have that will
need reviewed and
amended for cloud?
• What additional service
processes do you needs
for cloud (e.g., Supplier
Management)
• ITIL, ISO/IEC 20000 and
COBIT® are good
reference sources
Organization
• How are the services
processes and their
value chains mapped
into organizational
structures across the
organization and the
CSP?
• What are the required
roles and skills for each
and do they need to
change for cloud?
• What are the essential
processes that cross
multiple parts of the
organization and/or CSP
(e.g., change
management)
Locations
• Where are the service
processes executed?
• Where are physical
assets?
• Where is the data?
• What intellectual
property considerations
are there?
• What are the governing
legal & regulatory needs
of each location?
Information
• How is each processes
supported through
information systems?
• Service Management
toolsets?
• Trusted sources of data?
• Electronic integration of
sources (e.g., APIs)?
Suppliers
• What suppliers (in
additional to the CSP)
are needed to support
the service processes?
• What is the nature of
collaboration with each
supplier?
• What are the policies
governing selection and
oversight of suppliers?
Management
System
• What are the oversight
processes for planning,
assigning actions, setting
targets, making
decisions and measuring
performance to plan?
• How is the management
system itself managed?
• How is continual
improvement managed?
1 – Based on the “Operating Model Canvas” – see further reading.

20. For each POLISM element of the operating
model, follow a CSI approach
• The vision links to
o Organizational goals & objectives
o Governing policies
• Gap analysis of where we are to where we
need to be (next)
• Plan/Do/Check/Act, adjusting the vision where
necessary

21. It’s all about the processes
• The core part of the operating model are the
service processes
• This is where the where outcomes are delivered
and value provided
• Where to start? Configuration Management and
the CMDB is a fitting starting point!

22. The whole world is a CMDB
• For thousands of years we’ve come to rely on
machines of increasing complexity
• Machines are built from many components working
together to do something of value and generate the
desired outcomes
• IT systems are like any machine – components must
be connected in the right way for it to work to deliver
what we expect (utility) and how (warranty)

23. Dodgeball
A Case in Point:
CMDB mapping of the “Dodgeball” SaaS application
Configuration Item created – job done! Or it is?

24. Dodgeball
Fireball
A Case in Point:
CMDB mapping of the “Dodgeball” SaaS application (cont.)
But Dodgeball is part of a business
critical service offering

25. Dodgeball
Fireball
Dodge-In Dodge-Out
A Case in Point:
CMDB mapping of the “Dodgeball” SaaS application (cont.)
But Dodgeball is part of a business
critical service offering
And it relies on an essential data
feed from this system
And in turn provides an essential
data feed to this system

26. Dodgeball
Slowball Fastball
Fireball
Dodge-In Dodge-Out
A Case in Point:
CMDB mapping of the “Dodgeball” SaaS application (cont.)
But Dodgeball is part of a business
critical service offering
And it relies on an essential data
feed from this system
And in turn provides an essential
data feed to this system
And has a critical dependency on
this system …
… and this system.
The Lesson: even SaaS needs service mapped in the CMDB

27. Assignment of control across components
Components native to the
CSP’s CMDB can be brought
into your own CMDB (e.g., via
API/e-Bonding) with suitable
governance and controls
around their consumption
and maintenance

28. COBIT®5 View (ISACA) vs. Cloud Controls Matrix (Cloud Security Alliance)

29. Simple Process Model
Quality
Parameters
& KPI’s
Process
Owner
Resources
Process Activities
Process Control
Process Enablers
Output and
Output Specifications
Process
Goal
Roles
Input and
Input Specifications

30. Simple Process Model
Quality
Parameters
& KPI’s
Process
Owner
Resources
Process Activities
Process Control
Process Enablers
Output and
Output Specifications
Process
Goal
Roles
Input and
Input Specifications

31. Example – Change Management
Process Control
Process Enablers
Outputs:
o Deployed RFCs
o CAB Minutes / Actions
o Change Management Reports
Inputs:
o Change Schedule – Internal
o Change Schedule – CSP
o CMDB
o RFCs
Owner:
Change Manager
Goal:
o Minimise adverse impact of
change upon service quality
o Assess potential benefits of
change against risks and
costs to the organisation
o Ensure correct methods and
procedures used
KPIs:
o Number of RFCs implemented on schedule
o Number of RFCs bypassing CAB/EC
o Number of incidents caused by change
Process Activities:
o Record
o Review & Assess
o Risk & Impact Assessment
o Approval to Proceed
o Build & Test
o Approval to Implement
o Implement
o Post Implementation Review & Close
Roles:
o Change Manager
o CAB
o CSP
Resources:
o Service Desk
o Support Groups
o ITSM Tools
o Documentation
o Training
o CSP
Note: bulleted lists
are not exhaustive

32. Client versus CSP Responsibilities
• How does each service process need to change
to accommodate cloud (e.g., change in
responsibilities)
• How does the hand-off occur?
• A RACI (Responsible, Accountable, Consulted,
Informed) mapping of roles is essential

33. RACI Example – Configuration Management
• Simplified RACI – covers “R” only
• Quicker and simpler to develop in the first
instance
• “A” usually cascades up the organization
• The “C” and “I” activities often occurs through
forums (e.g., CAB) and electronic notifications
from service processes from ITSM toolsets
No
Level
ProcessStep
Service
Integration
&
M
anagem
ent
Configuratio
n
M
anager
Desig
n
Authority
Enterprise
Architect
Configuratio
n
Data
Ow
ner
Requirem
entsO
w
ner
R A A,R C I
1 1 Configuration Management Process
1.1 2 Configuration Planning
1.1.1 3 Define Configuration Management Strategy A R C C I I 1 1 0 2 1
1.1.2 3 Define Configuration Management Policy & Standards A R C C I I 1 1 0 2 1
1.1.3 3 Define Configuration Management CSFs/KPIs A R C C I I 1 1 0 2 1
1.1.4 3 Define, collaborate and test requirements that consume CMDB A C I C R 1 1 0 2 1
1.1.8 3 Define IT Business Process for consumption of CMDB A C I C C C 0 1 0 4 0
1.2 2 Configuration Identification
1.2.1 3 Define CMDB Design Principles A R I C C C 1 1 0 3 1
1.2.2 3 Define Data Model - conceptual, logical, physical A R I C 1 1 0 1 1
1.2.3 3 Define CMDB Configuration Management Process Artefacts A R I C C C 1 1 0 3 1
1.2.4 3 Provide non-discoverable CI data A C R I 1 1 0 1 1
1.2.5 3 Facilitate auto-discovery of discoverable CI data A C R I 1 1 0 1 1
1.2.6 3 Confirm completeness of CI data estate A C R I 1 1 0 1 1
1.3 2 Configuration Control
1.3.1 3 Maintain Configuration Data A C A I 0 2 0 1 0
1.3.2 3 Facilitate auto-discovery of discoverable CI data A C R I 1 1 0 1 1
1.4 2 Configuration Status Accounting
1.4.1 3 Provide / Facilitate generation of Configuration reports A R I I 1 1 0 0 1
1.4.2 3 Provide / Facilitate generation of Configuration related metrics/KPIs A,R 0 0 1 0 0
1.4.3 3 Coordinate & oversee CMDB continual improvements A R C C C I 1 1 0 3 1
1.5 2 Configuration Verification & Audit
1.5.1 3 Plan and conduct audit A R C C C I
1.5.2 3 Report on CMDB audit outcomes A C R 1 1 0 1 1
No
Level
ProcessStep
Configuration
M
anagem
ent
Configuration
Practitio
ner(Adm
in
)
Configuratio
n
Data
Ow
ner
Service
ProcessUser
ITSM
Platform
Adm
inistrator
1 1 Configuration Management Process
1.1 2 Configuration Planning
1.1.1 3 Define configuration scope, policy, strategy and governance & controls R
1.2 2 Configuration Identification
1.2.1 3 Define, establish and maintain Configuration Data Model - conceptual, logical and physical R
1.2.2 3 Define, establish and maintain configuration management process workflows R
1.2.3 3 Establish and maintain trusted data sources into the Configuration Management System R
1.3 2 Configuration Control
1.3.1 3 Ensure configuration data updates are incorporated (where needed) as part of Change Management R
1.3.2 3 Provide and maintain configuration data (and approve process user requests to update configuration data R
1.3.3 3 Provide administrative and technical support to process users and configuration data owners R
1.4 2 Configuration Status Accounting
1.4.1 3 Define and report on agreed metrics and Key Perfomance Indicators & Key Risk Indicators R
1.5 2 Configuration Verification & Audit
1.5.1 3 Coordinate & oversee periodica verification & audit of configuration data R
1.5.2 3 Perform periodic verification of configuration data and perform remediation activities R
Simple RACI – “R” only
Full RACI – all actors

34. And what about governance, risk and security?
How risk level maps against cloud service and deployment models

35. The IT Risk Management Lifecycle
• Risk Scenarios drive risk identification
• The Cloud Security Alliance (see Further Reading) is an excellent source of information and
template for cloud risk assessments
• Assessment should align with enterprise risk governance so risk portfolio and measures
are in true business terms
• Risk response options include accept, avoid, transfer/share, or mitigate
• Since inception of SOX, controls have become highly prevalent in the treatment of IT risk
and legal & regulatory compliance:
• Many are preventative, detective, corrective
• Can also be managerial, physical or technical in their implementation
• And additionally directive, deterrent, recovery and compensating controls

36. Interdependencies between Control Types
Interdependent controls are designed against risk
Scenarios, which for cloud are different to in-house

37. The Five Pillars of Cloud Security
• Service Management!
• Organization
• Technology
• Security and Data Protection
• Governance, Compliance, Legal and Audit

38. The Five Pillars of Cloud Security
Service Management
• The POLISM model we’ve discussed
• The contracts are king – ongoing effort to actively manage them
and service levels is essential
• CSP should be assessed on ability to integrate service
management with the customer to manage availability of services
with seamless execution of critical service processes
• Also requires the CSP effective capacity management to handle the
concurrent load of multiple customers in shared environments.

39. The Five Pillars of Cloud Security
Organization
• This must start with your organization’s strategy for
adoption of cloud based service
• Must include human resource planning
• What is the retained organisation and how are
relationships managed with the CSP
• Good Organizational Change Management is needed to
adapt business processes and organizational structures
to make cloud adoption a success.

40. The Five Pillars of Cloud Security
Technology
• This is a key driver to cloud computing – access to
technology and rapid innovation
• Interoperability and compatibility of new technologies with
legacy/heritage need considered.
• IT Architectures needs re-considered
• A different systems development lifecycle is required
• A different support model is required.

41. The Five Pillars of Cloud Security
Security and Data Protection
• Internal data typically leaves the trusted network perimeter bringing data protection
challenges
• Security of data at rest
• Security of data in motion
• Cyber threats can be both internal and external with collaboration needed between
customer and CSP
• Cloud environments can be more secure
• Don’t expect the CSP to follow your security policy
• Business Continuity should be an integral part of security as part of the CIA
(Confidentiality, Integrity and Availability) trio.

42. The Five Pillars of Cloud Security
Governance, Compliance, Legal and Audit
• Legal requirements must consider the industry and legal
jurisdiction(s) you are operating in
• Governance processes need to be able shared
responsibilities between the CSP and your organisation.
• Contracts need to include terms for cascading of
outsourcing partners
• Need to ensure a right to audit clause

43. Summary
• Do your homework
• Use POLISM to develop an operating model
• Understand the service processes you have and the ones you need
• Map the RACI for your processes, being clear of the hand-offs with
the CSP
• Use the Five Pillars for security and assurance of cloud services.

44. Further Reading
Operating Model Canvas (Van Haren
Publishing)
https://operatingmodelcanvas.com
Cloud Security Alliance – Cloud Controls Matrix
https://cloudsecurityalliance.org
COBIT®5 – Controls & Assurance in the Cloud
http://www.isaca.org/Knowledge-
Center/Research/ResearchDeliverables/Pages/Controls-and-Assurance-in-the-Cloud-
Using-COBIT-5.aspx

45. ITSMF UK
Premier Gate, Easthampstead Road, Bracknell,
RG12 1JS, United Kingdom
Tel: +44 (0) 118 918 6500 | Web: www.itsmf.co.uk