注冊 | 登錄讀書好,好讀書,讀好書!
讀書網(wǎng)-DuShu.com
當前位置: 首頁出版圖書科學技術計算機/網(wǎng)絡信息系統(tǒng)企業(yè)架構實用指南

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

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

定 價:¥32.00

作 者: James McGovern[等]著;李琦,郭耀譯;李琦譯
出版社: 清華大學出版社
叢編項:
標 簽: 暫缺

ISBN: 9787302114017 出版時間: 2005-09-01 包裝: 膠版紙
開本: 23cm 頁數(shù): 249 字數(shù):  

內(nèi)容簡介

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

作者簡介

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

圖書目錄

第1章 系統(tǒng)架構 1
1.1 卡納夏引入外來的架構師 2
1.1.1 基礎設施的架構方法 3
1.1.2 其他關于系統(tǒng)架構的關注點 4
1.1.3 工作于現(xiàn)有的系統(tǒng)架構 5
1.1.4 系統(tǒng)架構類型 6
1.1.5 使用系統(tǒng)架構增強系統(tǒng)價值 12
1.2 網(wǎng)絡協(xié)議 13
1.2.1 TCP/IP 13
1.2.2 其他協(xié)議 15
1.2.3 系統(tǒng)架構和業(yè)務智能 17
1.2.4 服務層協(xié)議 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 系統(tǒng)涉眾 33
2.5 創(chuàng)建軟件架構的例子 34
2.5.1 業(yè)務實例 36
2.5.2 理解需求 36
2.5.3 創(chuàng)建或者選擇架構 36
2.5.4 架構表示及通信 39
2.5.5 分析和評估架構 40
2.5.6 保證一致 41
2.6 架構描述語言與UML 41
2.7 品質屬性 42
非功能性需求和品質屬性 47
2.8 架構級的觀點 48
2.8.1 軟件架構的4+1視圖模型 48
2.8.2 應用軟件架構觀點 49
2.9 架構級風格、模式和隱喻 51
2.10 小結 53
第3章 面向服務的架構 54
3.1 SOA的優(yōu)點 54
3.2 SOA的特征 57
3.2.1 服務具有明確定義的接口與
策略 57
3.2.2 服務代表業(yè)務領域 61
3.2.3 服務擁有模件化的設計 62
3.2.4 服務應該被松散地耦合在
一起 63
3.2.5 服務是可以被發(fā)現(xiàn)并且支持
內(nèi)省的 64
3.2.6 服務是獨立于傳輸機制的 65
3.2.7 服務的位置是對客戶
透明的 65
3.2.8 服務應該是獨立于平臺的 65
3.3 Web服務 66
Web服務的問題 68
3.4 卡納夏的服務 69
3.4.1 卡納夏的SOA分析 69
3.4.2 內(nèi)部服務 69
3.4.3 卡納夏的Web服務 71
3.4.4 國際化 71
3.5 SOA的問題 71
3.6 SOA管理 73
3.7 SOA的最佳實踐 75
3.8 SOA反面典型 76
3.8.1 SOA就是一切?;A設施
什么都不是 76
3.8.2 關于SOA,我們只需知道
Web服務就可以了嗎 76
3.8.3 SOA講的是技術 77
3.8.4 任何東西都是一項服務 77
3.9 小結 77
第4章 軟件產(chǎn)品線 78
4.1 卡納夏的產(chǎn)品線 79
4.2 產(chǎn)品線的歷史 80
制造業(yè)隱喻 81
4.3 軟件產(chǎn)品線是什么 81
4.3.1 核心資產(chǎn)開發(fā) 82
4.3.2 產(chǎn)品開發(fā) 83
4.3.3 管理 83
4.4 產(chǎn)品線的優(yōu)點 83
4.4.1 降低的費用 83
4.4.2 縮短上市時間 84
4.4.3 靈活的人員配備和生產(chǎn)能力 84
4.4.4 更高的可預測性 84
4.4.5 更高的品質 84
4.5 產(chǎn)品線特性 84
4.5.1 相關的業(yè)務優(yōu)勢 85
4.5.2 核心資產(chǎn) 85
4.5.3 共享的技術和工具 89
4.5.4 支持組織 90
4.6 小結 96
第5章 方法學概述 97
5.1 軟件開發(fā)生命周期 98
SDLC的變化 99
5.2 極限編程 100
5.2.1 持續(xù)的計劃 102
5.2.2 持續(xù)的設計 102
5.2.3 持續(xù)的編碼 103
5.2.4 持續(xù)的測試 104
5.2.5 XP好處和不足 105
5.3 SEI/CMM 105
5.3.1 初始級 107
5.3.2 可重復級 107
5.3.3 已定義級 108
5.3.4 已管理級 108
5.3.5 優(yōu)化級 109
5.3.6 CMM的好處和不足 109
5.4 Zachman框架 110
Zachman框架的優(yōu)缺點 112
5.5 模型驅動的架構 113
MDA 的優(yōu)缺點 114
5.6 Rational統(tǒng)一過程(Rational Unified
Process) 116
5.6.1 統(tǒng)一建模語言(UML) 117
5.6.2 核心過程流程(Core Process
Discipline) 117
5.6.3 Rational工具集 119
5.6.4 RUP的優(yōu)缺點 119
5.7 使用這些方法學 120
5.8 小結 122
第6章 企業(yè)統(tǒng)一過程 123
6.1 企業(yè)統(tǒng)一過程概述 124
6.2 產(chǎn)品階段 125
6.3 退休階段 126
6.4 運作和支持流程 127
6.5 企業(yè)管理流程 127
6.6 為何要采用EUP 128
6.7 小結 128
第7章 敏捷架構 129
7.1 敏捷簡介 129
7.2 傳統(tǒng)企業(yè)架構方法的潛在問題 131
7.3 一個架構的敏捷方法 132
7.3.1 聚焦于人,而不是工藝或
技術 132
7.3.2 保持簡單 134
7.3.3 迭代和遞增地工作 134
7.3.4 親自動手 135
7.3.5 在開口談論之前先實踐 136
7.3.6 觀察全局 136
7.3.7 讓架構吸引你的客戶 136
7.4 敏捷架構的投入所產(chǎn)生的結果 136
7.5 卡納夏的敏捷架構 137
7.6 在你的組織中引入敏捷方法 139
7.7 還有其他架構是敏捷的嗎 140
7.8 敏捷方法的潛在問題 141
7.9 小結 142
第8章 敏捷建模 143
8.1 敏捷建模的目的 143
8.1.1 價值觀 144
8.1.2 敏捷建模的原則 145
8.1.3 敏捷建模實踐 148
8.2 敏捷模型 150
8.3 敏捷文檔 152
對架構師的影響 152
8.4 小結 153
第9章 表示層架構 154
業(yè)務需求和表示要求 154
9.1 關鍵表示層組件 155
9.1.1 主表示層組件 155
9.1.2 次表示層組件 157
9.1.3 業(yè)務層組件 160
9.1.4 數(shù)據(jù)層組件 160
9.2 通用設計建議 161
設計表示層 162
9.3 界面組件的設計綱要 164
設計用戶界面過程組件 169
9.4 小結 174
第10章 可用性和用戶體驗 175
10.1 理解可用性 176
10.2 用戶體驗組件 178
人機交互原則 179
10.3 可用性和用戶體驗設計過程 184
10.4 可用性技術 185
10.4.1 需求階段 185
10.4.2 設計、開發(fā)和測試階段 188
10.4.3 實施以及進行改良 189
10.5 共享可用性測試報告 189
10.6 即購即用體驗 190
10.7 小結 191
第11章 數(shù)據(jù)架構 192
11.1 業(yè)務問題 192
11.2 基準線數(shù)據(jù)架構 193
11.3 框架 195
11.3.1 業(yè)務架構 196
11.3.2 業(yè)務對象建模 197
11.3.3 業(yè)務數(shù)據(jù) 197
11.3.4 架構 199
11.3.5 驗證和最終復查 199
11.4 元數(shù)據(jù) 199
聯(lián)合元數(shù)據(jù) 200
11.5 高級元數(shù)據(jù)架構 204
對業(yè)務問題應用元數(shù)據(jù) 205
11.6 數(shù)據(jù)安全 205
11.7 敏捷數(shù)據(jù)庫技術 206
11.7.1 運用敏捷方法 207
11.7.2 使用腳本工作 209
11.7.3 規(guī)格化 211
11.8 小結 217
第12章 思想領袖 219
12.1 組織矩陣 219
12.2 外包和核心能力 219
12.3 強有力的技術領導 221
12.4 架構師面對時代的考驗 222
12.5 對最佳實踐的熱衷追逐 223
12.6 敏捷CIO 224
12.7 神奇的開放源碼 225
12.8 101咨詢師 226
12.9 為什么我應該成為CIO 227
12.10 下一時刻 228
12.11 小結 228
附錄A 業(yè)務案例 229
附錄B 實用的考慮 232
附錄C 敏捷企業(yè)架構的七種習慣 233
附錄D 模型 234
附錄E 參考文獻 236
附錄F 進階閱讀 241
敏捷 241
數(shù)據(jù)架構和數(shù)據(jù)庫 241
開發(fā) 242
企業(yè)架構 242
模式 242
表示和可用性 243
職業(yè) 243
面向服務的架構 243
軟件架構 243
UML 244
其他主題 244
附錄G 未來的書 246
關于作者 248

本目錄推薦

掃描二維碼
Copyright ? 讀書網(wǎng) ranfinancial.com 2005-2020, All Rights Reserved.
鄂ICP備15019699號 鄂公網(wǎng)安備 42010302001612號