企業架構實用指南

《企業架構實用指南》是清華大學出版社出版的圖書，作者是麥克高文。該書超越了理論，基於跨越多個行業立面組織中的實際經驗，講解了企業架構的策略。

基本介紹

• 書名：企業架構實用指南
• 作者：麥克高文
• 譯者：李琦郭耀
• 出版社：清華大學出版社

基本信息

作者: 麥克高文

譯者: 李琦郭耀

出版社: 清華大學出版社

出版年: 2005-9

頁數: 247

定價: 32.0

裝幀: 平裝

ISBN:9787302114017

內容簡介

來自傑出企業構架師的不可或缺的技術、過程和業務觀點。

當前許多企業組織面臨著設計、建造和維護大規模分散式企業系統的挑戰，以便能夠適應不斷變化的業務需要。許多人重複著其他人的錯誤，導致費用超支、完成日期拖延，乃至喪失了機遇。今日的商業環境為IT造成額外的交付負擔。不斷調整的業務驅動脫離了當前的企業IT系統能力；尤其如果系統是複雜、脆弱，難以容納變化的。企業架構能有助於今天做出前瞻性的IT投資。

企業架構實用指南幫助讀者為企業架構的成功實現而建立適應性的架構策略。每個觀點、技術和原則之後是由今日最知名的業界領袖提供的豐富知識。

幾位作者已為金融服務、電信、傳媒和電子商務領域中許多全球傑出企業架構了工業級的軟體和基礎設施。他們講解了實踐指南，對已有的實踐進行坦率的評價，並從親身經驗中提供詳細的實例。　

作譯者

JAMES MCGOVERN哈特福德金融服務公司(Hartford Financial Service)企業架構師．是暢銷書Java Web Service Architecture和Agile Enterprise Architecture的作者之一。SCOTT W．AMBLER．Ronin國際公司(RoninInternational)資深顧問．專攻面向對象的分析/設計．敏捷建模和重要系統架構審計。他的暢銷書包括Agile Modeling和The Elements of Java Style。MICHAEL E．STEVENS．哈特福德金融服務公司軟體架構師，是Developer．com的專欄作家。他是Java Web Services Architecture的作者之一。JAMES LINN．哈..

目錄

第1章 系統架構 1

1.1 卡納夏引入外來的架構師 2

1.1.1 基礎設施的架構方法 3

1.1.2 其他關於系統架構的關注點 4

1.1.3 工作於現有的系統架構 5

1.1.4 系統架構類型 6

1.1.5 使用系統架構增強系統價值 12

1.2 網路協定 13

1.2.1 tcp/ip 13

1.2.2 其他協定 15

1.2.3 系統架構和業務智慧型 17

1.2.4 服務層協定 19

1.3 小結 27

第2章 軟體架構 29

2.1 軟體架構的定義 30

2.2 軟體架構師的角色 30

2.3 為什麼需要軟體架構 31

2.3.1 兩個極端 32

2.3.2 折中方案 32

2.4 系統涉眾 33

前言

從前，某位訓練有素的科學家在他的實驗室里工作，他把盛滿試劑液的燒杯放到本生燈上，又拿起另一個燒杯，把內盛的試劑倒到前一個燒杯里。隨著溫度的升高，混合液的顏色開始變化，隨即突然泡騰起來，散發出非常美妙的芳香。

“我找到了！”科學家歡呼著衝出實驗室，把這個好訊息帶給他的主管們。

“我們一定要將它立即投產！”CEO說，“我們今年就能賣20億加侖！”

於是建築隊受命修建一個200英尺高的本生燈以及220英尺高的基座來安放50萬加侖的燒杯，還需要建一個500英尺高的起重機來高高舉起第二個燒杯，以便把內盛液體傾倒於第一個燒杯里製成混合液。

然而，不行，這樣的做法將會是愚不可及的。實驗室中的試驗和大規模生產相當不同。因此，企業系統若和實驗室的原型系統採用同一架構，未免有點古怪，是愚不可及的。企業系統異於諸如“餐廳區域網路”式的原型小系統，但是這種差異體現於架構，而不是設計思想。可是架構經常會被混淆於設計。架構表現的是在某類事物中普適的特徵、結構、行為和關係。設計表現的是細節，說明某類事物中特定的個體該如何建造。

架構和設計總是存在的。但在許多時候，它們埋沒在程式設計師的意識里，蹤影難覓。如果現在所有的程式設計師都是精幹的架構師/設計師，如果大家都具備長期卓有成效的企業系統開發經驗，如果大家在開發企業系統或其他相關項目時都願意和其他程式設計師交流思想，如果在系統開發完成後不需要其他人員做維護、甚至另起爐灶再開發一個新的企業系統，那么架構和設計難覓蹤影的狀況會一去不返。可惜實際情況並非如此，而是恰恰相反。

