什么是架構？

passthru

瀏覽了CU架構設計欄目的幾個有關架構的貼，我感到，幾乎所有在CU發(fā)表過看法人都對架構是什么？架構師有什么責任？概念很模糊。對此，我提出個人的看法。

我想，我們先把我上面提到的兩個問題放放，等到一些前提確定下來，我們再回頭對這個兩個問題做定義。

假設要搭建覆蓋全球的一個綜合應用系統(tǒng)，這個系統(tǒng)有功能點有5000萬個，并且覆蓋3000個業(yè)務領域范圍，同時貫穿于50億個業(yè)務種類的交易。而且，搭建這個應用系統(tǒng)后，對給使用這個應用系統(tǒng)終端的一個客戶，無論這個客戶在世界上哪一個主要城市，這個應用系統(tǒng)的響應時間要小于三秒鐘。

我們可以初步估計，要搭建這個綜合應用系統(tǒng)，經(jīng)過整合的業(yè)務架構大概在3000個左右；有世界上各類計算機廠商的各類計算機平臺和處理單元部件；有實現(xiàn)這個應用架構的各類網(wǎng)絡結構組件和技術，包括云技術、層次和區(qū)域劃分；架構中有總架構師，有各層次的分架構師；有項目主管理團隊，有各層次的分項目管理團隊；對3000個左右的業(yè)務，按業(yè)務分類，有首席業(yè)務專家，有相關的業(yè)務的專家群；在搭建好項目模塊部件后，有相應的實施團隊和相應的實施技術；等等、等等。

在這個應用場景下，從上到下描述架構，架構就是應用系統(tǒng)的輪廓，是一個虛擬的框架；在一個具體業(yè)務范圍內，業(yè)務架構是把業(yè)務需求，按照一定的模型構造出的沒有重疊的業(yè)務架構，可以付諸在硬件系統(tǒng)架構層硬件平臺，實施于一個或多個應用子系統(tǒng)。架構是介于應用業(yè)務需求和實施技術之間一個腳手架。這就是架構。

在這樣的應用系統(tǒng)搭建環(huán)境下，架構師沒有業(yè)務的概念，就是制造能夠方便梳理業(yè)務的架構模型，把業(yè)務專家提出來的，沒有梳理過、交叉的處理業(yè)務邏輯、流程和數(shù)據(jù)，經(jīng)過業(yè)務模型，形成業(yè)務架構；把成型的業(yè)務架構，在一個系統(tǒng)架構層面上，通過能夠實現(xiàn)業(yè)務架構的實施團隊和相關的技術，付諸實施在能夠發(fā)揮應用系統(tǒng)運行效率的硬件平臺上。

passthru

做點上述貼的補充

wang3320

我來學習下，謝謝了。

linghuchun

路過,學習學習.

passthru

我的blog：passthru.cublog.cn

passthru

   

