1.關於企業架構

        根據開放群組的業務領導層IT架構指引：“有效的企業架構（Enterprise Architecture，EA）對企業的生存和成功具有決定性的作用，是企業通過IT獲得競爭優勢的不可缺少的手段。”

        企業架構如同戰略規劃，可以輔助企業完成業務及IT戰略規劃。在業務戰略方面，可使用TOGAF及其架構開發方法（Architecture Development Method，ADM）來定義企業的願景/使命、目標/目的/驅動力、組織架構、職能和角色。在IT戰略方面，TOGAF及ADM詳細描述瞭如何定義業務架構、資料架構、應用架構和技術架構，是IT戰略規劃的最佳實踐的指引。企業架構是承接企業業務戰略與IT戰略之間的橋樑與標準介面，是企業資訊化規劃的核心。

        TOGAF架構開發方法ADM是一個可靠的、行之有效的方法，以發展能夠滿足企業商務需求的企業架構。

        （1）預備階段

        這一階段關注的是滿足新企業架構的業務指導所需的準備和初始活動，在此階段，應當採納面向服務的原則。這將幫助本階段兩項額外的輸出——治理和支援策略，以及初始架構庫進行相互的調整適應。

        （2）架構願景

        本階段關注於願景、範圍、業務驅動力以及準備情況評估。需要在這個階段定義架構專案的規模，風險承擔者以及架構檢視。

        （3）業務架構

        這個階段關注於業務架構方面的事情，如人員、流程和職能。需要在這一階段開發出一個基準和目標業務架構，並進行支援已有架構檢視的缺口分析。

        （4）資訊系統架構

        這一階段解決的是應用和資料架構問題。需要開發基準和資訊系統架構，進行支援已有架構檢視的缺口分析，架構資訊系統服務，並將它們與業務服務相關聯。

        （5）技術架構

        本階段定義架構所需的軟硬體基礎設施。在定義技術時，應當使用SOA參考模型。

        （6）機會及解決方案

        本階段關注於初級實施規劃，然後確認前面階段所定義的架構的交付工具。對解決方案組合、整合以及管理，以及內部或外部服務供應商的確認在本階段完成。

        （7）遷移規劃

        本階段的關注點是利用一個支撐性的先前階段確認計劃搭建一套細化的系列過渡架構，和專案實現團隊一同建立可行的實施和遷移。

        （8）實施治理

        本階段關注實施的架構性監管。架構實施應當堅持按照先前階段所定義的TOGAF和SOA治理及策略模型進行。

        （9）架構變更管理

        本階段關注新架構的變更管理，並幫助考慮採納物件導向的原則。架構變更管理的目標是要確保架構能夠實現其原有的目標業務值。這一目標包括以緊湊的架構方式管理架構變化。

        （10）需求管理

        處理所有型別的需求，包括顯著的業務推動者、關係，及新的功能和變更請求。

        參照此ADM模型，完成及預計完成工作內容如下表所示：

      不僅僅建立、維護企業架構是個複雜的問題，對於企業架構的使用也是一個非常繁瑣的事情。即便我們已經建立了一個全面的企業架構，並在之後的維護中保持了良好的一致性，但是面對這樣一個包羅永珍的企業架構，每個干係人又如何獲得其想要的資訊呢？舉例來說，企業的總經理需要的是組織中各個領域的概括，但並不關注於每個領域的細節，而對於基層的設計師來講，其所關注的卻是某個領域的細節。從目標和詳細度這兩個維度來看，沒有干係人會關注所有領域的所有細節，每個干係人關心的只是和自己的利益相關的企業架構的一個側面。因而如何從一個面面俱到的企業架構模型（描述）中根據干係人的關注點來獲取相應的側面資訊也是一個亟需解決的重要問題。

      綜上所述，不論是建立、維護企業架構，還是對其進行使用，都需要面對一個架構內容一致性的問題。之所以會有這個問題，究其根本是因為企業架構本身是對企業這一包羅永珍的客觀事物的抽象和描述，而對其進行建立、維護和使用的干係人由於其本身的背景、利益不同，他們對企業架構描述的操作也只能著眼於某一個側面。由此可見，企業架構描述與干係人的建立、維護和使用操作之間需要一個“介面”，用來規範干係人對於企業架構描述的各種操作，從而保證針對企業架構描述的修改和資訊共享的一致性。

2.視角

    此“介面”就是前面提到過的檢視（View）和視角（Viewpoint）。其中，檢視通常被定義為面向各干係人關注點的企業架構描述的一個部分，而視角則是對檢視內容的抽象和描述，他定義了檢視中所使用的概念元素、分析方法和展示方式。一言以蔽之，檢視定義了所看到的內容，而視角則定義了所採用的觀察角度。

