企业架构简介

5/5企业架构简介貴公司的資訊架構是「違章建築」嗎?

黃國熊前言

如果你在要買房子的時候，在詢問當中，建商告訴你說，我蓋房子的經驗有20年了，我蓋房子，從來沒有藍圖，都是直接蓋的，我想你的感想是趕快離開，然後心中想一定是碰到了一個瘋子。可是你可曾想過，貴公司內部的資訊系統，是否像蓋房子一樣，先由資訊架構師構想好了藍圖，然後按圖施工哪?當系統有發生問題時，可以像房子一樣，當管線出問題，可以找出建築藍圖，很快的找出問題，而不是依靠「經驗法則」來解決問題。

目前的資訊系統越來越複雜，從公司內部的資訊管理系統(MIS)，包括人事系統、會計系統、薪資系統、出勤系統等，與生管業務有關的MRP、MRP2，甚至範圍更大的ERP，和客戶關係相關的CRM，與上、下游相關的供應鏈(SCM)系統等。有的系統架構採用主從架構，有些系統是網站三層式架構，有些還是大型電腦系統，各個系統架構不同，開發的時間也不同，各系統之間的關連性如何?是否有重覆開發的相同功能等?把資訊部門的相關系統負責人員叫來詢問，可能他也不知道，因為他只清楚他自己負責的系統，而和其他系統的關連性，他就不知道了。更何況，資訊人員的異動是非常的頻繁，即使有文件交接，通常也不是最新的，常常需要到原始碼中查看，才能知道真正的功能。

公司整體的資訊系統的關連性來說明的東西就稱為企業架構(EnterpriseArchitecture)，就是公司內部關於資訊系統之各類「藍圖」的收集，包括了資料、商業流程、商業功能、網路架構、願景、甚至策略等關鍵性元素的描述，元素和元素之間的關係。就如同建築藍圖，並且記錄了現在、未來及移轉計畫，可以針對不同的需求者提供不同的觀點。所以不論你是公司內部的高層主管、經理人員、資訊人員或是一般的基層員工，都會對於公司資訊系統有不同的觀點和需求。

企業架構的趨勢

目前在大部分的組織裡，不論發展資訊系統或作研究，都會遵循特定的框架(framework)作為開發或研究之依據。就如微軟的.NET框架或JAVAJ2EE框架為目

前開發網站系統時普遍被採用之主要框架。根據InstituteForEnterpriseArchitectureDevelopments(IEAD)http：//http://./doc/d192e7030740be1e650e9a90.html中「TrendsinEnterpriseArchitecture2004：HowareOrganizationsProgressing?」所調查的部分

被調查組織特性中，以政府部門占大多數，其次是顧問業和金融業，也就是大型企業。

圖3：被評比組織之性質比例圖

發展企業架構，必然需要一個框架作為依據，但是每一種框架所強調的重點，都不相同，發展企業架構的企業會依據自己重視的部分，而採用一個框架。調查中發現企業在發展企業架構的企業時，所採用的企業框架中以自行量身訂做的框架為最多，除了非使用自己組織的框架外，則是以聯邦企業框架(FEAF)占最多。FEAF是美國聯邦政府自定的企業架構框架，採用的原因是美國政府法案中規定聯邦政府中各單位未來提報資訊預算時，必須採用FEAF，制定自己的企業架構，才會給予預算(此為舊的資料，目前又有一個新的框架FEA)。「老牌的」雷格曼框架(ZachmanFramework)占第二位，後面會做進一步介紹，而開放組織制定的TOGAF框架則居第三名。

圖4：企業架構框架使用比例圖

製作企業架構所需要的工具的調查中，微軟的Office系列(Word+Excel+PowerPoint+Visio)，占了七成，再其次的是Popkin’sSystemArchitect。並不是微軟的Office工具超強，而是目前也沒有特別的技術和規範，能夠整合存放企業架構的內容，企業架構的內容可能包含了文字、架構圖、網路圖、組織圖等沒有特定格式的內容。

圖5：企業框架工具使用比例圖

以雷格曼框架作為企業架構之說明

企業架構框架為企業架構的基礎，在此利用介紹企業框架來說明企業架構所存放的內涵。雷格曼框架是最早被提出的企業架構框架，發表於1986IBMSystemJournal，由JohnZachman所發表的”Aframeworkforinformationsystemsarchitecture.IBMSystemsJournal,Vol.26,No.3,1987.”，並於1992和J.F.Sowa發表“Extendingandformalizingforinformationsystemsarchitecture.IBMSystemsJournal,vol.31,no.3,1992.”，擴充1986年所發表的框架。雷格曼框架其實就是一個6x6矩陣，企業把公司內部的資訊系統資訊「填入」矩陣中，完成公司的企業架構，如下圖。

圖6：雷格曼框架

每一欄(column)所對應的是英文的5W1H(What，How，Where，Who，When，Why)，每一列(row)所對應的是範圍、業務模型、系統模型、技術模型、細部規格和運行系統；換句話說，整個矩陣之內容對應至企業的資訊系統，對於企業的中的每個人而言，對於資訊系統會有不同的需求和觀點，將參與的人分為五類(1)高階主管類，訂定企業的策略(規劃者：planner)，(2)企業內實際執行業務的人員(擁有者：owner)，(3)分析、設計系統邏輯的人員(設計者：Designer)，(4)運用資訊技術，系統設計人員(建立者：Builder)，(5)系統開發人員(開發者：Subcontractor)。每一類型的人所觀察的範圍，分別對應到每一列，簡略說明如下：

1.範圍(規劃者觀點)：定義企業的方向和業務目的，包括對系統開發邊界的定義。.

