CLOUDY VISION?

SEE CLEARLY THROUGH STRATEGIC ARCHITECTURE.

Clearly, moving to the Cloud can t just be a

shiny technology driven change. Given a

justified business case wrapped up in both

Business and IT Strategy is essential, lets now

take a look at how we can use architecture

as a method for introducing Cloud-based

changes to an organisation.

Ensure you have an established vision for your enterprise, as well as an approach to

operationally realise that vision – defined Business Objectives and Strategy;

Ensure you align your Cloud Strategy to your Business Strategy – defined common

approaches to achieve common objectives; and

Govern the implementation of your Cloud Strategy to ensure it continually delivers relevant

and beneficial results to your business.

In short, declare the intended future for your business, rather than leave it cloudy.

Flexi-ScaleScale up or down, in or out -

flexibility is baked into most Cloud

Services. Such operational agility is

significant driver for cloud adoption

and potentially a competitive

advantage.

Disaster RecoveryRobust Cloud-based backup and

recovery solutions for organisations that

lack expertise or investment.

Maintenance AutomationManaged infrastructure platforms

mean automation of patches,

security and software updates –

focus on growing your core business

not commodity IT.

CapEx ZeroPay as you go subscription model IT

service consumption rather than

purchasing, housing and maintaining your

own hardware and the skills needed to put

it together properly. Run costs (OpEx)

clearly increase, but big up front lump sum

payments all but disappear.

Collaborate!Share documents and data anytime,

from anywhere, updating and

sharing a vision in real time. Wrap in

workflow to add suitable process

governance and control – single

version of the truth – no more email

file attachment chaos!

Flexi-WorkingAny reasonable bandwidth internet

connection and you can get to work,

regardless of location – work / life balance

positive without productivity compromise.

Quality Cloud services are also not

restricted to supporting specific devices.

SecurityCloud isn t necessarily less secure than on

premises – trust is key, security is a joint

responsibility with the Cloud vendor, skills

and proof of defence in depth are essential.

Lost laptops and expensive data? Cloud

data stores negate the impact of lost or

compromised devices.

Non-Critical Workloads

Only?Cloud isn t only for Dev / Test,

Mission Critical use (combined with

business continuity capabilities off-

Cloud) may well work for your

business.

Migrate to GainLift and Shift migration to the Cloud

doesn t necessarily infer Cloud benefits

out of the box – your applications may

well need rewriting to properly utilise

Cloud native services in order to truly

gain the benefits e.g. auto-scaling etc.

CompetitivenessCloud delivers enterprise-class technology for all. Small

businesses can punch above their weight, acting faster

and disrupting established markets. The big guys find

new ways of connecting their dispersed siloes into an

organisation greater than the sum of its parts.

Egg BasketsOne Cloud Service approach and one

vendor may not be a sensible strategy,

while keeping things simple and

achievable in the short term, it makes

sense to have a plan that encompasses

the breadth of options available.

Cloud everything ...isn t necessarily a sensible strategy, Cloud may not be

right for your business at all. Analyse to understand

where it s best used and quantify the gains. TCO spread

over the service life as OpEx isn t necessarily cheaper in

the long term, consider ICT maturity and change agility,

adapt governance and budgeting to properly account

for Cloud utilisation – measure bang for buck carefully.

Cloudy Technical

PerspectivesVirtualisation and Private Cloud are

not the same thing, the latter

requires the former plus a Cloud

Platform ecosystem of capabilities.

The essential ingredient in defining both Business and Cloud Strategies and controlling

the risks associated with change projects, is Architecture. Architecture need not be

verbose and dull, nor can it be an ivory tower of theory, never based on real world

business operation. Architecture done right can be understood by all, business and IT. It

becomes an agent of managed change, not an impediment to agility. Use Architecture

to unambiguously communicate your enterprise vision, break down the siloes of

business and IT transformation, and ensure integration of common goals and

approaches. The rest of this series of articles explores an architectural methodology for

defining your Cloud Strategy, but before we begin properly, let s first recap on the

