加速企業業務的雲端策略

27 min readMay 18, 2022

本文將討論企業如何通過實施雲端策略來加速業務成果。每個雲端平台都有其自身的優勢，通過分析我們的業務策略並定義最適合的雲端技術，企業可以真正的利用雲端的優勢。

雲端策略不應該是“cloud first”，而應該是“cloud fit”。但在我們開始進行技術策略和實際的雲端規劃之前，我們必須探索推動企業的業務或策略以及在財務方面的內容是什麼。在本文中，我們將介紹以下主題：

分析企業的雲端策略
從企業架構定義雲端策略
讓雲端技術符合業務需求
應用 IT4IT的價值流
追蹤雲端運算的發展 — — 關注業務策略
制定全面的業務路線圖
將業務路線圖對應到"Cloud-fit"的策略

分析企業的雲端策略

在開始分析雲端策略之前，我們需要了解什麼是企業策略以及企業如何定義這樣的策略。正如我們在什麼是多雲(Multi-Cloud)文章中所了解的，每個企業都應該有創造營收和賺錢的目標。不過這不是一個策略，這只是一個空泛的口號。策略應該是由企業是"如何生產產品或服務來獲利"所定義的。

一個好的策略包括在時間、資料的使用之間經過深思熟慮，以及與膽識有關的事情，也就是 — — 敢於在某個時間點做出一個決策，並為此決策負責。這個決策必須基於 — — 正確的時間點還有計劃和資料的正確理解。如果企業在這方面做得好，他們將能夠加速成長，事實上，是增加收入。 整體策略會轉化為成一個商業案例。商業案例可以是:

使用雲端創造新的商業模式，例如提供SaaS服務
強化業務韌性，例如使用雲端實行BCP
使用雲端快速讓產品或服務上市
利用雲端進行大數據分析

從2020 年開始，由於 COVID-19 的爆發，全世界的人民幾乎都戴上了口罩。各國政府正試圖通過關閉學校、禁止企業會議和大型活動，甚至封鎖整個地區和整個國家來遏制病毒。很多人都面臨旅行限制。在哪一段時間這一破壞正在嚴重影響全球經濟，訂單急劇下降，許多公司正在面臨生存之戰。而這也變成企業加速數位轉型的契機。甚至到了現在(2022年末)，數位轉型卻沒有減速的跡象，因為下一波的經濟下行即將來臨。企業需要為成本效益極大化做好準備。

在疫情高峰時期。例如，生產口罩的公司開始飛速成長，但業務如果是在封鎖地區有著生產和服務的企業卻看到他們的市場以驚人的速度暴跌，現在則是反轉過來。換句話說，"時間點"是規劃業務加速時要考慮的最重要因素之一。話雖如此，這也是最難掌握的事情之一，因為沒有人有水晶球可以窺知未來。然而，這是當時企業不推動業務成長的一個原因。許多公司的策略可能已經從推動成長轉變為通過努力降低成本來維持生存，現在這個時間點(處於可能的經濟衰退)依然如此。在這裡，我們就有了定義雲端策略的第一個參數：成本控制(Cost control)，更重要的是成本敏捷性(Cost agility)。

第二個是資料的使用。看起來企業在業務運作中都會產生全新的資料，但當然沒有什麼比事實更具說服力的了。每個時代的每一個企業，都只能靠資料存在，因為它提供我們做出決策。我們可能沒有永遠是將某些東西視為資料，因為它並不是很容易識別，尤其是當它沒有放在一個核心位置時。

資料是關鍵。它不僅涉及企業（能夠）存取的原始資料，還涉及分析這些資料。我的客戶在哪裡？他們的訴求是什麼？這些訴求在什麼情況下是有價值的，是什麼使這些訴求發生了變化？企業該如何應對這些變化？如果需要，企業需要多少時間來滿足最初的客戶訴求並應用這些變動？這一切都來自資料。如今，企業擁有大量的資料來源(假設有進行一定的數位化)。最大的訣竅是我們如何以"安全的方式"向我們的組織呈現這些資源，因為這些資料可能會涉及保密、隱私和其他合規性法規。

