展開您的雲端旅程

任何包含應用軟體移轉的雲端轉型過程都將非常複雜。不過，在這種複雜性中，雲端之旅有一些明確定義的目的。其中一個這類目的涉及要讓目標應用軟體達到哪種「符合雲端需求」程度。為了在所需的時間範圍內移轉到雲端，您希望/需要應用軟體達到哪種符合雲端需求程度？在這份文件中，我們將概述這當中的一些目的，並根據我們的旅程重點介紹最佳實務和所學到的教訓。成功的關鍵在於事先清楚定義您的移轉目標，以便您可以針對如何達成這些目標做出最佳決策。您會發現自己面臨許多可能的路徑。在移轉過程中，開發人員、交付團隊和高階主管將需要評估並做出許多選擇，以決定如何繼續。

建議您將焦點放在下列技術和業務驅動因素，以制定達成您企業目標所需的決策。

可擴展性

雲端服務提供遠遠超出託管基礎架構所能提供的大規模運算能力，讓您的企業能夠成長來滿足市場商機。雲端型基礎架構即服務 (IaaS) 和平台即服務 (PaaS) 讓 ISV 得以專注於利用現代化組件建置可擴展的架構。移轉的另一項優點是，可以讓內部開發團隊不必管理和調整 IT 作業，而能夠將焦點放在效能微調和最佳化。

現代化

將工具集、服務及架構現代化可簡化組件間的整合，協助應用軟體實現雲端中可用工具和技術的完整價值。這類工具的範圍從基礎架構升級到自動化部署管線，再到可提升應用軟體效能的整合式機器學習模型，都包含在內。當市場正經歷快速且一致的變化時，現代化至關重要，因為應用軟體必須動態因應，才能夠跟上腳步。在某些情況下，可以將服務完全重寫和重塑品牌形象，利用最新的技術堆疊來降低成本或簡化服務選項。這類變更可以活化老舊產品，並打破以授權產品為常態的成熟市場局勢。在其他情況下，則可以用新方法對產品進行全面檢查，既改善服務，又同時保持品牌知名度和客戶忠誠度。這不一定需要對產品套件進行完全變更。

移轉到雲端已成為廣泛推動現代化的觸發因素。由於雲端能讓您和您的團隊存取您組織中先前未提供的服務、技術和專業知識，因此使得達成新目標和提供新功能變得可能。您的團隊可以在堆疊上「向上移動」以專注在全新、普遍適用的產品功能，而非與不同客戶之特定部署連結的自訂程式碼。隨著服務佈建、產品更新及客戶支援比以往更快，資源便可重新聚焦在開發新功能上。透過這種方式，雲端移轉為廣泛的現代化活動做好了準備，將從執行產品升級到客戶服務品質的一切事項都進行轉型。

---

「移轉到 Gen2 Cloud 使 Oracle 得以透過強大的 DevSecOps 模型確保成功交付服務，並讓我們能夠支援客戶的業務轉型。我們現在每天發布軟體，並讓佈建時間縮短了 98% 以上。」— Karthic Murali (Oracle 全球業務部資深首席產品策略經理)

---

標準化

遍及 IaaS 與 PaaS 的標準化可讓您降低開銷，並讓團隊更具彈性且可被取代。隨著組織成長，您的團隊將採用各種不同成熟度等級的工具。將這些工具集整合在雲端服務中，可大幅降低與這一層 IT 管理相關的複雜性。針對在整個組合中都可對應的工作，可允許開發和使用標準營運實務。標準化還能讓例行活動變得更簡單、更可預測，從而減少基本工作的人力需求。之前在各個應用程式之間瀏覽各種不同、可能不相容流程時所佔用的資源會被釋出，可專注在更重要的問題上，包括為客戶開發新一代產品和服務。

值得注意的是，標準化使得與安全性、風險、法規遵循及其他營運活動相關的全球政策與實務變得更容易實施，您的團隊輕輕鬆鬆即可將這些政策與實務套用至現有和新的產品。事實上，應用軟體可以繼承 IaaS 平台的許多固有功能，例如已認可的法規遵循認證。

收入最佳化

收入最佳化可透過兩種主要方式實現。第一種且最明顯的方式是，降低成本。透過利用 IaaS 來免除資料中心不僅可將財務模型從資本支出轉變成營運支出，通常也可顯著節省總擁有成本。但如果是將已移轉到雲端的應用軟體組合中所使用的技術堆疊合理化，所節省的成本則可能沒有那麼明顯。通用工具集可建立機構知識，並免除與非標準化工具的特別訓練相關的費用。同樣地，將基礎架構視為程式碼的通用工具集也可提供最終能節省時間和人力成本的自動化。最後，專精於整個組合都適用之基礎領域 (例如安全性) 的團隊，不需要在每個個別產品團隊中都產生專家。

第二種方式是，移轉到雲端可幫助您更快進入市場，最終將收入最佳化，因為在應用軟體已符合雲端需求或雲端原生之後，產品開發時間表通常就會縮短。更快進入市場意謂著更快實現收入。在應用軟體已符合雲端需求之後，就可以在幾分鐘內將其部署到全球任何地方。

綜合而言，上述原則應既能產生標準化產品和服務架構，也能提升部署速度和品質。規模源自對重複模式的設計，有助於將收入最佳化、更快實現價值，並進而能夠讓資源重新聚焦在提升客戶服務的品質和完整性。

---

WorkForce Software 將其勞動力管理解決方案移轉到 Oracle Cloud Infrastructure，並提升 30% 的績效。