potential benefits and a few of the misconceptions surrounding the Cloud.

Investing in the Cloud should be like investing in anything, a considered business. To avoid

piecemeal or point solutions you need to take a step back from the hype and stop dabbling. Avoid

the temptation to rush in without first establishing a strategy for using this technology in a way

that makes sense for your business. Cloud computing objectives are not IT specific, don t leave

Cloud decisions to your IT capability. The Cloud is ultimately a tool for agility and efficiency – it

empowers you to focus on your core business rather than Cloud technology itself. When

establishing a Cloud Strategy for your business:

CLOUD ARCHITECTURE

RISK

COMPLIANCE

GOVERNANCE

Core Cloud

Strategy

VISUALISE YOUR THINKING

Cloud

Operational

Strategy

Cloud Risk

Mitigation and

Governance

Strategy

ICT

MATURITY

ASSESSMENT

TOTAL COST

OF

OWNERSHIP

CONNECTION

OPTIONS

SOFTWARE AS A SERVICE (SAAS)

PLATFORM AS A SERVICE (PAAS)

INFRASTRUCTURE AS A SERVICE

(IAAS)

MULTI-CLOUD

CLOUD

HYBRID

PUBLIC

PRIVATE

OUTSOURCED

OPERATIONS

AND

LIFECYCLE

MGMT

APPLICATION

MIGRATION

STRATEGY

ON PREMISES

Having decided Cloud capabilities are potentially beneficial to your

business, where exactly do you start? What decisions do you need to

make and in what order? What should you communicate, to whom and

how?

What s needed here is a methodical, consistent, comprehensive and

repeatable approach to defining how and why things are going to

change. Architects and the architectural methodologies and tools they

employ (such as TOGAF and Zachmann etc.), typically provide the

assurance in this space – we won t deal in generalities here, instead we

will apply architectural approaches directly to our area of interest: all

things Cloud.

Let s begin with the Cloud Reference Model, illustrated here. One formal,

but not necessarily digestible explanation of what a Cloud Reference

Model actual is, could be as follows:

SECURITY

Core ICT Strategy

a high level or abstract Cloud-domain specific framework, containing

formal naming and definition of the types, properties, and

interrelationships of the entities that really or fundamentally exist,

produced to encourage clear communication and comprehensive thinking.

Put more simply: a visualisation of the things you should consider and

how they relate to one another in the Cloud context.

What follows is a methodology that will see you work your way through

this reference model, developing a robust and operationally realisable

approach to employing Cloud technology in your business.

First, the contentious topic of definitions! Having supplied a visual

overview of Cloud, I must also declare what I mean by each and every

part of this model, as grouped into four main categories:

Public and Private are all about Tenancy: with Outsourced IT, Hybrid, Cloud and Multi-

Cloud, an organisation must choose whether to utilise Public managed services – those

used in a partitioned multi-tenant fashion, or Private managed services – those dedicated

only to them. Tenancy can be at different (technically distinct) levels: hardware sharing,

hypervisor sharing, platform sharing and software sharing. Organisations rely on the vendor

to ensure that their service levels are met regardless of the demands made by other tenants

in the shared service and that there is adequate partitioning to prevent security breaches or

accidental operational interference. Anything dedicated to your sole use (Private), is more

expensive.

Hybrid is a combination of both one or more vendor s Cloud Platforms (see below) and On

Premises or Outsourced IT. The key to Hybrid is integration – without integration (network,

apps, data, security etc.), you are effectively operating infrastructure and data siloes that will

add to your technical debt and reduce your agility. Hybrid can also be On Premises or

Outsourced given some Cloud Platform vendors / technologies can be installed on your

own infrastructure or that managed for you. These include the open source Open Stack

and Microsoft s Azure Stack. The latter could be an excellent Cloud migration pathway for

strong On Premises IT shops that utilise MS technology – Azure and Azure Stack are both

underpinned by MS Hyper-V virtualisation hypervisor. If your IT is Outsourced, you can