最後，商業決策確實需要膽識，而膽識則是所有管理層都要有的。有了特定的時間點和世界上可取用的資料，我們需要足夠大膽地在某個時刻做出決策。選擇一個方向並朝著它前進。

一個大哉問是：

“雲端如何幫助我們制定決策和實現企業策略？”

企業的策略一般脫離不了以下四種類型:

成長/併購
創新/差異化
成本優勢
客戶服務/服務穩定性

而不同的企業策略就會產生不同的企業目標，而企業目的則分為四種類型

財務目標
客戶目標
內部目標
成長目標

更多的企業策略與目標管理可參閱本部落格雲端運算的治理與管理一文。而有關如何使用雲端科技來加強企業的競爭優勢運用雲端科技形成競爭優勢-Part 1文章。

產業地位

企業應該做的第一件事是分析它在該產業中的地位。或者，如果它進入新市場，它最初可以獲得並持有什麼地位。分析師經常使用策略大師麥克.波特的五力模型，包括既有競爭者、新進者的威脅、替代品的威脅、供應商的議價能力和客戶的議價能力。顯然，要執行此模型，需要調查大量資料。而這不是一次性的事情。這是對企業所處的產業地位不斷的分析，其結果可能將導致企業策略的改變。重要的是：在這個數位化時代，這些變化以越來越快的速度發生，這要求企業保持敏捷。這個模型可以用下圖來描述：

例如，讓我們看一下模型的一個參數：“替代品的威脅”。現今，客戶可以很容易找到產品或服務(視情況而定)。今天很酷的東西可能明天就完全消失了。此外，由於市場全球化以及我們通過互聯網在全球做生意的客觀事實，客戶可以輕鬆找到更便宜的產品或服務。他們不再局限於特定國家或區域來購買產品或服務。他們可以從世界各地得到它。因此，替代品的威脅是巨大的，需要不斷調整策略以減輕這種威脅。但是目前的地緣政治造成的多極世界正在形成，這也意味著反全球化可能正在開始。而這一切都與企業的產品/服務上市時間有關。企業需要能夠實現這種敏捷性的平台。

企業的核心競爭力

隨著市場行為和企業自身的不斷變化，定義核心競爭力並不容易。在過去的幾十年裡，企業變得越來越 T 形。以銀行為例。就在不久前，銀行的核心活動是保證消費者和公司的資金安全存放、發放貸款、投資和支付。為此，銀行需要金融專家。但這一切都改變了。他們的核心業務仍然採用上述因素，但現在，通過網站或手機app以完全數位化的方式提供這些服務，例如區塊鍊技術。銀行需要軟體開發人員和 IT 工程師來執行其核心活動。銀行變成了T型企業，有著廣度與深度。更具體來說銀行業變成了科技業。

長期計畫

當企業清楚自己的產業地位和核心競爭力時，他們需要擬定計劃。企業希望在 5 年後發展到哪裡？這是最困難的部分，如同我們上面提到的，沒有人有水晶球。企業只能基於資料和資料分析，它必須預測市場將如何發展以及公司如何預測變化。同樣，資料是絕對的關鍵，但由於市場需求確實變化非常迅速，因此公司也需要能迅速改變方向。

財務結構

最後，任何企業都需要清晰的財務結構。公司如何籌資？成本與不同業務領域、公司部門及其資產有何關聯？正如我們將在財務運營中發現的那樣，雲端對於建立整個企業金流的細致度洞察力非常有幫助。通過正確且一致的命名和標記，我們可以準確地確定企業在使用IT 資源產生的成本。雲端模型最好的部分是雲端運算的基礎是pay-as-you-go。雲端系統可以與業務本身相同的頻率來運作。當業務增加時，IT 消耗也會增加。當業務下降時，可以縮小雲端資源的規模，從而降低成本，而地端機房資源則是一個靜態，不論業務的增加(資源不夠無法承擔增加的業務量)或減少其資源(因為資源是固定的，無法省錢)。

因此，沒有什麼能阻止我們將業務遷移到雲端中。在企業的架構方面確實需要做一些準備。

從企業架構定義雲端策略