「我們看到了一個讓我們在資本支出中一開始就節省 30% 到 35% 的財務績效，而藉助從 OCI 獲得的絕佳績效，我們套件所實現的投資報酬率也持續變得越來越好。」— Mike Morini (WorkForce Software 執行長)

深入瞭解

---

在雲端實現價值的路徑

雲端運算可包含一系列 IaaS 和 PaaS 資源，以及多種軟體部署模型，範圍從存取裸機實例到整合式容器化環境，再到功能齊全的服務堆疊，都包含在內。就最基本層次而言，雲端運算係指以核心 IaaS 資源取代實體基礎架構組件。

大多數企業應用軟體原先都不是為雲端建置的。對許多應用軟體來說，要轉換成或遵守雲端模式既耗時且困難。不論是從時間還是人力的角度來看，重訂平台都會相當昂貴，因此從頭開始為雲端原生主體進行設計有時可能更加容易，也就不令人意外。考量到這一點，公司在考慮進行雲端移轉時，通常會發現自己處於三種主要情境的其中一種。

• 棄用傳統資料中心：運營資料中心所費不貲。建築物、人員、電力、散熱系統、維護及升級都只是日常職責的一小部分。許多企業正積極評估應用軟體組合來找出可在外部部署的候選產品，以減少或消除對資料中心的依賴。其首要任務是將應用軟體移出共置、託管的代管或內部部署資料中心，以試圖減少或消除資本支出。一般來說，企業會採用直接移轉策略，將應用軟體原封不動移轉到雲端中的裸機伺服器或虛擬機器上。
• 革新技術堆疊：在這種情況下，公司會開始對應用軟體進行增量變更，這將需要額外的投資，但隨著時間推移，預計也會帶來更多價值。例如，以雲端型 Oracle Autonomous Database 取代內部部署版本的 Oracle Database，而不對應用軟體本身進行重大變更。這有時也稱為移轉並改進策略。
• 全力投入雲端原生：與在導入上述其中一種情境時將較不成熟的應用軟體保持不變的成本相比，由下而上重新建構應用軟體以符合雲端需求的好處可能更大。雲端原生應用軟體本質上高度分散 (通常是以 12 要素原則建構)，因此其設計上是獨立於底層架構，也就是即使底層基礎架構故障，這些應用軟體也能繼續執行。簡而言之，評估此路徑對目標應用程式是否有意義是值得的，因為移轉到雲端一定會比移動與其底層基礎架構緊密結合的應用軟體更容易。

若要瞭解 Oracle 如何定義雲端原生、雲端原生應用軟體的起源，以及建構雲端原生應用軟體時應遵循的最佳實務，請參閱此電子書。

---

另一種設想這些情境的方式是，在將企業應用軟體移轉到 Oracle Cloud Infrastructure 的同時，也查看您可採取來使這些應用軟體更接近雲端原生架構的一系列行動。請參閱下面的圖 1。

圖 1：雲端移轉變更與投資等級

圖 1 左側代表變更最少、實現價值時間最短，且初始投資額最低。隨著您向右移動，變更、投資及時間的等級通常會增加，但實現的價值也會更大。此模型可協助您制定方法，以預測在移轉階段要考慮進行哪些種類的投資。請注意，由於應用程式是以多種方式建置的，因此這些情境不一定毫不相干，而是會稍有重疊。

上述情境可成為評估現有成熟度等級和雲端轉型目標的關鍵參考點。您目前狀態與目標狀態之間的差距，則可用來粗略估計雲端轉型所需的技術和流程變更範圍。在完美情況下，雲端轉型應使得所有應用軟體都轉變為雲端原生交付模型。不過，由於資源和時間限制，很少有組織可在單一流程中將其整個組合轉變為雲端原生模型。即使是簡單的重訂平台工作，也可能僅僅是為了複製舊有功能，就耗用大量資源及需要大量投資。

因此，雲端轉型的問題癥結是，在最佳雲端成熟度等級 (應用軟體在上面所示雲端代管到雲端原生連續圖譜中的位置) 與重新建構產品及其相關業務流程所需的工程投資之間做出取捨。在此階段，關鍵步驟是識別每個應用軟體的目前和目標成熟度等級，並粗略估計彌合差距所需的開發投資。

應用軟體若在移轉期間成熟度等級有所變更，則其營運模式與期望也必須一併變更。成熟度等級的變更會影響支援服務的團隊、流程及政策。

 

評估雲端的技術整備度

對目標應用軟體 (或提供多個 SaaS 型應用軟體之公司的整個應用軟體組合) 的技術理解，對於瞭解移轉的需求和相依性至關重要。在此階段，重點關注領域應該是識別應用軟體所需的功能，以及這些功能與這些相依性的關係。這將推動移轉活動的相對時間安排，並協助識別重點關注領域。評估應涵蓋三個關鍵面向。

