Zachman 架構方法 與 SBC 架構方法 之比較

Zachman框架是一種用來開發和維護較廣範圍詮釋的工具，當涉及企業組織中的企業構架（Enterprise Architecture）功能確立時，Zachman框架也可以提供很多框架模式幫助與呈現，在許多企業組織之中，關於Zachman框架的實際導入作法就是它將企業組織區分成為一個6*6的方格型矩陣圖，每個矩陣單元表格代表每一個組織的運作單元，在36個框架單元格中可以依據選擇每個單元(組織)特性來描述企業組織中的框架模型和作業模式來進行劃分，例如單位屬性、作業細節或者負責單位等種類如圖一。

圖一 Zachman企業框架模型

         Zachman框架裡的列代表企業最重要的功能面（如資訊、職掌、網絡、人員、時間、目標等），而行則是按照不同作業規劃（如指標、業務、系統、技術、庫存、資產）還有與一個方面相關的組織操作者（規劃者、業務執行者、控制者、實施者、接替者）來進行劃分。除此之外，行也因作業層級而不同，因為它們是企業組織上的抽象表達（環境中的、概念上的、邏輯的、物理的、詳細的和實際的），這反過來可能與組織操作者和作業規劃相連接來形成企業模型和職掌的單元方格。而Zachman框架並無規定每個單元方格的符號或順序填入模式，基本上也無法規範，因為這一個邏輯思考模式已經超出了參考結構目標的範圍。與大部分的何靜態框架一樣，Zachman在框架當中並沒有說明如何處理工作內容情境以及沒有清晰的回饋、描述組織系統的作業情況，而另一個比較容易產生混淆的是Zachman框架缺少標準化的結構符號表示。

另一種架構工具就是Structure-Behavior Coalescence(SBC)，它最重要的核心訴求即為「結構行為合一」的服務架構模式，其分支上已經衍生了SBC硬體架構、SBC軟體架構、SBC企業架構、SBC知識架構、SBC思考架構等等，如圖二所示。

圖二 SBC架構的應用

        目前在大部分的企業架構領域中除了一般流程導向的企業推廣模型之外，企業組織也開始慢慢得感受到光是流程上的注重以及落實流程上的每個節點並無法真正的改善企業運作時所遇到的問題，也就是企業內外的服務行為與組織結構上的連結程度，這往往造成企業主在經營上負擔與成本的浪費。以SBC企業架構來說，SBC架構工具就是以重新看待企業組織中的各個結構組成元素(即部門單位)，並了解每個結構元素間的操作行為，架構導向模型設計共由六個模型整合而成；此整合模型由架構階層圖、結構元素圖、結構元素服務圖、結構元素連結圖、結構行為合一圖與互動流程圖整合而成之架構式模型如圖三，並就各個架構操作階層說明如后：

圖三 SBC架構導向六個整合設計模型

一、架構階層圖(Architecture Hierarchy Diagram)：任何一個管理模型均可經由架構階層圖來說明
一個系統的分解與組合。架構階層圖可使原本複雜的系統變得易於讀取。如圖四，原系 統A可分解出AA、AB、AC三個子系統，其中AA至此不再分解，AB可再分解出AB1、AB2、AB3三個子系統，AC可再分解出AC1、AC2、AC3三個子系統。因此A、AB、AC，視為聚合系統(Aggregated System)，表示其可再分解出子系統，階層圖中之聚合系統均需再分解至不再分解為止。其中AA、AB1，AB2、AB3、AC1、AC2、AC3，便視為非聚合系統(Non-Aggregated System) 表示不再為其分解出子系統。此非聚合系統即是此研究中所稱之結構元素(Structure Element)。而此顯示出分解過程的圖例即可稱之為架構階層。

圖四 架構階層圖

二、結構元素圖(Structure Element Diagram)：把架構階層圖中之非聚合系統（結構元素）集合起來表示，便成為架構式模型中之第四個圖例結構元素圖。以圖五之階層圖中所示，其結構元素(Structure Element)共有AA、AB1、AB2、AB3、AC1、AC2、AC3。整合成圖四結構元素圖。

