英文原文：A practical guide to developing enterprise architecture

　　文/Franki Schafrik, 資深企業架構師, IBM

　　企業架構是業務及其支持數據、應用程序和 IT 基礎架構的邏輯組織，為未來的業務成功明確定義了目的和目標。典型的架構由展示業務的各個方面如何關聯的一些圖或模型組成。例如，組織結構圖是表示業務單元如何相互關聯的模型。

　　企業應該有一個代表其當前狀態的 “原樣” 架構，并且有一個規劃架構，以顯示在未來一年至五年的業務方向。

　　企業架構應該協調以下關鍵領域。請注意每個領域中的示例：

• 業務：流程、戰略、組織結構圖和職能
• 信息：概念性、邏輯和物理數據模型，顯示需要哪些信息，以及如何與其他信息（比如客戶和訂單）關聯
• 應用程序：應用程序組合、接口和服務
• 基礎架構：網絡概念圖、技術參考模型

　　為了實現協調一致，需要從每一個關鍵領域的視角對其進行建模，然后從各個角度鏈接模型。例如，從業務的角度對業務流程建模。不包括應用程序等內容。然后，將業務流程鏈接到支持它們的應用程序，這樣就可以幫助您實現協調一致。我們這樣做是為了確保每一個決策都是根據業務需求制定的，因此，應用程序并不會規定業務流程的設計方式。

　　本文假設您有一個建模工具，可以用該工具創建您的架構。本文中特定于實現的信息以 Rational System Architect 為基礎的。

　　“我們打算做架構......我們要做架構！”

　　1. 如果您沒有一個目標，您的項目將會失敗

　　確保您的架構失敗的最簡單方法是毫無目的地制定架構。我已和數百家客戶合作過架構項目。當項目沒有成功時，我問他們為什么要創建企業架構。他們回答：“因為我們想要一個架構！”

　　第 1 步. 確定架構的目標

　　您可以通過詢問以下問題來定義架構的目標：

• 哪些信息對于架構是重要的？
• 支持分析和決策需要多少細節？
• 誰將生成或使用架構？
• 架構的預期投資回報率是多少？
• 維護的考慮因素是什么？

　　如果您無法回答這些問題，您的架構項目很可能會失敗。如果沒有目標，您可能會浪費幾個月來繪制沒有人關心的業務流程圖。或者您可能繪制了一些復雜的應用程序接口圖表，但無法提交給高級管理人員，因為這讓他們感到頭疼。

　　以一家連鎖酒店為例，將酒店經理確定為 EA 的受眾。

　　通過了解架構的目的，您可以確定必需的模型和所需要的數據的范圍，從而確保人們使用您的架構進行分析和制定業務決策。

　　首次涉足架構時不要走極端。即使您擁有一個非常大的經驗豐富的團隊，您也無法捕獲有關組織的所有信息。

　　同樣重要的是，請記住，全面的架構可能會混淆重要的事項。例如，如果只有 50 個業務流程對您的業務是至關重要的，捕獲 5000 個業務流程就是沒有意義的。識別您的關鍵業務問題，并使用它們成為您的第一個架構項目的重點。

　　2. 架構為回答問題提供了一條路線

　　第 2 步. 確定業務問題

　　我與客戶做的第一件事，是討論對其業務至關重要的一些問題；然后我幫助他們確定哪些是他們難以解決的問題。許多客戶都需要回答以下問題：

　　酒店做架構的目的是改善入住登記和退房的體驗，使他們能更具競爭力。

• 不使用某個應用程序的影響是什么？
• 某個位置遷移的影響是什么？
• 需要使用哪些應用程序來支持業務流程？
• 更換服務器的影響是什么？
• 需要制定什么流程來支持新的戰略？
• 在我們的應用程序組合中，存在哪些不足或重復現象？

　　您的問題將促進架構內容的形成。如果大多數問題都涉及您的應用程序組合，那么您需要將重點放在定義應用程序領域。如果需要了解流程如何支持一個新的戰略，那么應該將重點放在業務領域。然后，就可以開始通過新的業務問題拓展架構的范圍。

　　第 3 步. 確定假設和業務規則

　　現在，您已經確定了受眾、目的和問題，然后應該確定用來限制或解釋關注領域的業務規則。

