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

　　文/Franki Schafrik, 資深企業(yè)架構(gòu)師, IBM

　　企業(yè)架構(gòu)是業(yè)務(wù)及其支持?jǐn)?shù)據(jù)、應(yīng)用程序和 IT 基礎(chǔ)架構(gòu)的邏輯組織，為未來的業(yè)務(wù)成功明確定義了目的和目標(biāo)。典型的架構(gòu)由展示業(yè)務(wù)的各個方面如何關(guān)聯(lián)的一些圖或模型組成。例如，組織結(jié)構(gòu)圖是表示業(yè)務(wù)單元如何相互關(guān)聯(lián)的模型。

　　企業(yè)應(yīng)該有一個代表其當(dāng)前狀態(tài)的 “原樣” 架構(gòu)，并且有一個規(guī)劃架構(gòu)，以顯示在未來一年至五年的業(yè)務(wù)方向。

　　企業(yè)架構(gòu)應(yīng)該協(xié)調(diào)以下關(guān)鍵領(lǐng)域。請注意每個領(lǐng)域中的示例：

• 業(yè)務(wù)：流程、戰(zhàn)略、組織結(jié)構(gòu)圖和職能
• 信息：概念性、邏輯和物理數(shù)據(jù)模型，顯示需要哪些信息，以及如何與其他信息（比如客戶和訂單）關(guān)聯(lián)
• 應(yīng)用程序：應(yīng)用程序組合、接口和服務(wù)
• 基礎(chǔ)架構(gòu)：網(wǎng)絡(luò)概念圖、技術(shù)參考模型

　　為了實現(xiàn)協(xié)調(diào)一致，需要從每一個關(guān)鍵領(lǐng)域的視角對其進(jìn)行建模，然后從各個角度鏈接模型。例如，從業(yè)務(wù)的角度對業(yè)務(wù)流程建模。不包括應(yīng)用程序等內(nèi)容。然后，將業(yè)務(wù)流程鏈接到支持它們的應(yīng)用程序，這樣就可以幫助您實現(xiàn)協(xié)調(diào)一致。我們這樣做是為了確保每一個決策都是根據(jù)業(yè)務(wù)需求制定的，因此，應(yīng)用程序并不會規(guī)定業(yè)務(wù)流程的設(shè)計方式。

　　本文假設(shè)您有一個建模工具，可以用該工具創(chuàng)建您的架構(gòu)。本文中特定于實現(xiàn)的信息以 Rational System Architect 為基礎(chǔ)的。

　　“我們打算做架構(gòu)......我們要做架構(gòu)！”

　　1. 如果您沒有一個目標(biāo)，您的項目將會失敗

　　確保您的架構(gòu)失敗的最簡單方法是毫無目的地制定架構(gòu)。我已和數(shù)百家客戶合作過架構(gòu)項目。當(dāng)項目沒有成功時，我問他們?yōu)槭裁匆獎?chuàng)建企業(yè)架構(gòu)。他們回答：“因為我們想要一個架構(gòu)！”

　　第 1 步. 確定架構(gòu)的目標(biāo)

　　您可以通過詢問以下問題來定義架構(gòu)的目標(biāo)：

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

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

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

　　通過了解架構(gòu)的目的，您可以確定必需的模型和所需要的數(shù)據(jù)的范圍，從而確保人們使用您的架構(gòu)進(jìn)行分析和制定業(yè)務(wù)決策。

　　首次涉足架構(gòu)時不要走極端。即使您擁有一個非常大的經(jīng)驗豐富的團(tuán)隊，您也無法捕獲有關(guān)組織的所有信息。

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

　　2. 架構(gòu)為回答問題提供了一條路線

　　第 2 步. 確定業(yè)務(wù)問題

　　我與客戶做的第一件事，是討論對其業(yè)務(wù)至關(guān)重要的一些問題；然后我?guī)椭麄兇_定哪些是他們難以解決的問題。許多客戶都需要回答以下問題：

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

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

　　您的問題將促進(jìn)架構(gòu)內(nèi)容的形成。如果大多數(shù)問題都涉及您的應(yīng)用程序組合，那么您需要將重點放在定義應(yīng)用程序領(lǐng)域。如果需要了解流程如何支持一個新的戰(zhàn)略，那么應(yīng)該將重點放在業(yè)務(wù)領(lǐng)域。然后，就可以開始通過新的業(yè)務(wù)問題拓展架構(gòu)的范圍。

　　第 3 步. 確定假設(shè)和業(yè)務(wù)規(guī)則

　　現(xiàn)在，您已經(jīng)確定了受眾、目的和問題，然后應(yīng)該確定用來限制或解釋關(guān)注領(lǐng)域的業(yè)務(wù)規(guī)則。

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

　　您應(yīng)該捕獲與架構(gòu)有關(guān)的假設(shè)，如 “新應(yīng)用程序的信息將在周五上傳” 或 “每一個業(yè)務(wù)單元都要負(fù)責(zé)記錄業(yè)務(wù)流程”。

　　第 4 步. 確定框架