also have your Hybrid environment outsourced – indeed it likely makes sense. Hybrid is an

overloaded term – many also use it as a combination of Public and Private Cloud but I

won t – I feel the two tenancy models are not so much a hybrid, more of a cost / benefit /

risk decision on per application or service basis. Likewise you could say multiple vendor

Cloud Platforms used together are a hybrid. Again I won t, for me this is Multi-Cloud.

Software as a Service, being owned, delivered via a Cloud Platform and managed remotely

by one or more providers, the software being typically based on one set of common code

and data definitions. The software application is consumed in a one-to-many model by all

contracted customers at any time on a pay-for-use basis or as a subscription based on use

metrics. Just about any software you can imagine can now be accessed from the healthy

Cloud Platform marketplaces and SaaS vendors, from core enterprise application services

such as email, anti-virus and so on, through the gamut of possibilities in content;

collaboration; communication; visualisation; finance etc.

Core Cloud

Strategy

Cloud

Operational

Strategy

Cloud Risk

Mitigation and

Govn. Strategy

Core ICT

Strategy

CLOUD ARCHITECTURE

RISK; COMPLIANCE;

GOVERNANCE

ICT MATURITY;

TCO

CONNECTION

OPTIONS

SOFTWARE AS A SERVICE

(SAAS)

PLATFORM AS A SERVICE

(PAAS)

INFRASTRUCTURE AS A

SERVICE (IAAS)

MULTI-CLOUD

CLOUD

HYBRID

PUBLIC

PRIVATE

OUTSOURCED

OPERATIONS AND

LIFECYCLE MGMT

APPLICATION MIGRATION

STRATEGY

ON PREMISES

SECURITY

REFERENCE MODEL ONTOLOGY, AKA WHAT I MEAN WHEN I SAY...

Cloud-native Infrastructure as a Service, rapidly evolving capabilities that typically include a

virtual package of servers of various sizes; storage; databases and network services like

firewall, load balancing and content caching delivered from shared, multi-tenant data

centres. IaaS is typically purchased on a usage-based, metered plan without contracts or

term commitments, although reserved resource subscriptions are also available, as are the

potentially cost effective marketplace concepts of Spot instances (AWS) and pre-emptible

VMs (Google). Typically, your experts would architect, code and execute your IaaS

implementation, then manage it just as if it were On Premises, including patching,

deployments etc. Security remains a joint responsibility between the subscribing

organisation and the Cloud Platform vendor.

With Platform as a Service, the consumer manages applications and data, while the

platform provider (in public PaaS) or incumbent IT or outsourcing partner (in private PaaS)

manages everything from the runtime to the hardware. These are platforms on which you

can host your own combination of enterprise applications. Tooling provided with the

platform takes care of tenant customisation, service monitoring and management, database

integration, versioning, security and so on. Vendors have created specialised PaaS offerings

and made them available on a variety of Cloud Platforms, including Integration Platform as

a Service (iPaaS) and Mobile Platform as a Service (mPaaS).

Technically, an internet connection is all that s required. Enhancing security over this

connection, Secure Sockets Layer (SSL) historically and now Transport Layer Security (TLS)

are commonplace at the application layer (Layer 4). For SaaS scenarios, this is usually all

that s needed, however, reliability, latency and security concerns may lead to an evaluation

of further options: Point-to-Site (P2S) and Site-to-Site (S2S) Layer 3 Virtual Private Network

(VPNs) connections and / or Virtual LAN (VLAN) Layer 2 Ethernet-like services, either of

which will connect to IaaS and PaaS offerings via Cloud Platform edge or peering services.

Typically the Cloud-native services available for consumption are related to the geography

of the connection point, but globally available services may be accessed via upgrade.

Separated from the internet, security and service guarantees, bandwidth selection / scaling

options.

Operations, Service and Application Lifecycle Management refers to the administration of

Cloud services and software and their delivery to an organisation s business practices at the

highest level of efficiency possible. It is concerned with ensuring the Cloud capabilities

underpin the business in accordance with defined SLAs, and evaluating service and

software efficiency / improvement opportunities proactively as a life cycle instead of a

solitary event or set of discrete events. ALM is only of concern for the organisation s own

software, not for SaaS. In short, IT Run in the Cloud and any touch points it has with On

Premises IT Run and Business Run in general. Clearly a huge area from both people and

technology point of view, including but not limited to Availability and Performance

Monitoring; Disaster Recovery; Provisioning; Self Service; Automation / Infrastructure as

Code; DevOps; CICD and so on.

Decide which of and why some proportion of the software applications that underpin your

business capabilities should execute on a Cloud hosted runtime environment.

Systematically audit you use where and why, assessing change and impact on the business

audience (time, cost, training, support etc.), TCO, integration, hosting and licence

requirements and so on. On a case by case basis, select the Application Migration Strategy

indicated by the analysis, such as Lift n Shift; Rewrite to Native Services; Retain as is;

Replace & Retire etc. Your strategy wrapped in a business case can provide insight on cost /

benefit prior to undertaking a targeted migration programme. Such strategies can apply

equally to core IT capabilities such as email, anti-virus, office productivity tools, service bus

etc. as well as generic enterprise business applications – CRM, ERP, etc. and specialist

applications – Mortgage Servicing, Underwriting etc.

Risk can be assessed holistically – the business use of Cloud and its integration into existing

IT (Hybrid) – but also in support of the Application Migration Strategy. An assessment

framework may contrast the risk profile of the current application hosting vs. the workload

on IaaS, PaaS and SaaS, establish mitigations, residual risk to be accepted by the business,

impact and likelihood. All Cloud risks require continuous monitoring and management.

Compliance assessment is equally continuous against industry specific regulatory standards

and technical standards as well as policies and principles of the business itself. The Cloud

also imposes legal and contractual compliance requirements on the business, as a client

they must ensure all use is appropriate and authorised and Cloud data centre locations may

impact data holdings e.g. GDPR, Safe Harbour etc. The business must collate data for

purposes of audit inspection and to guard against future litigation.

Governance should ensure that appropriate management and security is bought or built

into the Cloud, best practice and mature IT processes are adhered to, implementations are

controlled and accountable, policies and principles are enforced, knowledge is transferred,

support provided and so on. Management must know who is using the Cloud and

authorise what is put there.

Security remains a joint responsibility between the business and the service provider, Cloud

Platform or otherwise. Experience suggests that Cloud security is often more robust and

transparent than in-house defensive measures, even though those new to the Cloud cite it

as a significant adoption concern. Businesses have to assume that Cloud services are under

constant cyber-attack. Security consideration for your Cloud Platform will include but are

not limited to authentication, multifactor authentication and single sign on; identity

management and directory synchronisation; authorisation; auditing & detection; incident

management; forensics, penetration testing; encryption, accreditation against industry and /

or government standards and so on.

Cloud Architecture specifically relates to the architectural designs (solutions) for each of the

Data, Applications and Technology domains using Cloud-native services, platforms or

software. Before defining anything in these domains, your Business Architecture (org.

structures, roles & responsibilities, capabilities, functions, processes etc.) must be

established and mapped to existing Data, Applications and Technology. Typically, this is an

ongoing Enterprise Architecture capability responsibility undertaken as part of your

continuously refined Business Strategy designed to meet your changing Business

Objectives. This methodology won t focus on Business Architecture aspects, but without

them, establishing a coherent and properly aligned Cloud Strategy will be educated

guesswork at best, potentially wasting significant amounts of time and money by taking

wrong turnings. Cloud Architecture will typically include but is not limited to cloud-native

platform and infrastructure services; bare metal vs virtualisation vs containers; container

management, management services and APIs; Services Oriented and Microservices

application architectures; Big Data; data integration buses & platforms; solution

documentation and advocacy; architectural principles & governance processes; domain

specific Enterprise Architectures at Foundation, Common System, Industry Specific and

programme and project specific Solution Architecture levels of definition and detail.

Cloud means Cloud Platform, at its core Outsourced IT but surrounded by an ecosystem of

services and market places that support the models of service consumption: subscription

periods and pay as you go. You can still expect service level agreements baked in and are

buying some combination of the as a Service models to underpin your business capabilities

with IT. The marketplace of Cloud-hosted partner offerings, typically platform (PaaS) and

software (SaaS) services, is constantly evolving, as are the Cloud-native capabilities of the

base platform itself. Your Cloud Platform presence can be managed on your behalf, usually

not by the Platform provider, but by a marketplace partner.

When deciding where and how to run services and applications (workloads) and how to

migrate applications and who will carry out the migrations, it is vital to have an accurate

and unbiased ICT Maturity Assessment. Many businesses perceive a shortage of Cloud

competencies and an emerging skills gap within their IT functions. Such functions may also

lack the skills necessary to be involved in as a Service purchases, although their

participation is essential.

Total Cost of Ownership is also a vital input to Cloud decision making – do the applications

and services really warrant migration purely on economic measures? If the long term OpEx

in the Cloud is higher than the CapEx / OpEx combination of the current arrangements, it

may still be worth making the move based on other benefits accrued. Employ an

assessment framework to properly account for direct and indirect costs, apply appropriate

weightings, ascertain a method for quantifying the less tangible aspects of social / people

costs.

A business that spreads its use of as a Service across two or more vendor s Cloud Platforms.

A business running a multi-cloud environment will need to decide which of its applications

belong in the Cloud, and then with which provider a particular application should be

placed. For instance, an organization may conclude that its Cloud Storage would be best

shifted to Amazon Web Services (AWS) while its databases might be better run in Azure.

Multi-Cloud is a hedge against vendor lock-in, as well as a strategy for drawing in multiple

sources of outside expertise. Perhaps unsurprisingly, the key to Multi-Cloud is also

integration, specifically of the different Cloud-Platform APIs and infrastructure lifecycle

management tools. Like Hybrid and Cloud, you can have Multi-Cloud managed for you in a

Cloud Platform partner Outsourced model, rather than retaining multiple Cloud skill sets

yourself.

Using Data Centres owned and operated On Premises, the incumbent IT department

supplies business with a range of services that underpin their corresponding business

capabilities in accordance with defined service level agreements. These will include

networking (Ethernet, WiFi, WAN etc.), storage, backup & restore, servers (print, file,

processing etc.), virtualisation of servers and / or desktops, operating systems for servers

and end user devices, physical end user devices (phone, tablet, laptop, PC etc.),

integration / middleware capabilities (APIs, ESBs etc.), runtime platforms for enterprise

applications (e.g. Web Servers), enterprise applications (CRM, DBMS etc.), data provision

when and where required, security both physical and electronic at depth, support /

helpdesk and so on. IT will be a cost to the bottom line, both in terms of Capital and

Operational Expenditure. IT will align itself to business using Enterprise Architecture

methodologies. CIOs lead, CTOs advise and CFOs at times control the given IT capability of

a business. In an Outsourced managed environment, some or all aspects of this IT capability

are supplied by an external organisation, possibly overseas, operating under commercial

contracts for service delivery with financial (or other) penalties being applied for service

failures.

Wikipedia.org is an excellent resource for crowd-sourced definitions. If mine

are unconvincing or unclear, head there for another opinion.

1. CORE CLOUD STRATEGY

1.1 CLOUD VS. HYBRID

Are you a greenfield site (no IT at all, some kind of startup)? If the answer is yes,

go all in with the Cloud and focus on your new business, not commodity IT.

Unless of course your new business is IT, in which case you ll likely still go all in

with the Cloud. For the rest of us with businesses that have been around for years

or decades, an IT capability already exists. I will not address On Premises vs.

Outsourced IT - you ve already made that decision and will be aware of the CapEx

and OpEx costs of that commitment. The question here is: migrate everything to

the Cloud al la GE, ING or Netflix, or maintain some form of Hybrid arrangement,

running workloads where it seems to make most sense given the current IT

