軟體架構意圖性提升度量指標實踐

隨著業務規模擴充套件，軟體架構的演進需要與業務目標緊密結合。本文以旅行保險案例，闡述如何運用 EventStorming 和流程建模方法，分析業務流程並識別軟體架構的瓶頸。接著，透過定義關鍵績效指標（KPI）和領域分解，將業務目標轉化為可衡量的指標，並建立 KPI 值樹，將業務目標、領域 KPI 和技術指標串聯起來。實踐中，參考 DORA 度量指標（前置時間、佈署頻率、變更失敗率、平均還原時間）等資料，可以有效評估軟體交付效率和穩定性，進而驅動架構最佳化。同時，需注意指標並非目標，而是指導和促進因素，選擇指標時需考量團隊上下文。

軟體架構意圖性的提升：以度量為引導

在軟體開發的過程中，如何確保軟體架構能夠符合組織的目標和使命，是一個至關重要的問題。軟體架構的意圖性（intentionality）是指軟體架構能夠明確地支援組織的目標和使命，並且能夠在不斷變化的環境中保持彈性和適應性。本文將透過一個案例，介紹如何透過EventStorming和Process Modeling EventStorming來提升軟體架構的意圖性。

從大局觀EventStorming到流程建模EventStorming

在前一階段的工作坊中，Anna和她的團隊使用大局觀EventStorming來視覺化公司的業務流程和軟體架構。他們發現了一些熱點（hotspots）和軟體架構與業務流程之間的 mismatch。為了更深入地瞭解這些問題，Anna決定組織另一個工作坊，使用流程建模EventStorming來詳細分析一個操作價值流（operational value stream）。

流程建模EventStorming的實施

在這個工作坊中，參與者探討了「請求旅行保險報價」（request travel insurance quote）這個操作價值流。他們使用流程建模EventStorming來視覺化這個流程中的每一步驟、關鍵績效指標（KPIs）和熱點。這個過程幫助團隊成員瞭解了軟體架構與業務流程之間的關係，以及如何透過軟體架構來支援業務目標。

增加軟體架構意圖性的關鍵步驟

視覺化業務流程和軟體架構：使用EventStorming和流程建模EventStorming來視覺化業務流程和軟體架構，可以幫助團隊成員瞭解軟體架構與業務流程之間的關係。
定義關鍵績效指標（KPIs）：在流程建模EventStorming中，團隊成員共同定義了操作價值流的KPIs。這有助於確保大家對業務目標有一致的理解。
```
  graph LR;
    A[定義KPIs] --> B[統一理解];
    B --> C[業務目標一致性];
```
圖表翻譯： 此圖示展示了定義KPIs的過程，以及如何統一團隊成員對業務目標的理解。
識別熱點：透過分析熱點，團隊可以瞭解軟體架構和業務流程中的挑戰和浪費（waste）。
```
  graph LR;
    A[識別熱點] --> B[分析挑戰];
    B --> C[改善軟體架構];
```
圖表翻譯： 此圖示展示了識別熱點和分析挑戰的過程，以及如何利用這些資訊來改善軟體架構。
應用Lean原則：Lean原則提供了一種方法來識別和消除浪費，從而提高流程的效率。Toyota生產系統定義了八種型別的浪費，包括等待、運輸、庫存、動作、過度生產、過度加工、缺陷和技能浪費。
```
  graph LR;
    A[Lean原則] --> B[識別浪費];
    B --> C[消除浪費];
```
圖表翻譯： 此圖示展示瞭如何應用Lean原則來識別和消除浪費，從而提高流程的效率。
領域分解：透過領域分解，團隊可以將業務目標分解為可操作的指標，並瞭解不同工作之間的相互關係。
```
  graph LR;
    A[領域分解] --> B[業務目標分解];
    B --> C[指標可操作性];
```
圖表翻譯： 此圖示展示了領域分解的過程，以及如何將業務目標分解為可操作的指標。

程式碼實作與軟體架構最佳化

為了實作軟體架構的最佳化，可以透過以下程式碼示例來展示如何將上述原則應用於實際的軟體開發中。