　　每個業務都有規則。例如，如果您打算捕獲關鍵業務流程的信息，則必須捕獲該流程的所有法規或企業標準。舉個法規方面的例子，健康保險流通和責任法案 (Health Insurance Portability and Accountability Act, HIPAA)，該法案保護工作變更的人的健康保險的承保范圍。然后將創建一個企業規定，顯示該公司是否滿足 HIPAA 的要求。

　　您應該捕獲與架構有關的假設，如 “新應用程序的信息將在周五上傳” 或 “每一個業務單元都要負責記錄業務流程”。

　　第 4 步. 確定框架

　　以下行業標準框架可以幫助您創建一個企業架構：

• ToGAF
• Zachman
• EA3
• DoDAF

　　使用標準框架，可以為您的架構提供一個 “骨架”，然后，您可以利用它建立您的模型。

　　框架還提供了一些指導，指導您了解需要根據將要使用架構的利益相關者來捕獲哪些信息。它提供有關組織信息的指導，但沒有為您的架構建議具體的實現。

　　InterNET 有大量關于這些框架的信息。您要選擇什么框架主要取決于您的架構的目標、團隊的經驗，以及您是想遵循 ToGAF 這樣的已定義的流程，還是僅像 Zachman 那樣，幫助確定出于什么目的使用哪個模型。

　　您還可以組合多個框架。TOGAF 和 Zachman 經常一起使用。

　　3. 您的選擇應以您的目標為基礎，不要作出隨機選擇

　　如何將框架融入架構？

　　框架提供關于建模對象的指導。然后使用一些方法來創建模型。

　　方法是一個規則集，說明了如何對某個對象建模。例如，業務流程建模符號 (Business Process Modeling Notation, BPMN) 方法提供了用于業務流程建模的精確的規則和符號。

　　圖 4. 框架有助于確定方法的選擇

　　框架有助于組織架構的關鍵領域，并確定您需要建模的視圖，比如，解決業務問題所需的角度和數據。

　　連鎖酒店決定使用 Zachman 框架。

　　盡可能使用行業標準的方法，而不是 “內部開發” 的方法。行業標準的方法包括規則集和標準的建模方式。多數內部開發的方法無法以有用的方式捕獲信息，因為沒有明確定義的規則集，這使人們以多種方式對相同的信息進行建模。這也會影響分析，因為信息沒有按照標準進行捕獲。

　　根據需要的信息類型，可以生成多種模型來支持框架。

　　圖 5. 框架及所支持的方法

　　第 5 步. 創建一個元模型

　　元模型是架構的一個抽象視圖。它顯示您正在嘗試捕獲的數據以及數據之間的關系。這是您實現協調一致的地方，它以您的業務問題的解答為基礎。

　　例如，如果您需要了解支持特定業務流程的應用程序，在您的元模型中必須存在這兩者之間的關系。否則，數據之間不存在任何聯系，您無法解決您的業務問題，架構也無法發揮其作用。

　　請注意，在元模型中，您可能并不希望所有數據之間都存在直接關系，您應該只將存在邏輯關系的東西放在一起。例如，將組織部門與技術相關聯沒有任何意義，但將技術與應用程序相關聯就有意義了。Rational System Architect 等良好的建模工具支持通過遍歷元模型來創建復雜的報告。所以，在這個元模型示例中，您可以報告支持某項業務功能的硬件，即使兩者在元模型中并沒有直接關系。在元模型中，您可能從業務功能遍歷到該功能所擁有的某個業務流程，再遍歷到業務流程的位置，然后遍歷到該流程所需要的支持應用程序，最后，遍歷到支持該應用程序的技術。

　　圖 6. 關系（元模型）示例

　　您的元模型應該包括以下特性：

• 架構元素之間的關系。例如，業務流程和應用程序的關系。
• 元素的定義。例如，術語 “應用程序” 的意義和您將捕獲的屬性。
• 業務問題的可追溯性。例如，如果您的問題是 “什么應用程序支持什么業務流程？” 那么您應該知道，元模型中需要一個業務流程和一個應用程序，它們之間存在直接或間接的關系。

　　第 6 步. 確定架構中所需的模型

　　現在您已經確定了您的業務問題、框架以及解決問題所需的元模型，然后還需要了解要繪制什么樣的模型。

