Ad
More Related Content
What's hot (10)
Similar to Architecting your Cloud Strategy - Part One.vsdx (20)
Ad
Architecting your Cloud Strategy - Part One.vsdx
- 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.