1. 基礎架構需求：雲端會將軟體與其底層硬體或作業環境分離。成熟度高的應用軟體基本上不倚賴其環境，僅依賴可在雲端中輕鬆擴展的一般基礎架構資源，例如 CPU 或 Kubernetes 叢集。成熟度低的應用軟體倚賴所提供的特定設備、組件或環境，例如託管的基礎架構或其他專用系統。您必須先記錄您應用軟體對雲端基礎架構組件和組態的硬性倚賴程度，並最終予以消除。與底層基礎架構綁定/耦合的自訂項目 (不論是您還是您的客戶所建立) 並不罕見。
2. 服務組件：雲端會以獨立於應用軟體運作和交付的獨立服務形式，提供支援功能。成熟度高的應用軟體是圍繞離散的組件進行建構，在整個堆疊中的相依性最低，可讓您進行針對性的變更和升級，並最大限度延長正常運作時間。成熟度低的應用程式是以緊密耦合的大型組件構建而成，這些組件的相互倚賴性高，必須以單一實體形式進行管理。您必須記錄每個應用軟體的這些服務關係。
3. 營運整備度：雲端改變了技術架構，也改變了工作流程、技能組合、可用工具及營運模式。成熟度高的應用軟體已經能像雲端應用軟體一樣執行，並使用在雲端中運作良好的流程、標準和工具集。成熟度低的應用軟體則是在雲端缺少關鍵的支援服務、團隊以不適合雲端工作的技能組合支援它們，或使用在移轉到雲端後就會中斷的流程。

透過針對這些因素評估應用軟體的成熟度來開始移轉，可讓您適當地規劃，並避免發生造成延遲、增加成本及導致錯失目標的下游意外。由於目前的生產環境、支援服務套件和目標雲端環境在整個過程中將持續演進，因此難以低估移轉的複雜性。瞭解服務與應用軟體之間的連結不僅有助於事先進行明智的規劃，還能讓規劃靈活地因應移轉期間不可避免的變更。此評估在有效記錄的情況下，應該會為移轉過程產生明確的待辦事項清單。這將有助於確保預計的移轉時間表繼續與不斷變化的路線圖保持一致。

---

Zoom 在 Oracle Cloud Infrastructure 上快速擴展並啟動數百萬個並行會議。

「我們最近經歷了有史以來最顯著的業務成長，需要大幅提升我們的服務能力。我們探索了多個平台，而 Oracle Cloud Infrastructure 在幫助我們快速擴展能力及滿足新使用者需求方面提供重大助力。」— Eric S.Yuan (Zoom 執行長)

深入瞭解

---

財務目標

與任何 IT 計畫一樣，雲端轉型需要一系列投資，才能夠實現其完整價值，尤其是當目標應用軟體是為內部部署代管模型建置的情況下。應用軟體若被視為值得移轉到雲端，隨著時間推移最終就會變成雲端原生，否則會被終止。不過，初始目標通常是讓應用軟體進入雲端發布狀態。

若要讓您的應用軟體從目前狀態進入雲端發布狀態，需要進行一系列的決策和初始投資。您是打算就將應用軟體直接移轉到裸機伺服器 (在這種情況下，大部分投資都會在雲端基礎架構上)，還是已計畫先讓應用軟體符合雲端需求再進行移轉 (在這種情況下，將需要一些投資來將應用程式堆疊部件移轉成雲端型模型 (例如，將資料庫從內部部署移轉成 DBaaS 或 Oracle Autonomous Database))？如果您已建立硬編碼的自訂項目來啟用客戶特定功能，則必須針對將平台組件封裝並透過 API 以產品化功能形式交付的模型，重構這些自訂項目。為了在雲端擴展高度分散式應用軟體，將必須移除硬體或平台相依性。瞭解這些投資，對規劃及達成與雲端移轉相關的財務目標至關重要。

初始投資涉及進行與我們剛才所討論雲端移轉階段相關之必要產品變更所需的開發時間與人力。但也必須考慮其他支出。在轉型期間，您的組織可能產生的各種支出包括：

• 開發投資：重新建構產品或為移轉工作建立加速器所需的開發人力，包括支援資料庫移轉和應用軟體佈建等活動的自動化
• 移轉執行：佈建新資產、移轉現有環境和資料及淘汰舊有清單所需的人力資源
• 基礎架構採用：在 IaaS 升級過程中應計的訂閱費用，這會漸趨穩定，但在移轉期間會出現新的增長
• 滯留的基礎架構：在移轉過程中存留的資料中心和應計的資本支出折舊成本，這些須承擔至其能被消除或抵銷為止
• 勞動力轉型：與訓練、教育或重組現有團隊相關的支出，或取得具備所需雲端技能組合之新資源的支出
• 客戶轉型：與新模型無法支援的環境特性或服務條款變更相關的成本，包括新開發、獎勵、合約項目的重新協商或客戶流失

上述各項成本都或多或少是 IaaS 轉型過程的必要組成部分。各以不同形式影響您的成本概況。例如，開發投資和移轉執行支出可以是一次性費用，即使與此工作相關的資源可能為固定資源。新基礎架構的採用將導致一段時間內的支出淨增長，直到滯留的基礎架構支出被消除為止。有些勞動力和客戶轉型支出 (例如訓練或移轉獎勵) 將會是一次性支出。勞動力擴張或客戶合約變更等其他支出則可能導致新的持續性支出。

瞭解這些動態因素如何隨著時間推移而發揮作用，對您的組織為雲端轉型做好準備及設定期望至關重要。如果您的組織熱烈期盼雲端帶來的巨大好處，但缺乏對轉型風險的清楚瞭解，初始早期的支出增長將會令您吃驚，尤其是在您預先吸收移轉、重疊基礎架構及轉型成本的情況下。設定正確的期望並讓遞增進度的發展維持清晰可見，是組織在轉型過程中維持一致性和紀律的基本要素。

雲端移轉清單