class TravelInsuranceQuote:
    def __init__(self, customer_info, travel_details):
        self.customer_info = customer_info
        self.travel_details = travel_details

    def calculate_premium(self):
        # 計算保費的邏輯
        premium = self._calculate_base_premium() + self._calculate_risk_premium()
        return premium

    def _calculate_base_premium(self):
        # 基本保費計算
        return 100

    def _calculate_risk_premium(self):
        # 風險保費計算
        risk_factor = self._assess_risk()
        return risk_factor * 50

    def _assess_risk(self):
        # 風險評估邏輯
        # 這裡可以加入更複雜的風險評估邏輯
        return 1.2

# 使用示例
customer_info = {"name": "John Doe", "age": 30}
travel_details = {"destination": "Europe", "duration": 14}
quote = TravelInsuranceQuote(customer_info, travel_details)
premium = quote.calculate_premium()
print(f"The travel insurance premium is: {premium}")

內容解密：

TravelInsuranceQuote類別：這個類別封裝了與旅行保險報價相關的資料和行為。它接受客戶資訊和旅行詳情作為輸入。
calculate_premium方法：這個方法負責計算保險費。它呼叫了兩個私有方法：_calculate_base_premium和_calculate_risk_premium，來分別計算基本保費和風險保費。
_calculate_base_premium和_calculate_risk_premium方法：這兩個私有方法實作了保費計算的具體邏輯。基本保費是一個固定值，而風險保費則根據風險評估結果進行計算。
_assess_risk方法：這個方法用於評估風險。它傳回一個風險因子，用於計算風險保費。
使用示例：建立了一個TravelInsuranceQuote例項，並呼叫calculate_premium方法來計算保險費。這個示例展示瞭如何使用這個類別來取得旅行保險的報價。

未來，團隊可以繼續深入探索如何利用軟體架構來支援業務目標，並透過持續的迭代和改進，不斷提升軟體架構的意圖性。同時，也可以探索更多的工具和方法來視覺化和最佳化業務流程和軟體架構，以確保組織能夠在快速變化的市場中保持領先地位。

參考資料

Toyota生產系統，Toyota官方網站。
Nawras Shkmot，「The8 Wastes of Lean」，The Lean Way，2017年8月5日。

透過上述案例和程式碼示例，我們可以看到如何透過EventStorming和流程建模EventStorming來提升軟體架構的意圖性，並確保軟體架構能夠支援業務目標。這不僅需要技術上的實踐，也需要團隊的共同努力和持續改進。

軟體架構在組織擴充套件中的關鍵作用：以指標引導架構有意性

軟體架構在現代企業中扮演著至關重要的角色，尤其是在組織擴充套件的過程中。良好的軟體架構能夠支援業務目標的實作，並確保技術系統能夠隨著業務需求的變化而靈活調整。本文將探討軟體架構在組織擴充套件中的關鍵作用，並以指標引導架構有意性的實踐案例進行分析。

從業務目標到軟體架構

在組織擴充套件的過程中，業務目標與軟體架構之間的關聯性變得越來越重要。業務目標的實作依賴於軟體架構的支援，而軟體架構的設計也需要與業務目標保持一致。這種一致性可以透過將業務目標分解為可衡量的指標來實作。

指標的分解與軟體架構的關聯

以旅行保險領域為例，業務目標可以分解為以下指標：

提高保單啟用率
縮短報價請求到保單啟用或取消的時間

這些指標可以進一步分解為更具體的衡量標準，例如：

減少保險報價請求的匹配時間
減少手動資料修正的次數
提高客戶輸入的資料品質

這些指標不僅能夠衡量業務目標的實作程度，也能夠指導軟體架構的設計和最佳化。

軟體架構的意圖性與指標的引導

軟體架構的意圖性是指軟體架構能夠支援業務目標的實作，並確保技術系統能夠隨著業務需求的變化而靈活調整。指標的引導在實作軟體架構的意圖性方面發揮著關鍵作用。

案例分析：旅行保險領域的軟體架構最佳化

在旅行保險領域的案例中，軟體架構的最佳化是透過一系列實驗來實作的。實驗的目標是：