圖五 結構元素圖

        結構元素(Structure Element)彼此間的關係與互動，以Client-Server 觀念來解釋。如圖六所示，今假設有兩個結構元素，一為Client 端，另一為Server端。在Client 端之結構元素，有一個發送請求服務的port，Server 端之結構元素，則有一個接收服務請求的port；每個結構元素均同時有此兩種角色，即Client 端與Server 端，彼此間藉著服務的聯結關係產生互動，進而產生出行為。基於此原則，可建構出結構元素服務圖。

圖六 結構元素間關係互動連結圖

三、結構元素服務圖(Structure Element Service Diagram)：找出系統中之所有結構元素之後，接下來需把結構元素之服務(Service)描述出來，此即是本研究中所稱屬於結構角度的觀點。
        在找出所有結構元素的服務後，發現一個服務可以有很多的輸出入參數（Input Output Parameter）。各結構元素提供的服務，為此結構元素的介面或工作內容，因此服務的輸入參數為其結構元素的系統輸入，箭頭符號是直接指向結構元素；服務之輸出參數即是其結構元素的系統輸出，箭頭符號指向為離開結構元素。因此要完整表達一個服務，頇至少包含：服務名稱、輸入參數、輸出參數等三部份。但在此研究建構的過程中，因在最後之互動流程圖中，在結構元素的服務端亦有繪製此部份的輸出入參數，故在結構元素服務圖中，為求簡潔因此不再重繪，另因服務項目會視系統之大小而有多寡之分，為避免雜亂，忽略部份次要服務之輸出入參數，忽略的原則以不影響閱者整體之了解為原則。
        如圖七所示，「風險管理結構元素AA」有“Service 1”、“Service 2”等2個服務，“Service 1”服務的輸入參數為S1I、輸出參數為S1O；“Service2”服務的輸入參數為S2I、輸出參數為S2O。“Service 1”、“Service 2”等2個服務是由「風險管理結構元素AA」提供，即表示此結構元素有2個系統輸入(S1i、S2i)，及2個系統輸出(S1o、S2o)。「風險管理結構元素AB1」有“Service 4”1個服務，“Service 4”服務的輸入參數為S4I、輸出參數為S4O。

圖七 結構元素服務圖

四、結構元素連結圖(Structure Element Connection Diagram)：把各結構元素間之服務按其先後次序、以提供服務及被服務串聯起來，即成為結構元素連結圖，此圖可顯示出各結構元素服務間之連動如圖八。

圖八 結構元素連結圖

五、結構行為合一圖(Structure Behavior Coalescence Diagram)：採用架構導向塑模，最主要的目的就是把結構元素與行為整合在同一模型中，不使產生各自分離的結構角度模型和行為角度模型。在結構元素的服務間或結構元素與外在環境有互動時，此互動的串聯便會產生所謂的行為，把此結構元素透過行為串聯呈現便稱為結構行為合一圖(Structure Behavior Coalescence Diagram)，圖九中外在環境與結構元素「AB1」、「AA」互動後，返回風險管理結構元素「AB1」，再與「AC1」互動產生「行為1」。外在環境與風險管理結構元素「AB2」、「AA」互動產生「行為2」，其中箭頭方向表示此行為在各服務的供需中發生時間點的先後。

圖九 結構行為合一圖

六、 互動流程圖(Interaction Flow Diagram)：互動流程圖為架構導向塑模當中非常重要的一個圖。因根據此圖，可倒推至塑模的各個階段；到最初的階層圖。每張互動圖中至少包含五個要素：外在環境、結構元素及其提供之服務、各服務間的互動次序與其輸出入參數。如圖十；X 軸表結構元素與結構元素或結構元素與外在環境間的互動及資料流方向、Ｙ軸為時間軸其最後執行之互動會在Y 軸之最下方。時間是由上往下走。
        此處所指的互動便是外界環境和結構元素及結構元素與結構元素之間產生行為的方式，以服務名稱及輸出入參數(依箭頭方向代表輸出或輸入)來完成結構元素間的互動行為，另架構模型中之每一行為均應繪製一互動流程圖來表示。