　　以下行業(yè)標(biāo)準(zhǔn)框架可以幫助您創(chuàng)建一個企業(yè)架構(gòu)：

• ToGAF
• Zachman
• EA3
• DoDAF

　　使用標(biāo)準(zhǔn)框架，可以為您的架構(gòu)提供一個 “骨架”，然后，您可以利用它建立您的模型。

　　框架還提供了一些指導(dǎo)，指導(dǎo)您了解需要根據(jù)將要使用架構(gòu)的利益相關(guān)者來捕獲哪些信息。它提供有關(guān)組織信息的指導(dǎo)，但沒有為您的架構(gòu)建議具體的實現(xiàn)。

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

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

　　3. 您的選擇應(yīng)以您的目標(biāo)為基礎(chǔ)，不要作出隨機(jī)選擇

　　如何將框架融入架構(gòu)？

　　框架提供關(guān)于建模對象的指導(dǎo)。然后使用一些方法來創(chuàng)建模型。

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

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

　　框架有助于組織架構(gòu)的關(guān)鍵領(lǐng)域，并確定您需要建模的視圖，比如，解決業(yè)務(wù)問題所需的角度和數(shù)據(jù)。

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

　　盡可能使用行業(yè)標(biāo)準(zhǔn)的方法，而不是 “內(nèi)部開發(fā)” 的方法。行業(yè)標(biāo)準(zhǔn)的方法包括規(guī)則集和標(biāo)準(zhǔn)的建模方式。多數(shù)內(nèi)部開發(fā)的方法無法以有用的方式捕獲信息，因為沒有明確定義的規(guī)則集，這使人們以多種方式對相同的信息進(jìn)行建模。這也會影響分析，因為信息沒有按照標(biāo)準(zhǔn)進(jìn)行捕獲。

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

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

　　第 5 步. 創(chuàng)建一個元模型

　　元模型是架構(gòu)的一個抽象視圖。它顯示您正在嘗試捕獲的數(shù)據(jù)以及數(shù)據(jù)之間的關(guān)系。這是您實現(xiàn)協(xié)調(diào)一致的地方，它以您的業(yè)務(wù)問題的解答為基礎(chǔ)。

　　例如，如果您需要了解支持特定業(yè)務(wù)流程的應(yīng)用程序，在您的元模型中必須存在這兩者之間的關(guān)系。否則，數(shù)據(jù)之間不存在任何聯(lián)系，您無法解決您的業(yè)務(wù)問題，架構(gòu)也無法發(fā)揮其作用。

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

　　圖 6. 關(guān)系（元模型）示例

　　您的元模型應(yīng)該包括以下特性：

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

　　第 6 步. 確定架構(gòu)中所需的模型

　　現(xiàn)在您已經(jīng)確定了您的業(yè)務(wù)問題、框架以及解決問題所需的元模型，然后還需要了解要繪制什么樣的模型。

　　將業(yè)務(wù)流程作為一個例子，有許多行業(yè)標(biāo)準(zhǔn)支持業(yè)務(wù)流程的建模，如 BPMN 和流程圖。請根據(jù)以下條件選擇您的建模方法：

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

　　知道受眾和您想建模的內(nèi)容之后，您就可以確定您需要創(chuàng)建的圖表。在上面的例子中，因為您需要有關(guān)業(yè)務(wù)流程和系統(tǒng)接口的信息，您可以選擇以下模型：

• BPMN （捕獲業(yè)務(wù)流程）
• 系統(tǒng)架構(gòu)（捕獲應(yīng)用程序）

　　以酒店為例，他們需要回答的業(yè)務(wù)問題是 “什么應(yīng)用程序支持什么業(yè)務(wù)流程？”

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

　　圖 7. 使用模型來解決業(yè)務(wù)問題，所以架構(gòu)是有用的…

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

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

　　使用合適的工具

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

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

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

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

　　第 7 步. 整合架構(gòu)

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

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

　　如果這是您的第一個企業(yè)架構(gòu)，那么請在整個組織中使用一個公共的藍(lán)圖，使用與企業(yè)架構(gòu)相同的框架、術(shù)語和模型為業(yè)務(wù)線創(chuàng)建一個架構(gòu)。這樣，您就可以報告整個業(yè)務(wù)。

　　分析架構(gòu)

　　圖 9. 為分析節(jié)約能源！

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

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

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

　　完成分析后，就可以與他人共享成果。如果人們學(xué)會了如何使用架構(gòu)，就會看到它的價值。報告在這里是關(guān)鍵，所以在選擇企業(yè)架構(gòu)工具時，請確保它提供了強(qiáng)大的報告功能。

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

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

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

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

　　團(tuán)隊里有一個 "EA"

　　圖 11. 良好的 EA 團(tuán)隊確保成功

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

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

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

　　越多人參與支持架構(gòu)，使用該架構(gòu)的機(jī)會就會越多。

　　最后幾點建議

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

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

　　學(xué)會從架構(gòu)中將政治原因分離出來

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

　　使用架構(gòu)打破獨裁

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

it知識庫：開發(fā)企業(yè)架構(gòu)的實用指南，轉(zhuǎn)載需保留來源！

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