規劃新的企業架構時必須考慮的要素

　每個組織都具有獨特的業務需求，因此在為公司規劃企業架構方法時，考慮到多種因素是非常重要的。本文將研究在規劃新的或修改後的企業架構時應該考慮的事項。

　　本系列將探索建立成功的企業架構所涉及到的若干事項。您將瞭解的內容包括如何：

　　·按原樣對體系結構作文件記錄

　　·開發中間和目標體系結構

　　·設計敏捷的企業架構

　　·處理系統拓撲和組織問題

　　·監視體系結構設計的有效性

　　本文為您提供在處理企業架構設計和實現時要考慮的新觀點，從而開始本系列。您將探索將業務與技術戰略保持一致的重要性、為什麼交流技能對於您的成功至關重要，以及如何在組織中將自己定位為受信任的顧問。您還將研究一些可在該過程中使用的有用工具和技術，以及該過程中的一些應該瞭解的里程碑。

　　技能和能力

　　在企業架構設計的規劃階段，對具體設計技能的強調比較少，更多的重點放在使用戰略性業務技能上。正如您將在本部分中看到的，要將企業架構恰當地與業務保持一致，所涉及的不僅是確保流程得到足夠的處理。

　　採用業務和技術戰略

　　當您檢視企業架構的定義時，可以看到它基本上就是將特定的方法應用於組織當前或將來的結構和行為。它明確地處理流程和資訊系統，雖然也可以包括其他事情。建立強大的企業架構的關鍵是要認識到：無論您做什麼，體系結構設計都必須與組織的戰略方向和主要目標保持一致。關於企業架構的有趣之處在於，雖然它顯然一定與組IT的資訊系統相關，但重點實際上更緊密地與業務優化技術相連。

　　這些技術通常涉及到將企業架構資訊科技(IT)設計視為重疊在業務戰略之上的技術戰略。例如，如果組織有一個涉及到縮短上市時間的業務戰略，則體系結構必須通過旨在簡化設計、製造和生產流程的技術戰略來支援該業務戰略。而且，由於組織中決不是僅存在單個 迫切的業務戰略，您必須概念化並建立開發和操作模型，這些模型不僅能夠響應業務需求，而且能夠預先為業務需求做好計劃。您的設計必須是能夠指導業務開發和決策制定的藍圖，並且要足夠敏捷以快速改變方向。

　　正如在“Let’s talk:Build your enterprise architecture using communication and the right framework”中所提到的，正確的框架對於促進企業架構的實現大有幫助，這樣的框架描述一個結構，複雜的物件關係可通過該結構相互作用，從而將人員、流程和技術聯絡起來。Open Group體系結構框架(Open Group Architecture Framework，TOGAF)或Zachman Institute for Framework Advancement(ZIFA)支援的Zachman企業架構框架(Zachman Enterprise Architecture Framework)都提供了一個矩陣，使您可以安排幫助將業務需求與IT服務保持一致的元件的相互關係。

　　這其中的所有技能當然在於您能夠從足夠廣的角度去思考，以包含組織的所有可能性。如果對此技能沒有信心，應與您的主管商量以觀察員身份出席更多的業務會議，以儘可能多地傾聽和觀察。如果無法實現這點，應該要求主管定期為您提供有關更高層正在討論的事情的資訊，以便您能開始自己彌補此空白。如果您是主管，應該讓員工儘可能多地瞭解潛在的公司方向。您不必洩露機密細節，但至少要提供有關您的未來展望的一般資訊。

　　交流

　　由於您參與檢視組織的總體流程和系統以確保一切都順利，您還將發現做出一個決策會導致需要做出更多決策。例如，如果更改影響到多個部門，則更改一個簡單程式碼段的後果會擴大。這就是您需要加強交流技能的時候，以根據需要扮演中間人，甚至在許多情況下故意唱反調。

　　保持頭腦冷靜並使人信服的訣竅是儘可能清楚地解釋您的業務 論證。在對非技術受眾講話時跳過高度技術性的解釋——技術細節只會使人們混淆和暈頭轉向。相反，應堅持使用業務語言，這樣您會發現自己的想法和顧慮更容易得到接受。

　　例如，如果您知道某個來自市場部門的軟體變更請求會使銷售部門使用的某部分軟體過時，您需要以簡單的術語解釋這種情況。不要嘗試描述該軟體變更會明確地做什麼，只需使用類似如下的說明：“更改此軟體將導致銷售開支上升。但是，如果我們不更改它，市場部門將繼續遇到工作效率問題，從而最終導致的成本超過銷售部門所增加成本的兩倍。”

　　用簡單但直接的術語進行交流有兩個好處：

·它幫助您的受眾快速瞭解問題。

