企業架構分析

在資訊管理議題中，對於應用系統開發，常有所謂使用者未能適應系統，或者系統設計人員常被抱怨並不了解使用者需求等等問題，造成應用系統推遲上線時程。推究主因，還是在系統設計之初，使用者與設計者缺乏企業架構分析方法訓練所致。



何謂企業架構分析方法呢?

• 要界定應用系統結構元素〈Structural Elements〉
  
  
  
  • 結構元素通常是企業有交互作用的組織，包括價值鏈合作夥伴，甚至可以是競爭對手，端視應用系統要解決的問題層，或是服務層。
  
  
  • 結構元素也可以是企業活動文件〈Activity Documents〉，通常是表單或結報，這是從文件管理〈Content Management〉來分析企業觀點。
  
  
  • 結構元素具備有特質屬性〈Atrributes〉，其屬性為應用系統所關注的資訊〈Information〉，通常是應用系統該結構元素施作其行為時所需要或者所提供的欄位。
  
  
  • 結構元素屬性具備方向性，表明該屬性對結構元素，或其施作行為而言，是提供者〈Publisher/Write〉、是消費者〈Subcriber/Read〉，或者是兩者。
  
  
  • 結構元素屬性具備時間性，表明該屬性對結構元素，或其施作行為而言，在某時間限定內屬性方為有效。
  
  
  • 基於企業多樣活動，一群結構元素集合，組成不同活動領域〈Domain〉，所有領域的聯集就是企業活動總領域，通常應用結構層次圖表明企業不同領域之活動。
  
  
  • 一個結構元素通常都肩任多個活動領域角色，提供或者接收著不同服務。
  
  
  • 結構元素與其它結構元素之間， 可以用結構元素連結圖表明以此關係。
  
  
  
  


• 要界定應用系統結構元素行為〈Element Behaviors〉
  
  
  
  • 結構元素行為是結構元素對其他結構元素所提出之服務。
  
  
  • 結構元素所提出之服務行為，可以用結構元素服務圖表明行為細節。
  
  
  • 結構元素行為依該行為所需之屬性施作，其產出為另一個接收服務結構元素之屬性。
  
  
  • 結構元素行為是真正施作具體演算處理者。
  
  
  • 結構元素行為是有粒度區別的，通常是開發應用系統的目的所決定，且開發目的左右著預算，使用者不應期待會有一個與預算不相稱應用系統的誕生，更遑論通常預算都是被低估的。
  
  
  • 有時在不同系統應用中，提供服務與接收服務者是同一個結構元素，藉由與前次屬性值比較，若符合繼續施作條件，則當作是下一次行為之輸入，遞迴至臨界條件才逸出〈Back-Propogation〉。
  
  
  • 依據企業活動，將一系列結構元素行為相鏈結，就是商業流程。
  
  
  • 應用結構元素行為圖表明結構元素與交互行為細節。
  
  
  
  


• 要結構與行為合一，使結構元素與行為合當，當行為所需之屬性結構元素並不能完全提供，或施作行為所需之資源結構元素並不能負荷，當然也就無法滿足企業活動。

為了尋找並界定結構元素與其行為，必須要有一套系統科學方法，Zachman 架構框架〈Zachman Architecture Framework〉常被應用為企業架構分析方法，在不同企業面向中界定結構元素與結構行為。Zachman 架構框架採用 X-Y 軸分別為萃取層與面向層之 2 維分析表〈範例如下〉來協助架構分析：

• X 軸〈萃取〉：
  
  
  
  • 資料〈What/Data〉
  
  
  • 功能〈How/Function〉
  
  
  • 網路〈Where/Network〉
  
  
  • 組織〈Who/People〉
  
  
  • 時間〈When/Time〉
  
  
  • 動機〈Why/Motivation〉
  
  
  
  


• Y軸〈面向〉：
  
  
  
  • 範圍〈Scope/Contectual〉
  
  
  • 企業模型〈Enterprise Model/Conceptual〉
  
  
  • 系統模型〈System Model/Logic〉
  
  
  • 技術模型〈Technology Model/Physical〉
  
  
  • 其它模型〈Detailed Representations/Out of Context〉
  
  
  
  

每張 Zachman 框架分析表可以是應用系統所關注的功能，是企業總體活動的一個圖層，特別是自身系統功能與外部關聯的人事時地物間的關係。而面向層可以依系統粒度及需求而擴充，在 Z(x, y) 中則記錄著該面向中所要萃取資訊。Zachman 架構框架僅能表明面向與事務為何，但不能清楚指出具體架構元素與其行為，也不易表明結構元素行為施作所需屬性與產出，同時企業活動之間關聯也無從自分析表中獲得。然而 Zachman 框架分析表對於如何理解企業活動與應用系統開發目的仍有貢獻，進而點出系統範圍內有那些結構元素與行為，系統發展完成後再回頭檢視是否與當初規畫抵觸及預定達成之效果。

沒有實施架構分析，僅藉由傳統系統分析機制，使用者常因為較晚參與應用系統開發前規劃，往往不明瞭系統開發之目的。而開發者也常無法針對系統開發目的有所堅持，於是造成外行領導內行，導致專案走向失敗一途。探究根本原因是沒有清楚界定該系統性質是管理性質或是事務性質。

管理性質是指系統開發是為了降低成本、精準管控、服務客戶等目的，那麼系統設計是從整體營運績效為觀點，使用者只是扮演著資料收集與企業活動觸發者，因此使用者在此種系統開發中為弱性角色，管理目的才是系統開發強性角色。



事務性質是指系統開發是為了改善製程、提升作業效率等目的，那麼系統設計是從使用者工作習性為依歸，使用者扮演著所有作業程序流暢性改良者，因此使用者在此種系統開發中為強性角色，管理目的反而是系統開發弱性角色。



正因為總想畢其工於一役，系統設計在管理與事務性質間掙扎形成設計衝突，造成開發者在使用與管理者之間兩面不討好而進退失據，當然系統無法上線而導致失敗。同時使用與管理者力求完美，通常沒有管理成本觀念；沒有一個應用系統會是 100% 完美的，因為企業競爭環境在變，經營手段在變。一個只提升 30% 管理效益的系統能早一年上線，企業就能早一年減少30%管理成本，當績效提升後，整個管理視野也相對提高，許多原來斤斤計較造成專案延遲所執著的系統功能也跟著改變，應用系統亦如人一般，需要時間演化，受外在因素變化而變化。