企業架構與數位轉型策略

– 14 分鐘閱讀

隨著企業數位化轉型浪潮的推進，微服務架構的優勢日益凸顯，其彈性、可擴充套件性和技術多樣性，有效應對了快速變化的市場需求。然而，微服務的匯入也對企業架構提出了新的挑戰，企業架構師需要在確保系統穩定性的同時，兼顧業務敏捷性和技術創新。因此，理解微服務的運作機制以及如何與業務需求相結合，成為企業架構師的必備技能。此外，隨著企業融入數位生態系統，企業架構需要從更廣闊的視角考量企業在生態系統中的定位，以及與合作夥伴的協同發展，才能在競爭激烈的市場中保持優勢。這需要企業架構師具備更全面的思維模型，並能有效運用Zachman和TOGAF等架構框架來指導實踐。

為何企業需要企業架構

在現代商業環境中，企業架構（Enterprise Architecture, EA）扮演著至關重要的角色。EA是一門相對較新的學科，其源起於系統架構與整體業務策略脫節的時代。換言之，系統無法快速適應客戶需求。如果客戶的聲音能夠傳達給系統工程師，那麼改變系統以滿足這些需求通常需要數月甚至數年的時間。複雜、長期的專案是改變系統所必需的。在這個客戶需求快速變化的現代，系統需要迅速適應這些變化，「舊」架構方式已不再適用。我們需要能夠快速應對變化的架構，並且需要在所有層面——從系統架構到企業架構——實作這一目標。同時，企業架構需要控制變化，並確保變化與業務策略保持一致。

從單體架構到微服務

在探討企業架構與數位化的關係之前，我們必須認識到，企業架構作為一門學科，是在單體系統架構時代建立的。單體系統被設計為「一體化」的，很難進行變更。新增需求而導致的新功能和系統變更是一項繁瑣的工作，而且常常伴隨著風險。單體系統架構限制了變更的速度，系統本身也會不可避免地增長。事實上，系統架構幾乎不可避免地會偏離原來的架構，使得創新和滿足不斷變化的業務需求變得更加困難，同時保持系統的品質、可用性和可靠性。

圖1-5：單體架構與微服務架構的基本對比

圖表翻譯： 此圖示展示了單體架構與微服務架構的基本對比。在單體架構中，所有功能都被包含在一個程式中，而在微服務架構中，每個功能都被捕捉為一個獨立的服務，可以獨立開發和佈署。

想象一下，如果業務策略需要改變會發生什麼？我們已經看到企業因市場環境變化而重新考慮其策略的例子。這可能導致資產剝離或收購。無論哪種情況，都將對後續的架構產生巨大影響。更改系統架構可能成為一個危險的專案。例如，在大型的企業資源規劃（ERP）系統中剝離業務，或整合系統。

現代系統架構越來越依賴於微服務。微服務的概念如圖1-5所示。在微服務中，每個功能都被一個獨立的服務所捕捉。呈現資料或內容是一個獨立的服務，可以連線到持有資料的各種平台。如果一個平台沒有回應，呈現服務可以連線到另一個平台，以確保客戶服務仍然能夠交付。像Netflix和Spotify這樣的串流媒體服務就使用了微服務。呈現層——檢視或聆聽內容——是一個獨立的服務。它可以連線到持有該內容的各種資料系統，以確保到達消費者的最優、最有效的路徑。

轉向微服務對企業架構也有影響，因為它旨在將系統建構為一系列獨立開發和佈署的服務。每個微服務執行自己的程式，並透過介面與其他微服務進行通訊。每個服務都具備特定的業務能力及其自身的特性。

程式碼範例：微服務之間的通訊

import requests

def get_user_data(user_id):
    # 呼叫使用者微服務
    user_service_url = "http://user-service/users/{}".format(user_id)
    response = requests.get(user_service_url)
    if response.status_code == 200:
        return response.json()
    else:
        return None

def get_order_data(user_id):
    # 呼叫訂單微服務
    order_service_url = "http://order-service/orders/{}".format(user_id)
    response = requests.get(order_service_url)
    if response.status_code == 200:
        return response.json()
    else:
        return None

# 主程式
user_id = "12345"
user_data = get_user_data(user_id)
order_data = get_order_data(user_id)

print("User Data:", user_data)
print("Order Data:", order_data)

內容解密：

  1. 匯入必要的函式庫：使用requests函式庫來進行HTTP請求。
  2. get_user_data函式：負責呼叫使用者微服務以取得使用者資料。
    • 建構使用者微服務的URL。
    • 傳送GET請求並檢查回應狀態碼。
    • 如果狀態碼為200，則傳回JSON格式的使用者資料；否則傳回None。
  3. get_order_data函式：負責呼叫訂單微服務以取得訂單資料。
    • 建構訂單微服務的URL。
    • 傳送GET請求並檢查回應狀態碼。
    • 如果狀態碼為200，則傳回JSON格式的訂單資料；否則傳回None。
  4. 主程式：示範如何呼叫上述兩個函式來取得特定使用者的資料和訂單資訊。