　　將業務流程作為一個例子，有許多行業標準支持業務流程的建模，如 BPMN 和流程圖。請根據以下條件選擇您的建模方法：

• 信息的受眾。管理者理解如 BPMN 等簡單的圖表；軟件開發人員通常喜歡 UML 序列圖或用例。
• 元模型的元素。如果在您的元模型中，您需要了解數據以及與它相關的業務流程，請考慮使用 BPMN 對其建模。相反，如果您只是擔心流程步驟的順序，請考慮創建一個流程圖。

　　知道受眾和您想建模的內容之后，您就可以確定您需要創建的圖表。在上面的例子中，因為您需要有關業務流程和系統接口的信息，您可以選擇以下模型：

• BPMN （捕獲業務流程）
• 系統架構（捕獲應用程序）

　　以酒店為例，他們需要回答的業務問題是 “什么應用程序支持什么業務流程？”

　　重要的是，請記住，您不能用單一圖表來創建 EA 中的一切。此外，架構視圖的分離是一種最佳實踐，如應用程序視圖與業務視圖分離。如果您嘗試在同一個圖表中完成兩個視圖的建模，這樣做往往會造成混亂，并且無法以有意義的方式捕獲信息。

　　圖 7. 使用模型來解決業務問題，所以架構是有用的…

　　圖 8. …不要為了建模而建模

　　正如 Will Gadd 所說，“只是出來走走，做點不那么重要的事情，這樣做我就已經覺得很高興了。”

　　使用合適的工具

　　單一的建模工具或方法并不能提供完整的解決方案。除了開發模式的工具之外，您也應該有發布、需求管理和儀表板顯示等工具。儀表板在餅圖和條形圖等容易理解的圖表中展示您的企業架構信息。

　　如果您的架構工具是可定制的，則意味著將使用一些改變工具原有用途的問題定制。大量的定制通常標志著使用了錯誤的工具或方法。還請記住，定制會帶來架構上的管理開銷。

　　有些客戶通過定制架構工具來創建自己的模型。這并不是最佳實踐的方法，特別是如果 “模型” 是占滿了整面墻的單一圖表，其中包含了關于您的架構的所有信息，這肯定不是一個最佳實踐。我們不應該創建墻紙，而是建議創建報告。并不是一切都需要在一張圖上顯示。

　　在創建架構時，人和工具同樣重要。一個人不可能在架構的每個方面都是專家，因此需要發展一個成熟的團隊來支持架構。關于架構團隊的理想特性的列表，請參閱本系列的第一篇文章，從您的企業架構顧問身上獲取最大價值。

　　第 7 步. 整合架構

　　將您根據之前所確定的關系捕獲的數據鏈接在一起。無論銷售人員跟您說的話有多漂亮，不要相信，一個工具是無法奇跡般地做到這一點。此外，如果沒有一個資料庫，關系的鏈接真的很難做到。如果有人建議說該項目可以使用電子表格做到這一點，那么尋找另一個項目可能會是一個明智的決定。

　　如果您現有的項目或業務線已經有架構，并且您想創建一個企業架構，那么最簡單的方法是自下而上填充您的 EA。采用現有架構，并將共同的元素放進一個資料庫中。具體而言，可以嘗試標準化整個組織中使用的模型和術語，因為可能每個人都對同一個組織使用同一個名稱，比如，不是同時使用 “財務部”、會計或財會等別名，而是將它們標準化為 “財務”。

　　如果這是您的第一個企業架構，那么請在整個組織中使用一個公共的藍圖，使用與企業架構相同的框架、術語和模型為業務線創建一個架構。這樣，您就可以報告整個業務。

　　分析架構

　　圖 9. 為分析節約能源！

　　如果您不愿意花時間來分析架構，可能就不會去分析它。如果不分析它，那么為什么要構建它呢？在時間表中，這關鍵的一步常常被忽視。至少應該將 50% 的模型開發時間分配給分析，這包括審查模型以驗證和確認它。

　　然后執行定量和定性分析。此時數學很重要，在顯示投資回報率時尤為如此。如果您使用行業標準方法（如 BPMN），則可以使用定量分析來顯示縮短流程、節省時間、節省成本和消除冗余中的瓶頸。 BPMN 是 “結構化” 的，因為它有一個您不能違反的規則集。這些規則確保您可以執行分析，比如分析模擬業務流程的變化，看看該變化是否能夠節省時間或金錢，或者是否會造成瓶頸等負面影響。

