TOGAF的元模型中有很多多對多的關系，比較搞的是功能，流程，服務。

分層加入后難度就一下子上升了，用ER建模的思路，如要簡化多對多關系，中培專家建議可以引入一個實體變為多個一對多，就可以了。

業務架構和業務需求

TOGAF并沒有太多內容來描述如何做業務需求，但是這是我們必須要做的事情。從上面的闡述能夠發現，我是希望業務架構和業務需求能夠有一種方法進行銜接的。其實業務架構和業務需求本身就不沖突，兩者只是處在一個事物在不同層次的東西。架構關注的是更全面、概括、組織方面的東西，而需求關注的是用戶關心的業務細節，業務需求是業務架構的進一步分析。

業務規則對系統來說是核心內容，這部分內容必須仔細查看。規則分析得是否正確、完整是系統實現的前提，每個業務需求通過抽取應該能夠形成一些通性規則，對于通行規則可以作為技術框架的輸入，由框架統一實現一些問題。

業務架構需要做到什么粒度？

架構是產品的上層框架，只需要到具體功能模塊以及主要業務功能就行，具體的業務規則和異常處理都不需要考慮，那是需求分析的事情。

業務架構是否需要做原型？

需要，只是會很粗，并且不在意具體的UE，但是需求階段的原型應該可以從業務架構階段的原型中細化下來。

有沒有統一的規則表模板？

不同業務的規則是不一樣，不同小組的設計能力也是不一樣，不同平臺支持的規則DSL也是不一樣的，這個需要根據自己的情況來定義自己的格式，但必須能夠把規則描述清楚，做到自己、開發人員和測試人員都能一看就明白。

需求階段需要出以前的詳細需求規格說明書嗎？

對于內部來說不需要。但是必須要有原型，還有我上面說的幾個文檔，記住一定要保證同步。

不要夸大IT的作用

經常看到有企業對外宣傳上了一個什么大系統，以此來對外說明自己借助于企業信息化而開始具備了一些競爭優勢。企業信息化的確能夠加強企業競爭優勢，只是現在到處都提最佳實踐，而又想有競爭優勢，那就都開始定制化。定制化并不是一件輕松的事情，企業基本上都會花不少錢，那既然花錢了，而且還不少，那抱的期望自然也會比較大，這容易無形之下夸大了IT的作用。

如果從獨立系統來看，我覺得帶來一定的效率提升是不成問題的，畢竟軟件企業也不是招搖撞騙的，當然有些政府項目除外。然而，如果你希望通過在上一個軟件系統的同時，寄希望于專長搞技術的 IT廠商同時還幫你們制定企業戰略，那我覺得這可能會令你們失望了，也許將來還要為之付出代價。

IT信息化是幫助企業運營的，而運營執行的是戰略，從這個先后順序來看，那就是IT是在戰略規劃之后，而且這是由兩撥不通技能要求的團隊來完成。我們不能把IT太高估了，他們并不是無所不能的，我倒不是說軟件企業沒有這種能力，只是術業有專攻，企業不能把一個管理上的問題直接簡單轉換成一個IT問題來解決，否則得到的解決方案也一定是一個IT方案，而不是解決管理的方案。我認為管理問題還是通過管理的方式來解決更好些，該做企業戰略咨詢的還得做咨詢，該自己思考業務的還得自己規劃，IT相對這些來說，更向是一個戰略執行的工具而已，不能本末倒置，IT工作的輸出絕對不會是戰略，否則容易出漏子的。

中培不僅是國內IT培訓領域的頂尖品牌，而且還是The Open Group在中國區的黃金會員；中培已獲得The Open Group的正式鑒定授權，唯一以TOGAF認證培訓為主導的黃金會員機構；TOGAF認證作為中培最具影響力的精品課程之一，已獲多方面專家的認證。

想了解更多IT資訊，請訪問中培偉業官網：中培偉業