企業(yè)架構(gòu)實用指南

　　來自杰出企業(yè)構(gòu)架師的不可或缺的技術(shù)、過程和業(yè)務觀點。當前許多企業(yè)組織面臨著設(shè)計、建造和維護大規(guī)模分布式企業(yè)系統(tǒng)的挑戰(zhàn)，以便能夠適應不斷變化的業(yè)務需要。許多人重復著其他人的錯誤，導致費用超支、完成日期拖延，乃至喪失了機遇。今日的商業(yè)環(huán)境為IT造成額外的交付負擔。不斷調(diào)整的業(yè)務驅(qū)動脫離了當前的企業(yè)IT系統(tǒng)能力；尤其如果系統(tǒng)是復雜、脆弱，難以容納變化的。企業(yè)架構(gòu)能有助于今天做出前瞻性的IT投資。企業(yè)架構(gòu)實用指南幫助讀者為企業(yè)架構(gòu)的成功實現(xiàn)而建立適應性的架構(gòu)策略。這本經(jīng)典的手冊超越了理論，基于跨越多個行業(yè)立面組織中的實際經(jīng)驗，講解了企業(yè)架構(gòu)的策略。每個觀點、技術(shù)和原則之后是由今日最知名的業(yè)界領(lǐng)袖提供的豐富知識。幾位作者已為金融服務、電信、傳媒和電子商務領(lǐng)域中許多全球杰出企業(yè)架構(gòu)了工業(yè)級的軟件和基礎(chǔ)設(shè)施。他們講解了實踐指南，對已有的實踐進行坦率的評價，并從親身經(jīng)驗中提供詳細的實例。本書前言從前，某位訓練有素的科學家在他的實驗室里工作，他把盛滿試劑液的燒杯放到本生燈上，又拿起另一個燒杯，把內(nèi)盛的試劑倒到前一個燒杯里。隨著溫度的升高，混合液的顏色開始變化，隨即突然泡騰起來，散發(fā)出非常美妙的芳香。“我找到了！”科學家歡呼著沖出實驗室，把這個好消息帶給他的主管們?！拔覀円欢ㄒ獙⑺⒓赐懂a(chǎn)！”CEO說，“我們今年就能賣20億加侖！”于是建筑隊受命修建一個200英尺高的本生燈以及220英尺高的基座來安放50萬加侖的燒杯，還需要建一個500英尺高的起重機來高高舉起第二個燒杯，以便把內(nèi)盛液體傾倒于第一個燒杯里制成混合液。然而，不行，這樣的做法將會是愚不可及的。實驗室中的試驗和大規(guī)模生產(chǎn)相當不同。因此，企業(yè)系統(tǒng)若和實驗室的原型系統(tǒng)采用同一架構(gòu)，未免有點古怪，是愚不可及的。企業(yè)系統(tǒng)異于諸如“餐廳局域網(wǎng)”式的原型小系統(tǒng)，但是這種差異體現(xiàn)于架構(gòu)，而不是設(shè)計思想?？墒羌軜?gòu)經(jīng)常會被混淆于設(shè)計。架構(gòu)表現(xiàn)的是在某類事物中普適的特征、結(jié)構(gòu)、行為和關(guān)系。設(shè)計表現(xiàn)的是細節(jié)，說明某類事物中特定的個體該如何建造。架構(gòu)和設(shè)計總是存在的。但在許多時候，它們埋沒在程序員的意識里，蹤影難覓。如果現(xiàn)在所有的程序員都是精干的架構(gòu)師/設(shè)計師，如果大家都具備長期卓有成效的企業(yè)系統(tǒng)開發(fā)經(jīng)驗，如果大家在開發(fā)企業(yè)系統(tǒng)或其他相關(guān)項目時都愿意和其他程序員交流思想，如果在系統(tǒng)開發(fā)完成后不需要其他人員做維護、甚至另起爐灶再開發(fā)一個新的企業(yè)系統(tǒng)，那么架構(gòu)和設(shè)計難覓蹤影的狀況會一去不返。可惜實際情況并非如此，而是恰恰相反。因而，架構(gòu)和設(shè)計必須分開，并且明確化。架構(gòu)由知識豐富的專家制造，負責溝通、啟發(fā)和領(lǐng)導。僅有設(shè)計是不夠的。企業(yè)系統(tǒng)的設(shè)計必須適合此類系統(tǒng)的外延功能需求——可伸縮性、完整性、靈活性、可建造性等——這些都是由架構(gòu)決定的。企業(yè)系統(tǒng)經(jīng)常失敗的一個重要原因是架構(gòu)和設(shè)計被合并。其他一些和企業(yè)系統(tǒng)同樣復雜的人類活動，并沒有出現(xiàn)和這些大型IT項目相同的失敗率。這是為什么？我的回答是當前IT產(chǎn)業(yè)在三個主要方面存在顯著欠缺：*企業(yè)層的架構(gòu)（企業(yè)架構(gòu)）。*支持企業(yè)架構(gòu)的工具。*支持企業(yè)架構(gòu)的組織。架構(gòu)知識的燃眉之需設(shè)計一個企業(yè)系統(tǒng)是困難的。它要求大量的知識和技巧。在其他產(chǎn)業(yè)中，專業(yè)人員在開始工作前就被授予許多必要的知識。這些產(chǎn)業(yè)可以說是“知識專門化”。知識被劃分為各個專門的需求領(lǐng)域。在建筑業(yè)里，建筑師知道工廠設(shè)計和公寓設(shè)計是相當不同的，公寓設(shè)計又與教堂設(shè)計和辦公樓設(shè)計不同。又如，工程師明白設(shè)計磁盤驅(qū)動器和設(shè)計飛機是相當不同的（盡管它們都會用到空氣動力學）。汽車設(shè)計師了解十八輪大貨車的設(shè)計和家用轎車的設(shè)計不同。所有領(lǐng)域都有它自己的架構(gòu)，設(shè)計特定的產(chǎn)品要遵從它的架構(gòu)。在一個產(chǎn)業(yè)中，每個被關(guān)注領(lǐng)域以所謂的“架構(gòu)方法”（architecturalapproach）為特征。（RichardHubert稱之為“架構(gòu)風格”，參見ConvergentArchitecture，Wiley，2002。）涉及不同架構(gòu)方法產(chǎn)品的項目少有相同之處，相反地，生產(chǎn)含有相同架構(gòu)方法產(chǎn)品的項目會有許多共同點。因而，項目中所使用的技術(shù)和工具也可能是相同的。設(shè)計特定的產(chǎn)品有據(jù)可查，有章可循，由架構(gòu)方法規(guī)定其中的設(shè)計。那些跨領(lǐng)域（有些時候還會跨產(chǎn)業(yè)）的普適技術(shù)是非常重要的，但更重要的是這些技術(shù)對各種架構(gòu)方法的不同應用。按照客戶需求的架構(gòu)方法，制造產(chǎn)品所需的知識各有差別，客戶經(jīng)常會指定架構(gòu)方法：亦即，你會聽到“我需要一輛家用汽車”，而絕少聽說“我需要一輛車”。我們的產(chǎn)業(yè)倚重于技術(shù)，較少倚靠架構(gòu)方法。顯然，一個單機的圖形用戶界面應用程序和一個企業(yè)系統(tǒng)相當不同，這兩者又都不同于一個工廠自動控制系統(tǒng)。這些應用系統(tǒng)都各自體現(xiàn)著不同的架構(gòu)方法，架構(gòu)方法服務于相應的那類應用系統(tǒng)項目，這類項目具備大量普適知識。然而，許多IT項目仍然由掌握著一套技術(shù)工具的專業(yè)人員著手進行，他們并不具備必需的有關(guān)架構(gòu)方法的知識，而不得不在項目開發(fā)過程中艱難地逐漸學習。顯而易見，因為項目架構(gòu)師們被迫一邊自學一邊探索，許多項目無法表達出所需的信息。我們需要掌握有關(guān)架構(gòu)的知識，并使它應用于我們的產(chǎn)業(yè)。本書為滿足這個需求而跨出了重要一步。架構(gòu)工具的迫切之需世上計算機化程度最低的組織機構(gòu)可能是IT應用系統(tǒng)開發(fā)機構(gòu)。不過，等一下！它們不是在每張工作臺上都有昂貴的PC和網(wǎng)絡連接，并且裝配著昂貴的軟件開發(fā)工具嗎？當然，不錯。然而它們中相當一部分仍然停留在棉紡產(chǎn)業(yè)的工業(yè)化水平上。猶如一伙機械工程師被要求用他們的本行工具——焊槍、車床、千斤頂——來制造一種新型汽車。設(shè)計方案交予了他們，詳細到每一個螺母和螺釘，但是沒有針對“這類汽車”架構(gòu)方法的產(chǎn)品線（或者基礎(chǔ)設(shè)施）縫合生產(chǎn)過程。他們80%的精力用于建造這些產(chǎn)品線，只有20%的精力用于生產(chǎn)所需數(shù)量的汽車。當他們完成時，早已超過了預算經(jīng)費和期限。他們的產(chǎn)品線也該被丟棄了，因為這是為某類特定型號汽車而修建的。同樣，應用系統(tǒng)開發(fā)人員也可能具備良好的工具和精深的技巧，但是沒有架構(gòu)方法來教授、規(guī)約、定義開發(fā)人員的努力。每個項目必須定義它自己的企業(yè)架構(gòu)，并建造自己的基礎(chǔ)設(shè)施、“粘合”代碼、過程定制等（產(chǎn)品線）。當前的工具支持特定的技能與技術(shù)，可在多個架構(gòu)方法間通用。但是，我們沒有能夠支持特定的架構(gòu)方法的工具——稱為“架構(gòu)支持工具”。也許這就是我們的開發(fā)過程被割裂的緣故：一個可用的過程針對一個架構(gòu)方法。然而許多通用過程要求額外的縫合和定制。你最近什么時候看到過市面上某個通用客戶關(guān)系管理（CRM）過程是可以用來解決你的CRM的過程需求的？為了提高效率，過程必須是有針對性的——直到底層步驟。它們必須以制造出你的所需為目的。缺乏此類定位就是當前許多無目標（并且刻意如此）的超重過程被廣泛拒用的原因。我們需要支持工具來支持企業(yè)系統(tǒng)所要求的架構(gòu)方法，本書描述了許多對此類工具的需求。對適當組織的緊要之需設(shè)想一個IT部門擁有一批經(jīng)驗豐富的企業(yè)系統(tǒng)架構(gòu)師、能干而積極的開發(fā)人員，以及出色的工具和過程，包括企業(yè)架構(gòu)支持工具。這樣就一切齊備了嗎？可惜并不是。企業(yè)架構(gòu)師也需要一個合適的人員組織，架構(gòu)師在其中能如魚得水地發(fā)揮效用。衡量架構(gòu)師的效用的標準是應用系統(tǒng)開發(fā)項目工作的簡化程度。許多IT部門在項目（或產(chǎn)品）基礎(chǔ)上進行組織。除了一些基本的通用基礎(chǔ)設(shè)施，比如硬件、操作系統(tǒng)和數(shù)據(jù)庫管理系統(tǒng)（DBMS），每個項目都要自己決定其余部分。我見過許多創(chuàng)建者以這種方式安排人員和配備設(shè)施，但在可能是最困難的部分失敗了：人員組織出現(xiàn)了問題。一個解決這個問題的方法是把組織分為兩部分。一部分提供開發(fā)和運行時基礎(chǔ)設(shè)施來建立和使用企業(yè)應用系統(tǒng)，另一部分則制造企業(yè)應用系統(tǒng)。后者盡可能在技術(shù)、開發(fā)和企業(yè)構(gòu)架方法等諸多方面嚴格地促進前者。當前業(yè)界所采用的組織形式完全不是這樣的。無論組織最后怎么設(shè)定，重點在于組織是來支持某個特定的活動的。如果組織不能直接支持和啟動這種活動，那么就失敗在望了。為了讓應用系統(tǒng)開發(fā)項目成功運作而采用企業(yè)架構(gòu)，需要妥善考慮人員組織。本書將介紹有關(guān)企業(yè)架構(gòu)的組織形式。本書的重要性許多企業(yè)系統(tǒng)具有相同的架構(gòu)方法，這已然成為現(xiàn)今企業(yè)架構(gòu)領(lǐng)導者們間一個鼓舞人心的公論——雖然有些人使用不同的方式來表達，但相似的是都陳述了獨立于特定應用領(lǐng)域的種種技術(shù)、模式和設(shè)計，用來有效地制造出反應靈敏的、可伸縮的、靈活的、標準化的企業(yè)應用系統(tǒng)。本書的重要性在于從多方面概括了這種共性。本書從數(shù)據(jù)基礎(chǔ)要素（即計算機關(guān)機后永久保存的部分）到運行時軟件設(shè)計，到按關(guān)注面進行的架構(gòu)劃分，到可伸縮模式，乃至總被忽略的用戶界面，全方位地說明了一個成功企業(yè)系統(tǒng)所需的知識，并把許多標準綜合起來。本書的價值還在于：它不僅討論了需要建立些什么，而且談論了如何去建立從工具和模型，到開發(fā)過程和方法學，到產(chǎn)品線方法，到敏捷開發(fā)，也包括人員組織的重要問題。此外，本書的閃光點是作者們源自多年經(jīng)驗的、無懈可擊的、踏實實踐的工作經(jīng)驗和扎實技能。本書包括許多知識點——或者說介紹了許多知識點——采用易讀、中肯、不教條的方式講述，這正是一個成長中的企業(yè)架構(gòu)師所需要的。它是一本基礎(chǔ)性著作，可以作為企業(yè)架構(gòu)研究生課程的理想教材。實際上，我預期它能成為在我們這個神奇而生氣蓬勃的產(chǎn)業(yè)中，企業(yè)系統(tǒng)知識領(lǐng)域的重要組成部分。

　　麥克高文，哈特福德金融服務公司企業(yè)架構(gòu)師，是暢銷書Java Web Service Architecture 和Agile Enterprise Architecture的作者之一。SCOTT W.AMBLER，Ronin國際公司資深顧問，專攻面向?qū)ο蟮姆治?設(shè)計、敏捷建模和重要系統(tǒng)架構(gòu)審計。他的暢銷書包括Agile Modeling和The Elements of Java Style。