3.技術視角

        去年，我在做辦公系統升級改造規劃的時候，更多的考慮是系統平臺升級到雲端計算PaaS平臺，並解決一些問題及優化業務。例如《雲端計算統一辦公運營平臺服務能力設計方案》所描述的方案。其中，對流程全生命週期管理（注：這裡流程是指廣義上的業務，辦公管理支撐範圍的業務，多以走流程形式體現，因此文中命名為業務。）的理解如下面“管理業務資訊”用例圖（圖1）所示。

                                                    圖1

        按圖1中所示，此用例是以辦公能力基礎平臺為視角進行設計的。例如：

        平臺提供快速流程開發服務，相應的需要管理其開發成果，對開發出來的工作流進行版本管理，並管理工作流使用到那些業務中及工作流所繫結的表單，並以此支撐業務全生命週期管理；

        平臺提供快速開發表單服務，相應的需要管理其開發成果，對開發出來的表單進行版本管理，並管理表單使用到那些業務中，並以此支撐業務全生命週期管理。

        以表單為例，模擬操作步驟可以描述如下：

        （1）開發或變更表單；

        （2）管理表單版本，用以支撐表單所承載業務資料的歷史資料可追溯，以及表單自身變更歷史版本（《include》表示包括，是組成不可分割的一部分）；

        （3）為業務提供表單資訊，一般情況下是最新版本表單資訊；

        （4）管理業務資訊繫結表單資訊；

        （5）管理業務資訊衍生出業務版本資訊。

        因此，軟體功能方面必須包括：表單版本管理、工作流版本管理、業務資訊版本功能。沒有這些功能就無法實現業務全生命週期管理。

        在專案實施過程中，初期我更多的是關注管理和需求，為專案組提供業務建模指導，例如《易擴充套件的辦公流程化管理核心模型（第2版）》所描述的業務核心模型，文中，分析出本專案的核心業務模型為：審批流+文件=業務流程，也就是圍繞這三點進行需求分析和設計。

        核心業務模型中，審批流就是指工作流，文件就是指表單，業務流程就是指業務。

        從上文寫的順序分析，仍是以辦公能力基礎平臺為視角，也就是說以技術視角在進行分析、設計。

4、業務視角

        但是，在專案實施過程中，由於人力的短缺，我必須投入大量的精力參與設計工作，我的分工是主持業務全生命週期管理部分，以及業務的監控和分析。接下來，我的視角自然而然發生了轉變，聚焦到業務資訊及其全生命週期管理，經過分析，設計出的用例圖如下圖2所示。

                                                           圖2

        如上圖2所示，此用例圖從管理業務的視角進行設計，雖然表面上差別不大，但卻是“差之千里”。

        仍以表單為例，模擬操作步驟可以描述如下：

        （1）變更業務就是新建業務，通過辦公能力平臺開發或變更表單；

        （2）管理表單資訊，把新表單繫結到業務資訊上，其中，管理表單資訊只管理從辦公能力平臺上開發出來的表單資訊（《extend》表示擴充套件，是開發表單服務擴充套件衍生出的一部分，為業務資訊提供關聯）；

        （3）管理業務資訊繫結表單資訊；

        （4）管理業務資訊繫結工作流資訊，由快速流程開發服務提供新複製出的工作流資訊；

        （5）管理業務資訊衍生出業務版本資訊，歷史業務版本追溯業務歷史資料。

        通過用例圖的對比，實際上，就是視角的轉變：

        按業務視角，表單、流程二者或任一變化，就是業務變化，只記錄業務變化版本；

        而以技術視角，表單、流程分別管理版本變化，同時，按業務要求，也要管理業務的版本變化，如此管理將是非常複雜的工作，目前來看也是沒有必要的。

這樣，在資料庫設計和功能設計上將有天壤之別。如下圖3所示，按業務視角設計出業務變更過程的時序圖。

                                                                      圖3

        如上圖圖3所示，從核心業務角度來看，根本不需要表單版本管理、工作流版本管理功能。

        按業務視角，對應資料庫設計，複雜度將降低很多，不需要表單版本管理表、工作流版本管理表，以及相關的關聯表。

5、資料邏輯模型

                                                                                                                                              圖4

        按全省週期管理模型建模如上圖所示，此種模型類似於傳統簡化營業業務資料模型。

        業務資訊實體（假設為資料庫表）通過其中“原業務資訊記錄號”與“業務資訊記錄號”自關聯，以此追朔變更歷史；通過與流程/資訊執行例項與流程平臺對接，形成閉環並且全生命週期管理。

        由於筆者水平有限，歡迎討論、反饋。

        參考：

        企業架構 － 開篇：TOGAF介紹 周金根 2013.11

        企業架構研究總結（44）——企業架構與建模之Archimate檢視和視角  鬧市閒雲 2013.10

        百度百科.企業架構

        易擴充套件的辦公流程化管理核心模型（第2版）肖永威 2015.3