本文內容更新版本已轉至 ?http://www.zhoujingen.cn/blog/3695.html

?--------------------------

? ? 做管理型軟件產品一般都要經歷架構階段，而架構又可以簡單分為業務架構和技術架構，對于架構方法，在我以前的blog中大量的介紹了TOGAF。

使用TOGAF的幾個初衷

在我們開發軟件時，如果你做過設計和架構工作，那么你會發現軟件開發過程中其實存在很多斷溝。

業務架構到技術架構的不一致

業務架構是一撥人做，技術架構師另一撥人做，結果做業務架構時缺少技術架構的考慮，而技術架構缺少服務于業務的意識，最終沒有為業務服務。弄到最后業務架構和技術架構并不能很好的結合起來，導致還需要很多適配或反復工作。

還有一種情況是，業務架構做完之后扔給技術架構來實現，但是業務架構提供的東西并不全面，不能提供技術架構的輸入，導致溝通效率極其低下。

業務架構到業務需求的不一致

有些公司雖然崗位分的清楚，但是方法并不清楚。業務架構是一套方法，需求分析是一套方法，甚至于沒有方法，而是靠著個人能力去做，結果導致架構和需求交付物是獨立的，業務架構的東西不能順利轉移到需求階段

還有時候一個人就負責產品的業務，架構和需求一起做，這時候沒有方法的指導，其實很容易迷失在業務細節。 過早的進入業務細節對于產品來說是及其危害的，因為產品架構還未明晰時進入細節只會浪費時間導致重心偏離方向。

業務架構和實現的不一致 開發產品時，開發問一句，"做這個對系統有什么價值？"結果發現需求根本無法追溯回系統的價值點上，有時連需求人員都不知道為什么做了這個功能。如果產品生命周期較長，中間換了好幾撥人來做這個產品了，那么不僅是需求文檔不能追溯，就是靠口頭講也講不清。

業務架構采用的是業務語言，而技術實現采用的技術語言，兩者不是同一個語言，很難做到順利過渡，還需要再一次翻譯，有時候甚至在實現階段根本不看業務架構出來的東西

很少有開發人員清楚產品的業務架構，那么如何能夠做出好的產品來？

從上面可以看書，現實中產品開發存在的隱性問題其實還是蠻多并且很嚴重的，我也都經歷過。而解決這些問題就必須做到一下幾點：

找到一個指導業務架構的方法和框架

結構化架構交付物才有可能把架構知識轉移到開發環節

必須有一個業務開發平臺來集成業務架構、技術架構和開發框架

業務架構和業務需求

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

????在研發峰會上我講過一次使用TOGAF來做業務架構，下面是裁剪后的輕型迭代流程和交付物。其中的設計開發步驟中有Backlog，這個就是從業務架構和業務需求的產物。

????在我寫的敏捷方法之Scrum.pdf電子書中提到產品backlog是在項目開始的時候，由Product Owner準備的一個根據商業價值排好序的客戶需求列表。而在我們工作中，這個產品backlog如果要做到承上啟下的作用，考慮到它來自于業務架構，而又服務于產品開發，所以我們會定義一些格式，例如考慮功能的抽象、721的分析以及與開發框架匹配的文檔組織格式等。

????以下的文檔是根據我所做業務以及實現框架而做的格式，你可能需要根據你們自己的情況來制定屬于自己的backlog格式。

制定Backlog的考慮點

由于流程可以動態變化，以靜態的功能分解和信息結構作為backlog的主要輸入

考慮軟件產品線工程，進入開發前，設計產品的721

結合業務框架的模型抽取來編寫業務實體以及功能

盡量結構化文檔，不采用純文字描述，逐步抽取出具有確定含義的文字

術語和規則作為sprint文檔之外的重要文檔

產品業務模塊backlog

以下是實際工作中的一個示例：

????

• 按照子系統、業務模塊來組織產品backlog
• 每個子系統和模塊都附上唯一的編號，文檔中任何地方都可以引用
• 輸入、輸出表達模塊之間的關系，這個從業務架構的流程、功能分解中輸入
• 執行者和目的對應業務架構的角色和價值點
• 范圍、工具和技術屬于業務需求內容
• 7/2/1是根據業務、市場來劃分此模塊是通用功能、可變功能還是定制功能

產品模塊功能backlog

????產品業務模塊backlog大部分內容除了7/2/1之外，大部分內容只是業務架構的另一種表現形式而已。到了需求階段，必須對產品業務模塊backlog進行細化工作，那就是產品模塊功能backlog：

• 按照業務模塊、功能點來組織模塊功能backlog
• 抽取公共業務功能、通用業務規則，例如列表模板、通用編輯方式、通用業務功能，這些通用規則和說明形成單獨文檔，作為技術架構的輸入
• 業務規則列鏈接具體的業務規則說，業務規則的寫法根據遇到的規則類型定義自己的結構化格式
• 功能點仍舊也要做721設計
• 對于非通用性的業務功能需要描述具體任務操作步驟以及價值點
• 加入關注的非功能性需求，我們現在只加入了效率
• 大多數情況下，這個文檔的模塊能夠對應到開發中的實體，功能點能夠對應到界面上的一個按鈕或右鍵等，這樣有利于以后轉向模型驅動平臺下使用設計器來進行產品開發

術語表

如果術語很多，可以進行分組編號

規則表

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

一些問題

• 業務架構需要做到什么粒度？
  架構是產品的上層框架，只需要到具體功能模塊以及主要業務功能就行，具體的業務規則和異常處理都不需要考慮，那是需求分析的事情
• 業務架構是否需要做原型？
  需要，只是會很粗，并且不在意具體的UE，但是需求階段的原型應該可以從業務架構階段的原型中細化下來
• 有沒有統一的規則表模板？
  不同業務的規則是不一樣，不同小組的設計能力也是不一樣，不同平臺支持的規則DSL也是不一樣的，這個需要根據自己的情況來定義自己的格式，但必須能夠把規則描述清楚，做到自己、開發人員和測試人員都能一看就明白
• 需求階段需要出以前的詳細需求規格說明書嗎？
  對于內部來說不需要。但是必須要有原型，還有我上面說的幾個文檔，記住一定要保證同步。

推薦：你可能需要的在線電子書? ??

我的新浪圍脖： http://t.sina.com.cn/openexpressapp?? 敏捷個人sina圍裙：http://q.t.sina.com.cn/135484??

歡迎轉載，轉載請注明：轉載自周金根 [ http://zhoujg.cnblogs.com/]

?

轉載于:https://www.cnblogs.com/zhoujg/archive/2011/03/08/1977246.html

總結

以上是生活随笔為你收集整理的TOGAF：从业务架构到业务需求的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。