建立一個自包含的服務來管理旅行保險保單
評估將中央客戶資訊服務的依賴關係遷移到旅行保險保單服務所需的努力
評估將旅行保險保單資訊從中央客戶資訊服務遷移到旅行保險保單服務所需的努力

透過這些實驗，團隊能夠評估軟體架構的最佳化對業務目標的實作程度的影響，並根據指標的變化來調整軟體架構的設計。

指標的選擇與軟體架構的最佳化

在案例中，團隊選擇了佈署頻率和變更失敗率作為指標來引導軟體架構的最佳化。這些指標能夠衡量軟體架構的穩定性和靈活性，並指導軟體架構的最佳化方向。

KPI 值樹：連線業務目標與軟體架構的橋樑

KPI 值樹是一種用於連線業務目標與軟體架構的工具。它能夠將業務目標分解為可衡量的指標，並將這些指標與軟體架構的設計和最佳化聯絡起來。

KPI 值樹的結構

KPI 值樹通常具有三個層次：

組織級別的 KPI：衡量公司的整體健康狀況，例如 EBITDA 和客戶終身價值。
領域級別的 KPI：衡量特定業務領域的績效，例如旅行保險領域的保單啟用率和報價請求到保單啟用或取消的時間。
指標：衡量軟體架構的設計和最佳化的具體指標，例如佈署頻率和變更失敗率。

內容重點整理

軟體架構在組織擴充套件中扮演關鍵角色，支援業務目標並確保技術系統的靈活性。本文透過旅行保險領域的案例，探討了指標引導的軟體架構最佳化實踐。KPI 值樹作為連線業務目標與軟體架構的工具，能夠有效地指導軟體架構的設計和最佳化。

軟體架構最佳化實踐的未來方向

隨著業務需求的不斷變化，軟體架構的最佳化也需要不斷地進行調整和改進。未來的軟體架構最佳化實踐將更加註重以下幾個方面：

自動化：透過自動化工具和技術來提高軟體架構的最佳化和調整的效率。
資料驅動：透過資料分析和指標的引導來最佳化軟體架構的設計和實作。
靈活性：透過軟體架構的設計和最佳化來提高技術系統的靈活性和可擴充套件性。

透過這些實踐，能夠實作軟體架構的持續最佳化和改進，支援業務目標的實作和組織的擴充套件。

def calculate_deployment_frequency(deployment_data):
    # 計算佈署頻率
    total_deployments = len(deployment_data)
    time_period = deployment_data[-1]['timestamp'] - deployment_data[0]['timestamp']
    deployment_frequency = total_deployments / time_period.days
    return deployment_frequency

def calculate_change_fail_rate(deployment_data):
    # 計算變更失敗率
    total_changes = len(deployment_data)
    failed_changes = sum(1 for deployment in deployment_data if deployment['status'] == 'failed')
    change_fail_rate = failed_changes / total_changes
    return change_fail_rate

# 示例資料
deployment_data = [
    {'timestamp': datetime.date(2023, 1, 1), 'status': 'success'},
    {'timestamp': datetime.date(2023, 1, 15), 'status': 'failed'},
    {'timestamp': datetime.date(2023, 2, 1), 'status': 'success'},
    # 更多佈署資料...
]

deployment_frequency = calculate_deployment_frequency(deployment_data)
change_fail_rate = calculate_change_fail_rate(deployment_data)

print(f"佈署頻率：{deployment_frequency}")
print(f"變更失敗率：{change_fail_rate}")

內容解密：

此段程式碼用於計算軟體佈署的頻率和變更失敗率。首先，calculate_deployment_frequency 函式透過計算給定時間段內的佈署次數來得出佈署頻率。calculate_change_fail_rate 函式則透過計算失敗的變更次數佔總變更次數的比例來得出變更失敗率。這些指標對於評估軟體架構的穩定性和靈活性至關重要。示例資料展示瞭如何使用這些函式來計算實際的佈署頻率和變更失敗率。

軟體架構與度量指標的有意性提升

在軟體開發領域，隨著公司規模的擴大，業務環境和技術堆疊都會發生變化，這些變化不可避免地影響軟體架構。為了應對這些變化，軟體架構師需要根據資料（如KPI和度量指標）來制定解決方案，以滿足當前的約束條件（技術、人員、法規、市場等）。

