貴公司的資訊架構是「違章建築」嗎?
黃國熊
前言
如果你在要買房子的時候，在詢問當中，建商告訴你說，我蓋房子的經驗有20年了，我蓋房子，從來沒有藍圖，都是直接蓋的，我想你的感想是趕快離開，然後心中想一定是碰到了一個瘋子。可是你可曾想過，貴公司內部的資訊系統，是否像蓋房子一樣，先由資訊架構師構想好了藍圖，然後按圖施工哪?當系統有發生問題時，可以像房子一樣，當管線出問題，可以找出建築藍圖，很快的找出問題，而不是依靠「經驗法則」來解決問題。
目前的資訊系統越來越複雜，從公司內部的資訊管理系統(MIS)，包括人事系統、會計系統、薪資系統、出勤系統等，與生管業務有關的MRP、MRP2，甚至範圍更大的ERP，和客戶關係相關的CRM，與上、下游相關的供應鏈(SCM)系統等。有的系統架構採用主從架構，有些系統是網站三層式架構，有些還是大型電腦系統，各個系統架構不同，開發的時間也不同，各系統之間的關連性如何?是否有重覆開發的相同功能等?把資訊部門的相關系統負責人員叫來詢問，可能他也不知道，因為他只清楚他自己負責的系統，而和其他系統的關連性，他就不知道了。更何況，資訊人員的異動是非常的頻繁，即使有文件交接，通常也不是最新的，常常需要到原始碼中查看，才能知道真正的功能。
公司整體的資訊系統的關連性來說明的東西就稱為企業架構(Enterprise Architecture)，就是公司內部關於資訊系統之各類「藍圖」的收集，包括了資料、商業流
1
程、商業功能、網路架構、願景、甚至策略等關鍵性元素的描述，元素和元素之間的關係。就如同建築藍圖，並且記錄了現在、未來及移轉計畫，可以針對不同的需求者提供不同的觀點。所以不論你是公司內部的高層主管、經理人員、資訊人員或是一般的基層員工，都會對於公司資訊系統有不同的觀點和需求。
企業架構的趨勢
目前在大部分的組織裡，不論發展資訊系統或作研究，都會遵循特定的框架(framework)作為開發或研究之依據。就如微軟的.NET 框架或 JAVA J2EE框架為目前開發網站系統時普遍被採用之主要框架。根據Institute For Enterprise Architecture Developments (IEAD) http：//www.enterprise-architecture.info 中「Trends in Enterprise Architecture 2004： How are Organizations Progressing?」所調查的部分摘要，首先是對各國在電子化上程度上作評比及運用EA程度的評比，第一名是美國。台灣在電子化的評比是名列前茅，可是台灣目前不是聯合國的會員，所以不會列入評比。下圖是聯合國2003年各國電子化的評比和IEAD對於各國運用EA 的評比。
2
圖1：電子企業架構活動評比
電子化程度比較深的國家對於EA的運用比較重視。在接受訪查的組織中，若以地理區域別來分，還是以歐美地區對於EA規劃較重視，如下圖：
圖2：被評比組織之地理分佈比例圖
3
被調查組織特性中，以部門占大多數，其次是顧問業和金融業，也就是大型企業。
圖3：被評比組織之性質比例圖
發展企業架構，必然需要一個框架作為依據，但是每一種框架所強調的重點，都不相同，發展企業架構的企業會依據自己重視的部分，而採用一個框架。調查中發現企業在發展企業架構的企業時，所採用的企業框架中以自行量身訂做的框架為最多，除了非使用自己組織的框架外，則是以聯邦企業框架(FEAF)占最多。FEAF是美國聯邦自定的企業架構框架，採用的原因是美國法案中規定聯邦中各單位未來提報資訊預算時，必須採用FEAF，制定自己的企業架構，才會給予預算(此為舊的資料，目前又有一個新的框架FEA)。「老牌的」雷格曼框架(Zachman Framework)占第二位，後面會做進一步介紹，而開放組織制定的TOGAF框架則居第三名。
4
圖4：企業架構框架使用比例圖
製作企業架構所需要的工具的調查中，微軟的Office 系列(Word + Excel + Power Point + Visio)，占了七成，再其次的是Popkin’s System Architect。並不是微軟的Office 工具超強，而是目前也沒有特別的技術和規範，能夠整合存放企業架構的內容，企業架構的內容可能包含了文字、架構圖、網路圖、組織圖等沒有特定格式的內容。
5
圖5：企業框架工具使用比例圖
以雷格曼框架作為企業架構之說明
企業架構框架為企業架構的基礎，在此利用介紹企業框架來說明企業架構所存放的內涵。雷格曼框架是最早被提出的企業架構框架，發表於1986 IBM System Journal，由John Zachman 所發表的 ”A framework for information systems architecture. IBM Systems Journal, Vol. 26, No. 3, 1987.”，並於1992 和 J. F. Sowa 發表 “Extending and formalizing for information systems architecture. IBM Systems Journal, vol. 31, no. 3, 1992.”，擴充1986 年所發表的框架。雷格曼框架其實就是一個6x6 矩陣，企業把公司內部的資訊系統資訊「填入」矩陣中，完成公司的企業架構，如下圖。
6
圖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.運行系統：在使用中的系統，如資料庫中的資料，使用中的資訊系統等。
7
矩陣的欄表示系統中不同的領域，簡略說明如下：
1. 資料：對應該欄的每一列都是對用戶有重要意義的事務的理解和處理。
2. 功能：企業為維繫生存而採取的行為。
3. 網路：描述各種活動的地理分佈。
4. 人員：描述在業務及新技術引進所涉及的人員或組織。
5. 時間：描述時間因素對企業的影響。
6. 動機：是企業目標和戰略到具體部門和手段的轉換，包括企業運營的整套業務規則。
更進一步的對框架中的每一個格子(cell)說明：
欄1：What或 Data 欄
列1：列出企業中重要目標或資產，並定義出列2-列5的範圍或界線。
列2：企業中實際事物(目標、資產)所構成的關聯模型，例如：語意模型(Semantic Model)。
8
列3：此為增添物件之屬性、鍵值及正規化的E/R技術所設計之邏輯性(與技術無關)資料模型，例如：邏輯資料模型(Logical Data Model)。
列4：應用特定之資訊技術，利用列3邏輯性資料模型而產製之實體資料模型，例如：實體資料模型( Physical Data Model)。
列5：所有實體資料模型中資料物件定義，例如：資料定義 。
列6：資料(資料檔、資料庫)。
欄2：How 或 Function 欄
列1：列出企業所從事的程序(Process)清單，並定義出列2-列5的企業執行程序範圍。
列2：企業中實際的業務程序模型，例如：業務程序模型(The Business Process Model)。
列3：程序邏輯系統模型包含了支援業務程序設計和人機界面邊界定義，例如：應用架構(Application Architecture)。
列4：利用列3的邏輯系統模型，應用資訊技術，更深度進行系統設計，例如：系統設計(System Design)。
列5：利用列4 的規格，再詳細的進行程式設計，例如：程式(Programs)。
9
列6：可執行的程式。
欄 3： Where 或 Network 欄
列1：列出企業營運的位置。定義出和在列2-列5中企業相關位置模型的範圍或界限，例如：列出業務運作的位置 。
列2：企業營運結點位置及營運結點之間的溝通模型，例如：業務運籌系統。
列3：業務運籌系統之邏輯模型，例如：分散式系統架構。
列4：描述企業中實體的技術環境，包括了作業點和作業線的軟、硬體和系統軟體(作業系統和中介軟體)的設計，例如：技術架構。
列5：系統架構：硬體、軟體類別及結點地址的詳細定義，例如：網路架構。
列6：作業網路(通信設施)。
欄4： Who 或 People 欄
列1：列出企業分配工作責任的組織清單。定義企業中需承擔責任的組織的範圍，在以下的列2-列5中會說明。
列2：實際企業責任分派和工作產品說明的模型，例如：工作流程模型( Work Flow
10
Model)。
列3：人員介面架構(角色、資料、權限、使用案例模型)，例如：人機介面架構。
列4：這是企業工作流程的實體展現，例如：展示架構。
列 5：工作流程的非本文規格，包含個人存取系統的確認和工作授權規格，例如：安全架構。
列6：培訓後之人員。
欄 5：When or Time 欄
列1：列出企業驅動流程的事件清單。定義列2-列5中對企業值得注意的時間模型的範圍或邊界。
列2：業務循環模型包含了企業主要流程中起始事件和花費時間(週期)型，例如：主要的時程表。
列3：時間點(系統事件)和時間長度(程序週期)的邏輯系統規格，例如：程序結構。
列4：系統事件和實體程序循環的實體模型，例如：控制結構。
列5：定義出各作業時機，例如：作業定義。
11
列6：營運事件。
欄 6：Why或動機(Motivation) 欄
列1：列出企業中重要的主要業務目標或策略或關鍵成功因素。它定義了列2-列5中對企業目標模型的範圍或邊界。
列2：企業業務目標和策略模型。
列3：邏輯模型包含以目的、專有名詞描述的企業業務規則。
列4：設定業務規則規格。
列5：制定程式邏輯中規則規格。
列6：策略(強制性規則的程式碼)。
結語
由以上的說明，希望能夠對於企業架構可以有初步的概念。企業架構的內容並不是建立後就不會變動的，因為企業中的資訊系統會變動，所以必須隨時維護企業架構，才可以保持最新的內容。
建立企業架構是需要相當成本，可是一旦建立了企業架構，可以獲到極大的益處，以
12
下僅列出幾點：
➢ 對於資訊的預算可以達到較佳的控制
➢ 避免重覆的投資至相同資訊服務
➢ 改善計畫業務和資訊人員之間溝通方式
➢ 改善資料分享的分式
➢ 定義出標準的跨企業技術和資料
建立企業架構可以得到很大的益處，但是需要相當的成本。建立企業架構的構想，是值得CIO所考慮的。
參考文獻：
[1] “Trends in Enterprise Architecture 2004： How are Organizations Progressing?” http：//www.enterprise-architecture.info
[2] John Zachman. ”A framework for information systems architecture. IBM Systems Journal, Vol. 26, No. 3, 1987.”
[3] Sowa, J.F, and John Zachman. “Extending and Formalizing the Framework
13
for Information System Architecture,” IBM System Journal, 31:3. IBM Publication G321-5488. 1992
[4] “Enterprise Architecture : Zachman Framework ”
http://www.zifa.com/framework.html
14