這對組織架構、開發和維運團隊都有巨大的影響。在架構方面，業務單位可以定義自己的能力，並將其對映到特定的功能，而不必擔心這些服務對其他應用程式的影響。DevOps團隊可以開發和營運這些服務：「你建構它，你執行它」。微服務架構由鬆散耦合的元素組成，但這也意味著建構和營運團隊將是鬆散耦合的。

企業架構現在有著不同的任務，需要使企業內的架構原則成熟。企業架構師必須處理鬆散耦合的元件，甚至是自主運作的團隊，這些團隊負責這些元件的開發和營運。如果沒有從整體企業業務目標中衍生出適當的指導方針，這將成為一項風險極高的事業。企業架構是將所有這些結合在一起的膠水。從企業架構中必須清楚不同服務如何協同工作，以向企業客戶提供整體業務服務。它還必須提供明確的格式，以指導團隊如何在達成企業業務目標方面進行營運和協作。

鬆散耦合的元件和不同團隊對這些元件的工作將創造更大的適應性，但也會增加異質性。架構將變得更加動態，具有更高的粒度。保持企業架構與這些動態變化的一致性，是企業架構師面臨的新挑戰。

在下一節中，我們將進一步探討這一變化的角色。不過，這只是個簡介。在第6章中，我們將更詳細地討論這個話題。

微服務中企業架構的角色

當企業轉向微服務時，企業架構師的角色是什麼？在探討這個問題之前，指出微服務的好處是很有用的。微服務提供了更大的靈活性、可擴充套件性和韌性，能夠更好地滿足不斷變化的業務需求。

微服務的好處

  1. 模組化：每個微服務都是獨立的模組，可以獨立開發、測試和佈署。
  2. 可擴充套件性：可以根據需求對特定的微服務進行擴充套件，而不必擴充套件整個系統。
  3. 技術多樣性：不同的微服務可以使用不同的技術堆疊，選擇最適合其需求的技術。
  4. 故障隔離：一個微服務的故障不會直接影響其他微服務，提高了系統的整體穩定性。

程式碼範例：使用容器化技術佈署微服務

# 使用官方Python映像作為基礎映像
FROM python:3.9-slim

# 設定工作目錄
WORKDIR /app

# 複製需求檔案
COPY requirements.txt .

# 安裝依賴
RUN pip install --no-cache-dir -r requirements.txt

# 複製應用程式碼
COPY . .

# 暴露埠
EXPOSE 8000

# 執行命令
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

內容解密：

  1. 基礎映像：使用官方Python 3.9映像作為基礎映像。
  2. 工作目錄：設定容器內的工作目錄為/app。
  3. 依賴安裝：複製requirements.txt檔案到容器中，並安裝所需的Python套件。
  4. 應用程式碼：將當前目錄下的所有檔案複製到容器的/app目錄中。
  5. 埠暴露：暴露容器的8000埠，以便外部存取。
  6. 執行命令：使用uvicorn命令啟動FastAPI應用程式，並監聽所有網路介面的8000埠。

總之，企業架構在現代企業中的角色至關重要，尤其是在轉向微服務架構時。企業架構師需要確保不同微服務之間的協同工作，以及與整體業務目標的一致性。這需要新的思維方式和新的技術手段，但最終將帶來更大的靈活性、可擴充套件性和競爭力。

為何企業需要企業架構

企業架構（Enterprise Architecture, EA）在現代企業中扮演著至關重要的角色，尤其是在企業轉型和採用新技術（如微服務）的過程中。企業架構師需要對企業的整體業務和系統架構有全面的瞭解，以確保企業能夠有效地實作其業務目標。

微服務的優勢

微服務架構提供了多項優勢，包括：

  • 敏捷性：團隊不需要開發整個應用程式，而是專注於特定的服務，如資料函式庫服務或支付功能。這大大縮短了開發時間。
  • 彈性：微服務減少了單點故障的風險。只有部分應用程式會受到更新或事件的影響，從而減少了整體應用程式的停機時間。
  • 可擴充套件性：微服務可以佈署在多個應用程式和系統中，使其具有可擴充套件性。
  • 業務影響：由於開發週期更短，系統停機時間更少，企業可以節省成本並提高客戶滿意度，從而增加總收入。

企業架構師的角色

企業架構師不需要編寫微服務程式碼，但需要了解微服務的工作原理以及如何滿足業務需求。他們需要對整個業務和系統架構有全面的瞭解，以確保企業在轉型過程中保持一致性。

