[[442953]]

從優先事項和部署到制定計劃

許多技術架構師專注于瀑布方法，在規劃技術架構改進工作時，以甘特圖式的風格處置時間表，將工作路線圖視為最重要的東西。

許多技術架構師沉浸在瀑布方法中，在規劃技術架構改進時，將用甘特圖式的時間軸視圖繪制的路線圖，作為規劃技術架構改進時最重要的工件。

但路線圖是瀑布思維的遺留產物。在最高優先級的部署計劃順利進行之前，規劃超出最高優先級的平臺或業務功能之外的技術架構幾乎沒有意義。正如我們在敏捷應用程序開發中所學到的那樣，一個過早制定的計劃在開始實施之前就已經過時了。

通過靈活處理待辦工作的方式來管理技術架構規劃，會遠優于傳統經典的路線圖方式。

這種方法有兩種版本：平臺驅動的架構和業務功能驅動的架構。第一種是平臺堆棧取代了待辦工作中的敏捷“用戶故事”。第二種是圍繞業務功能來構建“用戶故事”的待辦需求。

平臺驅動的架構調整：使用這種方法，無論是基于上述的優先級方式，還是基于一些更適合自己企業的替代方案，通常都需要選擇一個平臺組件。無論基于哪種方式，規劃人員都會去尋找平臺級的漣漪效應(其他受影響的堆棧)和應用層的漣漪效應(能利用受影響堆棧的一些應用程序)。

在實施最高優先級平臺部署的過程中，技術架構師將在剩余的待辦工作事項中審查當前平臺里的用戶故事的優先級，并在適當的情況下對其進行修改以適應不斷變化的環境，然后開始為下一個最高優先級用戶故事制定計劃。

業務功能驅動的體系結構更改：在業務功能驅動的架構更改的工作中，盡管相關性并不能證明因果關系，但在業務和應用程序運行狀況評分都很低的功能中尋找造成業務流程瓶頸的應用程序是很合理的。

從技術架構的角度來看，業務功能驅動的變更是從配置具有最高優先級業務功能的核心應用程序開始，然后再延伸至附屬應用程序。

同時，公司的業務架構師將合作設計和實施由應用程序調整來實現的流程改進。

與平臺驅動的變更一樣，在部署具有最高優先級業務功能的應用程序過程中，技術架構師將進行審查，在適當的情況下，會調整待辦工作事項的優先級，并開始規劃下一個最高優先事項的用戶故事。

結論

這些知識夠用了嗎?

技術架構很復雜，他們必須如此處理，因為如果你曾經嘗試過記錄業務中所有發生的事情，以便IT能夠進行設計、構建、銷售、配送和支持其產品和服務，那么你就會知道業務工作很復雜。

順便說一句，這就是你的BCM所做的事情。僅在前三個 BCM 層就列出幾百個業務流程和實踐的情況并不少見。同樣，你那些映射到 BCM的應用程序清單數量達到一千個或更多也很平常。

記錄你所有的資產和規劃改進工作的過程，既耗時又費錢。

但這沒關系，因為如果不記錄你的所有資產和規劃必要的改進工作，最終會耗費更多的時間和成本。

當你面臨選擇是現在去做，還是以后再做時，你應該清楚的一件事，那就是以后再做將會更糟糕。

作者：Bob Lewis ，專欄作家

原文網址：

http://www.cio.com/article/3640510/the-secret-art-of-technical-architecture-improvement.html