企業架構分析

2009-01-01

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

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

  • 要界定應用系統結構元素〈Structural Elements〉
    • 結構元素通常是企業有交互作用的組織,包括價值鏈合作夥伴,甚至可以是競爭對手,端視應用系統要解決的問題層,或是服務層。
    • 結構元素也可以是企業活動文件〈Activity Documents〉,通常是表單或結報,這是從文件管理〈Content Management〉來分析企業觀點。
    • 結構元素具備有特質屬性〈Attributes〉,其屬性為應用系統所關注的資訊〈Information〉,通常是應用系統該結構元素施作其行為時所需要或者所提供的欄位。
    • 結構元素屬性具備方向性,表明該屬性對結構元素,或其施作行為而言,是提供者〈Publisher/Write〉、是消費者〈Subscriber/Read〉,或者是兩者。
    • 結構元素屬性具備時間性,表明該屬性對結構元素,或其施作行為而言,在某時間限定內屬性方為有效。
    • 基於企業多樣活動,一群結構元素集合,組成不同活動領域〈Domain〉,所有領域的聯集就是企業活動總領域,通常應用結構層次圖表明企業不同領域之活動。
    • 一個結構元素通常都肩任多個活動領域角色,提供或者接收著不同服務。
    • 結構元素與其它結構元素之間,  可以用結構元素連結圖表明以此關係。
  • 要界定應用系統結構元素行為〈Element Behaviors〉
    • 結構元素行為結構元素對其他結構元素所提出之服務。
    • 結構元素所提出之服務行為,可以用結構元素服務圖表明行為細節。
    • 結構元素行為依該行為所需之屬性施作,其產出為另一個接收服務結構元素之屬性。
    • 結構元素行為是真正施作具體演算處理者。
    • 結構元素行為是有粒度區別的,通常是開發應用系統的目的所決定,且開發目的左右著預算,使用者不應期待會有一個與預算不相稱應用系統的誕生,更遑論通常預算都是被低估的。
    • 有時在不同系統應用中,提供服務與接收服務者是同一個結構元素,藉由與前次屬性值比較,若符合繼續施作條件,則當作是下一次行為之輸入,遞迴至臨界條件才逸出〈Back-Propagation〉。
    • 依據企業活動,將一系列結構元素行為相鏈結,就是商業流程。
    • 應用結構元素行為圖表明結構元素與交互行為細節。
  • 結構行為合一,使結構元素行為合當,當行為所需之屬性結構元素並不能完全提供,或施作行為所需之資源結構元素並不能負荷,當然也就無法滿足企業活動。

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

  • X 軸〈萃取〉:
    • 資料〈What/Data〉
    • 功能〈How/Function〉
    • 網路〈Where/Network〉
    • 組織〈Who/People〉
    • 時間〈When/Time〉
    • 動機〈Why/Motivation〉
  • Y軸〈面向〉:
    • 範圍〈Scope/Contextual〉
    • 企業模型〈Enterprise Model/Conceptual〉
    • 系統模型〈System Model/Logic〉
    • 技術模型〈Technology Model/Physical〉
    • 其它模型〈Detailed Representations/Out of Context〉

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

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

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

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

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

廣告
%d 位部落客按了讚: