1. 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-Scale
Scale 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 Recovery
Robust Cloud-based backup and
recovery solutions for organisations that
lack expertise or investment.
Maintenance Automation
Managed infrastructure platforms
mean automation of patches,
security and software updates –
focus on growing your core business
not commodity IT.
CapEx Zero
Pay 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-Working
Any 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.
Security
Cloud 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 Gain
Lift 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.
Competitiveness
Cloud 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 Baskets
One 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
Perspectives
Virtualisation 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:

2. 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:

3. 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.

4. 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
OR
PRIVATE CLOUD
ON PREMISES PLATFORM
CLOUD
BOTH ON AND OFF PREMISES
OR
OR
1.1 CLOUD VS. HYBRID
Core Cloud
Strategy

5. 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.

6. 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.