investment?

There are options – it makes sense to spell them out unambiguously. The

illustration here should help in that regard, although you should note that not all

vendors are able to provide all the possible variations:

CLOUD, STEP BY STEP

In the remainder of this first part of a series of articles, I will focus on the core Cloud thinking: Hybrid vs. pure

Cloud, tenancy in Public or Private Cloud Platforms and finally, single Cloud Platform vs. Multi-Cloud

Platforms. That will set us up nicely for the next article in the series which will explore Cloud Service Models

(IaaS, PaaS, SaaS) and vendor offerings through the use of further Architectural Reference Models.

If you Outsource, likely your outsource partner is quite capable of putting

workloads into the Cloud for you and managing them there, if you decide to

explore that option with them. There will need to be good reasons to change the

current set up and migrate workloads – many of the same good reasons you

would need to move from On Premises to a Hybrid model. You could of course

manage the Cloud workloads yourself, especially if they don t really need that

much management as in the SaaS model. Just to make things a little more

confusing, you can also run a Cloud Platform On Premises or in an Outsourced

managed data centre using technology such as OpenStack and Azure Stack. And

of course, you can always do a mixture of all these things. How do you select the

right strategy for where to run your business workloads and why it does it make

sense to use the Cloud at all?

Your current core ICT strategy will influence this decision hugely, as will your

current IT Maturity and current Total Costs of Ownership for the IT capabilities

that underpin your business. You also need to have a good understanding of the

technology in play, its strengths and weakness, its change agility ready to meet

the changing needs of your business, a pragmatic assessment of your workloads

and how they integrate with one another and your business and external partners

at large. That s a lot of prerequisite insight to have available before being able to

make a properly informed decision – and this is where architecture practices and

methodologies come in, offering a comprehensive approach and toolset for

information gathering and communication. Do a quality job at this stage and you

have a solid foundation on which to build your Cloud Strategy.

PUBLIC TENANCY

PRIVATE TENANCY

BOTH TENANCY

MODELS

1.2 PUBLIC VS.

PRIVATE VS.

BOTH

HYBRID

OUTSOURCED

ON PREMISES

CLOUD

OFF PREMISES PLATFORM

CLOUD

OFF PREMISES CLOUD PLATFORM

+=

=

OR

OR

OR

ORPRIVATE CLOUD

ON PREMISES PLATFORM

CLOUD

BOTH ON AND OFF PREMISES

OR

OR

1.1 CLOUD VS. HYBRID

Core Cloud

Strategy

1.2 PUBLIC VS. PRIVATE VS. BOTH

Dedicate Private Cloud services are

contractually delivered against SLAs on a

individually negotiated basis, although

subscriptions can be relatively short term.

Extensively customisable environments, with

underlying hardware, network and storage

service performance as well as Cloud Platform

service specified according to the unique

needs of customer workloads.

Should the need arise, hardware need not be

virtualised, with dedicated compute and

storage hardware blended into the Private

Cloud Platform – to handle high throughput

data processing requirements for example.

This obviously can t be achieved in a Public

Cloud.

Given Private Clouds are dedicated to a single

organisation, digital and physical security can

be tailored to the exacting needs of the

customer, reaching the levels of government

and military acceptance. Physical security

within the hosting data centres can include

specifying support staff have maintained

appropriate clearances.

Compliance with UK and EU regulation,

typically regarding data distribution and

security, such as UK DPA / EU GDPR, HIPAA,

PCI DSS, is easier to prove and achieve in a

dedicated environment.

Pay-as-you-go by the hour for the service

resources consumed – very economical if

you re spinning up & tearing down

environments in conjunction with agile

delivery processes. Cloud service pricing may

vary by geography and you can use advance

reservations and spot market purchases to

further tweak costs to your advantage. No

ongoing contracts to tie you in.

Performance of the underlying hardware and

network that provides the Public Cloud

services is largely beyond your control,

although for some services, typically IaaS, you

can request optimisation of your resources

based on your usage at extra cost.