圖十 行為互動流程圖

        所以，依上述SBC架構標準結構模型來說明企業架構，充分將企業組織所有的結構元素(運作單位)與組織行為以最直及接標準化進行六個架構剖析階段後重新塑模，其所倚賴的是把企業組織的各結構面與執行行為面做結合，並將企業相關策略、組織、執行、人力資源整合為一立體層面之模型圖，並以階層方式分層次來表現其結構行為架構框架如圖十一，如此做法的最大優點即是Layer 1之結構行為合一也是Layer2 之一個結構元素亦或者是一個操作行為之一，以此類推到每一個Layer層面後即可以完整表現出一個企業的完整架構，在SBC企業架構模型下，我們便可以一目了然的看待企業各個階層的結構模式與操作行為，充分展示出企業主體架構之中可能產生之問題層面或者是提供企業組織重整之參考。

圖十一 SBC架構框架示意圖

企業架構與服務導向共舞

近來全球均適逢金融海嘯衝擊而驚魂未定，許多企業與政府無不痛定思痛，思考如何脫困及調整體質，來因應未來更嚴峻的挑戰。金融海嘯的發生，推究其真正主因，乃是人性貪婪惡性所致。企業為追尋年年大幅獲利與成長，高估整個市場胃納，由專業經理人與大股東們的合演了這齣鬧劇：

• 造成生產過剩，加上供應鏈乘數效應，各階層零組件假性需求大增，引發最底層原物料價格高漲。


• 原物料價格高漲結果又導致排擠效應，造成生產品結構性供需失真。


• 當假性需求開始泡沫，企業成長推動力減弱，必須再次挖掘新市場，新市場便指向擴張信用族群。


• 擴張信用族群始終相信財務槓桿與提前消費，是改善生活提高享受的萬用金丹。


• 要能發揮槓桿，企業不惜故意忽視風險，配合所得分配金字塔低層者演出，藉由編織美夢，鼓勵擴張信用而不自知。


• 金融產業藉由金融產品包裝，將不良債信產品美化，再以衍生商品型式賣給投資人，透過基金、連動債等多種面貌問市。


• 當最底層債信發生償付問題，如骨牌般拉枯摧朽般，將建立在沙灘上的所有城堡沖垮。


• 所有產業均發生連動，墮入信用流動性緊縮的惡性循環之中，昔日眾所稱羨的金融產業，人人自危，朝不保夕。

因此無論企業與政府都應重新自我檢視，找出短中期與未來趨吉避凶之道。然而如果不知道企業現況，則無從具體改造因應，企業現況應包括以下面向：

• 經營願景與策略：描述中長期經營願景，與如何達成目標之策略。


• 營運目標與戰術：描述短期營運目標，與如何達成目標之戰術。


• 市場評估與競爭力：描述市場區隔〈Market Segments〉市場謂納，競爭對手動態，企業本身競爭優勢。


• 商品與服務：描述企業獲利手段，所提供之產品與服務，包括產品定位、定價、特色功能等。


• 財務與資金流動管理：描述企業流動資產及如何支應營運資金需求。


• 研究發展與投資：描述企業投入研究發展項目，各期研發費用、競爭優勢分析，與效益評估等。


• 風險評估與審計：描述企業營運、研發、競爭力等風險因子，如何建立風險控制機制，如何透過會計制度適時審計。


• 運籌管理：描述企業產品與服務供應鏈，包括供應商評等、關鍵零組件、供料需時〈Lead Time〉，價格變動趨勢等。


• 生產製造與服務提供：描述企業產品與服務，生產製造與服務提供方式，包括組成清單〈BOM〉、製程、人力工時、成本，品質管制等。


• 組織任務與分工：描述企業組織部門任務，與其他部門分工互動，包括表單、流程、內規等。
  


• 人力資源：描述企業人力素質、專長、在職訓練，與人才招募、晉用、考核、資遣、退休等。


• 資訊科技與營運支撐：描述企業資訊方針與策略，應用系統、資料庫、軟硬體設備，與營運各項機制間關連等。

企業現況檢視範圍既廣且深，但要如何分析表達，並為不同背景經理人均能理解，使其能進而提出改造方案，首要分析方法與表達方式必須一元多樣，由簡入繁，由高入深，欲達此成果非引用「企業架構」〈Enterprise Architecture〉不可。



企業架構之方法在於闡明企業元素間之關係。企業元素是一個抽象概念；在〝組織任務與分工〞分析中，企業元素就是〝部門〞。元素間有交互作用，交互作用敘明彼此包括以下關係：