為什麼我們要將系統遷移到雲端中，因為“需要敏捷性，當然還有成本控制”。

接下來的兩個問題將是：使用什麼以及如何使用？在我們探索業務路線圖的方式和基本情況之前，我們將討論第一個問題：用什麼？雲端遷移計劃從業務規劃開始，涵蓋業務流程、營運、財務，最後是技術要求。我們將不得不評估業務需求以及這些需求所產生出來的IT要求。

在企業外包服務時，企業需要對承接外包的公司執行所謂的due diligence(DD)。根據其定義，DD是:

對潛在廠商(也就是 CSP及其經銷商)所進行業務的全面評估，特別是確定其資產和負債並評估其商業潛力

將數位資產轉移到雲端的過程聽起來可能過於繁重，但我們需要將其作為業務規劃方法。因為CSP與其經銷商可能會在之後退出市場，或是將某些服務下架(說不玩了，像是google cloud最常做這件事)，我們必需確保這個風險是最小的。

業務規劃

業務規劃包含了以下的部分：

檢視整個 IT 環境，包括應用程式、伺服器、網路、存儲、API 和來自外部廠商的服務。
將 IT 環境組件(components )對應到關鍵業務或重要業務的服務。
識別 IT 環境中的共享服務(shared service)和組件還有企業的產品/服務。
評估有關產品服務和關鍵業務服務的 IT 支援流程。這包括提供這些服務的自動化程度。

檢視階段的一個非常重要的步驟是評估應用程式和 IT 系統的服務等級和效能指標，這對於建立良好的雲端服務對應至關重要。服務等級和KPI 將適用於基於特定業務需求的應用程式和底層 IT 基礎設施。考慮Availability、Durability和備份等級的這些指標，包括 RTO/RPO 規範、 Business continuity和Disaster recovery。系統是否 24/7 全天候監控？支援的窗口是什麼？這些都是需要考量。正如我們將發現的那樣，服務等級和衍生的SLA在雲端部署中可能完全不同，尤其是在比較 PaaS 和 SaaS 時，PaaS甚至SaaS 管理的責任在很大程度上轉移到了解決方案廠商。

如果我們問 CFO 公司的核心系統是什麼，他/她可能會回答財務系統(大概都是ERP)絕對至關重要。回應這一點是企業架構師的職責。如果公司是電子工廠，那麼財務報告並不是最關鍵的系統。當財務系統無法執行時，公司可能不會馬上停止運作。然而，當電子組裝產線系統停止時，公司業務也確實停止了。這會立即影響業務。這在計劃遷移到雲端系統時意味著什麼？這些工廠的應用程式可以移到雲端中託管嗎？如果是這樣，哪要怎麼做？或者轉移的時間點是何時？

在組織層面中，企業架構師定義了業務目的、重要功能、重要流程與各種業務組件之間的交互。這些會描述出:

業務流程
產品與服務與它們的分類方式
業務能力
業務架構定義了企業如何運作以交付產品和服務。還定義了它需要能夠運行的資料，以及最後需要哪些系統。

業務規劃通常還包含以下事項:

探索整個 IT 環境，包括應用程式、伺服器、網絡、存儲、API 和來自廠商的服務。
將 IT 環境組件對應到關鍵業務服務。
識別 IT 環境中的商業服務和共享服務和組件。
評估與商品服務、關鍵和重要業務服務相關的 IT 流程。這包括提供這些服務的自動化稅水準。

以上這些是通常都是跟雲端遷移或雲端開發計劃的數位轉型時首先要討論的主題；從企業策略來看，我們應該清楚公司的核心系統支持的核心競爭力是什麼。

財務規劃

在業務規劃階段之後，我們還需要進行財務分析。畢竟，遷移到雲端平台的主要理由之一是成本控制(cost control)。但是

使用或遷移到雲端並不只是降低企業成本的問題。而是關於使企業的成本如何對應企業實際的業務活動"。

因此，從財務角度來確定雲端解決方案是否是一種選項並不是一件容易的事。我們需要有一個Total Cost Of Ownership計算方式。

TCO 確實是擁有一個平台的總成本，它應該包括所有直接和間接成本。這意思是什麼？在計算 TCO 時，我們必須包括與我們運行系統的