The high volume Public Cloud utility model

implies self management of systems – an

advantage technical buyers with skill sets that

permit detailed infrastructure and service

constructions, but a disadvantage for those

that want a fully managed solution.

Public Cloud implies other tenants share the

same hardware, storage and network devices,

likely also hypervisors and Cloud-native

services such as RDBMS under certain Service

Models. Under these circumstances, it is

harder and may prove impossible to meet

some regulatory compliance requirements.

PUBLIC PRIVATE

The multi-tenant Public Cloud is clearly perfect for where you or your customers have no

need to meet stringent security or compliance requirements, typically for simple web sites

or development and test labs. Private Cloud is by very definition, dedicated to you down

to a layer of infrastructure that makes sense – separate hypervisors at least, but likely

hardware, storage and network to some extent too – as deep as your pockets will go.

It s very likely that you will employ a blend of Public / Private Cloud solutions during your

Cloud journey – there will be many cases where it makes sense to go with a low cost

Public Cloud approach over infrastructure or services dedicated to your workloads.

It is essential to establish and use Architectural principles and Reference Architectures

that guide the use of each approach in your organisation. Provide the emergent design

of your agile solutions an intentional runway on which to safely land. Include some or all

of the following thinking in your approach:

Use a selection strategy based on Service Models, for example, Private IaaS where

you need fine grained control over the security and management of your

deployment environment and Public PaaS or SaaS to get a slice of commodity email

and office productivity Cloud services. Service Models will be the focus of the next

article;

Consider compliance broadly and then on a per application or service for your

business – which regulations apply where and when and how will they be met in each

case;

Security requirements for the application or service and its data, on the wire to / from

the Cloud and at rest in Cloud storage;

Data sovereignty – the data at rest location based on Cloud Platform vendor data

centre location – you may need to limit where in the vendor s infrastructure your data

resides which may not be possible on their Public offerings;

An honest evaluation of your organisation s ICT Maturity – it s ability to operationally

manage a Public Cloud Platform;

Integration requirements with other data sources or application services – not all of

which may be able to move to the same Cloud Platform from within your

organisation, as well as all the 3rd

party businesses with which you exchange

information;

The TCO projection, Public vs. Private vs. current arrangements;

Risk assessment profiles of the application under each tenancy model;

Your current capabilities in the Cloud – are you building on an existing proven

capability or trialling a new endeavour;

The availability of appropriate quality partner offerings and support in your business

regions;

The relevant Application Migration Strategy (your application may need to be

rewritten in order to be accepted onto a Public PaaS) and so on.

So why employ more than one Cloud Platform? Some

of the main reasons are:

Reduce the risk of vendor lock-in by backing

multiple Cloud providers – manage associated

risks, e.g. price rises, through choice and

competition;

Select the best of breed and most cost effective

Cloud service as the solution for each workload on

a case by case basis – satisfy the requirements of

each specifically rather than one size fits all;

Shift appropriately between providers as prices

fluctuate and new features become available –

your workload host may change repeatedly over

time – your business consumers all the while

unaware;

Enable teams across your business to access the

Cloud specific resources they need without

recourse to Shadow IT tactics;

Multiple Clouds can help minimise the risk of data

or service loss due to a localised Cloud Platform

failure;

Monitor usage, costs and performance of multiple

Cloud Platforms through a single management

tool, a wide variety of which can be sourced from

the Cloud Platform s ecosystems. With multiple

platforms come multiple ecosystems and suppliers

– the options are many and continuously evolving;

Added geographical data and service flexibility –

ensure data sovereignty requirements for specific

workloads are addressed by utilising providers with

data centres appropriate to your geography.

1.3 SINGLE CLOUD PLATFORM OR MULTI-CLOUD PLATFORMS

MULTI-CLOUD

Keep things simple with a single Cloud Platform:

A single Management user interface and API to

code your infrastructure against, ideally a single, or

at least simplified, tool set to use when doing so;

A smaller range of Cloud-native service

technologies to understand re. their strengths,