雲端移轉清單是移轉至雲端時不可或缺的要素。什麼是雲端移轉清單？簡而言之，這是產品群中所有資產及描述各項資產之相關關鍵資料元素的清單。此清單包含要移轉的目標應用軟體及其所有相依項目。用來擷取該資料的媒介並無關緊要，且由於資料通常跨公司內的各個部門，因此使用數種工具的情況也很常見。所需的資訊通常分散在一系列的生產、銷售及營運資料庫中。例如，組態管理資料庫可能會詳細追蹤技術相依性和資產位置，甚至詳細到實體伺服器和機架位置。不過，這並不會包括對決定客戶何時及如何收到轉型通知至關重要的業務和客戶考量事項。該資訊通常包含在專為營運和支援利害關係人設計的儲存庫中。此外，收購、特殊使用案例及產品孤島可能意謂著資訊進一步分散在多個儲存庫中。

移轉清單的主要用途是讓您集中檢視管理雲端轉型所需的因素。例如：資產是什麼？資產在哪裡？資產支援什麼產品？資產有什麼作用？資產支援哪些客戶？

從一開始，就必須意識到藍圖是一份活的文件。它會隨著時間演進，因此必須具有彈性，對於具有多個應用軟體或多個應用軟體版本的公司而言，更是如此。隨著新問題的浮現與新需求的發現，此清單也會隨之演進。甚至是底層的雲端基礎架構也可能在移轉過程中發生變更，而使此清單再次發生演變。移轉清單應儘可能多加擷取可用的資料，以便您開始進行初始規劃，然後隨著轉型透露出新的需求而添加各層詳細資訊。

管理移轉清單本身就是一項跨職能專案，必須讓詳細資料需求與詳細資料收集工作保持平衡。其中也包含識別相依性、限制條件和資源的元素，這些元素會影響時機和速度，例如精細的技術規格、架構方法、客戶需求和資料傳輸路徑。如果資訊太少，清單便不太有用。如果資訊太多，則維護費力，而可能很快就過時並被淘汰。

建議您使用下列移轉清單架構作為雲端移轉的起點。

由移轉清單到營運清單

雖然我們專注在移轉清單上，但雲端轉型最終會帶來兩項挑戰。最直接的是，它會產生規劃、排定優先順序及追蹤移轉活動的需求。不過，移轉本身會強制變更日常營運追蹤所需的資料。例如，實體伺服器和機架的相關移轉後組態詳細資訊將變得無關緊要，甚至個別實例的相關資訊也會變得較不重要。與此同時，整體使用狀況和資料出口等指標可能變得至關重要，尤其當組織採用自助服務模型時，更是如此。

建立移轉清單後，應該就會開始過渡到這些以雲端為中心的新資料模式和流程。雖然建立清單和移轉應用軟體的雙重挑戰是個別專案，但不應該分開進行。移轉工作是前導工作，且可能是組織第一次建立其資產的詳細整合檢視。這是一個應形成新移轉後清單檢視範本的轉變時刻。如上所述，移轉清單必須能夠彈性因應情況。如果妥善管理，移轉清單就會演變成一個有價值的移轉後清單管理工具。

試行通往雲端的道路

設計代管 SaaS 應用軟體的基礎架構

作為提供 SaaS 型應用軟體的 ISV，您需要安全、可擴展的企業級基礎架構，以隔離方式代管您的服務和管理客戶。下圖 3 所述的參考架構提供一個經過驗證的架構，內含最佳實務，可讓您在 Oracle Cloud Infrastructure 上代管 SaaS 應用軟體。

在此參考架構中，您會部署和管理多個隔離的應用軟體實例。每項部署都是針對特定租用戶，而管理這些個別租用戶應用軟體實例時，都是透過共同的管理層進行管理。

您可以選擇從單一程式碼庫建置所有租用戶應用軟體實例，也可以向每個租用戶提供自訂的應用軟體版本。此模式相當適合需要完全隔離應用軟體環境的 SaaS 客戶。

圖 3：OCI 上 SaaS 應用軟體的最佳實務參考架構

如需有關上述參考架構的更多詳細資訊，請造訪 Oracle Architecture Center。此外，我們還建立了 Terraform 型工具，並提供逐步指南，可協助您為四個租用戶部署架構。最後，我們一律建議遵循 Oracle Cloud Infrastructure 最佳實務指南，當中提供了四項常見業務目標的指導：安全性和法規遵循、可靠性和彈性、效能和成本最佳化，以及營運效率。

除了架構變更之外，您還需要考慮服務堆疊在雲端中將如何變化。用於監控的核心工具集、網路管理或部署在針對內部部署架構開發之舊有環境中的安全性，都將針對雲端發生演變。移轉到雲端之後，您便有機會擴展這些工具所能處理的範圍。雲端型工具不是提供主要監控端點，而是提供整個堆疊的監控功能。有時，雲端服務提供者會在核心功能之上再提供雲端或混合式監控工具。就 Oracle Cloud Infrastructure 而言，結合原生監控、標記及稽核功能不僅讓您能夠監控完整服務堆疊，且通常也能自動補救在指定規範外發現的異常狀況。如果您目前在內部部署環境中使用第三方監控工具，這些供應商也可能提供混合式或雲端型工具。

---

Cisco Tetration 將核心應用軟體移轉至 Oracle Cloud Infrastructure，使效能提升 60 倍。

「與 Oracle 的合作令人十分滿意。這就是 Cisco Tetration 蛻變魔法的發生原因。」— Navindra Yadav (Cisco Tetration 創辦人)

---

建立試點計畫