"直接成本"：存儲、網路設備、運算、軟體授權等成本。
"間接成本":人員成本，包含工程師、管理階層甚至評估與系統相關成本的會計師管理系統所涉及的勞動力成本。

以上這些都是費用；然而，這些間接成本往往沒有得到企業的全面考量。尤其是在雲端中，但其實這些都應該考慮在內。例如，運行自動化的服務管理和財務報告可以避免哪些成本？

因此，在評估成本和用以財務規劃來驅動我們的雲端架構時，需要涵蓋很多考量：

與 IT 基礎設施和應用程式相關的所有直接成本。這還包括機房的所在位置；例如，放在自家辦公司的機房佔的樓地板地面積和電力消耗，或是 co-locate在外包商的機房費用．
與從事 IT 基礎架構和應用程式作業的所有員工相關成本。這包括在這些系統上工作的第三方廠商的承包商和員工。
與廠商或第三方系統支援相關的所有軟體授權費和成本。
理想情況下，這些成本可以分配(chargeback/showback)給特定的業務流程、部門，甚至團隊與用戶，以便 IT 運營成本的來源一目了然。

為什麼這對制定架構很重要？開始企業的雲端之旅的一個關鍵財務驅動因素是從資本支出(CapEx- capital expenditure)到運營支出(OpEx- operational expenditure)的轉變。本質上，CapEx — — 涉及前期投資；例如，購買實體機器或軟體授權費用。這些通常是一次性投資，其價值在經濟生命週期內貶值。 OpEx— 都是與日常運營相關的成本，因此更加精細。通常，OpEx 被劃分為團隊執行日常任務所需的較小預算。在大多數雲端部署中，企業實際上只為他們使用的東西付費。如果資源閒置，則可以關閉這些資源並停止付費。如果需要，單一開發人員可以決定啟動額外的資源。

對於PAYG(pay-as-you-go) 部署來說確實如此，但我們會發現許多企業的環境以完全 PAYG 運行是不可行的。因為我們根本不需要關閉大型 ERP 系統的instance。因此，對於這些系統，企業可能會使用更多的預留資源(RI/CUD)，例如在較長時間內固定的預留機器。對於CSP而言，這意味著更長時間的穩定收入來源，因此他們給使用這些預留機器的企業給予折扣。不利的一面是，企業“可能”不得不預先為這些預留資源付費，不過大部分來說不需要。有些CSP預付得愈多折扣當然越多．但事實上，這樣的方式其實就是資本支出。所以在財務方面，雲端運算其實混和了CapEX與OpEx的費用模型。

技術規劃

最後是技術規劃，從基礎架構開始。我們可以計劃房子是一個四樓透天厝，但我們需要先建造房子。房子需要一個堅固的地基，首先可以支撐住房子，但也可以承載未來多餘的空間，例如頂樓要蓋游泳池。房間需要與房子融為一體，因為房子內的所有一切都是環環相扣的。這一切都需要好好規劃。好的計劃需要資訊 — 就是資料。

在雲端的世界中，我們不必自己解決所有問題。主要的CSP都有參考架構、最佳實踐和案例，可以幫助我們規劃和構建基礎，確保我們幾乎可以隨時適應新的組件和解決方案。

這正是在本文要強調的：“規劃、設計和管理一個面向未來的雲端環境。”

應用 IT4IT的價值流

許多企業面臨的問題是從業務角度來形朔雲端架構。 IT4IT 是一個幫助企業實現這一目標的框架。它是 TOGAF 的補充，因此也由 The Open Group 作為標準發布。 IT4IT 也是 ITIL 的補充，ITIL 為 IT 服務管理提供最佳實踐。 IT4IT 為使用 ITIL 啟用 IT 服務管理流程奠定了基礎。它旨在調整和管理數位化企業。它解決了這些企業面臨的挑戰，例如不斷加速擁抱和採用新技術。 IT4IT 的基本概念包括四個價值流(value streams)：