• 元素為多維空間下之〝座標點〞。第 0 維可以是企業鳥瞰圖，該元素為某圖層面中之項目，如〝物料需求表〞可以表示為 M(資訊科技與營運支撐圖層, 生產製造, 工令)。
  


• 關係定位：何為供給？何為需求？供給又分單一與多向，需求可再分暫態、中繼與最終。


• 型式定位：單向或多向，程序流程或事件觸發？


• 資料集：單一或總體。單一資料集可用於供給下達與需求返回；總體資料集可用於各相關聯交互作用元素權責資料之總集〈Super Set〉。


• 關聯條件：時間限制或某資料集欄位。

當然將企業架構做完整有系統地分析建構，殊為複雜。需要有建構工具始能事半功倍，由工具將前述分析結果，產生以下各圖：

• 企業方向圖: 鳥瞰企業整體營運，依前述企業現況各種面向〈經營願景與策略、營運目標與戰術、市場評估與競爭力‧‧‧等〉建構多層次關聯圖。
  


• 商業概念圖：簡述商業運作模式，包括獲利模式，商品及服務內容，建構企業整體多層次商業概念圖。
  


• 企業溝通圖：以企業組織部門為元素，依地理位置、服務類別，建構彼此多層次交互作用關聯圖。


• 程序圖：依企業組織、服務類別，建構該部門內部與其他部門間，相關服務類別下之作業程序圖。
  
  


• 組職架構圖：依地理位置、服務類別，建構組職階層架構圖。


• 應用程式架構圖：包括應用程式間調用層次、軟體架構〈入口網、內容服務、應用系統服務〉、資料庫、檔案系統、特殊設備等關聯圖。


• 服務導向圖：依地理位置、使用族群〈客戶、供應鏈、政府機關、公司內部、應用程式間〉、應用系統等建構多層次多面向，各式服務說明圖。


• 技術基礎架構：依地理位置、服務類別、應用系統等建構多層次多面向，包括硬體與網路設備系統圖。

透過企業架構分析手段，使企業內部及外部專家顧問更能清楚瞭解企業現況，進而指出具體企業改造提昇競爭力之方案。今天企業大多均面臨著許多挑戰：

• 微利時代來臨，為提昇企業獲利不得不提高產能。


• 市場價格受多種因素影響，如匯率、油電價、替代品，不再是供需間單純因素。


• 產品與服務之創新，由於生命週期短，多樣附加功能增，企業不得不投入研發，以期以最短時間上市。


• 產品與服務作業生產能更有效率，零組件成本要更低，人力要更省。


• 資金週轉時間要短，直接面向消費者，減少中間商剝削。


• 人力資源不足，勞動成本過高，高階人力素質不夠一將難求。


• 資訊能力不足，無法即時支撐多變營運服務。

要因應前述挑戰，企業必須要加強資訊能力，使能支撐多變營運服務。資訊管理與資訊工程專家，借鏡過去資訊缺失，服務導向架構乃應運而起。服務導向架構改善了資訊消費者與應用系統間分工機制，讓系統更貼近服務享用者，同時更靈活地因應各種多變營運服務。由於網際網路之盛行，故而服務導向架構以 Web 形態呈現，並有以下特點：

• 為求應用系統開發時程要短，引用〝軟體基礎建設〞概念，依功能角色區分，以軟體協力方式，共同達成服務要求。


• 軟體基礎建設包括以下組件：
  
  
  
  • 入口網服務〈Portal〉：透過應用系統間帳號整合，將各應用系統彙集於統一框架之下，使得 Portal 成為用戶綜合工作平台。依據用戶角色、使用權限、作業時段，呈現不同面貌。Portal 統合了包括企業願景與形象，產品與服務特色，日常作業與辦公室自動化工具等，大幅提昇工作績效。
  
  
  • 商業流程管理〈Biz Process Management〉：企業內部溝通係透過流程與表單，將作業與審核緊密地結合，不僅是組織間、成員間，甚至應用系統間均能透過圖型方式表達，充分實現企業架構中各層次間企業溝通圖。流程中統合循序式、並發式及混合式作業，各種觸發條件指揮了流程之路徑走向，將企業內外溝通透通地忠實反應。
    
    
    
    
    
    
    
    
    
    
  
  
  • 內容管理〈Content Management〉：在企業內部溝通過程中，會衍生一群〝文件〞，不同流程由於條件之不同而產生相同文件，或者產生不相隸屬文件。文件需要有多重〝標籤〞〈Attributes〉來定位描述文件之特性，以便日後泛型查詢。內容管理提供文件管理、審查、發佈等機制，豐富地保存企業內部溝通過程。
    
  
  
  • 應用系統服務〈Application Server〉
  
  
  • 資料庫服務〈Database Server〉
  
  
  
  


