在數位轉型浪潮下，企業如何平衡創新與穩定營運成為一大挑戰。本文將探討如何透過文化變革、組織架構調整和技術整合，提升企業敏捷性，並應對快速變化的市場環境。傳統層級式組織架構限制了創新，企業需要轉型為非層級式架構，讓團隊更貼近市場和客戶，並將客戶回饋融入企業策略。這種轉型需要企業具備敏捷性，能持續適應變化，快速回應市場需求。此外，自動化和標準化也是提升企業敏捷性的關鍵，讓資源得以有效分配，並專注於創造價值。
企業敏捷性與數位轉型
在數位轉型的過程中，企業面臨的最大挑戰之一是創新與穩定營運之間的平衡。負責保持系統穩定執行的中間管理階層，往往對創新持保守態度，因為創新可能會破壞現有的穩定營運。因此，在創新能夠到達決策者的層面之前，必須先說服中間管理階層。這就要求從一開始就讓所有的利益相關者參與進來，這是變革管理中的第一課。
文化變革的重要性
第二個重要的課題是文化變革。企業的文化對於變革的成功至關重要。管理變革是企業敏捷性的核心，而企業敏捷性又是數位轉型的關鍵。企業敏捷性意味著企業能夠持續不斷地適應變化，並將這種適應變成一種常態。只有具備敏捷性的企業，才能夠快速回應市場變化，甚至透過創新來引領市場。
非層級式組織架構
要實作企業敏捷性，企業需要採用非層級式的組織架構。團隊需要貼近市場和客戶，不斷與客戶互動，從而收集見解並將其回饋到企業的整體使命和戰略中。這種組織架構要求團隊對企業的使命和目標有共同的理解。
從傳統組織到敏捷組織
許多企業仍然採用傳統的層級式組織架構，這種架構阻礙了創新。創新比以往任何時候都更加重要。員工需要能夠在網路型組織中工作，在這種組織中，員工的位置不再重要，重要的是他們為公司做出的貢獻。員工應該能夠在企業的網路生態系統中自由流動，以尋找最佳的解決方案。
不可預測的市場
這種變革的挑戰在於，其結果可能較難預測，這正是許多企業，尤其是管理階層，所擔心的。市場的不可預測性並不是由企業組織變革引起的，而是市場本身變得越來越不可預測。企業需要準備好應對這種不可預測性，迅速調整以滿足客戶不斷變化的需求。
浮動架構的建立
在當今的市場中，專案的結果很難定義，但大多數企業仍然以預先定義的結果和詳細的規劃來執行專案。這種做法使得應對需求變化變得困難。敏捷工作方式允許企業根據需求變化調整結果和規劃。要實作這一點，專案不能被視為龐大、複雜的單一專案，而應該被分解為較小的組成部分。
以 DevOps 為例
DevOps 是一種加速開發和佈署的方法。DevOps 團隊通常規模較小，但包含了各種不同的專業人員，如開發人員、測試人員、安全專家和維運人員。他們被分配了特定的任務，通常以兩到三週為一個迭代週期，將任務的輸出整合到主產品中。在 DevSecOps 中，這些原則將被更詳細地討論，因為安全始終是“開啟”的狀態。
圖表翻譯：
此圖示展示了傳統層級式組織與敏捷組織之間的差異。傳統組織結構僵化，難以適應變化；而敏捷組織則更加靈活，能夠快速回應市場變化。
圖表翻譯： 此圖示呈現了傳統組織與敏捷組織在適應市場變化上的差異，顯示了兩種不同組織架構的優缺點。
在未來的數位轉型過程中，企業需要繼續關註文化變革和組織架構的調整，以保持競爭力。同時，採用 DevOps 和其他敏捷方法將有助於企業加速開發和佈署，從而更好地應對市場變化。
商業敏捷性的定義與目的
數位轉型有助於使企業具備商業敏捷性。但究竟什麼是商業敏捷性？簡而言之，它關乎使企業具有適應性。在前面的章節中，我們討論了阻礙因素：企業在轉型業務和企業本身的過程中面臨著許多阻礙。通常，傳統企業擁有遺留系統，而遺留系統伴隨著負債。負債——技術債只是其中之一，但並非唯一——會拖慢任何變革的速度。你需要先消除這些負債。
商業敏捷性的核心
創造一個具有適應性的組織的最大阻礙之一是，企業沒有辦法快速回應變化並分配資源來應對變化。這就是商業敏捷性的意義所在：及早察覺即將到來的變化，能夠快速回應變化，並分配資源來處理變化。對許多公司來說，這聽起來非常有風險。為什麼？因為敏捷的公司必須擁有足夠的資源來做到這一點：未承諾的資源。大多數公司會將未承諾的資源視為成本。我們稍後會討論文化，但這已經是一種思維模式的轉變。
資源管理與自動化
只有透過自動化，才能擁有未承諾的資源，這樣人們就可以專注於創造價值，而不是修復營運問題。它也需要標準化，但完全標準化的環境無法提供必要的靈活性。企業必須找到一個平衡點。
商業敏捷性的目的與實作方法
簡而言之，
- 商業敏捷性使企業能夠迅速對變化做出反應，而不受靜態、僵化的架構和未來設計的限制。
- 商業敏捷性為企業提供了處理意外事件的能力，這些事件會影響或衝擊業務。
商業敏捷性的目的是：
- 激發和促進創新
- 改善價值主張的同時降低風險
實作商業敏捷性的方法包括：
- 提供選擇。這最終是架構的目的：提供選擇。
- 對變化的可觀察性
- 導航的自由度
- 透過更快的回應速度建立快速、立即行動的能力
- 透過增加洞察力提高可預測性
- 快速重複業務流程，以回應客戶需求，透過捕捉客戶之聲
- 建立比競爭對手更快分配資源的能力
- 在企業生態系統中改變合作夥伴關係的能力和勇氣
增強商業敏捷性的EA原則
- 消除限制，去除部門壁壘
- 堅持客戶至上的原則，緊跟客戶旅程
- 認識到對客戶來說，重要的體驗遠勝於產品本身
- 精益管理
- 收集和管理專案組合
- 收集和管理創新計劃
- 建模和管理敏捷流程
- 在有意義的地方進行自動化
- 在架構中採用資料驅動的原則
- 促進快速決策
- 溝通，溝通，再溝通
為什麼企業需要商業敏捷性？
商業敏捷性必須透過架構來引導，包括敏捷工作和DevSecOps。但首先，我們需要回答另一個問題：為什麼企業需要變得商業敏捷？答案是：為了在顛覆中生存並透過創新引領未來。
打敗顛覆，引領創新
顛覆是一個熱門詞彙。另一方面，它是真實存在的，並將影響許多企業。地球上的幾乎每家企業都必須準備好應對快速變化的市場和客戶行為。這本身就觸發了持續的變化，對系統的穩定性構成潛在風險。企業需要方法和系統，能夠：
- 在企業中創造未承諾的資源，可以在需要時回應變化。
- 這意味著企業必須自動化常規和相關的操作。在Site Reliability Engineering（SRE）中，這被稱為“toil”，企業必須找到方法消除toil，以便讓人員騰出時間來處理新的需求。
- 這意味著自動化系統必須能夠預測整個供應和交付鏈中某個環節失敗時的業務影響。
- 系統能夠在事件發生之前減輕預期的影響。
所有這些都必須具有極高的可擴充套件性。第5章將全部圍繞可擴充套件性展開。
傳統企業面臨的挑戰
尤其是傳統企業，在自我轉型方面面臨著許多挑戰。它們必須在能夠開始打敗顛覆並成為長官者之前，先進行自我顛覆。阻礙點如下：
- 業務與IT之間的脫節。IT往往更先進，更願意開始採用新技術，但無法說服業務部門相信其附加價值。
- 企業實施敏捷框架，從小處開始，但接下來卻無法擴充套件。
- 向雲端的遷移和轉型比預期的更為複雜。
- 最後但並非最不重要的是人才戰爭。由於競爭激烈，專業人才越來越稀缺。
商業敏捷性框架
@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
圖表翻譯： 此圖示呈現了商業敏捷性的核心組成部分，包括適應性、快速反應和資源分配。適應性涉及消除負債，如技術債；快速反應依賴於自動化，以獲得未承諾資源；資源分配需要在標準化和靈活性之間找到平衡，這需要文化轉變。
圖表詳細解析
- 商業敏捷性 是整體框架的核心目標。
- 適應性 是實作商業敏捷性的關鍵一步，需要消除各種形式的負債，尤其是技術債。
- 快速反應 能力依賴於自動化，以釋放未承諾資源，使企業能夠迅速應對變化。
- 資源分配 需要在標準化和靈活性之間取得平衡，這一過程伴隨著文化轉變。
克服企業數位轉型的障礙
企業在進行數位轉型時，面臨著諸多挑戰。要克服這些挑戰，企業必須採取以下措施：
1. 建立共同願景和策略
企業業務部門與IT部門必須共同制定願景和策略，這是企業數位轉型的「北極星」。這意味著雙方需要緊密合作，確保技術與業務目標保持一致。
2. 最佳化營運模式
企業的營運模式必須聚焦於透過自動化消除不必要的工作，以釋放未被充分利用的資源。這需要企業重新設計工作流程，使其更具效率和靈活性。
3. 重組團隊結構
企業需要將組織結構進行「拆包」和「重新封裝」，形成更貼近客戶的團隊。這樣的團隊能夠更好地捕捉客戶需求，並專注於創造客戶價值的價值流上。這一過程必須與企業的「北極星」願景保持一致。
這些措施的實施需要透過企業內部的變革來實作。企業架構師（EA）的任務是提供建議和幫助，制定支援企業願景的長期戰略。企業需要明確前進的方向，「北極星」設定了目標，但並未提供到達目標的具體路徑。「北極星」的力量在於其簡單性，避免過度複雜和詳細的架構設計。
企業架構師的角色
在現代企業中，企業架構師必須具備以下能力：
- 戰略規劃：制定符合企業願景的戰略規劃。
- 功能轉型：透過迭代步驟推動功能轉型，以支援企業的願景和策略。
- 資源分配：確保資源的有效分配，以應對不斷變化的市場和客戶行為。
創新與技術的整合
技術是推動創新的關鍵，但前提是技術必須與業務充分整合。為技術而技術是毫無價值的。創新是現代企業的生命線，其過程包括四個階段：
- 挑戰：提出挑戰和問題。
- 聚焦：集中資源和注意力。
- 開發：開發解決方案。
- 驗證：驗證解決方案的有效性。
創新是一個迭代過程，必須嵌入企業的整體願景和衍生策略中。企業架構師應避免過度詳細的設計，建立「浮動架構」（floating architecture），使其具有足夠的彈性和適應性。
安全是內在的
在數位轉型的過程中，安全是一個至關重要的因素。企業面臨著日益增長的安全威脅，因此必須將安全融入企業架構的每個層面。這包括：
- 檔案化的安全政策和程式，並定期更新。
- 系統強化和其他安全引數，以保護環境免受威脅。
- 主動漏洞管理。
- 生命週期管理，包括補丁、更新和升級。
- 測試程式和流程。
- 自動化。
從現在開始，我們將不再只談論DevOps，而是DevSecOps，將安全融入開發和營運的每個環節。DevSecOps成熟度模型（DSOMM）可以幫助企業在這方面取得進步。
DevSecOps成熟度模型
DSOMM涵蓋了企業在DevOps中應滿足的所有安全方面，包括：
- 設計。
- 補丁管理。
- 基礎設施強化。
- 應用程式強化。
- 日誌記錄。
- 監控。
- 測試。
- 教育和指導。
- 流程。
透過實施DevSecOps並遵循DSOMM，企業可以提高其安全性和成熟度，從而更好地應對數位時代的挑戰。
圖表翻譯：
此圖示展示了DevSecOps成熟度模型（DSOMM），它涵蓋了企業在DevOps實踐中需要滿足的多個安全導向，包括設計、補丁管理、基礎設施強化、應用程式強化、日誌記錄、監控、測試、教育指導以及流程管理等方面。該模型能夠幫助企業評估並提升其在DevSecOps實踐中的成熟度，從而更好地融入安全考量於開發與營運流程之中。
為何DevSecOps對現代企業至關重要
微軟執行長Satya Nadella在2022年微軟Inspire大會的主題演講中精闢地解釋了DevOps為何與現代企業息息相關：「如今，每家公司都是一家數位公司。事實上，一些關鍵產業，如公部門、教育、能源、零售、娛樂和運輸業，對開發者的需求甚至超過了科技產業本身。這對所有人來說是一個巨大的機會。企業急於為專業和公民開發者提供一流的工具，使他們能夠擴大影響力。同時，他們也渴望採用DevOps，這正迅速成為將程式碼佈署到生產環境的預設方式，為所有人創造了巨大的機會，以幫助他們採用這些新流程。」
為何需要DevSecOps
試想一下，一個小偷通常會先觀察目標一段時間，找出弱點，如門鉸和鎖，並研究目標的行為模式以制定計畫。網路罪犯也採用類別似的行為：探索、計畫、攻擊。如果沒有這種認知，任何模型和工具都無法有效保護資產。
許多企業的CIO、CDO或IT經理都會提到，安全是他們面臨的最大挑戰。這是因為對企業IT環境的威脅和攻擊日益增多且變得更加狡猾。網路罪犯創造性地發明新的方式來破壞系統，這種速度令人擔憂。
為了應對這種威脅，企業正在採用敏捷開發和DevOps，包括自動化，以加快開發速度。然而，在這個過程中，安全往往被忽視。只有在應用程式經過技術測試和批准後，才會進行安全檢查，而且這些檢查往往僅限於靜態程式碼檢查，即靜態應用程式安全測試（SAST）。然而，SAST工具只能捕捉到約50%的現有漏洞。
除了SAST，還有動態應用程式安全測試（DAST）。DAST工具透過滲透測試主動掃描Web應用程式中的漏洞。然而，這些掃描耗時且通常無法精確定位漏洞。因此，這些掃描是不夠的。
DevSecOps成熟度模型（DSOMM）
要了解徹底的DevSecOps實施，可以參考OWASP的DevSecOps成熟度模型（DSOMM）。大多數企業可能達到第一級，但第一級已經需要採取諸如應用程式強化、隔離基礎設施和多層次加密等深遠措施。第四級應該是每個從事DevOps的企業的最終目標。在這個級別，我們談論的是應用藍綠佈署、混沌猴子和深入測試等技術。
藍綠佈署
藍綠佈署涉及建立兩個獨立但相同的環境：一個環境（藍色）用於生產中的現有功能，另一個環境（綠色）用於新的應用程式，完全與生產環境分離。
混沌猴子
混沌猴子是一種技術，透過隨機關閉或移除虛擬機器或容器來測試對生產環境的影響。這是DevSecOps中進行的多項測試之一，以觀察當環境受到駭客攻擊時的反應。
DevSecOps的要求
在探討DevSecOps的要求之前，讓我們先列出DevOps週期中包含的所有活動（圖4-2）。這些活動必須從企業架構（EA）的角度進行嵌入和支援。這些活動構成了我們整體模型的操作層，將在架構願景部分進行介紹。
DevOps週期中的活動
計畫
- 生產指標
- 需求定義（使用案例、原型設計）
- 商業指標（效能、解決時間、客戶滿意度）
- 新功能/修復的優先順序
- 發布計劃（時間、商業案例）
- 安全政策、遵守情況和要求
開發
- 設計（軟體、組態）
- 程式碼、程式碼合併、程式碼品質和效能
- 功能測試
- 發布候選版本
測試（驗證）
- 接受測試
- 迴歸測試
- 靜態分析（品質和合規性）
- 安全分析（漏洞）
這些活動必須在每個階段中被包含和支援，以確保DevSecOps的有效實施。透過將安全整合到開發和管理的過程中，企業可以保持對網路罪犯的優勢。
圖表翻譯：
此圖示展示了DevOps週期中的不同階段及其相關活動。從計畫到開發，再到測試，每個階段都有特定的任務和目標。這些活動共同構成了DevOps流程的基礎，並且必須與企業架構相結合，以實作有效的DevSecOps。
內容解密：
在DevOps週期中，每個階段都有其特定的任務。例如，在計畫階段，需要定義需求、設定優先順序並制定發布計劃。在開發階段，則需要進行設計、編碼和功能測試。最後，在測試階段，會進行接受測試、迴歸測試以及靜態和安全分析。每個階段都至關重要，並且需要與企業架構相結合，以確保整體流程的高效性和安全性。
DevSecOps 的實施與浮動架構的變革管理
在現代企業中，DevOps 的實踐已經成為提升開發效率和營運穩定性的關鍵。然而，隨著安全問題的日益突出，將安全融入 DevOps 流程（即 DevSecOps）變得至關重要。DevSecOps 不僅需要技術上的整合，更需要文化和意識上的變革。
DevSecOps 的三層實施
DevSecOps 的實施可以分為三個主要階段：教育訓練、整合安全流程和工具、以及自動化。
第一階段：教育訓練
在這一階段，企業需要對團隊進行安全意識的教育和培訓。這包括：
- 評估目前的流程狀態
- 蒐集相關的報告資料
- 透過與開發人員的訪談，識別當前流程中的優缺點
企業需要培養 DevSecOps 的文化，特點包括：
- 持續反饋
- 根據容器的微服務架構
- 團隊自主性
- 持續培訓
第二階段：整合安全流程和工具
在這一階段，將安全流程和工具整合到 DevOps 生命週期中。這涉及將安全工具納入現有的 DevOps 工具鏈，並對 CI/CD 工具鏈進行安全稽核，以確保安全性。
第三階段：引入或增強自動化
企業需要制定自動化路線圖，逐步將自動化引入各個工具鏈中。建議從小專案開始，例如修補程式或功能更新，以測試實施計劃。
自動化的重要性
自動化是 DevSecOps 成敗的關鍵。透過自動化一個建置、品質保證或安全檢查，可以作為概念驗證專案。記錄專案的發現，尤其是經驗教訓和團隊成員的反饋。
為何 DevSecOps 至關重要
許多企業未將安全整合到 DevOps 流程中的主要原因是誤認為安全會拖慢開發進度。然而，這種情況只有在未將安全與其他敏捷流程整合時才會發生。DevSecOps 能夠揭示開發、安全和業務之間的摩擦點，並提供解決方案。
浮動架構中的變革管理
變革管理和持續改進是現代企業不可或缺的。它們需要：
- 贊助
- 影響評估
- 準備度評估
- 緩解計劃
常見的變革評估方法是 PDCA（計劃-執行-檢查-行動）迴圈。然而，PDCA 並未考慮到條件變化所帶來的影響。因此，OODA（觀察-定位-決定-行動）迴圈成為一個更適用的替代方案。OODA 最初由美國空軍戰鬥機飛行員約翰·博伊德發明，其核心在於「定位」，即透過文化背景和經驗來影響觀察和決策。
OODA 迴圈的優勢
OODA 迴圈能夠幫助企業快速回應變化，並在競爭中取得優勢。其目標是「深入」競爭對手的思維，並將其應用於決策中。如圖 4-3 所示，OODA 迴圈是一個連續的過程，能夠幫助企業保持競爭力。
圖表翻譯：
此圖示展示了 OODA 迴圈的四個階段：觀察、定位、決定和行動。透過不斷迴圈，企業能夠快速回應變化，並做出更明智的決策。