　　通過查看模型，可以找出潛在的問題所在，然后完成定性分析。例如，如果您有一個業務流程反饋到流程的早期階段，那么這通常標志著該流程必須返工。消除流程中的反饋回路是改進流程的一種方式。

　　完成分析后，就可以與他人共享成果。如果人們學會了如何使用架構，就會看到它的價值。報告在這里是關鍵，所以在選擇企業架構工具時，請確保它提供了強大的報告功能。

　　不要忘記，您需要一個游戲計劃

　　圖 10. 制定您的 EA 游戲計劃

　　人們常常忘記，需要在解決了許多管理問題之后，才能啟動和支持 EA 項目。需要解決的一些管理問題包括：

• 如何部署企業架構？
• 在哪里部署它（Web 站點，等等）？
• 誰是團隊成員？
  • 審查委員會
  • 項目管理
  • 行政管理
• 誰將使用信息？
• 誰將可以訪問信息？
• 將要遵循什么標準？
  • 命名約定
  • 顏色編碼

　　團隊里有一個 "EA"

　　圖 11. 良好的 EA 團隊確保成功

　　您不能憑空創建架構。您必須做好準備，與 EA 團隊以外的人合作，否則用戶無法采納和使用您的架構。此外，您還要確保利益相關者（例如，付錢讓您構建架構的人，或者幫助您構建架構的人）參與了您的決策。

　　治理是制定決策所必不可少的。治理有助于定義您將在架構中使用的規則和戰略。以組織中的業務線命名的治理為例，人們可能不希望出現某人將這個部門稱為 “會計” 而其他另一個人將它稱為 “財務” 的情況。治理也決定了哪些模型已準備好發布為 “批準”。成功的 EA 所需要的典型委員會包括：

• 架構審查委員會
• 配置和控制委員會
• 管理指南（例如，誰可以創建模型，審批流程的什么，變更請求的流程是什么）

　　越多人參與支持架構，使用該架構的機會就會越多。

　　最后幾點建議

　　如果建立架構看起來很難，那是因為它的確很難。但這也表示您在以下其中一個方面犯了錯誤：

• 模型。例如，使用一個 BPMN 模型來捕獲應用程序界面。
• 利益相關者。例如，不熟悉業務流程的人提供輸入或反饋，而不是由真正做流程的人來提供這些信息。

　　學會從架構中將政治原因分離出來

• “不要記錄那條信息，否則人們會知道我們做錯了！” – 這是對企業架構的一個常見反應。但是記錄理想化的視圖是沒有意義的，因為您無法規劃未來糾正問題的方式。
• “我的組織正在使用不同的方法捕獲我們的架構。” – 在我合作過的每一個組織中，總會有一個業務線不希望以標準的方式開發他們的架構。沒有人是特殊的。沒有人有不以標準方式做事的正當理由。處理這種情況的最佳做法是培訓那些希望與眾不同的笨蛋。如果他們對期望的目標感到滿意并了解他們的期望，那么他們會愿意遵循標準。如果這個方法無效，那么您惟一的選擇就是打斷他們的腿。

　　使用架構打破獨裁

• “我們沒辦法跟那些家伙溝通，您知道，他們是做軟件的。” – 在大多數公司都有些人認為與軟件開發人員談話是一種挑戰。在您了解他們后，就會發現他們其實都是一些好人。并且，如果他們發現可以用簡單的方式與您溝通，可以使用圖片，而不是無意義的 500 頁需求文檔，那么他們對您的態度也會隨之改變。
• “我倒是愿意把數據給您，但我需要先與我的管理層確認一下。我下次再回復您好嗎？” – 有些人認為隱瞞信息可以保住工作。如果 Barney 是惟一了解您的應用程序如何連接在一起的人，那么您就不能解雇他。其他業務線可能不希望共享信息，因為他們怕您用這些信息來解雇員工。通過解釋將要采用哪些信息，以及如何讓提供信息的人從中受益，可以處理這些情況。如果您帶著不可告人的目的（如，解雇員工）來使用信息，那么您會看到愿意向您提供信息的人數會急劇下降。

it知識庫：開發企業架構的實用指南，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。