2.業務模型(擁有者觀點)：以企業術語定義業務內容，包括其結構、處理、組織等。

3.系統模型(設計者觀點)：以資訊術語更嚴格定義業務模型所描述之功能。

4.技術模型(建立者觀點)：以某種特定資訊技術描述前列的資訊流程，如程式規格、系統規格。

5.細部規格(開發者觀點)：以特定的語言、資料庫描述、網路圖等表示，如程式、資料庫規格等。

6.運行系統：在使用中的系統，如資料庫中的資料，使用中的資訊系統等。

矩陣的欄表示系統中不同的領域，簡略說明如下：

1.資料：對應該欄的每一列都是對用戶有重要意義的事務的理解和處理。

2.功能：企業為維繫生存而採取的行為。

3.網路：描述各種活動的地理分佈。

4.人員：描述在業務及新技術引進所涉及的人員或組織。

5.時間：描述時間因素對企業的影響。

6.動機：是企業目標和戰略到具體部門和手段的轉換，包括企業運營的整套業務規則限制。

更進一步的對框架中的每一個格子(cell)說明：

欄1：What或Data欄

列1：列出企業中重要目標或資產，並定義出列2-列5的範圍或界線。

列2：企業中實際事物(目標、資產)所構成的關聯模型，例如：語意模型(SemanticModel)。

列3：此為增添物件之屬性、鍵值及正規化的E/R技術所設計之邏輯性(與技術無關)資料模型，例如：邏輯資料模型(LogicalDataModel)。

列4：應用特定之資訊技術，利用列3邏輯性資料模型而產製之實體資料模型，例如：實體資料模型(PhysicalDataModel)。

列5：所有實體資料模型中資料物件定義，例如：資料定義。

列6：資料(資料檔、資料庫)。

欄2：How或Function欄

列1：列出企業所從事的程序(Process)清單，並定義出列2-列5的企業執行程序範圍。

列2：企業中實際的業務程序模型，例如：業務程序模型(TheBusinessProcessModel)。

列3：程序邏輯系統模型包含了支援業務程序設計和人機界面邊界定義，例如：應用架構(ApplicationArchitecture)。

列4：利用列3的邏輯系統模型，應用資訊技術，更深度進行系統設計，例如：系統設計(SystemDesign)。

列5：利用列4的規格，再詳細的進行程式設計，例如：程式(Programs)。

列6：可執行的程式。

欄3：Where或Network欄

列1：列出企業營運的位置。定義出和在列2-列5中企業相關位置模型的範圍或界限，例如：列出業務運作的位置。

列2：企業營運結點位置及營運結點之間的溝通模型，例如：業務運籌系統。列3：業務運籌系統之邏輯模型，例如：分散式系統架構。

列4：描述企業中實體的技術環境，包括了作業點和作業線的軟、硬體和系統軟體(作業系統和中介軟體)的設計，例如：技術架構。

列5：系統架構：硬體、軟體類別及結點地址的詳細定義，例如：網路架構。

列6：作業網路(通信設施)。

欄4：Who或People欄

列1：列出企業分配工作責任的組織清單。定義企業中需承擔責任的組織的範圍，在以下的列2-列5中會說明。

列2：實際企業責任分派和工作產品說明的模型，例如：工作流程模型(WorkFlowModel)。

列3：人員介面架構(角色、資料、權限、使用案例模型)，例如：人機介面架構。

列4：這是企業工作流程的實體展現，例如：展示架構。

列5：工作流程的非本文規格，包含個人存取系統的確認和工作授權規格，例如：安全架構。

列6：培訓後之人員。

欄5：WhenorTime欄

列1：列出企業驅動流程的事件清單。定義列2-列5中對企業值得注意的時間模型的範圍或邊界。

列2：業務循環模型包含了企業主要流程中起始事件和花費時間(週期)型，例如：主要的時程表。

列3：時間點(系統事件)和時間長度(程序週期)的邏輯系統規格，例如：程序結構。

列4：系統事件和實體程序循環的實體模型，例如：控制結構。

列5：定義出各作業時機，例如：作業定義。

列6：營運事件。

欄6：Why或動機(Motivation)欄

列1：列出企業中重要的主要業務目標或策略或關鍵成功因素。它定義了列2-列5中對企業目標模型的範圍或邊界。

列2：企業業務目標和策略模型。

列3：邏輯模型包含以目的、限制專有名詞描述的企業業務規則。

列4：設定業務規則規格。

列5：制定程式邏輯中規則規格。

列6：策略(強制性規則的程式碼)。

結語

由以上的說明，希望能夠對於企業架構可以有初步的概念。企業架構的內容並

不是建立後就不會變動的，因為企業中的資訊系統會變動，所以必須隨時維護企業架構，才可以保持最新的內容。

建立企業架構是需要相當成本，可是一旦建立了企業架構，可以獲到極大的益處，以下僅列出幾點：

對於資訊的預算可以達到較佳的控制

避免重覆的投資至相同資訊服務

改善計畫業務和資訊人員之間溝通方式

改善資料分享的分式

定義出標準的跨企業技術和資料

建立企業架構可以得到很大的益處，但是需要相當的成本。建立企業架構的構想，是值得CIO所考慮的。

參考文獻：

[1]“TrendsinEnterpriseArchitecture2004：HowareOrganizationsProgressing?”http：//http://./doc/d192e7030740be1e650e9a90.html

[2]JohnZachman.”Aframeworkforinformationsystemsarchitecture.IBMSystemsJournal,Vol.26,No.3,1987.”

[3]Sowa,J.F,and