　　·它幫助您快速解決問題。

　　向所有人說明涉及到的細節可能非常有誘惑力。但是如果您用技術性的解釋使受眾迷惑，則您永遠得不到希望達到的目的：完成設計的解決辦法。

　　觀察和分析

　　談到交流，您通常是應邀解決問題，對吧?當然，您越能以他們的業務語言而不是IT行話與其他人交流，他們就越有可能讓您參與規劃階段的討論。這使您成為一個受信任的顧問，能夠在業務戰略和決策出現時對其進行觀察和分析。此觀察和分析階段對於幫助簡化您的工作非常關鍵。

　　這是因為，在通常瞭解某個提議的更改的幾個月之前，您可能就已經確切瞭解企業正在考慮什麼。您將能更清楚地瞭解整個組織中的資源問題、任何更改將具有的影響，甚至是應該在部署之前執行什麼型別的測試用例。您將瞭解所有一切，因為您是決策者之一!

　　如果未邀請您加入規劃討論，應該接觸當前決策者並詢問其領域中正在發生的事情。提議出席他們的下一次會議，然後在您出席會議時只需觀察即可。在未經要求的情況下，開始分析人們在周圍閒聊的一些概念。要求出席另一次會議，然後在任何適當的場合順理成章地將您的分析插入當前計劃。正如前面提到過的，其基本思想是成為同盟者或受信任的顧問。當人們開始認識到您正在盡力幫助而不是妨礙他們的計劃時，他們將更樂意接受您的思想和建議。

　　工具和技術

　　當您嘗試用體系結構來為將來做規劃時，有時您所能擁有的最關鍵工具是對過去的充分了解。瞭解組織在繁榮和蕭條時期的思考、行動和反應方式可幫助您確定如何完成您的設計。

　　瞭解組織

　　有一項技術是任何企業架構師都應該攻克的，該技術聽起來非常簡單，但實際上相當複雜：瞭解組織。這並不意味著瞭解公司所在的行業或充分了解組織是如何運作的。其含義遠不止如此。

　　瞭解組織意味著瞭解其文化、價值、規範和原則。例如，您的組織是否每年都要慶祝創辦者紀念日(Founder’s Day)?如果是，則執行相關研究，以瞭解是誰創辦了公司、他或她的理想和目標是什麼，以及那些理想和目標是如何一年又一年地堅持下來的。也許您的公司最近被來自另一個國家的公司收購了。您是否瞭解該國家的商業習慣?例如，中國與美國的商業習慣差別非常大;在中國文化中，不同意見通常以非口頭語言來表達，而在美國，不同意見則是以口頭語言的方式表達的。

　　這些型別的文化問題為您提供了微妙——有時不是那麼微妙——的線索，讓您瞭解組織最看重的價值(誠實?利潤?榮譽?)以及那些價值如何影響業務環境。瞭解該資訊可以讓您在建立或更新企業架構時掌握主導地位。您可以更好地瞭解哪些更改會很快得到接受，以及哪些更改需要努力爭取。

　　您還能更好地瞭解參與者的關注事項。例如，如果您知道企業架構中的參與者最關心維持傳統業務方法而不是嘗試新方法，您就不會浪費時間去提出最終可能改變傳統業務方法的創新方法。

　　如果您還沒有對這種事情賦予多少注意力，快速趕上去也不是那麼困難。嘗試聯絡組織的交流或公關部門，並請求有關公司歷史記錄的文件。或者在下一次辦公桌上收到公司新聞稿時閱讀該新聞稿。雖然某些資訊可能讓您產生平淡無奇甚至無聊的感覺，但那些出版物始終包括相關事件和傳統。向長期員工詢問他們多年所見的更改或缺乏的更改情況。在會議期間聚精會神。主管們是否公開互相反對，或者爭論是否不太明顯?您的公司在使用什麼型別的管理風格?開放策略體現了集思廣益的意願。缺乏此類政策表明公司領導更喜歡堅持採用層次結構方法來完成工作。

　　正確的方法

　　在思考和規劃是以自頂向下的方法來實施的專案中，您參與了多少個專案?在此類方法中，最高管理層決定需要做出某個更改，較低管理層表示同意，然後組織中較低地位的人員根據需要參與進來實施更改。這就是大多數更改的實施方式。但有時可能恰好相反：組織中某個較低地位的人請求某個更改，在發生任何事情之前，該請求通過各級管理層一路上報到最高管理層。這兩種場景中通常缺失的是水平方法。

　　水平地思考意味著組織的不同級別可以合作決定需要做出什麼更改。更改的廣度及其對組織的影響得到最優先的考慮，而更改的深度則通常集中於垂直的自頂向下或自底向上的方法。還記得前面對有關了解組織的評論嗎?如果您已經完成了準備工作，則會了解公司是否偏向於使用一種方法而不使用另一種方法。