就像任何工程工作一樣，從小型試點計畫或原型開始，透過讓試行團隊和您的組織瞭解可行工作及進行方式，即可最大限度地提高成功機率。試點和概念性驗證計畫可識別並解決挑戰，而不會有伴隨全規模、全組織變革而來的時間與財務壓力。試點計畫可藉著緩慢移轉及熟悉新的營運環境，協助您管理變革速率。

試點計畫讓核心開發人員及營運人員小組有機會探索目標雲端環境，從而瞭解架構、服務及營運模式。這個團隊孕育出了實用知識、有用工具和最佳實務以及信心、專業知識和經驗的種子。就在您團隊建立此知識的同時，他們也在發展於雲端型環境中跨團隊協作的道路規則。雲端移轉需要應用軟體團隊從直接資源管理者演變為其他團隊所提供服務的消費者。試點計畫可讓應用軟體團隊瞭解服務界限的變化、與提供所用服務的營運團隊建立關係，以及瞭解如何向這些營運團隊提出需求。

試點計畫提供下列好處：

• 提供驗證 (或挑戰) 技術可攜性假設的相關資訊環境，特別是當技術一律在相同環境中執行的情況下。這有助於團隊瞭解他們是否已準備好進行移轉，並確定為了移轉需要進行哪些變更。
• 讓團隊有機會確認應用軟體/資料庫是否已準備好與目標環境中的服務進行整合。這可讓團隊知道所需進行的變更，以及應用軟體和目標服務環境都準備好進行移轉的時間。
• 讓團隊能夠為目標環境進行建置，從而建立一個立足點，這會成為組合其餘部分移轉至新服務與新環境時的出發點。這為團隊提供了其組合的策略性目標。

---

Manhattan Associates 將其供應鏈解決方案移轉到 Oracle Cloud Infrastructure，比之前的雲端解決方案節省了 50% 成本。

「就基礎架構而言，Oracle Cloud 在應用軟體和資料庫層的多功能性與靈活性，讓我們與先前的雲端解決方案相比節省了大約 50%。」— Jeff Demenkow (Manhattan Associates 副總裁)

---

管理試點計畫

試點計畫對技術與營運人員及高階主管與管理團隊而言，是一項學習體驗。高階主管和管理團隊應與試點團隊持續溝通，以協助消除組織障礙，並確保組織從試點專案中充分汲取經驗教訓 (亦即瞭解可行之處、失敗之處、最佳實務、教訓，以及所識別的標準模式或反面模式)。這項寶貴資訊可供擷取，然後與組織的其他人員分享，在理想的情況下，能提高後續雲端專案的有效性與效率。試點計畫可讓管理層測試制定計畫時所做的假設，並清除不確定因素。雖然這些假設因組織而異，但試點計畫都可呈現任何移轉過程中會面臨的一些重要挑戰。

• 訓練：試點計畫會測試現有技能，從而揭露組織對技術移轉工作的準備程度。管理層應利用試點計畫來評估技術熟練程度、瞭解哪些工具和能力最需要學習，並規劃如何針對這些關鍵領域的技能進行人員培訓 (或聘僱)。
• 協作：試點計畫會揭示開發、營運和支援團隊如何以不同的方式合作。管理層應確保這些團隊在試點期間確實合作，從而揭露新需求，並瞭解如何在這個新環境中運作。
• 改變的慾望：試點計畫讓公司有機會找出將影響更大範圍移轉的文化障礙。一個小組若在試點計畫中發生問題，在大規模環境中也會有相同的反應。試點計畫讓管理層有機會層識別問題、部署訓練，並調整計畫來因應其特定組織的實際情況。

順暢移轉的關鍵在於建立穩固的基礎。移轉的第一階段將推動開發一組核心的服務和平台，這些服務和平台將隨著移轉的進行而逐步擴展。最後，這些核心功能將需要擴展，以支援整個移轉組合。因此，初始雲端版本不僅要成功，還要為所有後續版本和升級建立跑道。

適應組織變革

設計代管 SaaS 應用軟體的基礎架構

隨著您組織交付模型和客戶關係的變革，可能需要新的技能、知識、業務流程和思維方式。這些變革可能對整個組織產生廣泛的影響，這也是為什麼文化變革常被視為是雲端轉型中最困難的層面。

單是這些變革的範圍之大，便足以產生「雲端轉型需要進行大規模重組，並導入具有雲端經驗及專長的替代人力」此一印象。雖然內部職能專業化的變革，以及以雲端技能組合為焦點的新人才聘僱，都是雲端轉型的主要組成部分，但您也無法承擔損失作為您迄今為止成功關鍵的既定流程、動力及貢獻者。您必須在組織變革速度與可能打斷持續業務和客戶體驗的情況之間取得平衡，這點至關重要。若要維持這種平衡，就需要重新調整職涯發展能力的結構性變更，以便讓現有員工過渡到新的營運模式。

將存在已久的軟體業務轉型為雲端交付模型，需要在眾多關鍵業務領域的假設、技術知識及標準作業流程方面，都做出巨大轉變。雖然所需的變更規模可能令人望而生畏，但根據我們的經驗，保留並投資現有團隊，通常比嘗試全面換聘雲端專家更好。組織若是規劃類似的轉型，應看看我們的 GBU 組織如何從對變革需求進行由下而上的分散式評估開始，讓每個團隊能夠建立其各自的移轉清單和服務堆疊路線圖，進而識別出其各自控制領域所需的步驟。此方法可讓團隊將其計畫與有形的變更驅動因素保持一致，同時避免對其潛在需求進行概要性假設。

