客戶天天打**要修改產品功能，簡單的乙個需求可能要做乙個月。產品越改越笨重，為了趕工期bug越來越多。頭疼！
產品從初級版到現在已經四個年頭，相關的程式設計師來去換了三批，在補丁上打補丁是常有的事，很多功能只是開了個頭，換個專案經理就被遺忘。我們總是害怕客戶在這個產品上提出新的需求，只要客戶還用得過去，能不改就不改。即使到了非改不可的地步，也會容忍這些僵化的**帶來的種種限制。
昨天才剛上的功能，忽然又要去掉。客戶在使用產品中的這些流程，難道事先就沒有人考慮到麼？現在說這個功能重要，又說要做各種的介面和延展，需求積壓到這個程度，對不起！**已經改不動了。
出來混，早晚是要還的。
在初期，我們的客戶並不了解資訊化可以為他帶來什麼、改變什麼。隨著時間的推移，企業資訊化層層深入，甚至已經演變成企業在市場競爭中的利器，逆轉的情況就出現了。企業客戶的業務流程從之前的順應軟體，逐步的變為讓軟體去順應該企業的發展。於是同一款軟體的客戶們提出了各種個性化的需求，加功能、改流程、維護優化等等。
那麼，我們如何避免這些頭疼的問題出現呢？
這些問題出現的根本原因是商業軟體的設計與開發方式已經不符合企業資訊化的發展要求。現在市面上大多數軟體，是幾個程式設計師憑自己對業務的理解，把各種功能拼湊起來成的，在初期這些軟體因為彌補了空白，企業確實看到了收穫，隨著專案的推進和新需求源源不斷的產生，系統的維護壓力越來越大，而且軟體中的業務流程與企業發展過程中的現實流程開始產生偏差，於是軟體為了迎合企業資訊化的要求不斷的修改，最後軟體越來越笨重，導致很多新的業務流程無法實現，**已經改不動了，所以這套所謂企業資訊化的系統能解決的大部分是固定程式的業務，企業資訊化進入糾結期。
但是，企業已經嘗到了資訊化的甜頭，在強大市場利益的驅動下，越來越多的軟體廠商並不一味的糾結下去，開始推出所謂的「客戶化」，即以客戶為導向，收集客戶的需求，搭建業務框架之後再開始編寫**。這種理念並沒有被快速的模仿，因為所謂的「客戶化」往往把軟體廠商弄得筋疲力盡，軟體業是個靠大量複製使用者而生存的行業，要做到真正的個性化服務需要承擔的成本將非常大。所以這種「客戶化」的理念，還只是技術架構層面的範疇。
最近在「客戶化」的基礎上，提出了「業務基礎架構平台軟體」
按計世資訊的定義：業務架構平台軟體是指以業務導向和驅動的、可快速構建應用軟體的平台。其包括整合應用平台、開發體系兩個部分。從技術角度分析，該平台軟體為複雜應用軟體系統的開發提供了乙個基本框架，並有與之相應的、方便易用的開發與維護管理工具。這個框架給出了一些複雜應用軟體的基本組成部分和實現方法，並且預置了很多供參考的軟體模組。有了這樣的準備，在業務基礎架構平台軟體之上開發管理軟體就可以降低複雜性，省去很多基礎性的研發工作，從而大大縮短研發週期，提高研發效率。
這種「業務架構平台軟體」其實就是功能模組形式下的「客戶化」。通過客戶的業務基礎框架，軟體會有很多模組化的功能和可擴充套件介面，一方面客戶可根據自身的業務特點從模組化的功能池子中選擇需要的功能；另一方面，當池子中的功能還不能滿足客戶需求時，通過模組化的擴充套件介面，程式設計師可以在基礎平台上迅速的開發新的功能。舉個大家熟知的例子：wordpress這款部落格軟體正是這種「業務基礎架構平台軟體」的典型，一方面提供很多欄目模組和功能供博主選擇，並且提供自定義；另一方面，因為這是乙個開源的平台，所以會有各種各樣的應用被迅速的相容進來。我們的軟體不需要向客戶開源，不奢望客戶參與開發，但是如果這個平台有良好的業務架構和技術架構，軟體的專案團隊在做功能增加和修改的時候只要模組化就行。於是，業務架構和技術架構被放到同乙個高度上來，避免出現開發過程以技術架構為主，業務架構為輔，業務進行架構設計之前過早的進行大規模的**編寫。
以上一直在強調模組化，這是「業務架構平台軟體」的關鍵所在，但是這個模組化，現今還處在摸索階段，三百六十行，每一行的業務流程都不同，但是我們通過大量的流程對比，是能夠發現一些規律的，這些規律的組合就形成了模組。《業務架構和應用架構》這篇文章的作者無處查詢，但是其中有一段話對業務架構的模組化說明值得借鑑：「初看架構這個詞容易理解為靜態的事物，但是廣義的業務架構一定是靜態和動態分析的整合和融合，在分析過程中相互影響又相互促進。動態的資訊即我們說的普通的價值鏈分析的思路，從企業端到端的一級流程到各個業務領域二級，**等流程的分析。形成一級流程->子流程->活動->活動單元->任務->事件的主線；而對於靜態資訊則包括組織，人員，崗位，角色，業務物件和表單，規程，模板等各種資訊。靜態資訊的重點是業務領域和業務物件，即形成業務領域->業務主題域->業務模組->業務單元->業務元件的靜態資料逐層分解。靜態資訊+動態資訊+互動點和介面分析後形成完整的業務架構。可以看到流程再細粒度分解後的活動單元的組合可能形成業務元件和業務模組，同時業務模組本身又存在更細粒度的流程和活動分解，業務元件本身又是多個流程的組成部分，因此靜態和動態相互融合，形成互動，所以必須分析互動和介面。」
除去以上這些，業務架構和技術架構下的模組化平台軟體還具有以下特質：
1、 以使用者為中心
使用者將成為資訊化的主導，他們不用去考慮技術如何實現，只需要了解自身業務流程，只需要利用模組池中的功能組裝成符合自身需要的目標軟體即可。這樣使用者可以徹底改變以前資訊化過程中的被動地位，從而有效保證軟體和需求二者之間的平衡。
2、 敏捷開發
因為具備模組化的介面和延展性，所以程式設計師不需用從零開始逐步開發，只要利用原有的模組為基礎進行開發。
3、 集大成
說到功能池的概念，這種軟體必將是乙個整合了多種系統的平台，它就像pc主機板一樣，會有很多插槽，無論你要建立什麼樣的管理系統，這些功能都將輕鬆整合在一起。
4、 生命週期很長
因為建立了業務架構和技術架構協調一體的機制，所以其生存的根本就在於能夠順應企業的發展，通過敏捷開發的方式來實現軟體的生命週期模型。這些因素都有效地驅動了軟體的持續完善，從根本上保證了管理軟體和企業發展的動態平衡關係，使軟體具備較長的生命週期。
在業務架構和技術架構協調一體的同時，漸漸發現，因為企業的應用越來越多，企業應用的多樣性、複雜性以及它們直接相互關聯互動的需求增強，已經越來越多的企業從應用層上公升到了資料層，如果還是像傳統軟體一樣，將資料儲存在系統檔案中，那麼這個所謂模組化的「業務基礎架構軟體」仍然無法發揮他的威力。
這時候就應該將資訊系統架構提到業務架構和技術架構的高度，協同解決。我們稱之為「業務架構、資訊架構、技術架構三位一體」
很榮幸，從2023年開始，我主導了一款餐飲行業應用軟體的設計和規劃工作。這一年半的時間裡，在專案組摸索尋找這種一體化的工作方法。其實並不是三種架構都在同乙個地方等你，而是走著走著發現問題，然後乙個乙個的撿起來，最後發現其實一開始三者是可以結合成一體的。
在資訊架構中，我們不僅將企業資料儲存到資料庫中，而且將這一資料庫儲存到統一的伺服器中，作為資料層開放。採用c/s結構，讓客戶和伺服器實時互動，系統記錄客戶的運算元據，通過對這些資料的分析歸納，做出行業通用的業務模型。客戶通過與伺服器的鏈結，可以任意的在功能池子中選擇自己需要的模組。
ibm在介紹其db2purexml時曾經提到：「由於這種開放的服務特性，這類核心資訊在服務各種業務的過程中必然需要考慮很大的差異性和複雜性，必然需要把資料的儲存和資料的訪問隔離。資料的差異性和複雜性將對資料模型的靈活性和可擴充套件性提出更高的要求，而資料的訪問和底層儲存的隔離，將直接導致未來越來越多的應用通過xml的服務介面獲取資訊而非用sql直接訪問底層資料庫表。」
是的，這正是saas成為行業趨勢的原因，軟體應該是「軟性」的，它能夠順應企業發展的需求，而不應該讓企業去順應軟體。業務架構、資訊架構、技術架構也正是saas的精髓所在。
業務 技術和架構
這兩天準備要接手天津商行的專案。但是在接手的過程中，對整個專案的理解卻是非常的困難。最大的問題，就是對業務的不理解。天津商行的這個專案不大，核心的業務就是日結，及其圍繞在日結之周圍的一些相關業務。其實也並不是特別的複雜，但是轉來轉去，開賬閉賬，憑證科目什麼的，的確對乙個財務的門外漢是異常的頭痛。雖然...
架構 專案 產品三位一體
寫 寫的久了考慮問題就不單純從 本身去考慮了，今天梳理一些語言基礎時突然想到這個話題，展開寫點自己的經驗和想法。對公司來說真正關心的是提供的產品和服務是否有足夠的競爭力，以給公司帶來可觀的收益，這個時候產品層面的重要性就體現出來了。一般來說，公司提供的產品都有相應的產品規劃，聚焦在哪些產品上怎麼體現...
細品架構9 100 技術 業務和架構之間的關係
在軟體設計開發的過程中經常會看到，很多所謂的架構討論實際上只是在討論某種技術。在很多人的概念裡面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術都是為了解決某種問題而存在的，學會了技術，並不代...