很多架構(gòu)師都是從好的開發(fā)人員逐步過渡而來的，但并非每個好的開發(fā)人員都希望成為架構(gòu)師，而且他們并不是都適合做架構(gòu)師。無論您是打算進(jìn)行職業(yè)轉(zhuǎn)型的開發(fā)人員，還是尋找能承擔(dān)體系結(jié)構(gòu)設(shè)計責(zé)任的合適人選的經(jīng)理，都務(wù)必對此轉(zhuǎn)型過程有個清楚的了解。本文將討論從實現(xiàn)專家到架構(gòu)師的過渡過程。
在尋找優(yōu)秀的指揮的時候，您首先要找的是一名優(yōu)秀的音樂演奏家。但并非每個音樂演奏家都能成為優(yōu)秀的指揮。架構(gòu)師的專業(yè)發(fā)展方面也與此類似。越來越多的 IT 組織開始認(rèn)識到良好軟件體系結(jié)構(gòu)的重要性，架構(gòu)師職業(yè)正迅速發(fā)展為 IT 內(nèi)一個獨立的門類。由于要從相當(dāng)小的候選范圍內(nèi)招募架構(gòu)師，因此這就給管理帶來了一些新挑戰(zhàn)。即使人力資源部門找到了候選者，針對經(jīng)驗進(jìn)行的篩選也比其他門類更為嚴(yán)格。跨越這些障礙的最快方式是要認(rèn)識到，大部分好的架構(gòu)師同時也是好的開發(fā)人員，因此尋找架構(gòu)師人才時可能首先應(yīng)該從普通開發(fā)人員中找起。招聘人員在對候選者(內(nèi)部或外部)進(jìn)行詳細(xì)審查時，應(yīng)該考慮這個觀點。不過，對此資源進(jìn)行挑選可能比較麻煩，因為只有極少的優(yōu)秀開發(fā)人員具有成為架構(gòu)師的特征或愿望。
本文列出了開發(fā)人員成為架構(gòu)師要進(jìn)行的工作。我將從可能考慮進(jìn)行此轉(zhuǎn)型的開發(fā)人員和評估進(jìn)行此轉(zhuǎn)型的開發(fā)人員的經(jīng)理這兩個方面來探討這一問題。我還將提供一系列在做出這些決策時要考慮的因素。
個人特征
軟件開發(fā)團(tuán)隊和管理層之間的聯(lián)系始終是 IT 中的一個關(guān)鍵所在。二者都傾向于以完全不同的方式考慮給定的問題。大部分相關(guān)技術(shù)都是討論項目經(jīng)理應(yīng)如何跟蹤和解釋開發(fā)人員的進(jìn)度和問題。但溝通不足的情況仍然非常普遍，而且這是項目失敗的首要原因。好的架構(gòu)師是解決這個問題的最有效辦法。架構(gòu)師的主要責(zé)任是提供開發(fā)人員和項目經(jīng)理之間的共用溝通媒體。他們負(fù)責(zé)讓業(yè)務(wù)規(guī)則及需求與工程實踐及限制相適應(yīng)，以確保成功。以下是成功架構(gòu)師的一些主要特征。
愿意并有能力進(jìn)行溝通：在開發(fā)人員中發(fā)現(xiàn)架構(gòu)師的最有價值標(biāo)準(zhǔn)是有效的溝通。您需要技術(shù)嫻熟、經(jīng)驗豐富的開發(fā)人員，這樣的人員需要有就項目中的業(yè)務(wù)相關(guān)問題進(jìn)行溝通的經(jīng)歷。架構(gòu)師經(jīng)常必須對理解方面的差距進(jìn)行預(yù)計，然后才能有所貢獻(xiàn)。他們必須愿意克服困難來確保技術(shù)和業(yè)務(wù)觀點的融合。他們并不必對意見交換工作進(jìn)行計劃和協(xié)調(diào);這仍然主要是項目經(jīng)理的工作。他們的任務(wù)是確定表述系統(tǒng)設(shè)計時的最佳工具和構(gòu)件，以促進(jìn)有效的意見交換。他們必須能夠判斷當(dāng)前方法顯得不足而需要采用新方法的情況。寫作技能也非常重要，還需要具有制作草圖的技能或使用制圖軟件的能力。
具有處理談判細(xì)節(jié)方面的經(jīng)驗：架構(gòu)師經(jīng)常需要負(fù)責(zé)討論系統(tǒng)開發(fā)的技術(shù)折衷方案。優(yōu)先級的沖突可能會帶來實踐限制、風(fēng)險規(guī)避或可能導(dǎo)致在各個不同業(yè)務(wù)組之間需求不同。優(yōu)秀的架構(gòu)師能夠有效地評估技術(shù)可能性，并能在不損失項目的主要價值的前提下制訂開發(fā)計劃來處理各種利害關(guān)系和限制。這與前面討論的溝通技能緊密相關(guān)，但同時也要體現(xiàn)架構(gòu)師的技術(shù)能力。好的架構(gòu)師候選者應(yīng)該是經(jīng)常幫助對有爭議的討論進(jìn)行引導(dǎo)的人，能夠使討論得出新的想法，而不會使其在一個位置停滯不前。
自覺主動;積極解決設(shè)計問題：架構(gòu)師的日常工作目標(biāo)經(jīng)常并不明確。很多開發(fā)人員直接參考功能規(guī)范來列出任務(wù)清單。架構(gòu)師通常則是向這些開發(fā)人員提供所需結(jié)構(gòu)的人員，以便盡可能提高工作效率。好的候選者不僅進(jìn)行溝通方面的工作，而且也會預(yù)計各種設(shè)計問題并加以解決——通常在沒有任何具體指示的情況下自覺進(jìn)行。無論所分配的職責(zé)如何，積極參與項目的開發(fā)人員都有機(jī)會從一起工作的人員中脫穎而出。
抽象思維和分析：架構(gòu)師必須能夠理解表述模糊的概念并將其變成相關(guān)各方能夠理解的項目構(gòu)件。他們必須能夠理解抽象概念，并以具體的語言對其進(jìn)行溝通。開發(fā)人員中好的候選者經(jīng)常要求或自己主動解釋開發(fā)生命周期中容易混淆的問題。他們能迅速評估各種想法并將其納入后續(xù)工作的操作建議中。
開發(fā)人員經(jīng)常具有很強(qiáng)的數(shù)學(xué)能力，而好的架構(gòu)師則傾向于表現(xiàn)出更強(qiáng)的口頭表達(dá)能力。管理人員經(jīng)常說開發(fā)人員具有“工程意識”，而這是一個用于評估架構(gòu)師的非常有意義的方面。架構(gòu)師應(yīng)該具有很強(qiáng)的解決技術(shù)問題的能力，但還必須能夠準(zhǔn)確獲知更為全面的人員如何與技術(shù)交互的信息。這要求具有某種形式的抽象思維(而不再是代碼的細(xì)節(jié))，這種思維能力可能較難形成。
有些人認(rèn)為，某種級別的正式教育是成為優(yōu)秀開發(fā)人員的必備條件之一，我并不同意這種精英論。我遇到了很多高中就輟學(xué)的優(yōu)秀開發(fā)人員。不過，對于體系結(jié)構(gòu)設(shè)計工作，我的個人經(jīng)驗以及我對所需能力的認(rèn)識都讓我相信，好的架構(gòu)師通常至少獲得了一個有挑戰(zhàn)性的學(xué)士學(xué)位。
跟蹤生命周期
好的架構(gòu)師通常有在具備定義良好的軟件開發(fā)生命周期(Software Development Life Cycle，SDLC)的組織工作的經(jīng)驗。架構(gòu)師必須理解在其所屬專業(yè)內(nèi)最重要的操作過程。這并不意味著需要有其他前提，例如，并不需要高能力成熟度模型(Capability Maturity Model，CMM)級別的工作經(jīng)驗。好的架構(gòu)師可能來自使用 SDLC 的多個小型迭代的極限編程(Extreme Programming，XP)方法的組織。務(wù)必注意各種傳統(tǒng)軟件開發(fā)操作，如 Michael A. Jackson 的方法：Jackson 結(jié)構(gòu)編程(Jackson Structured Programming，JSP)和 Jackson 系統(tǒng)開發(fā)(Jackson System Development，JSD)。Jackson 的研究對架構(gòu)師職業(yè)發(fā)展的意義就像 Donald Knuth 的研究對程序員一樣重要。架構(gòu)師可以偏愛任何經(jīng)典的、經(jīng)過時間考驗的軟件系統(tǒng)開發(fā)方法。
SDLC 也可以成為評估架構(gòu)師合適人選的有用機(jī)制。每個 SDLC 階段都具有能提供相關(guān)線索的特征。SDLC 包含很多小的變體，但在此部分，我將使用幾乎所有方法的公共基礎(chǔ)部分。下面的列表詳細(xì)說明了 SDLC 的各個階段，并列出了好的架構(gòu)師候選者在每個階段表現(xiàn)出來的特征。
- 分析：在分析期間，好的架構(gòu)師會考慮非技術(shù)影響，以便了解需求和將在其中進(jìn)行開發(fā)的環(huán)境。架構(gòu)師可為風(fēng)險評估任務(wù)帶來廣泛的軟件經(jīng)驗供參考。尋找具有豐富經(jīng)驗的開發(fā)人員，以幫助業(yè)務(wù)部門理解技術(shù)人員正確解釋需求所需的信息。尋找在開發(fā)的早期階段能夠預(yù)計可能遇到的問題的開發(fā)人員。
- 設(shè)計：在高級設(shè)計期間，好的架構(gòu)師會收集問題空間的各個抽象元素，并就其進(jìn)行溝通，以便開發(fā)團(tuán)隊草擬將要開發(fā)的系統(tǒng)的相關(guān)圖表。架構(gòu)師負(fù)責(zé)將需求謹(jǐn)慎地映射到所得到的系統(tǒng)體系結(jié)構(gòu)的功能。在詳細(xì)設(shè)計期間，他們所扮演的角色并不是核心角色，但為了根據(jù)整個系統(tǒng)的規(guī)則對特定模塊的元素進(jìn)行審查，仍然需要他們。尋找善于讓團(tuán)隊能夠預(yù)計設(shè)計決策對最終系統(tǒng)的影響的開發(fā)人員。尋找善于確定一些最佳構(gòu)件來促進(jìn)與技術(shù)和非技術(shù)受眾溝通設(shè)計問題的開發(fā)人員。
- 實現(xiàn)：在實現(xiàn)期間，架構(gòu)師對項目進(jìn)行引導(dǎo)，以確保其符合系統(tǒng)體系結(jié)構(gòu)。他們在一線評估技術(shù)更改請求，并確定如何對設(shè)計進(jìn)行調(diào)整，以最好地處理此類請求。架構(gòu)師還要密切了解開發(fā)人員的進(jìn)度，特別要跟蹤系統(tǒng)中模塊間的集成點的狀態(tài)。尋找經(jīng)常對討論進(jìn)行引導(dǎo)來連接多個子系統(tǒng)的開發(fā)人員。尋找項目經(jīng)理可以依賴其快速地進(jìn)行與更改和出現(xiàn)的問題相關(guān)的風(fēng)險評估的開發(fā)人員。
- 測試：架構(gòu)師對系統(tǒng)集成和用戶接受度測試進(jìn)行指導(dǎo)，并負(fù)責(zé)評估進(jìn)度的正確溝通的持續(xù)測試結(jié)果。尋找理解錯誤模式且善于將測試復(fù)查結(jié)果轉(zhuǎn)換為行動計劃的開發(fā)人員。
- 維護(hù)：在維護(hù)期間，架構(gòu)師將發(fā)起關(guān)于系統(tǒng)集成的討論。無論處理 IT 基礎(chǔ)設(shè)施問題，還是確保部門之間的技術(shù)合作，架構(gòu)師都必須完全理解應(yīng)用程序，必須快速學(xué)習(xí)姊妹應(yīng)用程序的體系結(jié)構(gòu)，而且必須就集成點和風(fēng)險進(jìn)行有效溝通。尋找具有系統(tǒng)集成經(jīng)驗且表現(xiàn)出快速掌握全貌的能力的開發(fā)人員。系統(tǒng)集成是一項獨特的任務(wù)。
架構(gòu)師培養(yǎng)建議
有些組織能比其他組織更有效地進(jìn)行架構(gòu)師培養(yǎng)。如果充分考慮到招聘此類新專業(yè)人才的困難，努力促成能鼓勵開發(fā)人員發(fā)展為架構(gòu)師的環(huán)境是非常明智的策略。但務(wù)必避免對不愿意或不適合走這條路的開發(fā)人員進(jìn)行處罰。組織應(yīng)該為開發(fā)人員制訂多條發(fā)展路線，包括那些愿意繼續(xù)擔(dān)任開發(fā)人員的人。對架構(gòu)師而言，資深開發(fā)人員不可或缺。他們可以實現(xiàn)系統(tǒng)中最關(guān)鍵的模塊。通過對其他開發(fā)人員進(jìn)行代碼檢查和測試支持，他們可幫助確保總體軟件質(zhì)量，而如果質(zhì)量不能保證，即使最好的體系結(jié)構(gòu)也毫無用處。
組織應(yīng)制訂個人評估程序，以鼓勵開發(fā)人員考慮其職業(yè)目標(biāo)，其中要包含體系結(jié)構(gòu)設(shè)計的選項。應(yīng)該鼓勵經(jīng)理在其下屬中尋找體系結(jié)構(gòu)設(shè)計人才。應(yīng)該實現(xiàn)指導(dǎo)計劃，讓架構(gòu)師與希望成為架構(gòu)師的開發(fā)人員協(xié)作工作。應(yīng)該鼓勵開發(fā)人員通過參加各種協(xié)會、撰寫文章和參加會議，從而參與到專業(yè)領(lǐng)域中來。通過這樣參與進(jìn)來，可幫助開發(fā)人員從新的角度理解系統(tǒng)，并幫助他們更好地就其認(rèn)識進(jìn)行溝通。這樣還能培養(yǎng)可提高效率的重要創(chuàng)新想法。
結(jié)束語
開發(fā)人員一旦邁出了通向體系結(jié)構(gòu)設(shè)計專業(yè)方向的第一步，就可以利用很多資源來獲得幫助，其中包括很多來自 IBM 的資源。有時候，此過程的最困難的部分就是第一步，而本文提供了一些線索和提示，經(jīng)理和開發(fā)人員可以利用其來評估應(yīng)該鼓勵哪些人努力成為架構(gòu)師。
另外，附加一個作為架構(gòu)師進(jìn)行總體技術(shù)架構(gòu)的參考
（例如：項目集群架構(gòu)，包括一些指導(dǎo)原則、最佳實踐和技術(shù)標(biāo)準(zhǔn)）
總體技術(shù)架構(gòu)是由技術(shù)架構(gòu)構(gòu)件（Technology Building Block, TBB）所組成，這些技術(shù)架構(gòu)構(gòu)件，簡要地描述了技術(shù)架構(gòu)的主要組件和功能。此技術(shù)架構(gòu)的制訂，參考了業(yè)界的標(biāo)準(zhǔn)及相關(guān)的模型，以作為設(shè)計應(yīng)用系統(tǒng)時需要遵循的技術(shù)原則或標(biāo)準(zhǔn)。
茲將各技術(shù)架構(gòu)構(gòu)件概述如下：
· 應(yīng)用TBB
定義應(yīng)用系統(tǒng)設(shè)計、分析與開發(fā)所需遵循的標(biāo)準(zhǔn)與規(guī)范，并參考業(yè)界普遍使用的技術(shù)準(zhǔn)則，以達(dá)成應(yīng)用系統(tǒng)架構(gòu)的一致性、擴(kuò)充性以及延展性，提高應(yīng)用系統(tǒng)組件的可再利用性。
· 數(shù)據(jù)TBB
構(gòu)建一個具有彈性的數(shù)據(jù)處理平臺，提供數(shù)據(jù)存取、定義、轉(zhuǎn)換、復(fù)制等管理功能，以作為企業(yè)數(shù)據(jù)共享之基礎(chǔ)。
· 共享應(yīng)用服務(wù)TBB
提供各應(yīng)用系統(tǒng)所共享之技術(shù)功能模塊，以及應(yīng)用系統(tǒng)集成之基礎(chǔ)架構(gòu)，使新系統(tǒng)可以快速而自動的集成現(xiàn)有系統(tǒng)之資源與服務(wù)，以提高現(xiàn)有系統(tǒng)的擴(kuò)展性與可再利用性。
· 接口服務(wù)TBB
構(gòu)建統(tǒng)一的接口服務(wù)平臺，并制定各渠道系統(tǒng)的業(yè)務(wù)發(fā)展和技術(shù)支撐體系，以提高業(yè)務(wù)支持能力與客戶滿意度。
· 系統(tǒng)管理TBB
構(gòu)建一個集中化的、整合的、授權(quán)的、安全的系統(tǒng)管理架構(gòu)，以管控各種的IT資源，在單一的控制平臺上，依各管理者所被賦予的管理權(quán)限去制定管理的策略，以達(dá)成整體IT資源的高可用性、高運作效率、高安全性。
· 安全TBB
定義信息安全戰(zhàn)略相關(guān)的技術(shù)與準(zhǔn)則，并構(gòu)建全行各應(yīng)用系統(tǒng)或接口的授權(quán)和認(rèn)證機(jī)制，提供各應(yīng)用系統(tǒng)的統(tǒng)一訪問接入服務(wù)。
· 共享系統(tǒng)服務(wù)TBB
主要由操作系統(tǒng)或低層的系統(tǒng)功能提供，為應(yīng)用系統(tǒng)及軟件所共享。
· 網(wǎng)絡(luò)服務(wù)TBB
定義網(wǎng)絡(luò)服務(wù)架構(gòu)所需遵循的技術(shù)規(guī)范與準(zhǔn)則，以及應(yīng)用系統(tǒng)設(shè)計時應(yīng)考量的網(wǎng)絡(luò)相關(guān)技術(shù)事項。
· 平臺服務(wù)TBB
定義系統(tǒng)硬件平臺所使用之技術(shù)架構(gòu)與準(zhǔn)則，必須符合世界潮流，以及高性能、易操作性、可擴(kuò)展性、高安全性、高可用性等關(guān)鍵要素。
· 系統(tǒng)開發(fā)服務(wù)TBB
導(dǎo)入完整的應(yīng)用系統(tǒng)開發(fā)方法論，并定義整合性應(yīng)用系統(tǒng)開發(fā)工具所須具備的技術(shù)標(biāo)準(zhǔn)與使用規(guī)范。
如上圖所示，總體技術(shù)架構(gòu)之構(gòu)件細(xì)化與描述如下：
1.3.1.1 指導(dǎo)原則
1. 高內(nèi)聚（high cohesion）與松耦合（loosely coupled ）的設(shè)計原則
2. 高度擴(kuò)充性與延展性
3. 設(shè)計可再利用性高的功能組件
4. 設(shè)計跨平臺的功能模塊
5. 基于標(biāo)準(zhǔn)
6. 能利用已有的核心系統(tǒng)
7. 可快速部署和易于管理
8. 構(gòu)件化架構(gòu)的目標(biāo)是提高業(yè)務(wù)效率
9. 可共享的構(gòu)件必須能被任何構(gòu)件化設(shè)計的應(yīng)用所調(diào)用
10. 如果可能，盡量選擇購買而不是開發(fā)構(gòu)件
1.3.1.2 技術(shù)議題
1. 應(yīng)用系統(tǒng)設(shè)計與開發(fā)
最佳實踐
· N-tier的面向服務(wù)架構(gòu)設(shè)計
· 統(tǒng)一的應(yīng)用接口
· 由業(yè)務(wù)單位負(fù)責(zé)定義業(yè)務(wù)邏輯
· 不限平臺的業(yè)務(wù)邏輯設(shè)計
· 構(gòu)建各自獨立的業(yè)務(wù)邏輯組件
· 通過業(yè)務(wù)規(guī)則使用數(shù)據(jù)
· 建立程序撰寫標(biāo)準(zhǔn)
技術(shù)標(biāo)準(zhǔn)
· 跨平臺的程序開發(fā)語言，如 C、C++ or Java.
2. 應(yīng)用框架
最佳實踐
· 使用一致的應(yīng)用框架設(shè)計
· 表現(xiàn)層與業(yè)務(wù)邏輯分離的設(shè)計原則
· 重用性高的共享服務(wù)構(gòu)件設(shè)計
技術(shù)標(biāo)準(zhǔn)
· J2EE
· Struts Framework
· .NET
3. 設(shè)計模式（Design Pattern）
最佳實踐
· Model-View-Controller（MVC）
· Intercepting Filter
· Front Controller
· Business Delegate
· Data Access Object
· Service Activator
4. 構(gòu)件重用
最佳實踐
· 建立識別和實現(xiàn)構(gòu)件的方法論
· 建立一個構(gòu)件審閱組（Component Review Board）以識別通用構(gòu)件
· 建立一個構(gòu)件倉庫以維護(hù)可重用構(gòu)件的信息
· 每一個構(gòu)件都必須有一個公開的API
· 構(gòu)件服務(wù)應(yīng)該可以被任何構(gòu)件化的應(yīng)用或其它構(gòu)件調(diào)用
技術(shù)標(biāo)準(zhǔn)
· 在基礎(chǔ)安全服務(wù)層，應(yīng)不使用供貨商所有權(quán)的API調(diào)用，而使用GSS-API或遵循公共數(shù)據(jù)安全體系結(jié)構(gòu)（CDSA）的API 調(diào)用和產(chǎn)品
· 企業(yè)內(nèi)基礎(chǔ)服務(wù)平臺必須至少遵循公共數(shù)據(jù)安全體系結(jié)構(gòu)2.0 （CDSA V2.0）
5. 面向?qū)ο虻臉?gòu)件
最佳實踐
· 應(yīng)用系統(tǒng)開發(fā)者應(yīng)使用基于EJB的面向?qū)ο蚣夹g(shù)開發(fā)企業(yè)級的構(gòu)件。而實施前的合適的面向?qū)ο虻姆治龊驮O(shè)計是必不可少的
技術(shù)標(biāo)準(zhǔn)
· 購買的產(chǎn)品必須遵循 CORBA 2.0 或更高，以及IIOP協(xié)議
· 開發(fā)或購買的企業(yè)解決方案應(yīng)建立在EJB和Servlet模式上。應(yīng)用服務(wù)器應(yīng)該遵循EJB 1.1 或更高
· 在企業(yè)級或戰(zhàn)略級應(yīng)用中，應(yīng)避免使用OLE/DCOM 和 Windows DNA
1.3.2.1 指導(dǎo)原則
1. 構(gòu)建一個具有高度適應(yīng)性的數(shù)據(jù)基礎(chǔ)架構(gòu)
2. 在實體上將OLTP與OLAP數(shù)據(jù)源分別配置
3. 數(shù)據(jù)架構(gòu)應(yīng)該是企業(yè)級的，如此才可以提高和促進(jìn)企業(yè)內(nèi)部的數(shù)據(jù)共享
1.3.2.2 技術(shù)議題
1. 集中化的元數(shù)據(jù)
最佳實踐
· 使用并維護(hù)集中化的元數(shù)據(jù)倉庫（CMR，Centralized Metadata Repository），保存集中化的元數(shù)據(jù)的定義
· 在設(shè)計或修改數(shù)據(jù)庫前，通覽CMR中的已有標(biāo)準(zhǔn)和數(shù)據(jù)元素，以確保新設(shè)計的數(shù)據(jù)庫是符合CMR標(biāo)準(zhǔn)的
· 利用CMR和元數(shù)據(jù)審核小組來創(chuàng)建企業(yè)級數(shù)據(jù)定義，鼓勵跨部門共享數(shù)據(jù)
技術(shù)標(biāo)準(zhǔn)
· 客戶系統(tǒng)必須遵循CMR的數(shù)據(jù)定義標(biāo)準(zhǔn)
· 支持客戶定義數(shù)據(jù)的COTS（Commercial off-the-shelf）系統(tǒng)必須能滿足CMR數(shù)據(jù)定義標(biāo)準(zhǔn)，否則，供貨商應(yīng)該提供到元數(shù)據(jù)的轉(zhuǎn)換規(guī)則，以實現(xiàn)數(shù)據(jù)共享
· 當(dāng)跨部門、跨系統(tǒng)共享數(shù)據(jù)時，應(yīng)使用集中化元數(shù)據(jù)交換標(biāo)準(zhǔn)
1.3.3.1 指導(dǎo)原則
1. 集成的架構(gòu)強(qiáng)調(diào)數(shù)據(jù)交換、業(yè)務(wù)流程和終端展現(xiàn)的相互關(guān)聯(lián)
2. 當(dāng)決定是否采用集成時，方案的生命期是關(guān)鍵考慮因素
3. 集成架構(gòu)依賴于眾多中間服務(wù)層，如接入層引擎、數(shù)據(jù)庫網(wǎng)關(guān)、信息、集成服務(wù)、XML 和第三方工具等
4. 對現(xiàn)有系統(tǒng)的影響應(yīng)最小化
5. 盡可能地采用通用技術(shù)
6. 當(dāng)集成異類系統(tǒng)時，通過使用中間服務(wù)層而提高終端用戶功能，從而最大化靈活性
1.3.3.2 技術(shù)議題
1. 應(yīng)用集成
最佳實踐
· 連結(jié)異質(zhì)系統(tǒng)中的數(shù)據(jù)或流程
· 提供新舊系統(tǒng)能同時并存與合作的應(yīng)用平臺
· 使用適配器
· 業(yè)務(wù)流程管理
· 商業(yè)活動監(jiān)控
技術(shù)標(biāo)準(zhǔn)
· Web Services
· JCA
· Message Queue
· CORBA
· BPEL
2. 服務(wù)導(dǎo)向的架構(gòu)設(shè)計
最佳實踐
· Web Services
技術(shù)標(biāo)準(zhǔn)
· SOAP
· WSDL
· UDDI
3. XML
最佳實踐
· 透過 XML進(jìn)行商業(yè)協(xié)同作業(yè)
· 使用 XML管理文件與數(shù)據(jù)庫
技術(shù)標(biāo)準(zhǔn)
· IFX
· ebXML
· RosettaNet
· SWIFT
1.3.4.1 指導(dǎo)原則
1. 統(tǒng)一的，可接入門戶的應(yīng)用接口原則
應(yīng)用系統(tǒng)應(yīng)使用統(tǒng)一的、易用的、可納入未來企業(yè)門戶的接口方式。
2. 統(tǒng)一的接口標(biāo)準(zhǔn)
起草并確認(rèn)Web和非Web應(yīng)用系統(tǒng)用戶接口設(shè)計的標(biāo)準(zhǔn)和原則，這些標(biāo)準(zhǔn)包括：
· 工業(yè)標(biāo)準(zhǔn)的選擇
· 總體用戶接口的原則
· 用戶接口設(shè)計標(biāo)準(zhǔn)
· 用戶接口組體標(biāo)準(zhǔn)
3. 內(nèi)部用戶接口的可用性原則
用戶接口應(yīng)提供可連接相關(guān)業(yè)務(wù)流程的各信息技術(shù)應(yīng)用、數(shù)據(jù)和服務(wù)的、經(jīng)過整合的統(tǒng)一界面。
4. 統(tǒng)一客戶接口
應(yīng)提供其客戶所有產(chǎn)品和服務(wù)的直接接口，并以技術(shù)上保證界面的標(biāo)準(zhǔn)化、規(guī)范化、一致性。這種統(tǒng)一和規(guī)范可通過對外企業(yè)門戶和渠道整合來實現(xiàn)。同時這種接口服務(wù)應(yīng)保證客戶信息和產(chǎn)品及服務(wù)的安全性。
5. 用戶接口的集成性原則
用戶的接口設(shè)計應(yīng)考慮相關(guān)業(yè)務(wù)的整體性和應(yīng)用與應(yīng)用之間的關(guān)聯(lián)及集成。
1.3.4.2 技術(shù)議題
1. 訪問服務(wù)
最佳實踐
· 門戶管理服務(wù)
· 安全服務(wù)
· 數(shù)據(jù)訪問服務(wù)
· 應(yīng)用集成服務(wù)
· 搜索服務(wù)
技術(shù)標(biāo)準(zhǔn)
· Portlet
· LDAP
· JDBC
2. 渠道整合
最佳實踐
· 個性化服務(wù)（Personalization）
· 內(nèi)容管理服務(wù)
· 多重協(xié)議與編碼轉(zhuǎn)換（Transcoding）
1.3.5.1 指導(dǎo)原則
1. 配置和資產(chǎn)管理
應(yīng)逐步建立企業(yè)性的應(yīng)用。系統(tǒng)軟硬件資產(chǎn)及其配置數(shù)據(jù)庫，以統(tǒng)一資產(chǎn)和配置進(jìn)行管理。
2. 系統(tǒng)性能管理
新的應(yīng)用系統(tǒng)的設(shè)計和實施必須確認(rèn)并滿足系統(tǒng)性能需求。應(yīng)逐步建立企業(yè)性的應(yīng)用系統(tǒng)的性能跟蹤和監(jiān)測手段，其先決條件是逐步建立企業(yè)性的系統(tǒng)、數(shù)據(jù)運營中心。
3. 軟件分發(fā)原則
軟件的版本及升級應(yīng)統(tǒng)一管理、決策。軟件的分發(fā)和升級應(yīng)自動化，并由企業(yè)統(tǒng)一管理。
4. 系統(tǒng)操作
應(yīng)逐步建立企業(yè)統(tǒng)一的系統(tǒng)運營操作支持體系。
5. 問題管理
系統(tǒng)管理應(yīng)包括統(tǒng)一的流程和方法來實現(xiàn)、報告及解決應(yīng)用系統(tǒng)的問題。
6. 容量管理
應(yīng)用系統(tǒng)的硬件容量，包括CPU、內(nèi)存、I/O、硬盤等，應(yīng)用系統(tǒng)對并發(fā)用戶的支持、數(shù)據(jù)庫的容量、網(wǎng)絡(luò)容量、峰值容量等等必須得到統(tǒng)一的監(jiān)測并定期報告，以盡早發(fā)現(xiàn)問題并提出對策。
7. 變更管理
應(yīng)用系統(tǒng)的管理應(yīng)包含變更管理的流程和方法。
8. 可獲得性管理
應(yīng)用系統(tǒng)的管理應(yīng)提供自動監(jiān)測系統(tǒng)軟、硬件及其網(wǎng)絡(luò)可用性的工具和方法，以滿足系統(tǒng)的可用性需求。
1.3.5.2 技術(shù)議題
1. 服務(wù)臺（Help Desk）
最佳實踐
· 必須重新思考與設(shè)計服務(wù)臺機(jī)制，以提供集成的支持功能
· 單一聯(lián)系方式的服務(wù)臺支持運營體系
· 多層次的服務(wù)臺支持組織架構(gòu)
· 所有的問題、事件、請求都應(yīng)該在這里被記錄與追蹤
2. 運營管理
最佳實踐
· 集中式的系統(tǒng)監(jiān)控機(jī)制，并支持遠(yuǎn)程之管理需求
· 對所有設(shè)備、網(wǎng)絡(luò)、服務(wù)和應(yīng)用的啟動、停止、重啟與狀態(tài)監(jiān)測
· 可用性管理保證服務(wù)和流程達(dá)到和客戶約定的可用性水準(zhǔn)
3. 性能監(jiān)控與優(yōu)化
最佳實踐
· 容量管理優(yōu)化以滿足一定服務(wù)水準(zhǔn)所需要的設(shè)施容量
· 性能監(jiān)控有利于發(fā)現(xiàn)潛在問題、采取實時反應(yīng)，從而提高服務(wù)質(zhì)量
4. 服務(wù)水平管理
最佳實踐
· 確保明確提供的服務(wù)類型，就提供的服務(wù)水準(zhǔn)和客戶達(dá)成一致
· 盡早鑒別潛在失誤
· 減少錯誤導(dǎo)致的系統(tǒng)中斷時間
· 盡早通知客戶使其能盡早采取措施
· 盡可能精確的向客戶描述服務(wù)水準(zhǔn)
· 通過主動監(jiān)控服務(wù)進(jìn)程中關(guān)鍵點的服務(wù)指針，確保為客戶提供的服務(wù)水準(zhǔn)，以及早發(fā)現(xiàn)和通報客戶可能發(fā)生的進(jìn)度延遲
1.3.6.1 指導(dǎo)原則
1. 安全的業(yè)務(wù)價值評估
信息技術(shù)安全應(yīng)首先宏觀地著手于對企業(yè)信息資產(chǎn)和業(yè)務(wù)操作的安全評估：企業(yè)資產(chǎn)可能得到的威脅、威脅帶來的影響及其威脅可能的發(fā)生概率等方面，提出整體安全的技術(shù)架構(gòu)。
2. 對隱私權(quán)的考慮
安全架構(gòu)的設(shè)計和實施應(yīng)符合政府和國際機(jī)構(gòu)對個人（客戶和企業(yè)員工）隱私權(quán)的保護(hù)規(guī)定。這種隱私權(quán)的保護(hù)體現(xiàn)在何時、怎樣、在多大程度上可以披露有關(guān)客戶或企業(yè)員工的個人信息。
3. 對內(nèi)、對外網(wǎng)絡(luò)和業(yè)務(wù)往來的安全原則
安全架構(gòu)應(yīng)確定對外業(yè)務(wù)網(wǎng)絡(luò)或通過公共網(wǎng)絡(luò)進(jìn)行業(yè)務(wù)操作的安全基礎(chǔ)技術(shù)，包括：
· 對外網(wǎng)絡(luò)連接的安全政策
· 標(biāo)準(zhǔn)安全通信基礎(chǔ)技術(shù)
· 支持與第三方業(yè)務(wù)往來的安全架構(gòu)
4. 安全控制和易用性的關(guān)系
綜合性的、切切實實的安全控制手段是必要的，但不能以犧牲和影響企業(yè)員工的工作效率或業(yè)務(wù)業(yè)績?yōu)榇鷥r。嚴(yán)重影響工作效率和業(yè)務(wù)業(yè)績的安全控制手段必須得到技術(shù)上的改善并優(yōu)先實施。
5. 安全管理
信息技術(shù)安全機(jī)制必須得到一定程度的安全管理控制能力的支持。這里的安全管理包括：
· 確定和完善企業(yè)統(tǒng)一的、一體化的安全管理組織
· 制定和發(fā)布統(tǒng)一的安全政策、標(biāo)準(zhǔn)和安全操作流程
· 教育和培訓(xùn)安全意識
· 制訂新的安全標(biāo)準(zhǔn)更新流程
· 推廣新的安全工具、發(fā)布流程及手段
6. 安全架構(gòu)的實施考慮
在進(jìn)行安全架構(gòu)組件的實施過程中，應(yīng)基于業(yè)務(wù)價值的評估，充分考慮以下的技術(shù)需求：
· 授權(quán)需求（Authorization）
· 資產(chǎn)保護(hù)（Asset Protection）
· 可稽核性（Accountability）
· 可獲得性（Availability）
· 可保證性（Assurance）
· 可管理性（Administration）
這些需求應(yīng)貫徹于安全實施項目的始終。
7. 安全檢測原則
企業(yè)應(yīng)建立定期或不定期的綜合性的安全檢查機(jī)制，以保證公司的安全控制能力、員工意識、安全工具和防范手段的到位，是否存在新的安全漏洞等等。定期檢查和評估應(yīng)用、系統(tǒng)、網(wǎng)絡(luò)及分支行、網(wǎng)點的安全能力。
1.3.7.1 指導(dǎo)原則
1. 提供良好的輸出、輸入接口，以及相當(dāng)方便的執(zhí)行程序的環(huán)境
2. 使硬件資源的使用更有效率
3. 使用共享的存儲裝置
1.3.8.1 指導(dǎo)原則
1. 重點優(yōu)先原則
企業(yè)的網(wǎng)絡(luò)必須確保重點應(yīng)用能優(yōu)先使用網(wǎng)絡(luò)資源，能為核心業(yè)務(wù)和關(guān)鍵應(yīng)用提供連續(xù)性的可靠的網(wǎng)絡(luò)服務(wù)。
2. 高可靠性原則
· 關(guān)鍵設(shè)備和模塊在數(shù)量、性能、容量和鏈路帶寬等方面上要有冗余設(shè)計。
· 在新技術(shù)和新產(chǎn)品的選擇上要盡量采用經(jīng)過實際檢驗的可靠技術(shù)和產(chǎn)品。
· 設(shè)計上堅持簡單＝可靠的原則，盡可能減少故障點。
3. 高可用性原則：
· 網(wǎng)絡(luò)的性能滿足未來應(yīng)用不斷增加和業(yè)務(wù)量高峰的挑戰(zhàn)。
· 網(wǎng)絡(luò)在大負(fù)荷、大流量的壓力下，能連續(xù)、穩(wěn)定運行，而且不降低整體性能。
· 能讓用戶體驗到網(wǎng)絡(luò)使用的方便靈活，體現(xiàn)網(wǎng)絡(luò)為工作和生活方式的改進(jìn)帶來的價值。
4. 可擴(kuò)展性原則
貫徹“松散耦合”的整體設(shè)計思想，建設(shè)層次化、模塊化、可擴(kuò)展的網(wǎng)絡(luò)。
5. 安全性原則
網(wǎng)絡(luò)的設(shè)計和規(guī)劃、實施應(yīng)考慮對內(nèi)、對外連接的安全性，保證用戶在權(quán)限之內(nèi)的網(wǎng)絡(luò)連接和對資源的訪問。
6. 開放和標(biāo)準(zhǔn)的原則
網(wǎng)絡(luò)的設(shè)計應(yīng)充分考慮相應(yīng)工業(yè)標(biāo)準(zhǔn)，應(yīng)盡可能地利用現(xiàn)有或未來工業(yè)標(biāo)準(zhǔn)以支持企業(yè)網(wǎng)絡(luò)連接或?qū)ν饪蛻簟I運商或供貨商的連接。
7. 可管理性原則
網(wǎng)絡(luò)作為應(yīng)用基礎(chǔ)設(shè)施，面對所有的網(wǎng)絡(luò)用戶，網(wǎng)絡(luò)資源相對于應(yīng)用需求始終是有限的，網(wǎng)絡(luò)管理體現(xiàn)對網(wǎng)絡(luò)資源的有效管理，對用戶使用網(wǎng)絡(luò)有統(tǒng)一的規(guī)范；需要有統(tǒng)一的網(wǎng)管平臺和網(wǎng)絡(luò)運維組織機(jī)構(gòu)負(fù)責(zé)全行的網(wǎng)絡(luò)運維管理；確保應(yīng)用的數(shù)據(jù)特征在網(wǎng)絡(luò)中可分類、可識別，網(wǎng)絡(luò)對應(yīng)用的服務(wù)管理通過QOS等技術(shù)手段逐步實現(xiàn)端到端的質(zhì)量保證。
8. 網(wǎng)絡(luò)核心的高效設(shè)計原則
為了保證網(wǎng)絡(luò)核心的高效性，應(yīng)用策略控制和網(wǎng)絡(luò)多重服務(wù)盡量在網(wǎng)絡(luò)邊緣來實現(xiàn)。
9. 應(yīng)用部署的網(wǎng)絡(luò)成本控制原則
應(yīng)用的部署會占用網(wǎng)絡(luò)的成本，應(yīng)用模式、結(jié)構(gòu)、軟件平臺、數(shù)據(jù)分布等方面要體現(xiàn)對網(wǎng)絡(luò)設(shè)備和廣域網(wǎng)資源節(jié)省占用的原則，如有大流量數(shù)據(jù)交換的多臺服務(wù)器要盡量部署在局域網(wǎng)的同一網(wǎng)段內(nèi)；客戶端盡量靠近服務(wù)器。
10. 網(wǎng)絡(luò)投資的有效性原則
二層含義：一是要保護(hù)原有的投資，二是要保證后續(xù)投資的有效性。
1.3.9.1 指導(dǎo)原則
1. 服務(wù)器設(shè)計要盡可能以物理的服務(wù)器為單位
2. 緊迫任務(wù)系統(tǒng)要避免單點失敗
3. 所有服務(wù)器上的應(yīng)用、應(yīng)用套件或一個應(yīng)用中的層要二進(jìn)制兼容
4. 盡可能使用開放的、獨立于廠商的標(biāo)準(zhǔn)
5. 服務(wù)器應(yīng)允許多任務(wù)和多線程
6. 服務(wù)器應(yīng)能升級
另外附加一個關(guān)于前端架構(gòu)師的內(nèi)容，希望對于客戶端編程設(shè)計的開發(fā)人員轉(zhuǎn)型提供一個參考：
當(dāng)后端技術(shù)伴隨.Net, Rails和Java之類的框架發(fā)展得越來越抽象和強(qiáng)大，前端技術(shù)的潛在發(fā)展也日益復(fù)雜。在束縛前端技術(shù)潛在好處的差勁實現(xiàn)之前， Web需要更多的前端架構(gòu)師。多虧了諸如跨瀏覽器支持的先進(jìn)技術(shù)的發(fā)展，用戶體驗、更多有意義的主題比如無障礙都撥云見日，這個世界再也不僅僅就HTML和CSS如此簡單，因此，絕大部分的團(tuán)隊都需要一個真正理解和實踐涉及到前端的一切的人。
角色
這并不是一個扼要和簡單的清單，對于下面的主題／技術(shù)，前端架構(gòu)師也不能僅僅滿足于了解一下里里外外而已，而是需要足夠的深入研究，并有自己出色的見解。
XHTML
CSS(1, 2, 3)
跨瀏覽器和跨平臺
DOM腳本編程
AJAX
Flash
漸進(jìn)增強(qiáng)和適度降級
無障礙
可用性
信息架構(gòu)
界面設(shè)計
視覺設(shè)計
表現(xiàn)層邏輯（ASPX, Rails視圖等）
商業(yè)規(guī)則和邏輯
作為一個前端架構(gòu)師，必須擁有這些領(lǐng)域的絕對執(zhí)行力。例如，前端架構(gòu)師能夠決定某個特性是使用AJAX還是傳統(tǒng)的頁面刷新。哪個更便于使用？對無障礙的影響如何？改用Flash有意義嗎？
撥亂反正
表現(xiàn)，結(jié)構(gòu)，行為和商業(yè)邏輯的混雜，導(dǎo)致不必要的復(fù)雜，導(dǎo)致難以維護(hù)的怪胎解決方案。就如后端需要正確地劃分為數(shù)據(jù)層，商業(yè)邏輯，表現(xiàn)邏輯等，前端開發(fā)復(fù)雜到是時候調(diào)整其架構(gòu)了。編寫良好結(jié)構(gòu)或者說避免使用表格布局是遠(yuǎn)遠(yuǎn)不夠的。這是第一步，前端架構(gòu)的哆咧咪而已。現(xiàn)在是時候關(guān)注DOM腳本編程，AJAX, 無障礙等，該升級了。
非編程不可
主張前端架構(gòu)師必須懂得真正的編程知識，而這正是很多自封為前端架構(gòu)師的人所缺乏的。意思不是能夠剪切粘貼改進(jìn)代碼就行了，而是能夠跟老練的工程師商討如何能夠最好地結(jié)合前端。這就是說，前端架構(gòu)師需要真正理解結(jié)構(gòu)遭遇商業(yè)邏輯的問題。如果工程師說某些東西使用ASP.Net DataGrid是不可能實現(xiàn)的，前端架構(gòu)師必須能夠解釋如何與為何要使用DataList或Repeater取代，解釋為何DataGrid在該情景下是個錯誤的選擇……。這只是個例子，問題還在于僅知道客戶端編程也是不夠的。能夠使用與工程師相同的術(shù)語，能夠討論（前后端）關(guān)鍵集成的最佳解決方案，這是絕對必須的。
斷線的風(fēng)箏
我們今天正處在一個不妙的處境中，原因在于幾乎沒有人能夠為前后端的溝壑搭橋。一般工程師不會有興趣或?qū)嵺`標(biāo)記，CSS, 或DOM腳本編程，大部分客戶端開發(fā)者也沒有與后端技術(shù)協(xié)作的經(jīng)驗。幾周入門PHP不會成為程序員，幾周入門XHTML也不會成為真正的客戶端開發(fā)者。
罪魁禍?zhǔn)?br />
首先想到的十足例子是，ASP.Net完全漠視Web標(biāo)準(zhǔn)，同樣地，web氛圍（我們指表格和占位gif）讓W(xué)eb標(biāo)準(zhǔn)郁悶。企業(yè)項目的大多數(shù)框架輸出的標(biāo)記，即使使用1999年的標(biāo)準(zhǔn)來衡量，都是糟糕無比的。如此巨大和“專業(yè)”的產(chǎn)品怎么能才夠不忽視，按理說是整個項目最簡單的方面？只有靜態(tài)代碼。理由是，基于技術(shù)的立場衡量產(chǎn)品，結(jié)構(gòu)，CSS和其他客戶端技術(shù)都是“事后諸葛亮”。表現(xiàn)邏輯，結(jié)構(gòu)和行為混雜，壓根無助于無障礙，Web標(biāo)準(zhǔn)，或者前端技術(shù)干凈的分離。抬起你的頭來，就在2006，這些都成受歡迎的慣例了。
總結(jié)
如果這個世界上姿態(tài)最鮮明的產(chǎn)品和項目都如此低劣的方式來處理事情，其他的還有什么好說？毫無疑問，我們需要前端架構(gòu)師，而且就在昨天。歸結(jié)于歸結(jié)，我們有一堆相互關(guān)聯(lián)的技術(shù)，很少人能夠埋頭鉆研它們之間的關(guān)系，這很不幸。正確做事的真正價值在于容易的維護(hù)和長期的適應(yīng)性。雖然在關(guān)鍵時刻，有些方式更容易選擇其他的方法和拼湊起另外的東西。對某些人來說，這可能是可接受的做事方式。但是，對我們大部分人來說，這是拙劣的抉擇，也非常不專業(yè)。