業(yè)務架構的重要性

    我們在一個行業(yè)做項目實施有10年以上經(jīng)歷，比如銀行業(yè)，我們會發(fā)現(xiàn)，銀行核心系統(tǒng)每過三五年，就會有一次大調整，甚至推翻舊核心，重新做新的核心。這個核心更新周期，隨著經(jīng)濟發(fā)展的速度起伏，做相應的調整。經(jīng)濟發(fā)展速度放緩，更新核心周期就相對長一些；經(jīng)濟發(fā)展速度如果加速，更新核心周期，就相對短一些。
     其它行業(yè)也有相同的更新核心的周期。
     往往我們在做新核心更新項目啟動論證時，我們幾乎都會有相同的結論：對舊核心布布丁丁已經(jīng)到了不能實施的地步，舊的核心架構已經(jīng)不能滿足現(xiàn)有的，或將來可預見的業(yè)務需要，所以必須啟動核心項目改造，用新的核心架構代替舊的核心架構。
     我們對舊核心進行分析時，我們就會發(fā)現(xiàn)舊核心的復雜層度已經(jīng)大大超出我們能夠理解接受的范圍，就是說核心中的一大部分的功能點，存在重復，或部分重復功能點。如果，因為業(yè)務的需要，對一個功能點進行功能拆分，或多個已經(jīng)存在的功能點進行合并，其結果，我們沒有辦法預見做了這個功能拆分，或合并，會對整個核心系統(tǒng)有什么影響？對這個風險，沒有一個人敢拍著胸脯，敢承擔。
     這種現(xiàn)象，對各行各業(yè)，對IT行業(yè)，無論是應用系統(tǒng)，或軟件產(chǎn)品，都是一個結癥，都有一個更新周期。圈內人對應用系統(tǒng)，或軟件產(chǎn)品，已經(jīng)固化了架構；圈外人有新的思想，想在找一個突破口，無論通過何種途徑，有人際關系、架構、實施技術，等等。
     圈外人即使突破替代圈內人，或并列成為圈內人，過了三五年，可能被新的圈外人同樣取代或并列。
     我們不禁要問，為什么會有這樣的現(xiàn)象發(fā)生？然道在圈內的人比圈外的人智商低嗎？或圈外人進入圈內后，智商被弱化了嗎？
     我個人的看法，關鍵是有無一個能夠梳理業(yè)務需求的業(yè)務架構。
     以往應用系統(tǒng)實施，或軟件產(chǎn)品研發(fā)，幾乎都沒有一個能夠梳理業(yè)務需求的業(yè)務架構。沒有這個梳理業(yè)務需求的業(yè)務架構，和用這個架構梳理的過程，即使新的應用系統(tǒng)或軟件產(chǎn)品“成功上線”，已經(jīng)存在的大量的重復功能點，和運維期間不斷積累的重復功能點，又會把應用系統(tǒng)，或軟件產(chǎn)品推到一個死胡同；又把我們推到一個不得不進入的更新周期中。
     各行各業(yè)有的是比IT人員更專業(yè)的業(yè)務專家。業(yè)務專家從未梳理過多線條的業(yè)務流程功能點，特別是復雜交叉、有重復的功能點，因為每一個業(yè)務專家，由于部門分工不同，他們各自只對他們的一畝三分田的業(yè)務比較熟悉。從而，他們從未考慮過業(yè)務功能點重疊會給IT項目實施帶來難題。
      ​IT人員的優(yōu)勢，特別是架構師，他們會采用業(yè)務架構來梳理業(yè)務需求。但是，如果IT人員若沒有意識到業(yè)務架構的重要性，勢必會跟隨業(yè)務專家的意識，被動地拖入到周期性的更新循環(huán)當中。

passthru

補充一點：

如果采用SOA理念設計的業(yè)務架構，對一個500萬左右的項目中實施，效果是驚人的。

按傳統(tǒng)做法項目實施，項目經(jīng)理計劃采用20人，10個月工期，而且項目經(jīng)理還不保證項目能夠按期完成；采用SOA理念架構做業(yè)務架構梳理業(yè)務，在項目實施過程中，邊做編碼和測試，邊按架構進行架構完善設計，即一方面進行業(yè)務需求的梳理；一方面又進行架構的完善、編碼和測試。項目在實施過程中，僅兩個主力編程，10個月后項目按期上線。在項目實施過程中，在任意時間內，業(yè)務需求都可以隨時增加和調整。在運維期間，運維人員只有一個，業(yè)務需求也可以隨時增加，再按業(yè)務架構，梳理到相應的架構中。

dinglang_2009

主要還是 基礎架構(運維)+軟件架構

pitonas

什么是架構？對此，我概念很模糊。

passthru

     架構的定義很廣泛。
     我們經(jīng)常說的架構是通常都是泛泛指軟件架構、軟件工程架構、網(wǎng)絡拓撲架構、程序架構、軟件項目業(yè)務模塊架構等等，與IT有關的領域。所以，我們無形當中，就把架構定義窄義化了。

    從幾何學的角度出發(fā)，不在同一個平面上的四個點才能有“架”。在這個條件下，大于四個點，并且大于四個平面組合的型才能形成“架構”。

    IT領域的各類架構都像生活里其它架構一樣，都是從需求開始，需求積累到一定程度，就要對需求進行梳理，這個梳理需求的工具就是架構；把需求轉換為有型的流處理，處理的形態(tài)就是架構的體現(xiàn)。對一個領域的業(yè)務，比如軟件產(chǎn)品設計、網(wǎng)絡工程實施部署和管理、銀行業(yè)務、保險業(yè)務、ERP制造工作流管理、ERP物流流程管理等等，都屬于各自領域的業(yè)務范圍。對某種業(yè)務范圍需求的梳理就是業(yè)務架構。

    做一個比喻，有了架構，就像蓋房屋，業(yè)務流程就是屋樑或支柱，屋樑支柱在什么地方擺放，是架構已經(jīng)設計好的位置，屋樑擺放是橫的，支柱擺放是豎立的。否則，沒有架構，屋樑支柱的擺放起不了支撐的作用。

    我的經(jīng)驗是用SOA理念設計的業(yè)務架構，并且在這個業(yè)務架構上各個功能點功能唯一；按照業(yè)務需求，通過這個業(yè)務架構設計出來的業(yè)務處理流程都是唯一的，這才是我需要的業(yè)務架構。做不到這兩點的業(yè)務架構有存在這樣或那樣的缺陷。