weaknesses and opportunities for use in your

solutions;

A single approach to and problem space for Cloud

connectivity;

A less diverse set of skills which need to be learnt

or bought in by your organisation for self managed

Cloud endeavours;

A single support process and point of contact,

simplified SLA;

A single vendor to commercially negotiate with –

Multi-Cloud implies more complicated cost

tracking and billing management;

No data and application integration challenges

between multiple Clouds. Less challenges between

the Cloud and your remaining On Premises or

Outsourced IT;

Reduced need for security and governance

planning due to reduced complexity and

distribution;

A single strategy, rather than having to establish

principles that guide the selection of the right

Cloud for the right workload, often across large

application portfolios.

CLOUD

There are powerful advantages to each approach – you may envisage further potential or detractions

in the context of your organisation. At the beginning your Cloud journey, when advocating a strategy

for Cloud or Multi-Cloud, it will pay dividends to keep solutions as simple as possible, but no

simpler . Much also depends on your current IT strategy and its ability to execute.

For example, Azure Public Cloud may be the best fit for many of your current Microsoft technology

and .Net application workloads, potentially backed with an On Premises (Azure Stack), Outsourced or

Private Cloud architecture for those with high security and / or compliance requirements. At the same

time, your open source Java solutions running on Ubuntu Linux may be best deployed into AWS,

perhaps alongside your real time streaming solutions on AWS Kinesis and your Hadoop Big Data

ecosystem. Then there is your legacy mainframe, something that won t ever leave your On Premises

setup – integration with its data and functions is as essential as the integration of both Cloud

Platforms. Application portfolios are typically complex – one size doesn t fit all, so Multi-Cloud may

provide the opportunities without the restrictions of a single platform.

Ultimately, to make the correct decisions, you need Architects who understand the range and

possible uses of the different Cloud vendor offerings and, most importantly, how they map to the

requirements of your different business capabilities. Architecture is also essential in handling the

complexities of integrating multiple Cloud Platforms and legacy systems and data. Use Architecture

to deliver Cloud benefits and value to your business at an acceptable cost and risk.

CLOUD AND FINANCIAL SERVICES: FCA GUIDANCE

The FCA have said Cloud will improve choice and solution innovation

within the financial services sector, facilitating expansion and increasing

the ability for financial service providers to renew their IT systems in a

more efficient manner. The regulator also stated that there is "no

fundamental reason why cloud services (including public cloud services)

cannot be implemented, with appropriate consideration, in a manner

that complies with our rules" delivering "commensurate benefits for

firms and consumers". The guidance includes considerations for Cloud

adoption, including regulation, business continuity, data protection and

security, risk management, effective regulatory data access and so on.

Guidance, published November 2015:

https://www.fca.org.uk/publication/guidance-consultation/gc15-06.pdf

FINALLY

The internet is awash with statistics about the take-up of Cloud in todays organisations, most

indicating significant increases in the near future but with comparatively few organisations who are

currently heavily reliant on the technology. Security remains the most significant concern, but this

remains a joint responsibility regardless of the Cloud Platform – inside jobs by malicious employees

purportedly account for roughly the same number of breaches as external cyber attacks. It s also

possible that in many organisations, the current IT setup is more vulnerable than the services vendors

and partners can provide on any Cloud Platform.

Given the ubiquity of commodity Cloud computing, working out how you may use Cloud to best

advantage and preparing properly within your business seems like necessary due diligence. If Cloud

is akin to the next industrial revolution, who wants to be referred to as another Kodak or Nokia?

Architecture and architectural methodologies such as the one we have begun to explore, can help

establish a solid springboard for your Cloud journey.

That s it for the Core Cloud Strategy, next article all things Operational. Your constructive feedback is

greatly appreciated!

Gareth Llewellyn, November 2016.

See more about me at LinkedIn https://uk.linkedin.com/in/gareth-llewellyn-a4bb1112b

This document is available as a PDF from my LinkedIn profile.

All opinions in this article are my own and are not necessarily endorsed by my employer.