大多數企業（除完全雲原生企業外）都有需要長期營運的舊系統。企業架構師需要管理應用程式組合，瞭解系統和應用程式如何與業務流程相關聯。

關鍵考量因素

  • 系統和應用程式的關鍵性及其對業務流程的影響。
  • 將系統轉換為微服務的商業案例，包括所需的資金和資源。
  • 轉型對其他系統的影響以及風險評估。

轉型階段

轉型過程可以分為以下幾個階段：

  1. 評估：探索建立微服務的效益和商業案例。
  2. 規劃：驗證評估結果和商業案例，並制定轉型的路線圖。
  3. 執行：選擇合適的技術堆積疊並為 DevOps 團隊定義指導方針。
  4. 持續反饋：持續監控迭代結果，識別失敗點和差距，並進行改進。

這些階段是一個持續迴圈的過程，因為企業的業務需求會不斷變化。

DevOps 的整合

DevOps 負責管理這個過程。現代企業架構需要採用 DevOps 方法，特別是在規劃階段，企業架構師需要定義業務指標、生產指標、需求定義、新功能優先順序和修復計劃等。

DevOps 活動

  • 業務指標（客戶聲音、客戶滿意度等）。
  • 生產指標（包括業務目標和服務水平協定）。
  • 需求定義。
  • 新功能優先順序和修復計劃。
  • 發布計劃（商業案例）。
  • 安全方面。

圖表翻譯：

此圖示展示了 DevOps 的迴圈過程，包括規劃、開發、測試、佈署和監控等階段。DevOps 是一個持續改進的過程，透過不斷的反饋和迭代來提高產品品質和交付效率。

圖表重點說明

  1. 持續整合與交付：DevOps 強調自動化的整合與交付流程，以加快產品迭代速度。
  2. 跨團隊協作：開發（Dev）與維運（Ops）團隊緊密合作，確保產品的高品質交付與穩定運作。
  3. 監控與反饋：透過持續監控系統執行狀態，收集反饋並進行改進，以提升使用者經驗和系統可靠性。

為何企業需要企業架構

企業架構（Enterprise Architecture, EA）在現代數位化轉型的過程中扮演著至關重要的角色。它不僅關乎企業內部的營運效率，也涉及企業在數位生態系統中的定位與合作。

企業架構的核心角色

企業架構在DevOps（實際上應該是DevSecOps）的各個階段中發揮關鍵作用，包括設計、驗證、生產、發布和組態等建置活動。在監控階段，企業架構同樣重要，因為這是衡量指標的實際階段，例如：

  • 環境的效能和可用性，包括IT基礎設施和應用程式
  • 終端使用者的回應和體驗

雖然這裡提到DevOps，但實際上應該是DevSecOps。安全性不是在DevOps週期上附加的東西，而是與該週期整合在一起的。

簡而言之，企業架構需要提供結構和指導。這是企業架構師的角色。這已經是一項艱鉅的任務，但情況變得更加複雜。企業並不孤立存在，而是生態系統的一部分。

企業架構在數位生態系統中的角色

許多企業正在進行數位轉型，使其與其他企業、供應商、公共機構、金融機構和客戶數位化連線。企業已成為數位生態系統的一部分。

這意味著架構應該關注企業在數位生態系統中的位置。數位生態系統首先是一個網路，它連線企業，並使它們能夠相互互動以創造價值。

分享的思維模型和數位平台

要實作跨生態系統的互動，企業需要有一個分享的思維模型和一個允許它們連線和互動的數位平台。

分享的思維模型使公司在各種情況下能夠達成共識。由於生態系統中所有公司的價值都是透過合作創造的，因此單一公司的利益並不佔主導地位，而是整個生態系統的利益。決策是共同做出的，以實作客戶的最大價值。

在生態系統中的決策的一個重要原則是二階思考。這意味著生態系統中的一家公司不會立即嘗試解決問題，而是與生態系統中的其他公司一起分析問題。作為一個生態系統，會對決策的後果進行思考，並在評估這些後果後選擇對系統最佳的解決方案。

圖表翻譯： 此圖示呈現了企業如何在數位生態系統中透過分享思維模型進行共同決策，並透過二階思考來找到最佳解決方案。

分享平台的重要性

要有效地營運生態系統，我們需要一個分享平台。在許多現代企業架構中，分享的基礎平台很可能是一個關鍵構件。Amazon和Microsoft是這種平台的優秀例子，它們允許企業分享技術和商業主張。

現代企業的新挑戰

現代企業是數位生態系統中的一個連線企業。這在過去幾年中引入了複雜性。企業的生態系統已經增長並將繼續增長，因為該生態系統中的利益相關者數量已經增加並將繼續增加。這創造了巨大的溝通、互動和業務機會，但也帶來了複雜性和潛在風險。