Strategy to portfolio : Portfolio包含技術標準、計劃和政策。它處理來自業務面的 IT 需求，並將這些需求對應到 IT 的交付項目。 portfolio的一個重要方面是專案管理，讓企業的業務和 IT 保持一致。
Requirements to deploy: 這個價值流側重於建立和實施新服務或調整現有服務，來達到更高的品質標準或獲得更低的成本。根據 The Open Group 的文件，這是對敏捷 Scrum 和 DevOps 等方法的補充。
Request to fulfill: 這個價值流就是讓部署服務的人員很容易的就進行部署。隨著公司及其 IT 採用 IaaS、PaaS 和 SaaS 等結構，這個價值流通過提供和管理雲端服務的目錄來實現服務代理(service brokering)，並以此加快滿足終端用戶提出的新需求，這個也就是對企業在雲端中進行標準化。
Detect to correct: 服務會變動。這個價值流支援監控、管理、修復和其他推動這些變動的運營面。

下圖為IT4IT value stream:

追踪雲端的發展 — — 關注企業的業務策略

任何雲端架構師或工程師都會告訴我們，雲端運算是很難跟上發展的腳步。每一年，雲端運算的主要業者都會發布一大堆有的沒有的新功能。這些可能是大改版或只是一些小的調整。這是源源不斷的創新。無論如何，請盡量跟上所有這些創新、發布和新功能。

不過更糟糕的是。創新不只來至於CSP，還有很多我們需要執行的第三方工具才能遷移或開發應用程式，甚至非功能性的需求。如 XebiaLabs 的 DevOps 週期表(如下圖)，它不斷更新新技術和工具。或CNCF Cloud Native Interactive Landscape。

沒有任何一間企業有辦法跟上所有不斷推出的新功能。所以企業需要有重點，這應該來自我們在前上述中討論的策略。換句話說，不要被推出的所有新技術沖昏了頭。管理雲端架構時必須考慮三個重要方面：基礎架構(foundation architecture)、延遲成本和機會效益。

基礎架構(foundation architecture)

任何架構都會從baseline開始，我們稱之為基礎架構甚至參考架構。 TOGAF 包含到了兩個領域：技術參考模型(technical reference model)和標準資訊庫(standard information base)。技術參考模型描述了通用平台服務。在雲端環境中，這將是所用平台的基本設置。

例如，在主流的CSP中，常見的做法是部署hub-and-spoke model。 Hub包含適用於不同spoke中所有工作負載的通用服務(shared service)。考量到雲端外的世界（地端機房或互聯網）的網路gateway、跳板機、管理服務器和集中管理的防火牆。在雲端服務中，客戶建立一個由客戶自己擁有和管理的虛擬資料中心 —VPC(virtual private network)(Azure稱作vNet)。在公有雲的私有部分中，也就企業私有的網路，以及可以容納實際工作負載的私有網段：

現在，必須在基礎架構中描述如何設置 VDC(virtual data center)。這將是baseline。想一想：我們不會在每次導入新應用程式時都重建整個地端機房？同樣的規則也適用於我們在公有雲服務之上構建的VDC。

標準資訊庫(SIB)是構成我們基礎架構的第二個組件。我們遵循 TOGAF：它提供了一個標準資料庫，可用於定義源自 TOGAF 基礎架構的組織特定架構的特定服務和其他組件。簡而言之，它是一個包含標準的資訊庫。對於雲端，這可能是一個相當廣泛的清單。要考量以下幾點：

用於通訊和網路安全的網路協議標準，包括分段(segmentation)的等級和網路管理。
VM標準；例如，使用的OS的類型和版本。
存儲和存儲協議的標準。檢視CSP 提供的類型存儲和案例。
Security baseline
合規標準；例如，適用於某些業務領域或產業的框架。

延遲成本

我們已經有了基礎(參考)架構，但現在，企業的業務面臨著經過評估的新技術：它們將為業務帶來什麼？正如我們之前提到的，使用每一種的新技術是沒有意義的。這裡的關鍵字是商業案例(Business case)。