---

8x8 透過移轉至 Oracle Cloud Infrastructure，讓全球緊密相連、降低成本 80%，並改善服務。

「隨著視訊會議迅速成為當今新世界的結締組織，我們看到了我們的使用者人數飆漲。為了支援該指數型增長，我們考察了數個平台，並選擇了 Oracle 的 Gen 2 Cloud 基礎架構，因為它提供強大的安全性、出色的性價比，以及世界級的支援，可為這樣的使用者激增情況提供服務。」— Vik Verma (8x8 執行長)

觀看影片

---

商業影響

成功的雲端試點計畫與整個組織的變革相輔相成。若要從主要為代管或內部部署的組合移轉成雲端型業務，將需要在組織與客戶的互動方式上做出根本性轉變。不過，要對既定商業實務和假設進行哪種程度的變更，將主要取決於在雲端轉型過程中對產品進行多大範圍的變更。

即使是在變更不多的情境下，轉變成 IaaS 也會推動業務流程的轉變。在此背景情況下，我們的 GBU 確定了兩個關鍵機會。

1. 以將短期波動與長遠預期都納入考量的營運支出導向預測模型，取代資本支出密集型實體基礎架構管理
2. 讓已無須承擔傳統職責的安全性與法規遵循團隊進化，專注於提供服務組件

對於應對這些變革及其應用軟體中技術變革的組織來說，將能夠更好地發揮雲端移轉的全部潛力。

與客戶結盟

從提供「收縮膜包裝」產品或甚至是從提供代管產品到實際雲端服務，會是您與客戶將共同經歷的旅程。事實上，就是這種即服務模型的變更，讓雲端與所有先前的代管模式有所區分。對雲端服務的每一項變更都會影響客戶的體驗，從可擴展性、正常運作時間到彈性，都包含在內。在某些情況下，客戶可能會請求 (甚至是要求) 變更為新的交付模型。在另一些情況下，客戶對特性、功能及成本的期望，則可能會演進成只能透過雲端交付來支援。

隨著您開始讓客戶參與您的雲端策略，您必須為以下兩個觀點做好準備：對發展路線的興奮期盼，以及對離開熟悉事物的抗拒排斥。若要應對這些觀點，必須與客戶有清晰且審慎的溝通來指明工作方向，如此才不會迷失在技術細節中，或引發危險信號。這正是讓組織內部的客戶專責團隊參與互動的關鍵時刻，以確保他們瞭解正在進行的工作、企業所做的投資，以及產品與交付的預期結果。為此，您的客戶專責團隊必須參與其中，才能夠將這項變革轉化為服務條款，增強客戶對服務的信心。

針對將使用雲端服務的客戶，情境可以變得再複雜一些。有些客戶群會要求使用雲端服務；因為他們瞭解 SaaS 在效率和敏捷性方面可帶來的好處。不過，隨著雲端或 SaaS 選項已成為賭注，必須讓客戶瞭解區別供應商服務的功能和服務等級協議，而不是雲端本身的價值。

但並非所有客戶都渴望使用雲端服務。具體而言，代管或託管服務模型的現有客戶可能對現狀已感到滿意，特別是如果他們具有與雲端交付不一致的定製服務組件或非標準環境與存取模型，就更是如此。甚至是已瞭解移轉至雲端服務將受益匪淺的客戶，也可能對交付條款變更或移轉其環境所需的服務中斷感到不安。

若要讓客戶放心，就需要跨行銷、銷售、支援及客戶成功團隊進行協調和不斷溝通。在理想的情況下，客戶完全不會發覺其工作負載已移轉；他們會在某一天注意到效能提升，但不會發覺發生了哪些變更。實際上，若要將服務移轉至雲端，通常需要升級和停機，還可能變更服務條款或可用功能。要引導客戶度過上述事件，同時又不偏離整體轉換時間表，是一項複雜的壯舉，需要的不僅僅是瞭解變革的好處就好。還需要認同正在進行的變革，並在可能影響客戶業務的移轉步驟上保持一致。

---

CMIC 將其營建企業軟體移轉至 Oracle Cloud Infrastructure，使部署速度加快 10 倍。

「除了 OCI 相較於其他雲端供應商更具成本優勢之外，我們現在也更為敏捷。OCI 為我們提供了新層級的技術彈性。我們正運用 Oracle Container Services 和 Oracle Autonomous Database 等技術邁向未來，以便繼續專注於提供最佳營建 ERP 軟體。」— Vince Di Piazza (CMIC IT 與雲端基礎架構主任)

觀看影片

---

一旦客戶對將伴隨雲端轉型而來的優勢與變革表示支持，您組織所面臨的最後一步就是將客戶的工作負載實際移轉到新的環境。這會成為決定移轉和新環境驗證測試最佳時間的挑戰。客戶即使接受將停機一段時間，但通常仍然會對該停機時間應於何時發生有強烈意見。

儘管客戶偏好將對您來說很重要，但您也必須平衡許多其他考量。規劃移轉涉及許多因素的取捨，包括產品或服務的技術屬性、協調所有客戶的偏好、內部資源限制，以及業務目標 (例如合併/消除現有的舊有資料中心，或終止棄用中的產品線)。為了平衡這些衝突的優先事項，請將客戶專責團隊納移轉規劃活動中，因為它們將代表市場期望表達關鍵想法。