• 為求應用系統開發時程要短，引用〝軟體建構〞概念，使用工具融入應用系統發展生命週期，以提高軟體品質：
  
  
  
  • 應用系統分析與建立模型〈System Analysis & Modeling〉
  
  
  • 商業元件設計開發〈Biz Component〉
  
  
  • 人機介面設計開發〈User Interface & Web Usability〉
  
  
  • 除錯與除錯管理〈Debug & Debug Management〉
  
  
  • 測試與測試管理〈單元測試、整合測試、壓力測試〉
  
  
  • 部署與部署管理〈Deployment〉
  
  
  
  


• 為求應用系統開發時程要短，引用〝軟體 IC〞概念，應用系統乃是一組可重複使用元件之組合。


• 服務由協力軟體共同交互作用所產生，包括基本服務與組合服務二種。

如此一來企業便能透過服務導向架構優點，在極短時間內滿足多變營運服務要求。由於強調元件重複使用，同時也累積企業核心競爭力─智慧財產，使企業能更靈活地遊刃於市場之間。

近來政府組織再造議題又起，然如何分析政府運作現況，莫衷一是。行政院研考會發表「行政院組織改造–資訊改造與服務創新策略規劃」提出以下論述：

• 組織改造資訊業務二大策略主軸


• 資訊移轉〈Transition〉工作要項


• 資訊改造〈Transformation〉前瞻性議題


• 資訊價值改造

然而如何落實規劃，精準掌握資訊再造目標，則非應用〝企業架構〞精神與方法不可：

• 找出功能近似部會加以整合精簡；


• 找出部會間互動更佳模式提昇行政效率；


• 找出資訊系統資源加以整合擴大效益；


• 使用客觀科學方法擺脫政治考量；

經過企業架構分析，使能具體評估部會資訊簡併整合效益，並進一步勾勒出願景，才能真正建立高效率電子化政府，打造為民服務導向架構，提高政府資訊投資報酬率，最後提昇整體作業績效，實為百姓之福！

企業架構分析

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



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

• 要界定應用系統結構元素〈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%管理成本，當績效提升後，整個管理視野也相對提高，許多原來斤斤計較造成專案延遲所執著的系統功能也跟著改變，應用系統亦如人一般，需要時間演化，受外在因素變化而變化。

中山大學推廣教育處 - SBC 架構課程

課程目標

企業架構的影響力日增, 各企業架構師組織也紛紛成立, 從企業角度來看, 投資企業架構師是非常值得的, 本課程目標即是幫助學員能了解並加強企業架構師之基本技能。

2009-12-07起開課
企業架構與應用剖析(週一 三班) [第1期]
http://www.cea.nsysu.edu.tw/cec_system/enrollinfo/file/492.pdf

2009-12-08起開課
輕鬆學會軟體架構與應用(週二 四班) [第1期]
http://www.cea.nsysu.edu.tw/cec_system/enrollinfo/file/491.pdf

SBC 是什麼的縮寫?

SBC 是

Structure-Behavior Coalescence

的縮寫.....

SBC 代表 「結構行為合一」

Definition of 系統架構

System architecture is an integrated, holistic, coordinated, coherent, and coalescence model for a system's multiple views, i. e., structure view, behavior view, and other views, in which
(A)a system comprises many structure elements;
(B)multiple views such as structure view, behavior view, and other views are derivable from interactions among these structure elements;
(C)multiple views such as structure view, behavior view, and other views are all contained in this model.

「SBC架構」的應用

「SBC架構」的應用很廣，包括：SBC硬體架構、SBC軟體架構、SBC企業架構、SBC知識架構、SBC思考架構等等。