“商業案例能確定雲端資源的消耗是否支援企業的特定業務需求”。一個簡單的例子如下：一個企業在要連上網際網路需要有一條對外線路。企業可以升級頻寬，但這需要投資。而企業則需要為額外的頻寬付費。但是，它可以幫助員工更快地完成工作。如果僅僅因為公司投資於更快的網路線路這一事實，員工就可以承擔更多的任務，那麼儘管有投資，但就這一商業案例的成效是正面的。

如果出現市場需求，而企業無法快速回應這種市場需求，企業可能會失去部分市場份額，從而損失營收。 採用新技術或加快應用程式的開發以滿足不斷變化的需求將導致成本增加。這些成本對應於錯過特定時間和及時將服務或產品推向市場。就是我們所說的延遲成本。延遲成本作為一個術語，由 Donald Reinertsen 在他的《產品開發流程原則》一書中提及：

We need cost of delay to evaluate the cost of queues, the value of excess capacity, the benefit of smaller batch sizes, and the value of variability reduction. Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mindset of a development organization.

雖然它主要用作財務參數，但很明顯，延遲成本可以成為評估使用雲端技術的業務案例的驅動因素。預設情況下，敏捷的使用雲端資源可以減輕延遲成本的財務風險

機會效益

如果有什麼東西可以稱為延遲成本，那麼也應該有一些東西可以稱為機會效益。如果延遲的成本是因為沒有及時適應市場變化而失去動力的風險，機會的效益實際上是通過探索未來的發展和相關技術來加速業務。它可以非常廣泛。例如，假設一家電商通過使用客戶用來訂購商品的同一個app提供銀行服務，從而進入銀行業務。或者，想想一家汽車製造商，如特斯拉，進入保險業務。

雲端服務的高度存取性甚至易用性促成了這些轉變。在行銷術語中，這通常被稱為blurring(指的是模糊或混淆不同產品、服務或品牌之間的界線，以創造更多的市場競爭力或引起消費者的興趣)。在傳統世界中，同一家電商向其客戶提供銀行服務確實會遇到更多麻煩，但隨著 SaaS 在金融app中的推出，從技術角度來看，將其整合到其他app中並不難。當然，這還沒有考量金融監管機構的銀行執照要求以及必須遵守不同的金融合規框架等問題。從純技術的角度來看，借助雲端技術，企業可以更輕鬆地嘗試其他商業領域並快速進入這些領域。

最好的例子？ AWS。不要忘記亞馬遜最初是一家電商書店。由於其訂購和交付平台的穩健性，亞馬遜發現它還可以向其他方“出租”存儲系統。畢竟，他們擁有基礎設施，那麼為什麼不充分利用它呢？因此，S3 存儲作為第一個 AWS 雲端服務推出，並通過各種方式使 AWS 成為僅次於零售核心業務的領先CSP。這就是一個機會效益。

有了這個，我們已經討論瞭如何定義策略。我們知道我們來自哪裡，我們知道我們要去哪裡。現在，讓我們通過建立業務路線圖(business roadmap)並最終將該路線圖對應到我們的雲端策略，將所有東西整合在一起並使其更加具體，從而評估不同的部署模型和雲端開發階段。

制定全面的業務路線圖

制定業務策略和路線圖的不是以下這一段一段文章就可以涵蓋一切。但是，對於企業架構師來說，了解如何評估業務路線圖很重要：

企業的使命和願景，包括企業如何瞄準市場並提供商品或服務的策略規劃
目標、目的和方向。同樣，這包括規劃，其中業務面制定了何時以及如何實現特定目標，以及在資源方面實現目標所需採取的措施。
SWOT 分析顯示企業是否在正確的時間做正確的事情，而不是需要在策略方面進行調整。
卓越運營。每個企業都必須定期檢視其表現。這是通過 KPI 測量完成的：交貨是否準時？客戶滿意嗎(例如客戶滿意指標CSAT)？而有關雲端的卓越營運，可參考AWS的雲端架構框架-卓越維運篇文章。

業務路線圖的驅動因素可以非常多樣化，但最常見的驅動因素如下：

營收
毛利率
銷售量
潛在客戶數
上市時間
客戶滿意度
品牌識別度
投資回報(ROI)