您的組織除了必須為一段投資和移轉期間，以及雲端交付模型的持續技術與業務流程變革，做好準備之外，也必須為吸引客戶參與移轉的方式，以及產品和客戶關係的新現狀，做好準備。

我們 GBU 回應上述需求的做法是，先檢閱轉型在技術上、營運上及交付承諾上會如何影響客戶，從而隔離需要特別關注、參與互動及可能變更商業關係的需求。客戶專責團隊的準備工作也是以類似的觀點為基礎，涉及了產品、營運、策略和其他團隊之間的協作，既提供普遍的雲端素養，同時也因應特定產品與客戶變革。

這項工作不僅僅只是讓客戶專責團隊做好與客戶互動的準備。藉由讓跨職能的核心領導層齊聚一堂，使其在客戶互動上達成一致，也創造了寶貴的機會，可將主要由技術領導的計畫擴展為更廣泛的舉措，這些舉措攸關重新審視解決方案核心價值、重新闡明產品與眾不同之處，以及規劃在市場中保存並增長該價值的最佳方式。

預先準備

設計代管 SaaS 應用軟體的基礎架構

在本手冊中，我們根據從移轉數千個實例上代管的 60 多個 GBU 應用軟體所學到的經驗教訓，提供了最佳實務指導。以下總結我們在整個旅程中所面臨的五大挑戰，因為我們確信這些挑戰適用於將應用軟體移轉到雲端的任何組織。

1. 確定移轉前的開發工作
   若要為既定的應用軟體進行雲端發布準備，可能需要大量投資，尤其是將產品轉變成雲端原生產品更是如此。投資雲端原生應用軟體原則可產生能從雲端獲得的最高效益，但同時也需耗用大量時間和開發資源，才能夠達成該目標狀態。產品的雲端準備時間越長，您就越遲才能享有移轉至雲端的固有遞增優勢，而可能有更長的時間暴露在通常與舊有環境相關的風險中。與此同時，並非所有產品都同等受益，需視其生命週期階段和客戶狀況而定。充分瞭解並記錄移轉前要進行的開發工作量，是成功移轉的關鍵。
   
   GBU 應用軟體群非常多樣，包含處於各個雲端成熟度等級和生命週期階段的產品。雖然所有應用軟體都需移轉至雲端，但在雲端發布前應進行多少產品變更，卻令人苦惱。為了找出正確的平衡，組織必須評估每項產品的生命週期階段、成長潛力，以及將產品導入雲端所需的工作。根據上述綜合評估，GBU 便確定了每項產品的優先順序和支出等級。
2. 確定開發組合
   要對雲端投資整備度投入多少工程頻寬，以及對因應市場需求開發新特性和功能投入多少工程頻寬，對 GBU 來說是一個難以達成的平衡。
   
   GBU 在雲端轉型優先順序上並無不一致之處，但產品團隊確實難以理解應投入多少心力，來開發會改善客戶體驗和效能但又不取代客戶所需功能的雲端功能。若要進行雲端開發，需要投資底層營運功能，這可能會分散組織回應客戶對新功能之需求的能力。有了這些取捨，就很難搞清楚如何在雲端整備度與產品增強計畫之間分配時間。
   
   為了應對這項挑戰，GBU 仰賴第 1 章所探討的雲端成熟度架構，深入瞭解每條路徑所需的相對開發投資。接著，他們審視了每個潛在雲端轉型階段的投資報酬率，並將該結果與預期新功能開發所帶來的潛在收入貢獻進行權衡比較。這提供了一個通用評估架構，可用來確定正確的工作組合，讓目標業務成果清晰可見。

   ---

   Altair 選擇 Oracle Cloud Infrastructure 上的高效能運算功能，將性價比提高了 20%。

   「當我們考察所有雲端供應商時，發現 Oracle 非常專注於 HPC。他們的裸機產品我認為是業界首創，具備高速、低延遲的網路功能，這對我們來說非常重要。」— Piush Patel (Altair 策略關係資深副總裁)

   ---

3. 瞭解產品群
   無論貴公司擁有單一應用軟體還是大型組合，在雲端移轉過程中都需要追蹤和清點許多因素。為了充分理解需要進行哪些變更，您必須完全瞭解所有現有應用軟體儲存庫中的目前清單，以及打算在雲端使用的內容。如果您要移轉的應用軟體很多，則可能沒有現有清單，或是您可能需依賴有關特定應用軟體狀態的部落知識。即使公司只有一個面向客戶的應用軟體，也仍需清點整個應用軟體堆疊，以確定移轉至雲端時將需要變更哪些層面。瞭解雲端中將有的需求變更和所需的設計樣貌，是記錄轉型所需工作的關鍵層面。
   
   每個應用軟體實例都需要不同類型和數量的工作，具體取決於實例的特性 (版本、硬體/平台相依性、自訂項目、客戶存取模型等)。此外，應用軟體資料可能分布在多個記錄系統中。
   
   Oracle GBU 整合了 30 多項收購項目，其產品群遍布 80 個資料中心和 12,000 多個應用軟體實例。與這些實例相關的關鍵資料高度分散，且不一定在所有組件產品團隊中都以一致的方式進行管理。如果沒有這項資訊，他們就無法有效地組織和規劃移轉人力。為了清楚瞭解需要移轉的內容，GBU 必須展開專門的資料收集和整合工作。

   ---

   「Oracle GBU 團隊透過移轉至 OCI 將資本支出降低 80%，並將基礎架構成本降低 64%。」— Mike Prindle (GBU 雲端架構副總裁)
   

   ---