　　大多數情況下的最佳方法是同時垂直和水平地思考。雖然用您的設計來深入挖掘組織可以促進創新，但是要確保組織中所有受影響的人都能接受該設計。不存在完成設計的正確或錯誤方法，但是最好執行一些有關水平和垂直方法概念的研究，以確定哪一種方法更適合您，或者是否應該同時使用兩種方法。

　同樣，瞭解組織對此項技術也會發揮作用。當您從整個組織中獲得的反饋表明您的計劃似乎不錯時，您知道自己已經找到了正確的方法。在設計的這個部分，不要害怕與儘可能多的人交談。您從越多的人那裡探出反饋，您就越有機會為組織找到正確的方法。

　　里程碑

　　在深入研究除設計和IT以外的企業架構元素時，里程碑有一點含混不清。它們不一定是可測量的里程碑，因此在研究我這裡列出的里程碑時，您需要有一點創造性和周密的思維。

　　實現更改

　　對於任何企業架構設計，都存在影響業務員工的更改。因此，與公司的交流團隊合作是非常關鍵的，以確保更改不僅得到理解，而且還在整個組織中得到採用。更改不是在單個步驟中實現的。它是在三個關鍵步驟中實現的：

　　·準備

　　·接受

　　·交付

　　這些步驟通常通過持續的交流進行處理，其中一個關鍵訊息堆疊在另一個關鍵訊息之上。

　　讓我們面對它：您和其他人工作數月以確保您建立的設計無縫地部署到組織中。但是除部署團隊以外的其他每個人完全不清楚即將發生的更改。他們處於所謂的無意識階段。甚至在您開始考慮部署廣泛影響組織的新軟體或硬體之前，您就需要通過交流有關該更改及其為什麼有必要的資訊，從而讓組織做好準備。受影響的人需要知道會發生什麼結果以及何時發生。

　　當組織為即將到來的更改做好充分的準備時，您可以推進到實現更改的下一階段：幫助人們接受更改。他們知道更改並不意味著他們將會喜歡更改。接受階段旨在幫助構建公司方向的積極意識。只有在此階段之後，人們才會接受或支援該更改並開始採用它。

　　您在實現更改的過程中的角色非常關鍵。沒有您的知識和輸入，交流團隊甚至無法開始與員工交流正確的資訊。沒有正確的資訊，員工就不會接受所發生的更改。而且如果員工不採用您做的更改，您就已經遭遇了潛在的失敗。

　　IBM Rational 產品套件擁有各種可幫助您實現組織更改的工具。developerWorks文章“Organizational change in the Internet age”提供了有關此主題的很好見解。

　　實現價值

　　此里程碑涉及到一點自省。儘管最明顯的地方是在部署之後，但可以在該過程中的任何位置使用此里程碑。問自己以下問題：

　　·此計劃是否真正實現了我預期的業務價值?

　　·人們是否真正更有效地工作?

　　·企業是否獲得了實現競爭力所需要的資訊?

　　價值是一個模糊不清的術語。它通常基於人們的感知。人們是否認為 他們正在從您的設計中獲得預期的東西?如果是，則該設計可能至少實現了您預期的大部分價值。不過您需要執行一些調查來確定。不要依賴幫助您實現該設計的人們。他們 很可能認為該設計有價值!相反，應該利用交流團隊來執行一些調查，或者自己對員工或一線管理人員執行一些隨機的電話調查。

　　他們是真正能夠告訴您該設計是否為他們實現了任何價值的人。如果他們的工作更容易，如果工作效率更高，如果停機時間縮短，則您就獲得了有關該設計價值的有力保證。但是如果您聽到不是那麼滿意的報告，請不要驚慌。使用那些報告作為學習到的教訓，並將它們用作即將到來的升級的基礎。記住，使用者起初通常不情願採用新工具。如果您在使用者響應中聽到大量有關該技術的恐懼，可直接與教育和交流團隊合作確定下次可做什麼不同的工作，以在下一次設計部署之前通過培訓和針對性資訊來減輕那些恐懼。

　　總結

　　本文為您提供了一些要在處理企業架構設計和實現時考慮的新觀點。您的組織具有獨特的業務需求，因此務必要確認這其中哪些觀點對您有價值，哪些觀點對您沒有價值。一般情況下，這裡列出的觀點幾乎在任何場合下都有效。決定因素在於您以新的態度來處理企業架構的意願。請繼續關注本系列中的下一部分，其中將討論當前(或按原樣)的體系結構文件記錄。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-414874/，如需轉載，請註明出處，否則將追究法律責任。