這些是企業的整體目標，意味著企業中的每個部門都應遵守這些目標，並使其計劃與業務目標保持一致。這些目標最終出現在業務路線圖中。對於大型企業，這些可能很複雜，但也很簡單，如下圖所示：

IT 是驅動一切的引擎：軟體開發、資源規劃、CRM 系統、銷售網站和客戶應用程式。如今，需求變得更具挑戰性。生命週期越來越短，速度越來越快。長期以來，IT 一直是瓶頸，但現在它擁有所有可用的技術來促進各個方面的業務。 “IT 不再被視為成本中心，而是業務推動者。”

將業務路線圖對應到Cloud-fit的策略

大多數企業從地端機房開始他們的雲端遷移，儘管越來越多的企業也已經在雲原生開發方面走得很遠。我們也需要顧慮到另一種可能：計劃將我們的地端機房遷移到雲端中，但企業也已經在雲端中運作雲原生應用程式。企業的各項業務可以有"單獨的雲端軌跡，以不同的速度運行"。使用雲原生工具在雲端環境中執行單一業務的新應用程式的開發是有意義的。接下來，企業還可以計劃將其地端機房遷移到雲端平台。有很多方法可以做到這一點。我們將探索這些方法，但也會研究這些雲端遷移的驅動因素。關鍵資訊是，我們很可能不會只使用一個路線圖(可能因各項業務而異)。 每個路線圖它由具有不同複雜程度和不同方法、不同速度的多個軌跡組成。

我們一直在討論企業策略、業務需求甚至財務規劃是有充分理由的。具有這些不同軌跡的路線圖的構成完全取決於我們的評估和規劃的結果。這也是企業架構的一部分。

這裡我們引用Redhat的技術主管 Radhesh Balakrishnan的話：

A multi-cloud strategy allows an organization to meet specific workload or application requirements — both technically and commercially — by consuming cloud services from several cloud providers.

他同時也提到：

“並非每個部門、團隊、業務功能、應用程式或工作負載在其雲端的效能、安全性、地理範圍方面都有類似的要求。隨著雲端運算變得更加成熟和主流，能夠使用滿足其各種應用程式和資料需求的多個 CSP 至關重要。”

這些業務需求將決定雲端遷移方法。我們有以下幾種技術策略：

Rehost: 應用程式、資料和服務器按原樣遷移到雲端平台，原來在地端機房長成什麼樣就一樣移過去。這也稱為lift and shift。這種方式效益往往很低。因為我們就沒有利用雲原生服務的任何優勢。
Replatform:應用程式和資料遷移到不同的技術平台，但應用程式架構保持不變。例如，使用 GCP的PaaS服務，將在地端中放在VM的mysql移動到 GCP 中的 cloud SQL中。
Repurchase: 舊的Application直接廢棄，改用 SaaS服務(但需要注意是否需要轉移舊資料)．這裡說的不是真的重新買這個Application，而是使用不同類型的解決方案替代它．
Refactor(重構):現有應用程式的內部設計和優化。這也可以是部分重構，其中僅修改應用程式的一部分已便在雲端中以優化的方式運作。在完全重構的情況下，對整個應用程式進行修改以在效能和成本方面進行優化，進而往雲原生應用程式的方向前進．然而，重構是一個複雜的過程。重構通常針對 PaaS 和 SaaS。
Rearchitect:這比重構更進一步，並且不修改應用程序的架構。這個方式確實包括利用雲端環境來重新設計其整體架構。
Rebuild: 開發人員利用最新的工具和框架從頭開始構建新的雲原生應用程式。
Retire:如果應用程式在未來的業務中不是策略性的需求，這個方式就是有效的。當應用程式退役時，需要在應用程式和底層基礎設施退役之前清理並經常歸檔資料。當然，當應用程式在功能上被refactored, rearchitected, rebuilt, 或repurchased，應用程式可以作為後續策略延後退役。
Retain:什麼都不動．

預測企業業務的未來結果並不容易，因為許多參數可能都有重要作用。 Gartner 等研究機構指出，在rehost、replatform和repurchase的情況下，總體成本節省將在 20% 到 40% 之間。當應用程式完全rearchitect 和rebuild時，節省的費用可能會更高。淘汰應用程式將帶來最大的節省，但話又說回來，假設該應用程式提供的功能對企業仍然很重要，它將需要以另一種方式來實現該功能，看是要購買、實施、採用和 (或)開發。在起草商業案例和選擇正確的策略時，必須考慮到這一切。