生態系統的強度取決於系統中最弱的合作夥伴。這需要加以控制以保護企業。企業架構必須透過承認企業依賴於其合作夥伴和生態系統中的利益相關者來解決這一問題。

這種架構的轉變通常被稱為浮現式架構（emergent architecture）——一種隨著變化而發展的架構，對變化做出敏捷反應，並在沒有固定架構約束的情況下抓住機會。數位生態系統中的企業需要快速適應和採用。改變架構需要時間，並且需要在設計上具有足夠的彈性，以應對未來的變化和挑戰。

為何企業需要企業架構（Enterprise Architecture）

企業架構（EA）是現代企業管理與資訊技術發展的重要根本。它提供了一種全面的方法來管理和規劃企業的IT資源和業務流程，確保企業能夠有效地實作其使命和戰略目標。

企業架構的必要性

在當今快速變化的商業環境中，企業面臨著諸多挑戰，包括技術創新、市場競爭加劇和客戶需求的多樣化。為了應對這些挑戰，企業需要一個強大的架構來支撐其業務運作和發展。企業架構透過提供一個全面的視角，將業務戰略、流程、資料和技術整合在一起，幫助企業實作一致性和協同工作。

北極星（North Star）的概念

傳統的企業架構方法往往被批評為過於僵化和緩慢，無法適應快速變化的市場環境。因此，人們提出了「北極星」的概念，作為一種更靈活的企業架構方法。北極星提供了一個方向和目標，而不是一個固定的藍圖。它引導企業前進，但不規定具體的實作路徑。

北極星的主要特點包括：

  1. 簡單易懂：北極星應該是簡單和易於理解的，能夠被生態系統中的所有利益相關者所接受。
  2. 靈活更新：北極星應該能夠快速更新，以適應變化的環境。
  3. 高層次視角：北極星應該提供一個高層次的視角，關注關鍵的業務流程和依賴關係，而不是陷入低層次的技術細節。

北極星的優點

北極星的概念比傳統的企業架構方法更具靈活性，能夠更好地適應快速變化的商業環境。它提供了一個清晰的方向和目標，幫助企業在複雜的生態系統中保持一致性和協同工作。

企業架構的益處

實施企業架構可以為企業帶來多種益處，包括：

  1. 提高業務與IT的一致性：企業架構有助於確保IT系統和業務流程之間的緊密協作，提高企業的整體績效。
  2. 降低成本：透過標準化和簡化流程，企業架構可以幫助企業降低營運成本。
  3. 改善變更管理：企業架構提供了一個框架，用於管理和控制變更，確保變更的有效實施和最小化風險。

變更管理的必要性

變更管理是企業架構中的一個重要組成部分。沒有有效的變更管理，企業架構就無法發揮其應有的作用。變更管理確保了對企業架構的修改是可控的、可追溯的，並且與企業的整體戰略目標相一致。

使用Zachman和TOGAF框架

Zachman和TOGAF是兩個最廣泛使用的企業架構框架。它們提供了一套全面性的指導原則和方法，幫助企業建立和管理其架構。

Zachman框架

Zachman框架由John Zachman提出，它使用一個6x6的矩陣來描述企業的不同視角和層面。這個框架強調了不同利益相關者之間的關係和依賴關係。

Zachman框架的核心思想

Zachman框架的核心思想是透過描述企業的不同視角和層面，提供一個全面的視角。它強調了業務流程、資料和技術之間的整合，以及不同利益相關者之間的協同工作。

圖表翻譯：Zachman框架矩陣圖

此圖示展示了Zachman框架的6x6矩陣結構，用於描述企業的不同視角和層面。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 企業架構與數位轉型策略

package "微服務架構" {
    component [API Gateway] as gateway

    package "核心服務" {
        component [用戶服務] as user
        component [訂單服務] as order
        component [商品服務] as product
        component [支付服務] as payment
    }

    package "基礎設施" {
        component [服務發現] as discovery
        component [配置中心] as config
        component [鏈路追蹤] as trace
    }

    queue "訊息佇列" as mq
    database "各服務資料庫" as db
}

gateway --> user
gateway --> order
gateway --> product
gateway --> payment

user --> mq : 事件發布
order --> mq : 事件發布
product --> mq : 事件發布
payment --> mq : 事件發布

user --> discovery : 註冊/發現
order --> discovery
product --> discovery
payment --> discovery

user --> db
order --> db
product --> db
payment --> db

@enduml

圖表翻譯： 此圖表展示了Zachman框架的不同視角和層面，包括範圍、企業模型、系統模型、技術模型、工程模型和營運模型。每個層面都對應著不同的利益相關者和視角。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。