4. 排定移轉工作優先順序並進行組織
   實際移轉工作負載可採取一些途徑，範圍從複製現有 VM 的映像檔到安裝新實例和複寫資料，都包含在內；但全部都需要某種程度的技術投資或人力承諾，才能夠完成。由於移轉所涉及的人力數量和不同類型在組織產品群中的各項產品環境中會成倍增加，因此很容易就會變得難以承受。可用於完成任務的資源有限，且通常也負責管理日常作業。

   ---

   OceanX 將其商業智慧系統從 Amazon Web Services (AWS) 移轉至 Oracle Cloud Infrastructure，效能提升了 3 倍。

   「我們需要資料平台以更低的成本擴展並提供高效能。將資料平台從 AWS 移轉至 Oracle 是 OceanX 最成功的移轉之一，加上還大幅提升效能及節省大量成本，意謂著整個計畫是一項巨大的成就。這最終使我們能夠為客戶提供一個平台，讓他們能夠更快地做出更明智的決策。」— Vijay Manickam (OceanX 資料與分析副總裁)

   ---

   GBU 雲端轉型需要 3,000 個以上的個別移轉專案。這些專案原本是根據客戶偏好來排列優先順序 (即根據整合的客戶意見來排列移轉時間範圍的優先順序)，或根據特定環境的移轉整備度來排列優先順序。最終，此方法未能在移轉過程中讓業務效益增加。如果沒有共同的優先順序或協調架構，GBU 就會看到移轉活動量不一致。由於資源高度競用和浪費可用資源的期間交替出現，因此為負責完成移轉工作的團隊帶來了負擔。
   
   為了解決這些挑戰，GBU 設立了一個專門負責移轉工作的中央計畫管理辦公室和一個執行監督委員會，負責根據目標業務成果來排列移轉優先順序並識別關鍵機會。
5. 管理組織變革
   雲端轉型涉及眾多變革，需要新領域的知識、技能組合和流程，以及其他領域的文化變革。管理這些人力資源挑戰可能會比雲端轉型過程的技術組件更困難。為了因應此情況，Oracle GBU 透過專注於訓練，幫助現有團隊進化成雲端團隊。何時引進新人才、何時尋找以其他方式讓組織進化的機制，面對此問題時，GBU 需要依據其主要職能領域和產品群組進行勞動力評估，然後針對每個使用案例對應適當的改善計畫。如果貴公司有多個應用軟體需要移轉，請思考一下您可以在何處建立涵蓋所有產品 (例如安全性和一般 IaaS) 的基礎雲端知識。

慶祝成果

本手冊是以 Oracle GBU 團隊的經驗為基礎，這些經驗是在將 60 多個 SaaS 型應用軟體移轉至 Oracle Cloud Infrastructure 的過程中所累積。這些應用軟體支援全球跨八個產業和超過 199,000 家客戶的核心企業功能。精心設計、計畫完善且妥善執行的移轉可帶來可觀的效益。

• 將 80 個資料中心合併成 11 個
• 將資本支出降低 80%
• 將基礎架構成本降低 64%
• 軟體供應商從 28 家減少到 10 家
• 將軟體支出降低 42%
• 轉為每日發布軟體
• 將佈建時間縮減 98% 以上
• 將計畫性停機時間縮減 98% 以上

雖然此 ISV 手冊是以我們 GBU 團隊所獲得的經驗為基礎，但他們的工作只是 Oracle Cloud Infrastructure 數次大型移轉的其中之一。若將所有 SaaS 應用軟體的收益和客戶數量都算在內，Oracle 可被視為全球最大的 ISV 之一，深諳移轉流程。實際上，我們已將整個產品組合 (包括 Oracle Fusion Cloud ERP、Oracle Fusion Cloud EPM、Oracle Fusion Cloud HCM、Oracle Advertising and CX 及 Oracle Fusion Cloud SCM) 都移轉至 Oracle Cloud Infrastructure。這些移轉是名為 Oracle@Oracle 之轉型計畫的一部分。這是一個多年的專案，涉及分佈在數十個資料中心的數萬個應用軟體。

以下是這些努力所帶來的一些好處。

• 基礎架構 – 我們應用軟體組合的可用性達到 99.99%、成本節省 30%，且效能提升 2 倍到 10 倍
• 財務 – 能夠在 10 天內完成結帳並申報所得
• 人力資源 – 人才審核週期縮短了 70%
• 供應鏈 – 將供應鏈規劃週期從 1 週縮短為 48 小時，改善程度達 71%
• CX – 活動前置時間從 4 週縮短至 5 天，改善程度達 82%
• 永續性 – 在 2019 會計年度中重複使用或回收利用了 99.4% 於 Oracle 收集的退役設備

與 Oracle 合作

我們正在幫助 ISV 擴展其潛在市場，同時增加其收入增長潛力。請傳送電子郵件到：oraclecloud-isv_ww@oracle.com 以進行深入瞭解。

若要深入瞭解 ISV 選擇 Oracle Cloud 的原因，請參閱下列資源：

• isv.oracle.com
• 適用於 ISV 的 Oracle@Oracle 方案
• 探索雲端代管注意事項和模式微型網站

---

Körber 將倉儲管理系統整合到 Oracle Cloud Infrastructure 上，執行速度提高了 40%。

「在我們評估不同的決策點時，OCI 對我們在市場開拓策略方面嘗試採取的行動而言非常具有戰略意義。」— Rick Schrader (Körberö 北美銷售和聯盟資深副總裁)

觀看影片

---