起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識業務架構、信息架構、技術架構三位一體
客戶天天打電話要修改產品功能，簡單的一個需求可能要做一個月。產品越改越笨重，為了趕工期bug越來越多。頭疼！
產品從初級版到現在已經四個年頭，相關的程序員來去換了三批，在補丁上打補丁是常有的事，很多功能只是開了個頭，換個項目經理就被遺忘。我們總是害怕客戶在這個產品上提出新的需求，只要客戶還用得過去，能不改就不改。即使到了非改不可的地步，也會容忍這些僵化的代碼帶來的種種限制。
昨天才剛上的功能，忽然又要去掉?？蛻粼谑褂卯a品中的這些流程，難道事先就沒有人考慮到么？現在說這個功能重要，又說要做各種的接口和延展，需求積壓到這個程度，對不起！代碼已經改不動了。
出來混，早晚是要還的。
在初期，我們的客戶并不了解信息化可以為他帶來什么、改變什么。隨著時間的推移，企業信息化層層深入，甚至已經演變成企業在市場競爭中的利器，逆轉的情況就出現了。企業客戶的業務流程從之前的順應軟件，逐步的變為讓軟件去順應該企業的發展。于是同一款軟件的客戶們提出了各種個性化的需求，加功能、改流程、維護優化等等。
那么，我們如何避免這些頭疼的問題出現呢？
這些問題出現的根本原因是商業軟件的設計與開發方式已經不符合企業信息化的發展要求?，F在市面上大多數軟件，是幾個程序員憑自己對業務的理解，把各種功能拼湊起來成的，在初期這些軟件因為彌補了空白，企業確實看到了收獲，隨著項目的推進和新需求源源不斷的產生，系統的維護壓力越來越大，而且軟件中的業務流程與企業發展過程中的現實流程開始產生偏差，于是軟件為了迎合企業信息化的要求不斷的修改，最后軟件越來越笨重，導致很多新的業務流程無法實現，代碼已經改不動了，所以這套所謂企業信息化的系統能解決的大部分是固定程式的業務，企業信息化進入糾結期。
但是，企業已經嘗到了信息化的甜頭，在強大市場利益的驅動下，越來越多的軟件廠商并不一味的糾結下去，開始推出所謂的“客戶化”，即以客戶為導向，收集客戶的需求，搭建業務框架之后再開始編寫代碼。這種理念并沒有被快速的模仿，因為所謂的“客戶化”往往把軟件廠商弄得筋疲力盡，軟件業是個靠大量復制用戶而生存的行業，要做到真正的個性化服務需要承擔的成本將非常大。所以這種“客戶化”的理念，還只是技術架構層面的范疇。
最近在“客戶化”的基礎上，提出了“業務基礎架構平臺軟件”
按計世資訊的定義：業務架構平臺軟件是指以業務導向和驅動的、可快速構建應用軟件的平臺。其包括集成應用平臺、開發體系兩個部分。從技術角度分析，該平臺軟件為復雜應用軟件系統的開發提供了一個基本框架，并有與之相應的、方便易用的開發與維護管理工具。這個框架給出了一些復雜應用軟件的基本組成部分和實現方法，并且預置了很多供參考的軟件模塊。有了這樣的準備，在業務基礎架構平臺軟件之上開發管理軟件就可以降低復雜性，省去很多基礎性的研發工作，從而大大縮短研發周期，提高研發效率。
這種“業務架構平臺軟件”其實就是功能模塊形式下的“客戶化”。通過客戶的業務基礎框架，軟件會有很多模塊化的功能和可擴展接口，一方面客戶可根據自身的業務特點從模塊化的功能池子中選擇需要的功能；另一方面，當池子中的功能還不能滿足客戶需求時，通過模塊化的擴展接口，程序員可以在基礎平臺上迅速的開發新的功能。舉個大家熟知的例子：WordPress這款博客軟件正是這種“業務基礎架構平臺軟件”的典型，一方面提供很多欄目模塊和功能供博主選擇，并且提供自定義；另一方面，因為這是一個開源的平臺，所以會有各種各樣的應用被迅速的兼容進來。我們的軟件不需要向客戶開源，不奢望客戶參與開發，但是如果這個平臺有良好的業務架構和技術架構，軟件的項目團隊在做功能增加和修改的時候只要模塊化就行。于是，業務架構和技術架構被放到同一個高度上來，避免出現開發過程以技術架構為主，業務架構為輔，業務進行架構設計之前過早的進行大規模的代碼編寫。
以上一直在強調模塊化，這是“業務架構平臺軟件”的關鍵所在，但是這個模塊化，現今還處在摸索階段，三百六十行，每一行的業務流程都不同，但是我們通過大量的流程對比，是能夠發現一些規律的，這些規律的組合就形成了模塊?！稑I務架構和應用架構》這篇文章的作者無處查找，但是其中有一段話對業務架構的模塊化說明值得借鑒：“初看架構這個詞容易理解為靜態的事物，但是廣義的業務架構一定是靜態和動態分析的集成和融合，在分析過程中相互影響又相互促進。動態的信息即我們說的普通的價值鏈分析的思路，從企業端到端的一級流程到各個業務領域二級，三級等流程的分析。形成一級流程->子流程->活動->活動單元->任務->事件的主線；而對于靜態信息則包括組織，人員，崗位，角色，業務對象和表單，規程，模板等各種信息。靜態信息的重點是業務領域和業務對象，即形成業務領域->業務主題域->業務模塊->業務單元->業務組件的靜態數據逐層分解。靜態信息+動態信息+交互點和接口分析后形成完整的業務架構?？梢钥吹搅鞒淘偌毩６确纸夂蟮幕顒訂卧慕M合可能形成業務組件和業務模塊，同時業務模塊本身又存在更細粒度的流程和活動分解，業務組件本身又是多個流程的組成部分，因此靜態和動態相互融合，形成交互，所以必須分析交互和接口。”
除去以上這些，業務架構和技術架構下的模塊化平臺軟件還具有以下特質：
1、 以用戶為中心
用戶將成為信息化的主導，他們不用去考慮技術如何實現，只需要了解自身業務流程，只需要利用模塊池中的功能組裝成符合自身需要的目標軟件即可。這樣用戶可以徹底改變以前信息化過程中的被動地位，從而有效保證軟件和需求二者之間的平衡。
2、 敏捷開發
因為具備模塊化的接口和延展性，所以程序員不需用從零開始逐步開發，只要利用原有的模塊為基礎進行開發。
3、 集大成
說到功能池的概念，這種軟件必將是一個集成了多種系統的平臺，它就像PC主板一樣，會有很多插槽，無論你要建立什么樣的管理系統，這些功能都將輕松整合在一起。
4、 生命周期很長
因為建立了業務架構和技術架構協調一體的機制，所以其生存的根本就在于能夠順應企業的發展，通過敏捷開發的方式來實現軟件的生命周期模型。這些因素都有效地驅動了軟件的持續完善，從根本上保證了管理軟件和企業發展的動態平衡關系，使軟件具備較長的生命周期。
在業務架構和技術架構協調一體的同時，漸漸發現，因為企業的應用越來越多，企業應用的多樣性、復雜性以及它們直接相互關聯交互的需求增強，已經越來越多的企業從應用層上升到了數據層，如果還是像傳統軟件一樣，將數據存儲在系統文件中，那么這個所謂模塊化的“業務基礎架構軟件”仍然無法發揮他的威力。
這時候就應該將信息系統架構提到業務架構和技術架構的高度，協同解決。我們稱之為“業務架構、信息架構、技術架構三位一體”
很榮幸，從2009年開始，我主導了一款餐飲行業應用軟件的設計和規劃工作。這一年半的時間里，在項目組摸索尋找這種一體化的工作方法。其實并不是三種架構都在同一個地方等你，而是走著走著發現問題，然后一個一個的撿起來，最后發現其實一開始三者是可以結合成一體的。
在信息架構中，我們不僅將企業數據存儲到數據庫中，而且將這一數據庫存儲到統一的服務器中，作為數據層開放。采用C/S結構，讓客戶和服務器實時交互，系統記錄客戶的操作數據，通過對這些數據的分析歸納，做出行業通用的業務模型?？蛻敉ㄟ^與服務器的鏈接，可以任意的在功能池子中選擇自己需要的模塊。
IBM在介紹其DB2pureXML時曾經提到：“由于這種開放的服務特性，這類核心信息在服務各種業務的過程中必然需要考慮很大的差異性和復雜性，必然需要把數據的存儲和數據的訪問隔離。數據的差異性和復雜性將對數據模型的靈活性和可擴展性提出更高的要求，而數據的訪問和底層存儲的隔離，將直接導致未來越來越多的應用通過XML的服務接口獲取信息而非用SQL直接訪問底層數據庫表?！?/p>
是的，這正是saas成為行業趨勢的原因，軟件應該是“軟性”的，它能夠順應企業發展的需求，而不應該讓企業去順應軟件。業務架構、信息架構、技術架構也正是saas的精髓所在。
今天玩把概念，個人一些零星的觀點不成體系，僅作拋磚引玉。感謝大家百忙中的閱讀！
來源：http://www.pmday.com/archives/335
相當nice