從較高層次來看，我們可以將這些策略劃分為三個階段:

傳統方式：
儘管企業將讓開發人員直接在雲端平台上使用雲原生工具，但他們中的大多數還是會有傳統的程式放在地端機房。遷移到雲端時，他們可以選擇三種方案：

Lift and shift
對應用程式進行適合雲端化的運作後再行遷移，也就是先優化再遷移
而第三種就是前兩種的混合

雲端化：這個階段就是對應用程式進行現代化改造並將其用於雲端平台。這是包含 PaaS 和 SaaS 以從雲原生技術中受益的階段。

動態的：這是應用程式完全雲原生並因此完全動態的最後階段：它們通過使用 CI/CD 的敏捷工作流程進行管理，使用容器和serverless解決方案的完全可擴展特性，並使用everything as code的原則完全自動化，達到IT 業務所需的敏捷性。

這一切都包裝在以下模型中。該模型表明這三個階段是連續的，但正如我們已經解釋的那樣，不過有時情況不一定是這樣：

這個模型顯示了未來幾年將主導雲端策略的三個趨勢：

從軟體到服務：
企業不必再投資買軟體，也不必投資於跑這個軟體的IT基礎設施。相反，他們使用完全由廠商來管理的軟體。這個想法是，企業現在可以專注於使用能滿足業務需求的軟體，而不必擔心這個軟體的實施細節以及運作和管理軟體本身。它基於內生增長(endogenous growth)的經濟理論，認為經濟增長可以通過開發新技術和提高生產效率來實現。使用 PaaS 和 SaaS，可以顯著提高這種效率。

不過這種方式不一定適合所有企業。因為這種方式在某種程度上企業”Lose control”，而這意味著可能有些監管會無法通過。或是企業會擔心被vendor lock in。

從VM到容器：
虛擬化技術為資料中心帶來了很多效率。然而，容器在利用電腦運算能力和存儲方面的效率更高。 VM仍然在guest OS中使用大量系統資源，其中容器使用host OS，並且在此之上只有一些library。容器往往更加靈活，因此在以非常有效的方式分散式服務方面變得越來越流行。甚至像 SAP 這樣的大型軟體商也已經使用容器分發和部署組件。 SAP Commerce 支援使用 Docker 容器，運行 Docker image instance。這些image是由特殊檔案結構構建的，這些檔案結構反映了 SAP Commerce step的組件結構。但上述所提到的效益則取決於企業的技術團隊的能力。

Serverless的運算：
Serverless是關於編寫和部署代碼而不用擔心底層IT基礎設施。企業只需為他們使用的東西付費(pay-as-you-go)，例如運算能力或存儲。它通常適用於一種觸發事件(event trigger)：應用程式 request event並在該應用程式的後端觸發一個動作；例如，檢索某個文件。公有雲平台提供不同的serverless決方案：Azure function/AWS lambda / GCP cloud function。它提供了最大量的可擴展性以實現最大的成本控制。在這一點上必須指出：儘管serverless概念將變得越來越重要，但在技術上不可能將所有程式功能都納入 serverless，這是需要case by case的。

總結

在本文中，我們討論了用於分析企業的業務策略的方法，並將其對應到雲端技術路線圖。我們還認知到，追踪CSP發布的所有新版本和功能的雲端技術與功能幾乎是不可能的。我們需要確定企業的業務目標和目的，並定義一個盡可能適應企業的業務未來的清晰架構，如果我們的雲端架構足夠靈活採用新功能，而且因企業業務要求需要使用，哪麼這個新功能對企業的業務就是有效益的。

業務敏捷性必須成為現代數位化企業的重點。業務驅動力源自財務、客戶、產品和內部目標，但這些在當前市場中正在迅速變化。主要趨勢之一是即將到來的基於訂閱式經濟，它迫使企業建立敏捷組織和能夠快速回應這些變化的系統。