數位轉型需要企業具備清晰的策略藍圖和執行框架。從定義目標營運模式（TOM）開始，逐步重構組織架構，最終建立混合型企業。過程中，修復基礎設施、匯入新的營運模式、建立微型企業生態系統，並持續創新解決方案至關重要。為有效管理轉型，Obeya 方法提供集中監控和瓶頸識別機制。應用程式組合管理需轉向 SaaS 和訂閱模式，以保持持續創新。產品生命週期管理成為應用程式管理的核心，涵蓋需求、架構、開發、測試、佈署、持續整合、營運和發布管理。七大品質屬性（互操作性、可組態性、效能、可發現性、強健性、可移植性和可用性）以及對應的架構原則指導應用程式設計。
在數位轉型中，零信任安全至關重要，強調「永不信任，始終驗證」。雲原生技術和微服務架構提供模組化、可攜性和細粒度控制，支援零信任和敏捷開發。DevOps 和 DevSecOps 實踐促進開發、維運和安全團隊的協作，將安全整合到整個開發流程。一切即服務的概念和數位平台架構提供靈活的服務提供和消費模式。新的數位應用組合管理強調靈活性、易用性、微服務、容器化、敏捷性、持續改進和自動化。風險管理在轉型過程中扮演關鍵角色，FMEA 和 QFD 方法幫助企業識別、評估和緩解風險。風險管理應整合到企業架構（EA）中，並遵循成熟度模型逐步提升風險管理能力。
數位轉型的實務藍圖與創新思維
在數位轉型的過程中，企業需要制定清晰的路線圖，以確保能夠順利實作轉型目標。本章節將探討企業如何透過定義TOM（Target Operating Model）、重構組織架構以及建立混合型企業來推動數位轉型。
短期目標：奠定基礎
在短期內，企業需要專注於以下幾個關鍵領域：
- 定義TOM：明確未來營運模式的藍圖。
- 修復基礎設施：確保數位工作場所和基礎設施的健全。
- 初步解構組織：從小規模開始，對一兩個單位或團隊進行解構。
內容解密：
- 定義TOM是數位轉型的起點，涉及對未來企業營運模式的全面規劃。
- 修復基礎設施包括升級數位工作場所和技術基礎設施，以支援未來的業務發展。
- 初步解構組織是將傳統企業轉變為更靈活、更貼近客戶需求的微型企業的第一步。
中期目標：採納與擴充套件
在中期階段，企業將開始：
- 採用新的營運模式：透過創造第一批微型企業，進入混合模式。
- 重構與擴充套件：繼續解構和重構企業，並擴充套件微型企業的規模。
內容解密：
- 採用新的營運模式意味著企業開始實施新的組織架構和營運方式，以提高靈活性和創新能力。
- 重構與擴充套件需要持續進行組織調整和業務擴張，以適應不斷變化的市場環境。
長期目標：創新與擴張
在長期階段，企業將致力於：
- 形成生態系統微型社群：建立不同微型企業之間的合作與共創機制。
- 擴充套件微型企業：進一步發展和壯大微型企業。
- 創新解決方案：不斷創新，以開發新的產品和服務。
內容解密：
- 形成生態系統微型社群涉及建立Ecosystem Microcommunity Contract（EMC），促進不同微型企業之間的協作。
- 擴充套件微型企業需要持續投資於創新和人才培養，以保持競爭力。
- 創新解決方案是企業持續發展的關鍵，透過不斷創新來滿足客戶需求和市場變化。
受控轉型與Obeya
為了有效地管理轉型過程，企業可以使用Obeya（一種源自日本的管理方法，意為「大房間」）來集中管理和監控轉型的進展。Obeya透過視覺化展示所有相關資訊，如戰略、成就、專案、改進和資源，有助於識別瓶頸並採取緩解措施。
圖表翻譯：
此圖示展示了Obeya的實施框架，包括轉型目標、SWOT分析、業務使命、抑制因素、成功案例、專案、新計劃和資源管理等關鍵要素。
應用程式組合管理
隨著數位轉型的推進，企業可能需要重新設計其應用程式組合，轉向SaaS和訂閱模式。Tien Tzuo在其著作《Subscribed》中預測，訂閱模式將成為未來企業的主要商業模式。這種模式鼓勵企業持續創新和改進，就像Google的Gmail服務一樣，始終保持在「測試版」狀態，不斷更新和整合新功能。
內容解密：
- 重新設計應用程式組合涉及評估現有應用程式，並根據業務需求進行調整或替換。
- 轉向SaaS和訂閱模式可以提高靈活性和可擴充套件性，同時降低成本。
應用程式生命週期管理與數位轉型
在數位轉型的時代，持續創新意味著產品永遠不會真正完工。消費者已經習慣了他們的智慧型手機、平板電腦電腦和電腦上的應用程式不斷更新和升級，直到某個服務或產品到達其生命週期的盡頭。這是探索生命週期概念，特別是生命週期管理的最佳時機。
生命週期管理的核心地位
生命週期和生命週期管理已經成為應用程式及其基礎軟體最重要的方面。或許更準確地說，生命週期管理是現代企業中最關鍵的過程。產品生命週期、資訊生命週期和應用程式生命週期是互補的。它涵蓋了幾乎所有我們在前幾節中討論的內容，包括：
- 需求
- 架構
- 開發
- 測試
- 佈署
- 持續整合
- 營運
- 發布管理
從發布管理開始，生命週期再次從需求開始，因為從發布開始，客戶將提出新的需求，因此需要開發新的功能。這個迴圈一直持續，直到某個產品、服務或應用程式在技術上無法再更新和升級，或者——更常見的是——與開發新產品相比，這樣做太費力和成本太高。業務規劃、預期的業務成果和衍生的商業案例必須始終在這個過程中佔據主導地位。
對架構的影響
客戶透過數位管道訂閱企業提供的服務。客戶訂購、升級、暫停、還原和續訂訂閱。因此，底層服務必須能夠對此做出反應：擴充套件、縮減、暫停、提供（無縫）升級。為了使其更加複雜，這需要在任何平台上、任何時間、任何地點實作。
應用程式管理的七大品質屬性
每個應用程式都必須遵守一系列品質屬性。我們區分了七個屬性，每個應用程式都必須根據這些屬性進行驗證：
- 互操作性：系統根據標準、協定和策略相互互動的可能性。
- 可組態性：將系統修改為所需狀態的能力。
- 效能：系統根據規格運作的程度。
- 可發現性：透過門戶或瀏覽器等輕鬆找到系統的程度。
- 強健性：系統的還原能力，例如系統從故障中還原的速度。
- 可移植性：將系統轉移到不同平台的難易程度。
- 可用性：使用系統的難易程度。
架構原則
在應用程式組閤中，這些品質屬性被轉化為架構原則：
客戶優先：這是迄今為止最重要的規則。企業存在是因為它們有客戶。因此，企業系統（包括內部系統）必須以客戶為設計、開發和佈署的物件。
資料驅動架構：企業根據資料做出決策。這些資料將使企業能夠更好地為客戶服務。
事件驅動架構：系統對客戶請求觸發的操作做出反應。這是自動化中的重要原則，尤其是在根據訂閱的商業模式中。當客戶請求訂閱某項服務時，會啟動一系列活動，以確保客戶獲得他們訂閱的服務或產品。
測試驅動架構：測試驅動開發是數位轉型中的另一個重要原則。它允許企業大幅加快開發速度，因為開發人員一開始就不會編寫大量的程式碼或程式。在測試驅動的環境中，首先執行初始測試場景，顯示失敗。這些失敗成為編寫和不斷改程式式碼的輸入。
專注於七大品質屬性：在資料驅動、事件驅動和測試驅動的環境中，七大品質屬性始終佔據主導地位。
專注於變革——“利用小規模的力量”：不要試圖一次改變一切。從一個專案開始；學習並利用經驗進行下一個專案。同樣適用於企業的組織結構。從一個單位開始，改革、轉型、學習並利用經驗轉型下一個單位。
為微服務架構設計：這在某種程度上也是關於“利用小規模的力量”。讓團隊專注於一個服務。微服務更容易升級和更新。但同樣，這只有在考慮品質屬性時才有效，尤其是關於互操作性和可發現性的屬性。這需要團隊之間的合作：開發人員和營運人員，以及團隊之間的合作。
為建置、測試和佈署設計架構：這似乎有點顯而易見，但太多次架構只關注服務或產品的最終狀態。架構還描述瞭如何從A點到達B點。解決方案不僅僅是期望的狀態，還包括如何達到期望狀態。這就是轉型。
採用左移原則：這是關於轉移責任。企業架構（EA）將提供指導方針和，而團隊將負責服務和產品的開發、測試和佈署。左移是採用微型企業的一個關鍵要素。這些微型企業必須被允許相當自主地運作，並根據客戶的需求做出決策。這才是真正的左移：將流程和資源更接近客戶，使其能夠提供更快速的解決方案，以滿足客戶的需求。
內容解密：
上述九大架構原則是現代企業在進行數位轉型時的重要指導方針。它們強調了以客戶為中心的重要性，以及如何透過資料驅動、事件驅動和測試驅動的方法來實作這一目標。同時，它們也突出了在設計架構時需要考慮的七大品質屬性，以及如何透過微服務架構和左移原則來提高企業的敏捷性和回應速度。
圖表翻譯： 此圖示展示了一個根據事件驅動架構的客戶服務流程。當客戶發出請求時，系統會觸發一系列事件，包括資料分析、決策制定和服務提供。整個流程形成了一個閉環，透過持續改進和反饋機制，不斷最佳化客戶體驗。
數位轉型中的零信任與敏捷平台架構
在數位轉型的過程中，企業必須採取零信任的安全措施，這意味著安全不是附加的，而是內建於每個架構元素之中。零信任的基本原則是「永不信任，始終驗證」，這不僅適用於人員，也適用於系統。在數位世界中，一切皆身份，系統亦應如此對待。
雲原生技術與微服務架構
雲原生技術是實作零信任和敏捷開發的關鍵。雲原生應用程式與底層基礎設施鬆散耦合，透過容器動態組態資源，並使用API進行獨立通訊。微服務提供了模組化、可攜性和對資源的細粒度控制。
程式碼範例：微服務API通訊
from flask import Flask, jsonify
app = Flask(__name__)
@app.route('/api/service1', methods=['GET'])
def service1():
return jsonify({"message": "Service 1 is running"})
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
內容解密：
此範例展示了一個簡單的微服務，使用Flask框架建立了一個API端點/api/service1。該端點傳回一個JSON回應，表明服務正在執行。此設計允許不同微服務之間透過API進行通訊，每個服務可獨立佈署和擴充套件。
DevOps與DevSecOps實踐
DevOps強調開發和維運團隊的協作，而DevSecOps則進一步將安全整合到開發和佈署流程中，從一開始就將安全納入考量，而非在應用程式準備投入生產時才新增。
程式碼範例：DevSecOps中的安全掃描
# .github/workflows/security_scan.yml
name: Security Scan
on:
push:
branches:
- main
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run security scan
run: |
# 使用安全掃描工具
echo "Running security scan..."
內容解密：
此GitHub Actions工作流程檔案定義了一個名為「Security Scan」的CI/CD流程。當程式碼推播到main分支時觸發該流程。該流程包括簽出程式碼和執行安全掃描步驟，確保在程式碼變更時自動進行安全檢查。
一切即服務與數位平台架構
「一切即服務」的概念使得企業能夠以更靈活的方式提供和消費服務，包括硬體即服務（HaaS）、資料函式庫即服務（DbaaS）等。這些技術共同構成了數位平台的基礎，如圖3-8所示。
圖表翻譯：
圖3-8展示了一個數位平台架構的範例，包括執行環境、管理、儲存、計算、網路和安全等各個層面。此架構設計旨在提供靈活性、可擴充套件性和安全性，以支援企業的數位轉型。
新的數位應用組合管理
新的數位應用組合必須反映轉型後企業的策略，遵循以下黃金法則：
- 靈活性
- 對開發者的易用性
- 使用微服務和容器開發平台無關的應用
- 敏捷性
- 持續改進
- 自動化和向左移（shift-left）以減少營運工作量
風險控制
任何變革都伴隨著風險。實施新的企業架構（EA）會帶來重大風險，因為它會觸發新的設計和重新設計。採用敏捷工作和DevOps意味著企業接受失敗的可能性。測試驅動開發（TDD）是一種常見的做法，透過測試發現失敗並據此開發應用程式。
程式碼範例：TDD測試案例
import unittest
def add(a, b):
return a + b
class TestAddFunction(unittest.TestCase):
def test_add(self):
self.assertEqual(add(1, 2), 3)
self.assertEqual(add(-1, 1), 0)
self.assertEqual(add(-1, -1), -2)
if __name__ == '__main__':
unittest.main()
內容解密：
此範例展示瞭如何使用Python的unittest框架進行TDD。首先定義了一個簡單的add函式，然後建立了一個測試類別TestAddFunction來測試該函式的不同場景。TDD的做法是先寫測試，再根據測試結果開發功能。
風險管理在數位轉型中的關鍵作用
在數位轉型的過程中，企業不僅需要關注技術的採用和創新，還必須有效地管理與轉型相關的風險。風險管理是確保企業能夠在快速變化的市場環境中保持競爭力的關鍵因素之一。
風險評估與 FMEA 方法論
風險評估是風險管理的基礎。企業可以使用**失效模式與影響分析（FMEA）**來系統地識別和評估潛在風險。FMEA 是一種結構化的方法，透過分析風險的嚴重性（Severity）、發生機率（Occurrence）和可檢測性（Detection）來評估風險的優先順序。
- 嚴重性（S）：評估風險發生時可能造成的影響程度。
- 發生機率（O）：評估風險發生的可能性。
- 可檢測性（D）：評估風險發生前或發生時被檢測到的難易程度。
透過這三個引數的評估，企業可以計算出風險的優先順序，並據此制定相應的風險緩解措施。
風險管理與 QFD 的整合
FMEA 通常作為**品質功能展開（QFD）的一部分。QFD 是一種用於捕捉和優先考慮客戶需求的方法，透過品質屋（House of Quality, HOQ）**矩陣來實作。這種方法幫助企業聚焦於最重要的產品或服務方面，並識別需求、客戶期望與風險之間的矛盾。
品質屋矩陣
圖表翻譯： 此圖示展示了品質屋矩陣的結構，包括客戶之聲、優先順序、關係矩陣、競爭價值等關鍵要素。它們共同幫助企業確定產品或服務的關鍵特性和技術難點。
風險管理程式的最低要求
有效的風險管理程式至少應涵蓋以下幾個方面：
- 產品或服務範圍：考慮客戶的需求和期望，確保產品或服務能夠滿足預期的功能。
- 功能評估：對每個功能進行評估，識別可能的失效模式。
- 後果評估：分析特定功能失效可能造成的後果，不僅限於系統內部，還包括對客戶的影響。
- 嚴重性評估：評估失效的嚴重程度及其後果。
- 原因分析：對每種失效模式進行原因分析。
- 設計階段回饋：將風險評估結果回饋到設計階段，確保風險管理是 QFD 的一部分。
風險管理與企業架構（EA）的整合
風險管理應該是企業架構（EA）的一部分。EA 為產品和服務的設計過程提供了指導方針和約束條件。透過將風險管理整合到 EA 中，企業可以確保在創新過程中有效地識別、量化和緩解風險。
成熟度模型與風險管理
有效的風險管理需要企業具有一定的成熟度。**能力成熟度模型（CMM）**是評估企業成熟度的常用工具。企業透過提升成熟度，可以實作對風險管理的精細控制，從而達到可預測的業務成果。
創造浮動架構
本章節將探討如何建立現代化的架構模式，並透過採用和應用DevOps的原則來避免反模式的陷阱。這將是一個浮動的、動態的架構，但我們也會學習如何透過變更管理保持控制。最終，我們要建立能夠實作業務敏捷性的架構。這一切都始於文化和正確的心態。
建立持續架構
「持續架構」這個術語最早由Murat Erder和Piere Pureur在2015年出版的書中提出。該書的副標題是《敏捷和雲端為中心的世界中的可持續架構》，這非常準確地概括了其內容。他們定義了現代架構的六項原則，這些原則在前一節中已經有詳細的討論。這些原則主要圍繞著品質屬性。在本文中，我們將對其中幾項原則進行更深入的探討，因為它們構成了現代化、敏捷架構的基礎。
關鍵字是「持續」。DevOps和敏捷都是建立在持續的原則之上，透過管道實作持續整合和持續佈署。為什麼這對現代企業如此重要？為什麼企業架構師應該關注這一點？因為這對數位增強型企業的業務至關重要。架構必須反映敏捷性。企業架構師應該提出以下相關問題：
- 誰是我們的客戶？
- 企業提供的產品是否滿足客戶的需求？
- 企業如何衡量客戶對產品的滿意度？
- 企業如何衡量客戶對企業本身，尤其是與企業互動的滿意度？
- 將新功能納入現有產品需要多長時間？
- 開發新產品需要多長時間？
- 團隊是否被授權直接從客戶那裡收集反饋以改進產品？
- 團隊是否被授權根據反饋自主更改需求？
- 企業使命和目標是否對團隊來說非常明確？
- 團隊是否被授權自行組織結構，以最高品質交付產品？
- 前述所有問題是否在清晰的企業結構和相應的流程中闡明？
- 企業是否真正採用和實踐敏捷，真正以DevOps方式運作，並且團隊緊密接觸客戶？
持續架構主要透過三項原則來解決這些問題：
- 延遲設計決策直到必要時再做：這對於回應事件和變化非常重要，能夠及時做出反應。
- 為變化而架構，或者更好地說，為持續變化而架構：但不要試圖一次做完所有事情，要利用「小而美」的力量，這是下一節的主題。
- 為建置、測試和佈署而架構，這就是我們在DevOps中所做的：我們將在本章中詳細討論DevOps和DevSecOps。
進行架構設計的一個風險是，我們只關注技術層面。這樣做的風險是，我們仍然會建立龐大、靜態、幾乎是單體的架構，這些架構「固定」了整個企業。這樣做會造成界限，實際上是在築起企業籠子。相反，我們希望建立一個浮動的架構，讓企業能夠自由移動，具備適應性和敏捷性。持續架構框架正是針對這一點。
該框架包含了一種工作方式和工具箱，但也包括兩個與架構本身同等重要的主題：角色和儀式，這兩者共同構成了組織的文化。在本文的最後一章，我們將討論架構師的角色，但我們已經可以說，這個角色正在發生重大變化。正如我們將瞭解到的，架構本身不再是固定的和僵化的，架構師的角色也是如此。在敏捷團隊中，所有成員都將承擔一些架構任務。企業架構師，或稱為首席架構師，將越來越成為服務型長官者。持續架構框架仍然認可企業架構師的作用，將其視為連線業務、資料和技術之間的紐帶，同時也是監督所有資產的教練。利用參考模型和模式，企業架構師以「進化」的方式引導團隊設計和建立解決方案。
接下來是儀式，旨在創造和維持團隊之間以及與業務中所有其他利益相關者之間的協作文化。持續架構框架確定了一個對話區，在那裡團隊可以就架構進行辯論和交流想法。這類別似於敏捷工作中的團隊所舉行的儀式，如每日站會和迭代規劃。它們都服務於同一個目的：實作敏捷。
從小處著手實作敏捷
這是本文前面已經討論過的一個話題：如果數位轉型如此重要，為什麼還不是每家公司都已經採用了它？簡單的解釋是，大多數公司試圖「煮沸大海」。許多作為轉型一部分而啟動的專案，最終沒有超出試點或概念驗證階段。這與技術無關。阻礙成功轉型的障礙在於文化，導致缺乏戰略願景和相應的組織結構。
首先，企業和企業架構師需要意識到一點：並非企業中的每個人都相信轉型的必要性。「中層泥潭」是每個組織中都存在的一個著名實體。「中層泥潭」是指緊接在高層管理者下面的一層，高層管理者在這裡展開戰略。然而，創新很少從高層管理者或C級開始。通常，它始於實際工作開展的那一層。因此，重要的是要開始進行「現場考察」（Gemba walks）。創新正是在這裡獲得了立足之地。
程式碼範例
def calculate_customer_satisfaction(surveys):
"""
計算客戶滿意度平均分數
:param surveys: 包含客戶滿意度分數（1-5）的列表
:return: 平均滿意度分數
"""
if not surveys:
return 0 # 如果沒有調查資料，傳回0
total_score = sum(surveys)
average_score = total_score / len(surveys)
return average_score
# 範例使用：
survey_responses = [4, 5, 3, 4, 5]
average_satisfaction = calculate_customer_satisfaction(survey_responses)
print(f"平均客戶滿意度：{average_satisfaction}")
內容解密：
此程式碼範例用於計算客戶滿意度的平均分數。首先，它檢查輸入列表surveys是否為空，如果為空，則傳回0以避免除零錯誤。然後，它計算所有調查分數的總和，並將總和除以調查數量以得出平均分數。此函式對於評估客戶對產品或服務的整體滿意度非常有用。
圖表示例
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 數位轉型架構實踐與創新
package "安全架構" {
package "網路安全" {
component [防火牆] as firewall
component [WAF] as waf
component [DDoS 防護] as ddos
}
package "身份認證" {
component [OAuth 2.0] as oauth
component [JWT Token] as jwt
component [MFA] as mfa
}
package "資料安全" {
component [加密傳輸 TLS] as tls
component [資料加密] as encrypt
component [金鑰管理] as kms
}
package "監控審計" {
component [日誌收集] as log
component [威脅偵測] as threat
component [合規審計] as audit
}
}
firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成
@enduml
圖表翻譯： 此圖示展示了計算客戶滿意度平均分數的流程。首先，它檢查是否有可用的調查資料。如果有，則計算所有調查分數的總和，然後計算平均分。如果沒有調查資料，則直接傳回0。最終，程式傳回計算出的平均滿意度分數或0（如果沒有資料）。這個流程確保了程式能夠正確處理各種輸入情況，並給出合理的結果。
從小處著手的重要性
從小處著手對於實作敏捷至關重要。它允許企業在不冒太大風險的情況下測試新想法和方法。透過從小專案或試點開始，企業可以評估什麼有效，什麼無效，並據此調整策略。這種方法還促進了創新文化的形成，因為團隊可以在較低風險的環境中實驗新事物。