因而，架構和設計必須分開，並且明確化。架構由知識豐富的專家製造，負責溝通、啟發和領導。僅有設計是不夠的。企業系統的設計必須適合此類系統的外延功能需求——可伸縮性、完整性、靈活性、可建造性等——這些都是由架構決定的。

企業系統經常失敗的一個重要原因是架構和設計被合併。其他一些和企業系統同樣複雜的人類活動，並沒有出現和這些大型IT項目相同的失敗率。這是為什麼？我的回答是當前IT產業在三個主要方面存在顯著欠缺：

* 企業層的架構(企業架構)。

* 支持企業架構的工具。

* 支持企業架構的組織。

架構知識的燃眉之需

設計一個企業系統是困難的。它要求大量的知識和技巧。在其他產業中，專業人員在開始工作前就被授予許多必要的知識。這些產業可以說是“知識專門化”。知識被劃分為各個專門的需求領域。在建築業里，建築師知道工廠設計和公寓設計是相當不同的，公寓設計又與教堂設計和辦公樓設計不同。又如，工程師明白設計磁碟驅動器和設計飛機是相當不同的(儘管它們都會用到空氣動力學)。汽車設計師了解十八輪大貨車的設計和家用轎車的設計不同。所有領域都有它自己的架構，設計特定的產品要遵從它的架構。

在一個產業中，每個被關注領域以所謂的“架構方法”(architectural approach)為特徵。(Richard Hubert稱之為“架構風格”，參見Convergent Architecture，Wiley，2002。)涉及不同架構方法產品的項目少有相同之處，相反地，生產含有相同架構方法產品的項目會有許多共同點。因而，項目中所使用的技術和工具也可能是相同的。設計特定的產品有據可查，有章可循，由架構方法規定其中的設計。那些跨領域(有些時候還會跨產業)的普適技術是非常重要的，但更重要的是這些技術對各種架構方法的不同套用。

按照客戶需求的架構方法，製造產品所需的知識各有差別，客戶經常會指定架構方法：亦即，你會聽到“我需要一輛家用汽車”，而絕少聽說“我需要一輛車”。

我們的產業倚重於技術，較少倚靠架構方法。顯然，一個單機的圖形用戶界面應用程式和一個企業系統相當不同，這兩者又都不同於一個工廠自動控制系統。這些套用系統都各自體現著不同的架構方法，架構方法服務於相應的那類套用系統項目，這類項目具備大量普適知識。然而，許多IT項目仍然由掌握著一套技術工具的專業人員著手進行，他們並不具備必需的有關架構方法的知識，而不得不在項目開發過程中艱難地逐漸學習。顯而易見，因為項目架構師們被迫一邊自學一邊探索，許多項目無法表達出所需的信息。

我們需要掌握有關架構的知識，並使它套用於我們的產業。本書為滿足這個需求而跨出了重要一步。

架構工具的迫切之需

世上計算機化程度最低的組織機構可能是IT套用系統開發機構。不過，等一下！它們不是在每張工作檯上都有昂貴的PC和網路連線，並且裝配著昂貴的軟體開發工具嗎？當然，不錯。然而它們中相當一部分仍然停留在棉紡產業的工業化水平上。猶如一夥機械工程師被要求用他們的本行工具——焊槍、車床、千斤頂——來製造一種新型汽車。設計方案交予了他們，詳細到每一個螺母和螺釘，但是沒有針對“這類汽車”架構方法的產品線(或者基礎設施)縫合生產過程。他們80%的精力用於建造這些產品線，只有20%的精力用於生產所需數量的汽車。當他們完成時，早已超過了預算經費和期限。他們的產品線也該被丟棄了，因為這是為某類特定型號汽車而修建的。

同樣，套用系統開發人員也可能具備良好的工具和精深的技巧，但是沒有架構方法來教授、規約、定義開發人員的努力。每個項目必須定義它自己的企業架構，並建造自己的基礎設施、“粘合”代碼、過程定製等(產品線)。當前的工具支持特定的技能與技術，可在多個架構方法間通用。但是，我們沒有能夠支持特定的架構方法的工具——稱為“架構支持工具”。也許這就是我們的開發過程被割裂的緣故：一個可用的過程針對一個架構方法。然而許多通用過程要求額外的縫合和定製。你最近什麼時候看到過市面上某個通用客戶關係管理(CRM)過程是可以用來解決你的CRM的過程需求的？為了提高效率，過程必須是有針對性的——直到底層步驟。它們必須以製造出你的所需為目的。缺乏此類定位就是當前許多無目標(並且刻意如此)的超重過程被廣泛拒用的原因。