企業規劃架構管理

前言：本站為你精心整理了企業規劃架構管理范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

關于企業規劃和企業架構（Enterprisearchitecture）設計，在現有的企業管理者中往往存在一些錯誤的觀點，比如完美主義、“大而全”等。本文提出了企業EA設計和構建的兩個原則：JustInTime和JustEnough，企業架構設計的團隊只有依照這兩個原則才能夠真正實現企業架構設計的預期結果，獲得最大的投資收益。

企業架構任務的規模和復雜性都可能非常巨大。如果沒有細致的規則，企業架構（EA）的團隊常常變成“細節驅動”，失去企業總體的視圖。專注的EA團隊應用系統的EA流程來在業務的“上下文”中定義戰略需求，然后根據實際優先級創建未來狀態依賴的可遞交件。

EA成功將由公司和業務線經理理解、遲遲和實現架構的程度決定。到2007年為止，15%的EA核心團隊從IT組織的管理結構中轉移出，直接向企業戰略或者企業變更管理部門報告。2007年之前，40%的企業架構設計師將在業務戰略或者流程工程方面擁有主要專家技能。

完美主義是最大的敵人。這個眾所周知的信條必須被每個企業架構設計師深刻理解。在關于EA團隊的研究中，我們常常看到他們迷失在細節中，失去了對總體結構的預測能力。企業架構設計師常常被來自用戶的大量的細節需求所驅動，這些用戶希望EA團隊作為工程組織工作。在他們決定實現時，與他們作為工程師的主要訓練一致，很多企業架構設計師非常愿意提供這方面的幫助。他們經理的實現完美的模型，在所有可能的細節層次上，對于所有的觀眾而言。企業架構設計師常常夸大他們的狀態，方法是通過成功、顯示特定項目的能力、以及設定未來細節問題解決的障礙。企業架構設計師必須記住他們的主要目標不僅是作為工程中心，而且要為企業戰略決策制訂提供現實的、環境的基礎，并且提供跨企業的實現一致性。

很多EA團隊驅動自身到總體的詳細視圖中，方法是通過錯誤地嘗試從開始就完全移植模型的完美“地圖”。為“完整性”而奮斗可能導致團隊在實際任務上偏離方向。雖然很多完美完整的模型中有很多的屬性，這些屬性很少可以幫助架構設計師鑒別從何處開始，或者決定何時完結。高水平的模型分類學在使用時可以作為澄清架構思維的工具。不幸的是，他們可能導致大的、包容一切的EA努力，這種努力在失敗以前幾乎毫無意義。

正如業務需求可能驅動EA努力一樣，業務需求應該驅動流程，這種流程是由EA開發的。這些流程必須考慮業務文化問題，以及業務驅動。

卓越架構團隊的特點

1.解釋架構努力將是不斷進行的過程，而不是單一的事件。早期的結果將不會是完全包括，或者完全詳細的。團隊產生了架構文檔，作為建立的基礎。

2.通過鑒別“閃電戰工程”所需的組成部分，確定優先級，通過致力于這些領域得出結果。

3.他們評估標準化和文化對應的業務規則水平，不允許EA設定于不現實的目標。

JustInTime：只涉及最需要的部分

企業需要必須首先通過公共需求圖景（CRV）定義，但概念架構必須被開發。只有當這些先決條件已經滿足后，架構團隊才應該專注于詳細的架構模型開發。最佳實踐是，EA的努力首先致力于對業務最關鍵的模型。兩個主要的檢驗可以用來為工作排定優先級，現實架構努力的早期結果：

最高優先級應該給予那些直接與戰略機會有關的模型，正如CRV驅動的早期分析所顯示。業務戰略和低水平細節之間的“戰略契合”應該是業務架構設計師和LOB經理的共同任務。第二個檢驗鑒別已經很好定義和標準化的架構模型，即使還沒有完全宣布。現存的規則和標準可能需要澄清、修改、再工程，但是至少已經應該可以在現實世界中被檢驗。其優勢和弱點被理解，執行個人已經被檢驗來處理這些問題。如果這些規則和標準仍然有價值，增加的移植努力應該得到更早的結果。

作為一個例子，正在進行全球市場擴張的公司對于以下要素有較強的需求，包括：通用全球通訊環境、跨區域協同和知識管理。關注于全球整合標準、信息政策和協同工具的EA努力客戶很快表現出業務價值。公司通過在在同樣的地理區域購買相關業務公司來增長收入，他們可能從跨業務協同的客戶管理和目標市場中獲益。EA模型開發戰略應該首先關注信息管理、整合、CRM和企業分析相關的問題。其他的領域擁有比較少的優先級。

有些現存的實現可能已經表示出了公司內的事實標準。很多年的系統投資導致很多公司創建了“工程平臺”，這些平臺嚴格文檔化、經過壓力測試并且在嚴格的管理規則下升級。架構團隊應該通過快速將這些管理規則放置于EA雨傘之下。通過在一些領域快速產生結果，識別和包括現存的最佳實踐，架構團隊強調EA努力，并將之作為可以產生業務需求相關的可行結果的機會。EA努力成為了雙面的方法：持續實現已定義的架構（通過轉換和EA保險流程）；進一步創建額外的、新的或者更多的擴展模型。兩條路徑可以通過一致性和依賴性一起管理。

JustEnough：只為本公司服務

EA項目的文化和總體接受度驅動了何時、何處以及多少EA模型詳細可以被引入。EA流程模型定義了每個模型的一些維度。最終取決于業務經理實現的架構順從度；他們將實現架構標準超出了他們認為可能產生收益的點。因此，雖然EA團隊可能感覺到有驅動力要實現某個詳細，開發必備的詳細是不必要的，也可能導致達不到預期效果。

EA模型：ETA例子

我們鑒別了每個企業技術架構（ETA）領域，架構標準化的一些維度。鑒別列表的那些部分可能對標準化每個部分有意義：

圖：企業ETA的5個維度

例如，一個激進的企業公司可能沒有定義按照所有領域的配置水平定義標準。在此公司，標準方法的感知價值當用創新和市場時間加權時是有問題的。按照定義，業務模型確保了實驗和文化反映的特定自有。即，合理的業務管理實際上再次發明了已經存在的“輪子”。業務經理通常同意：通用方法（如規則、技術）是必須的，將他們實現在某些領域，但卻沒有看到更多詳細規范的好處。

達到架構詳細的正確水平常常是發現性的努力。缺乏細節成為了實現業務目標時刻的可見障礙。很多公司看到這種需求，因此再次述諸EA努力。但是，“反架構”的態度不會一夜間消失。成功的架構團隊逐步剝落反對情緒。關鍵點是，架構設計師有時的失敗是由于他們解決的問題是沒有人愿意提出的。但是通過關注對業務有價值的現實細節水平，EA努力在在面對業務和IT社區時保持可信度。

Just-Enough,Just-in-Time：風險

此方法不是沒有風險的，通過開發基于業務優先級的模型，很容易過分最優化“初生的”模型，代價是未來模型的高成本。以下要點非常重要：根據EA流程和在最高的細節水平上定義滿足整體論的早期模型，使最終結果很容易見到，同時可以取得企業水平的最優化。

業務沖擊

驅動企業架構到正確的細節水平的組織加總了改善企業績效、質量和獲利能力的實現。

要點

架構戰略意圖如果超越業務需求并且沒有顯示早期的、有意義結果，這樣的戰略意圖就不能被維持。EA努力可能沒有考慮與被忽略的規則和標準相關的長期文化偏差