KPI與度量指標的正確使用

KPI（關鍵績效指標）與度量指標應該作為和促進因素，而不是目標。它們不應該決定行為。如果人們開始說「我們沒有達到KPI X或度量指標Z」，這通常意味著KPI被用作目標。正確的做法是明確區分目標和度量指標。

軟體架構中的度量指標

軟體架構師可以從網站可靠性工程（SRE）社群中學習，該社群使用服務等級協定（SLA）。SLA是特定服務或供應商在法律契約中規定的預期服務水平。當服務水平未達到時，供應商通常會面臨財務後果。如果團隊支援具有SLA的軟體，那麼為團隊設定目標是有意義的。在這種情況下，視覺化KPI、度量指標和目標，並思考它們之間的聯絡是非常有用的。

DORA度量指標的應用

《Accelerate》（IT Revolution Press, 2018）一書由Dr. Nicole Forsgren、Jez Humble和Gene Kim撰寫，對軟體架構和軟體工程領域產生了深遠影響。該書提出的四個軟體交付和營運績效度量指標（圖6-12）被廣泛使用：

前置時間（Lead Time）：從提交程式碼到佈署上線所需的時間。
佈署頻率（Deployment Frequency）：軟體佈署到生產環境的頻率。
變更失敗率（Change Fail Rate）：因變更導致的失敗率。
平均還原時間（Mean Time to Restore）：從故障發生到還原正常所需的平均時間。

這些度量指標是衡量團隊速度和穩定性的先行指標。研究表明，這些技術度量指標在高效能團隊中很常見。然而，每個團隊都有其特定的上下文，因此還有其他相關的度量指標可以被產品工程團隊使用。

def calculate_lead_time(commit_time, deploy_time):
    """
    計算前置時間
    
    :param commit_time: 程式碼提交時間
    :param deploy_time: 佈署時間
    :return: 前置時間
    """
    lead_time = deploy_time - commit_time
    return lead_time

# 示例用法
commit_time = "2023-01-01 12:00:00"
deploy_time = "2023-01-01 13:00:00"
print(calculate_lead_time(commit_time, deploy_time))

內容解密：

此程式碼定義了一個函式calculate_lead_time，用於計算前置時間。它接受兩個引數：commit_time（程式碼提交時間）和deploy_time（佈署時間），並傳回前置時間。這個函式簡單地計算了從程式碼提交到佈署上線所需的時間。

其他度量指標的選擇

除了DORA度量指標外，還有其他有用的度量指標，例如：

平均發現時間（Mean Time to Discover）：指從IT事件發生到被發現的平均時間。
吞吐量（Throughput）：衡量產品工程團隊交付工作批次的能力。
員工淨推薦值（Employee Net Promoter Score®）：衡量員工滿意度，可以推動更高的員工留存率。

度量指標的上下文依賴性

每個團隊都有其特定的知識領域、技能水平、技術堆疊和其他上下文因素。因此，使用度量指標時需要考慮團隊的具體情況。比較不同團隊的績效是沒有意義的，因為每個團隊的運作環境不同。

有效溝通與期望管理

在進行軟體架構實驗或變革時，與利益相關者進行有效溝通至關重要。需要清晰地說明預期的後果、預期的結果以及如何實作組織的目標。這樣可以獲得利益相關者的支援和理解。

  graph LR
    A[開始實驗] --> B[溝通預期結果]
    B --> C[執行實驗]
    C --> D[評估結果]
    D --> E[分享結果]

圖表翻譯： 此圖表呈現了軟體架構實驗的流程。首先，開始實驗並與利益相關者溝通預期的結果。接著，執行實驗並評估結果。最後，分享結果給其他團隊或部門，以提供見解和解決共同的問題。

圖表解密：

這個Mermaid圖表展示了軟體架構實驗的一般流程。它從開始實驗開始，經過溝通預期結果、執行實驗、評估結果，直到最後與其他團隊分享結果。這個流程強調了溝通和分享的重要性。

玄貓

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