2007 年 4 月 24 日
和 IBM 體系結構專家親密接觸。瞭解他們爲何要做目前所做的事以及如何達到目前的職位。探索他們職業生涯中遇到的種種曲折，瞭解他們如何通過這些經歷最終進入 IT 體系結構領域中。
長大後，您想幹什麼？雖然我已經工作了很長時間了（已經到了不願意公開自己的工作年限的地步了），我仍然在考慮這個問題。或許您也是這樣。事實上，如果您和我一樣是生育高峯期出生的，您可能將不斷問自己這個問題，給出各種不同的答案，直到有一天極不情願地被推入退休隊伍中爲止。
本月我們將詢問專家組一個類似的問題（不過我們將問的是他們的過去，而不是他們對將來的看法）：
爲什麼您覺得 IT 體系結構方面的工作適合您，爲了成爲架構師，您走過了什麼樣的路？
正如您將看到的，IBM 技術帶頭人也經歷了同樣的心路歷程。事實上，他們似乎都有一個共同的特點，就是始終都在積極地嘗試獲得新的經驗和知識。或許這使得他們有些像雜家， Grady Booch 就使用這個詞來描述自己，而這又被 Merriam Webster 定義爲“閒人”或“不安分的人”。（此處並不是說“不誠實或沒用的人”。）更可能的是，這使他們成爲博學家（即 Merriam Webster 所說的“具有各方面知識”的人）。他們日子過得似乎都不錯!
對於希望成爲 IT 架構師的普通人，這可能會使他們望而卻步。那麼，究竟在 IT 領域中工作的哪些人如此有創造力而同時又過得這樣快樂呢？但他們每個人都是很久以前從普通人開始一步步做起的。他們並不是一下子就獲得了成爲 IT 架構師的所有技能，他們經歷了漫長而艱難的過程，並深入各種不同領域纔得到了所需的技能。設計方面也是如此。其他人則是在嘗試了其他角色後才選擇這個職業。
考慮到我們的專家組成員對新鮮事務的好奇心，我忍不住認爲這可能並不是他們中的任何人的最終歸宿。如果我們要討論的是他們以後的職業生涯，我想會發現他們在將來承擔起新的任務、對新的挑戰發起攻擊。我們都經歷了很長的成長過程，但我認爲他們有可能還會繼續這個過程。因此，如果下次問他們這個問題也會非常有意義：“長大後，您想幹什麼？”讓我們拭目以待吧。
developerWorks Architecture 團隊——
Paul Dreyfus，編輯
developerWorks
  |
|
任何方面都能推動架構師的工作：客戶、他的團隊、體系結構、小故障和各種問題。我認爲體系結構更多的是一種態度、完美地建起軟件“大廈”的熱情，但現實卻往往使得這不那麼完美。不過，追求完美的想法與現實之間的平衡會讓架構師保持一定的清醒態度，因爲他必須向客戶交付一個正常運行且性能良好的系統。
回憶：我看到自己參加會議、在白板上畫圖、處理一個接一個的問題。在團隊的幫助下，我嘗試利用過去所積累的知識在問題領域中的各種力量和約束之間求得平衡。模式？或許吧。我喜歡體會團隊活力在周圍流動的那種感覺——每一分鐘，我都能在同事仔細描述各種情況的細枝末葉時獲得啓發和學到新的東西：爲什麼這個情況略有不同，因而必須修改模式，以處理實際情況。
編寫代碼的日子：編寫代碼是孤獨的探尋過程。這個探尋過程同時也是永不停止的。有時候還沒有回報。找到錯誤，會得到表揚。如果最終的交付內容/版本中沒有錯誤，則不會提到這些代碼中的重要性和您在其中投入的精力！
我喜歡編程——不過現在很少進行此類工作了，僅在學術中需要時纔會做這樣的工作。處理項目時，我已不再進行代碼編寫工作了。
香港，1980 年：我開始使用 BASIC 和 Fortran 進行編程。我非常喜歡編程。轉眼到了 1995 年，我開始進行 Java™ 編程，享受接口實現和鬆散耦合所帶來的純粹樂趣。但應該如何設計系統結構呢？
即使獲得了最好的運行代碼，仍然需要一個能夠承受非功能需求衝擊的結構。因此，您需要能夠對各種相互衝突的約束進行權衡，在重複考慮當前情況的細微差異的前提下進行決策。
我比較認可“模式生成體系結構”這樣的學術流派。從藍圖（一組基本模式）開始，然後根據自己的實際情況進行擴展和自定義。這就在最佳實踐和現實具有特定的無名品質（QWAN，Quality Without a Name）之間獲得了最佳的平衡點，這一點我非常喜歡。
我喜歡自己的架構師工作。 :)
|
|
並不是我決定要做一名架構師，而是我從事的工作所涉及的內容正是我們目前所稱的體系結構方面的東西。
開始的時候（大部分時間，甚至到現在也是如此），我們並不進行“體系結構設計”。我們只編寫程序，其中的任何體系結構都是意外出現的。
我在 14 歲時編寫了第一個程序（使用的是 Fortran，當然我對於良好的設計所知並不多，體系結構方面懂的就更少了）。上大學時（最初在 Air Force Academy，後來在 Santa Barbara 的 University of California），我遇到了當時形成了深度設計的早期理念的很多人：David Parnas、Mary Shaw、Tony Hoare、Edsger Dijkstra 等。剛剛二十歲出頭的時候，我擔任過一些相當大（甚至按照今天的標準也可以這麼說）的實時分佈式系統的項目工程師和項目經理的角色，爲美國軍事航天項目提供支持。
1982 年退役後，我加入剛剛創建的 Rational®，參與了 Ada 項目的大量工作。我的大部分時間都奔走於美國各地，與合同客戶和軍隊協作，以幫助他們應用軟件工程的最佳實踐以及這個新興的語言。
我一直是個雜家，出現在科學所指引的地方。我逐漸發現商業領域的很多組織開始邀請我幫助他們進行類似的工作，因此我開始偏離 Rational 的核心業務，將我的精力投入到這個更大的領域中。也大約在這段時間，我撰寫了第一篇有關面向對象的設計的論文，並開始編寫我自己的第三本書（與此主題相關）——其中所有內容不過是對我通過這些項目得到的經驗的總結。我還與 Bjarne Stroustrup 進行了合作（他是 C++ 的發明者，我們甚至還一起去參加了全國性的巡迴演講），因爲我們發現他的語言設計方法和我的系統設計方法非常相似。
在那段時間裏，我仍然進行編程工作：我使用 ObjectPascal（在 Mac 平臺上）編寫了 Rational Rose 的原型，並採用 Smalltalk（PC 平臺上）編寫了第二個更爲完整的版本。Dave Stevenson 和我是第一個 Rational 建模產品的架構師（採用 C++ 編寫；這對 Rational 是一項突破，因爲之前的所有產品都是使用 Ada 完成的）。
這些產品進入市場後，我再次承擔起作爲架構師和體系結構指導人的角色，爲我們的一系列最大的客戶服務。在此期間，我受到 Philippe Kruchten 的工作的很大影響；他領導進行了早期的流程設計等方面的工作，同時他還是 Canadian Air Traffic Control System 的首席架構師之一。他也參與了有關體系結構描述的 IEEE 標準方面的工作。
|
|
最近這些年，Kent Beck 和我組織了名爲 Hillside Group 的模式研討會；這個研討會今天仍然是模式文化的重心。我是 World Wide Institute of Software Architects (WWISA) 的最早成員之一，同時也是後來成立的 American Institute of Software Architects (AISA) 的第一批成員之一，這兩個組織都致力於發展軟件體系結構實踐。
這段時間裏，隨着 Rational 的業務全面納入 IBM 中，我也回到了我原來進行的體系結構方面的工作。我不僅對 IT 體系結構感興趣，而且也對軟件密集型系統的每個領域的體系結構原則感興趣。體系結構方面仍然有很多東西我們不知道——它所代表的東西、它所不能代表的東西、如何最好地表示它、體系結構級別存在何種模式等等。因此，我花費了大量的時間通過實踐和研究來進行學習。在實踐方面，我仍然繼續擔任我們客戶（甚至也包括尚不是我們客戶的組織）的架構師兼體系結構指導人的角色。在研究領域，我正在編寫 Handbook of Software Architecture，該書的目標是確定各種有意義的軟件密集型系統的體系結構。我與 Software Engineering Institute (SEI) 的體系結構人員進行了大量的合作。同時，我也非常密切地關注着 Murray Cantor 在系統工程方面的進展。我在嘗試幫助人們記住，“SOA” 中的“A”表示“體系結構”，另外還參與了一些新興商業和行業體系結構標準方面的工作。
我仍然在進行編程工作（大部分時間都是用 Java），但我想自己現在終於知道了如何設計我所編程的系統的體系結構。
|
|
當時是我學生生涯的倒數第二個學期。我在堆滿研究論文、翻開的書籍和無數的潦草筆記的書桌上埋頭苦讀，並考慮我的畢業論文的命題。我被這個抽象的幾何模型困擾着，試圖說明其對計算圖形的潛在影響。我成天看不同維度形狀的視圖、準平面和 N 維空間的抽象數學變化，都有些頭大了。在此過程中，我清楚地發現自己處於這樣一個十字路口：理論計算機科學（學術方向）或應用計算機科學（計算機行業從業）。我非常果斷地選擇了後者，畢業後加入了一家在《財富》雜誌排行 10 強的銀行。
我在此銀行中擔任助理諮詢師，我所屬的團隊負責設計廣泛分佈於全球範圍內的信用證解決方案。我全面接觸了正式軟件開發生命週期方法、經過業界檢驗的工程原則、軟件產品堆棧和大量商業銀行領域的概念。有了這些經驗，我大膽地來到瑞士，爲多家銀行提供諮詢服務，指導他們解決多個領域的技術問題（如進行電子文檔存檔，以實現異類數據集成）。瑞士人對精工和質量方面的關注是非常有遠見的，而他們對採用新興技術的渴望讓我有機會接觸各種創新產品。
|
|
到此時，我已非常深入地瞭解了銀行業務，並加入了一個全球性 SI 的研發部門，重新回到我最擅長的領域。在這裏，他們允許我對應用程序層進行分析，並能夠直接研究 OS 內核和基礎硬件的基本細節。我對 UNIX SVR4 進行了修改——調整引導和調度算法、優化設備驅動程序、調整事件和中斷處理、對機器代碼進行反向工程、研究前輩（Ritchie、Thompson、Joy）編寫的組件、使其識別 x86 和 RISC 處理器內部指令、處理後來出現的新興微內核和實時操作系統。從中獲得的經驗鞏固了我對解決方案和應用程序實際 如何運行的認識。
隨後進入 .COM 時代，全世界都開始更多地接觸面向對象的概念，而我也不希望被這個潮流拋在腦後。因此，我開始擔任一家新成立的公司的首席工程師，該公司當時正在研發用於解決異類企業數據源的實時集成的產品。我負責設計和構建核心運行時基礎設施、元數據管理和數據訪問框架。這個公司真的是一個 OO 新兵訓練營。我的同事（大部分都剛剛畢業）都具有完全的 OO 意識——我甚至懷疑他們將 Gang-of-Four 的書作爲早餐！我很快便成了 OO 的信徒，對 OO 設計、模式和技術以及如何將其應用於 Java 以及早期 J2EE 瞭如指掌。除了核心產品體系結構外，我還承擔其他一些任務：客戶銷售、提供 UI 工具和人爲因素方面的培訓、生成安裝二進制文件、排除客戶部署的故障等等。
很快我開始渴望感受大公司的那種節奏，隨後加入 IBM。最初我有些擔心自己會迷失在藍色巨人懷抱中，但很快發現 IBM 的運作方式就像帶保護傘的 VC，充滿了主人翁意識和創新。我最初是 WebSphere Application Server 產品的一名開發人員，進行的是系統管理和 EJB 容器組件方面的工作。之後，我加入了 IBM Research 的一個孵化項目 NextWeb，爲 Web 服務建議和創建綜合框架，包括“on-the-glass”服務。由此引出了各種臨時標準，並最後定型爲 OASIS WSRP TC。同時，我還負責設計 WebSphere Portal Server 中的一些組件的體系結構，以將這些孵化技術投入實際應用。
到此時，我掌握了 Web 服務和初期 SOA 的要點。我開始爲 IBM 戰略業務合作伙伴提供技術指導，引導他們充分利用我們的中間件投資組合，從而更好地完成他們的重要產品功能。隨着 SOA 技術不斷成熟，我的這些服務範圍開始擴展到大型 IBM 客戶和相關的適配器方面——共享技術策略、指導他們進行體系結構試點項目以及將他們的問題轉給我們的軟件產品團隊。目前，我的工作重點已經發生了進一步的變化，負責將全球客戶活動中發現的關鍵差距和問題反映到 IBM 軟件投資組合和解決方案資產中，從而幫助推動 IBM 軟件部的 SOA 需求策略的發展。
我非常幸運，能夠親身經歷 IT 的諸多方面，正如前面提到的，還通過這些經歷磨練了我的基本學習技能。就今天而言，如果在處理技術理念僵局或應付要命的競選活動（是的，在 IBM 也有這樣的活動）讓我感覺到自己的精力不足，爲了重新打起精神，我只需要從書架上取下我的畢業論文看看就能辦到。
|
|
我之所以認爲 IT 體系結構是我的正確選擇，是因爲這個技術領域是讓我最爲癡迷的領域（現在仍然如此）。這種專業性驅使我在沒有任何時間期限時開展研究工作，也正是這個因素讓我錯過吃飯時間，因爲我捨不得暫時停止閱讀有關新技術的資料。我非常喜歡將很多不同的觀點組合爲一個具有內聚力的交付內容，嘗試將似乎不相關的東西形成一個更爲相關的解決方案。體系結構強調確定很多不同技術細節的挑戰，這包括對項目的成敗非常關鍵的細節，也包括對滿足涉衆的需求有直接影響的細節。
在我職業生涯之初，擔任的是開發人員的工作，工作重點在較大的軟件工程中非常具體的元素；這通常意味着主要在實現階段參與相關工作，而在體系結構設計期間卻涉及的不多。我當時所進行的設計工作主要是“小型”設計，通常屬於一個應用程序中的工作。隨着我職業生涯的發展，我越來越認識到，即使通過非常嫺熟的技能創建了軟件構建塊，但如果基本理解和體系結構不正確，項目成功的機率也將大打折扣。因此我開始主動尋找能讓我更多參與此類活動的項目。這讓我傾向於喜歡發現解決方案的總體概貌。一段時間後，我開始在項目進行期間擔任架構師的角色。以後的故事您都知道啦 :)
|
|
我倒是希望自己對職業生涯以及整個人生都有所計劃，但我必須承認並非如此。我女朋友和我曾就自由意志進行過討論。她認爲存在自由。而我認爲我們是非常非常複雜的圖靈機，完全由輸入信息序列定義。因此，我可能不應該來回答這個問題。不過，每個人都知道我將如何回答。我的圖靈機進入了一個狀態，迫使我自然而無休止地鑽研任意主題。
我上大學前沒有見過計算機（準確地說是大二才首次看到計算機）。是的，我有些落後。實際上，我都是在那之後很久才首次看見計算機的。我在大二時見到了計算機終端。我當時學習了 FORTRAN，才發現以下事實：
- 我真的很喜歡編寫程序。
- 我真的很擅長編程。
無論如何，我現在並不確定自己是否仍然對此很擅長。我仍然喜歡我工作的技術方面的東西：調整代碼、編寫小段 PHP、討論一些設計選擇、考慮重要的下一步工作。我定期到現場視察，花上一整天時間對項目進行檢查，並與項目人員進行討論。現場人員說，儘管會受時差的影響而且每天工作時間很長，我似乎從來不覺得累。他們想知道我是如何做到的。這樣的日子是我工作中最有意思的日子，我非常喜歡。我對它們的喜愛程度超過了對咖啡的喜愛。
正是這個原因讓我覺得 IT 是我的正確選擇。那麼，我走過的路是什麼樣的呢？我不斷地探索新問題（現在也是如此）。我所走過的路似乎是最具挑戰，也是最有趣的。
|
|
我之所以選擇 IT 體系結構，有很多與 Bobby 相同的原因。我最開始負責維護其他人編寫的代碼。我經常遇到這樣的情況，我要維護的代碼，除了編寫者本人外，幾乎沒有任何人能夠理解。（至少那些希望理解這些代碼的人無法理解。）爲了更好地瞭解代碼所進行的各方面工作，我要重寫代碼，以便能夠更好地瞭解系統如何工作。我發現（我的經理和其他更爲資深的軟件工程師也發現了這一點）自己能夠很好地重寫軟件，從而更便於其他人在我之後進行維護。
隨着時間的推移，我的技能不斷提升，所接觸的項目範圍也越來越廣泛，我經常發現所處理的軟件存在功能重複（或功能非常相近）。我會重新設計此類冗餘功能，以使其包含在應用程序內的可重用模塊中，從而減少要維護的代碼量，降低出現錯誤的潛在可能性。
此時我發現自己希望在更廣泛的範圍內應用這些技能。我想知道我所處理的所有這些應用程序如何一起工作。我想正是在此時我決定要成爲一個 IT 架構師。爲了最終達到我的目標，我接觸了諸多 IT 領域的東西，包括 QA 測試和操作。我還在一個替換 ERP 系統的部署中扮演過主要角色：這項工作要求對舊 ERP 系統與對其依賴的外圍應用程序（或反過來）間的所有接口進行全面的檢查。
所有這些經驗促成了我的 IT 體系結構技能的形成。我當然很同意 Bobby 的觀點，爲了成爲高效率的 IT 架構師，務必通過操作、維護、測試和部署軟件獲得足夠的經驗，從而形成堅實的基礎。
|
|
我成爲架構師所走的路可能與大多數人都不一樣，因爲我大學學的是數學專業，在高中和大學都編寫過很多簡單的計算機程序。大學畢業後，我加入了一家大型零售企業，學習使用各種技術構建商業應用程序。我掌握了很多編程語言和技術，並在後來擔任過團隊負責人、設計師和教師的職位。之後，我厭倦了這樣的生活，決定轉行，因此去上了一所法律學校。從法律學校畢業後，我驚訝地發現很多大公司（不是律師事務所）在招聘應屆法律專業畢業生。在接受招聘面試的過程中，我發現，在法律學校中學習的各種技能（例如，問題確定和衝突管理）對領導能力的各個方面都非常重要（前提是必須掌握這些技能）。此外，我記得在法律學校學習的第一年，一位教授曾指出，該校的目標實際上是僅僅教會我們三件事情：如何讀、如何寫以及如何思考。這些是我們的主要課程。
在決定不從事法律方面的工作後，我在一家諮詢公司謀得了一個職位。我後來離職，並首次加入了一家小型計算機公司（當時規模小）Tandem Computers。我在 Tandem 獲得了大量的經驗，讓我對各個公司如何購買各種先進技術以及如何使用技術有了更全面的瞭解。更爲重要的是，由於在 Tandem 擔任過不同的角色，我擔任過指導諮詢師、程序員、軟件工程師和架構師的職責。我發現自己不僅需要進行設計和編碼，還需要幫助爲解決方案確定恰當的技術，還必須考慮使用模式、服務質量，而且必須同時考慮以後的需求和目前的需求。
我發現好的架構師都是善良的獨裁者，具有很強的技術、良好的寫作能力、良好的口頭表達能力，能夠在各個層次進行溝通。我很喜歡這個新角色。我之所以加入 IBM，是因爲我遇到了很多非常聰明的人，他們都在非常大的公司工作，與 CEO、CIO 交流，影響着技術方向，並負責設計主要解決方案（其成功對高級執行人員非常重要）的體系結構。我也希望成爲這樣的人——現在我是了。
|
|
我從事 IT 工作的頭五年，主要是在零售行業像打雜的一樣（不過仍然被稱爲 DBA）設計和優化數據庫。當時是 20 世紀 80 年代初（是的，從我的年齡就能夠猜出來），但我仍然感到驚訝的是，重構包含幾百萬記錄的數據庫之類的簡單任務經常要花上 2 到 3 天時間。聯機重組和關係數據庫之類的東西當時還不流行！進入公司幾個月後，我詢問當時的上級，爲什麼 CPU 大部分時間都是空閒的，還運行這麼慢，他給的答案是“原本就是這樣的。我們只需要按照手冊中的過程進行操作就行了。這就是爲什麼勞動節的這個週末加班的原因（譯者注：美國勞動節在 9 月的第一個星期一），方便您對問題進行修復。我們每年只有一次機會對數據庫進行重組（對於不熟悉數據庫的讀者，我解釋一下重組：重組通常用於對已經填充了信息的數據庫進行重新設計或重建），以便爲應付聖誕節的購物高峯期做好準備。”
|
|
當時我剛剛走出學校的大門。我非常失望，發現自己所學的所有關於並行計算機科學理論並沒有在那個年代的計算機系統上得到利用——至少在我所知的數據庫系統上是如此。我的目標是設計一個並行版本的重組命令，從而不必在所有周末都在綠色屏幕（指綠色的單色顯示器）前度過。而正是這個使我開始進行數據庫設計、並行編程和多任務操作系統設計。當我將原來約兩天半的重組執行時間降低爲約 7 個小時後，我升了職，我的老闆告訴我，他認爲我以後會成爲一名好的架構師（如此之類的說法）！很快，我成爲了一家小諮詢公司（後來被一家更大的計算機供應商收購）的數據庫諮詢師，開始爲很多客戶設計和調整數據庫。
接下的五年左右，我在教客戶如何設計數據庫和應用程序，以最有效地使用 CPU 資源。這意味着要討論應用程序和數據庫體系結構——而這使我開始接觸 IT 體系結構。我最初以數據庫設計爲核心的工作重點讓我開始探索實體關係模型（一項大部分數據庫設計人員仍然在使用的技術）。後來，在 80 年代末期，我開始研究語義建模（我當時認爲這種技術非常不錯），後來又開始研究對象建模和對象數據庫。大約在這段時間，我首次接觸了“元數據”和“元數據庫存儲庫”——當時正是應用開發週期 (AD/Cycle) 的年代。數年後（也就是 90 年代中期），同時發生了一系列有意義的事件，建模語言（如 UML）、元數據語言（如 Meta-Object Facility、XML DTD 以及後來的 XML 模式）和中間件（如最初的 CORBA 和後來的 J2EE 、.NET 及 ESB）開始採用面向對象的方式，並最終發展爲基於組件和麪向服務的系統。
從這期間的某個時段起，我的名片上開始出現“數據庫架構師”、“對象架構師”、“軟件架構師”、“首席架構師”之類的字樣。也正是這段時間，我被推舉到 Object Management Group (OMG) 的“體系結構委員會”；這是一個行業標準組織，致力於推廣各種行業標準，如 Common Object Request Broker Architecture (CORBA)、統一建模語言（Unified Modeling Language，UML）以及後來的模型驅動的體系結構（Model-Driven Architecture，MDA）。我想人們最終認爲我是個“架構師”，是因爲我幾年前開始不再編寫代碼，而開始將更多的精力放在如何使系統一起工作——工具、應用程序和數據集成的世界。
現在我需要考慮的是各個“體系結構”如何一起工作，如“如何將模型驅動的體系結構和麪向服務的體系結構概念一起使用”。使用開放源代碼（主要是 Eclipse 和 Apache 項目）和開放標準（主要來自 W3C、PMG 和 OASIS）基於真實客戶場景設計一起工作的軟件工具是這段時間我在 IBM 作爲架構師所進行的工作。我還要花時間爲重要客戶提供協助，幫助他們定義體系結構和使用工具與中間件時的策略方向。我想我仍然是個架構師，因爲我現在是 IBM 軟件部體系結構委員會指導委員會 (IBM Software Group Architecture Board Steering Committee)、IBM Eclipse 審查委員會 (IBM Eclipse Review Board) 和 OMG 體系結構委員會 (OMG Architecture Board) 的成員。
毫無疑問，我現在意氣風發，準備繼續在體系結構的賽場上馳騁幾年。也可以說，我現在對體系結構如醉如癡——特別與 IBM 內外這麼多業內出色的架構師在一起時。
|
|
儘管我的職位中有架構師 三個字，但卻不從不敢對架構師這個稱呼感到理所當然。相反，我對 Kent Beck 所寫的關於極限編程 (Extreme Programming) 一段話更爲贊同：不要強制性地要求團隊成員專業化，成爲分析人員、架構師、程序員、測試人員和集成人員——每個 XP 程序員每天都會參與所有這些關鍵活動。
能夠做各個方面的事情，這纔是 IT 的樂趣所在。可以構思一個新想法、對其進行展開、向其他人展示、獲得反饋，然後對其進行改進。而且可以任何時間在任何地點做這樣的事情。其他哪種職業能讓您有這樣自由進行創新的機會呢？
因此要尋找任何能夠培養所有這些技能的機會。不要不敢接觸任何新技術和編寫“Hello World”一類的簡單應用程序。始終有新東西值得學習和嘗試。
|
|
我年輕的時候，經常對看起來似乎簡單的東西如何工作感到疑惑。爲什麼我的自行車有這麼多轉動的部件？爲什麼自行車上有一個鏈子連到踏板上？如果將割草機的小電動機連接到自行車後面將發生什麼樣的情況？自行車會自己動嗎？騎自行車不捏把手下坡時，最好的做法是怎樣的？我並沒有意識到，這正是充滿吸引力的體系結構世界之旅的開始。
和很多同事一樣，我並沒有成爲架構師的想法。但和他們一樣，在我的 IT 領域的成長過程中，成爲架構師的路似乎是一個自然的發展過程。我的職業生涯始於 80 年代末期，最開始在 IBM AIX 開發實驗室工作。我當時的體系結構概念全是關於 AIX 的速度/數據提供和功能。我並不理解自己作爲 C 和 C++ UNIX 編碼人員和測試人員能如何幫助客戶實現和部署任務關鍵型應用程序。其中的很多應用程序都作爲所謂的“資本主義社會”的催化劑或爲其提供主要支持。
離開 AIX 開發實驗室後，我開始擔任與客戶協作的 IT 專家，嘗試實現客戶機-服務器系統。我從事此工作後不久，.COM 熱潮開始了，而很多人稱爲“Java 進化”的趨勢也在這個時候出現了。換了公司後，我於 90 年代中期開始在 Sun Microsystems JavaSoft 組織擔任第一份名片上有“架構師”字樣的工作。從這之後到現在這段時間內，我在不同的 IT 專家角色（執行師和 IT 架構師）之間不斷來回轉換着。
|
|
儘管與架構師相比，我更喜歡“執行師”這個詞，但“架構師”接受度似乎更廣泛，也似乎更受尊敬。我們架構師對技術非常感興趣，因爲我們知道技術如何支持體系結構以及體系結構如何支持 IT。作爲 IT 專家，我通常在知道問題前就已知道了解決方案。例如，我口袋裏有 Java 這樣的錘子，無論手裏的釘子或螺絲釘（問題）的大小如何，我都能夠使用 Java 將其解決。這種理念在很長一段時間內都非常適合我的情況。在上世紀 90 年代末期和本世紀之初，我最終認識到，無論我的編程技能多麼先進，對結果的影響始終微乎其微。我隨後認識到：“體系結構更多地與理解問題是什麼相關，而不是考慮應該使用何種工具和技術來解決此問題。”
我從這些經歷所總結得來的首要原則是：全面理解問題將幫助您確定使用何種技術來解決此問題。
|
|
我上大學時，並不認爲自己將要成爲一名架構師。我認爲自己之所以成爲架構師，是緣於我傾向於對我（以及我的團隊的一些成員）使用的大部分組件進行定形或設計工作。在我擔任每個職位（程序員、系統管理員、諮詢師、中間件產品專家）的過程中，我都傾向於問自己這類問題：爲什麼在做目前正在做的事情以及按照我做事的方式進行是否合理？
我與一些非常聰明的人合作過，學到了大量知識，知道如何將大的複雜問題分解爲較小的可行單元並同時兼顧全局。我認爲這是架構師幫助解決難題和進行大型項目時的關鍵方面之一。我喜歡儘可能從多個角度看待問題，以找到最佳解決方案。我很希望親自動手解決問題，非常喜歡接觸新軟件、新體系結構、新領域和新技術——並將其應用到我的項目中。這是一個持續的學習過程，我很喜歡這樣的生活。
現在可以方便地通過多種渠道進行學習（網絡課程、自學、網站、演示程序等等），學習新技術已不再是難事。關鍵是如何將其應用到實際生活中——而這正是好的體系結構決策與其他決策的區別所在。這非常具有挑戰性，我所知的做到這一點的唯一有效方法就是不斷參加新項目，瞭解自己不熟悉的新領域。
|
|
我一直對設計和製作各種東西充滿着濃厚的興趣。隨着漸漸長大，我真的很喜歡爲科學展覽和其他愛好（如電子學）設計（體系結構設計）試驗的過程。我通過這些開始注重動手爲項目和愛好繪製設計圖。我的父親是一位非常著名的免疫學專家和極端的完美主義者，他向我灌輸了在嘗試動手工作前首先進行設計（設計體系結構）的價值。
|
|
不過，我成長爲架構師的道路有些曲折。我本科時學習的是生物學和計算機科學。我努力利用多學科方法進行微生物學或免疫學（繼承我父親的衣鉢）領域的基礎研究。我真正的第一份工作是在 80 年代中期參與政府的一份合同履行工作；計算機在當時還是一種奢侈品。幸運的是，我的客戶財力雄厚，購買了多臺 PC。徵得了實驗室主管的同意，我使用計算機開發了一些程序，用於進行費時且手工計算時容易出錯的必要計算工作，以便得到化驗結果。
在實驗室進行了幾年腦生物化學研究後，我覺得自己對計算機和設計系統方面的東西有很高的熱情。我重返學校，並完成了計算機科學碩士學位課程。幸運的是，我從研究生院畢業後，就馬上獲得了參與設計一個首創性電信服務提供系統的體系結構的機會——同樣也是爲政府工作。（這項工作讓我不得不從頭學習很多東西。）我們開發的系統將最終爲政府的每個部門提供服務。這五年在一體化電話公司服務方面的工作經歷讓我獲得了指導其他工程師所必要的經驗，最終成爲了所有員工中出色的一員。
我在電信併購狂潮開始前離開了電信方面項目的工作，並隨後加入 IBM，擔任組件代理團隊的架構師。以後的事情大家都知道了。最終，我發現 IT 體系結構爲我提供了跨組織邊界工作的機會，使我能夠設計對客戶業務帶來切實影響的系統體系結構。
|
|
我在爲本專欄第三期提供的“瞭解各個相關部分以及它們彼此如何結合”中給出了此問題的部分答案。體系結構意味着瞭解所涉及的所有部分以及它們彼此如何結合。那麼，如何學着進行此類工作呢？我是怎麼做的呢？（假設我經歷過這樣的階段！）
我首先從事的是軟件測試工作，我接受這個工作完全是因爲可以通過其在編寫軟件的團隊中獲得一個職位（儘管當時我並未編寫過軟件）。測試讓我思考這樣一些類型的問題：如何知道何時軟件正確工作？如果某個功能不正確工作，如何判斷？什麼最容易出問題，怎樣會引起問題？後來發現，這些問題對測試人員非常有意義。另外，我還發現這些問題可以幫助您瞭解如何創建好的軟件。
我的第一項編程工作是對現有代碼進行維護。這項工作實際上教會了我如何編寫可維護（或不可維護）的代碼，以及如何恰當設計來促進重用。代碼應該可供兩類讀者閱讀和理解：
- 執行代碼的計算機
- 維護代碼的開發人員
我遇到了很多代碼都是僅滿足了第一類讀者的需求，而忽略了第二類讀者。一直到今天，我都盡力不犯這樣的錯誤。
因此瞭解如何測試和維護代碼幫助我成爲了一個更好的代碼編寫人員。能夠進行代碼編寫工作，幫助我學會了如何設計組件和框架以及如何將實現隱藏在接口後。必須測試自己的代碼，讓我學會編寫能夠作爲可重用組件分離且能夠作爲單元進行測試的代碼。然後，我開始爲不同的部分進行編程：數據庫、消息傳遞、工作流等，甚至還包括本身具有多個部分的應用程序，如 EJB 和 Servlet。有了這些經驗，我開始將應用程序視爲各大部分一起工作的整體，封裝了每個部分如何實現的細節。隨着我開始將應用程序視爲由各大部分、分佈層次以及運行所需的專用引擎組成，我開始像架構師一樣思考問題了。
因此，我的建議是，從底層做起，循序漸進。掌握每個層次的能力；您將需要以此爲基礎來進入下一個未知的層次。缺少這個基礎的架構師工作起來會比較費勁。
|
|
體系結構是我的正確選擇，因爲它是特定的參與層次，使我能夠最高效地給項目帶來最積極的影響。這在以前指的就是（目前有時候還是如此）測試、代碼維護、開發、設計。可能某一天這將會涉及其他什麼內容。（管理？可能不會。）但就目前來說，體系結構是我幫助完成項目的最佳方式。
在以前的專欄文章中，David Jackson、Grady Booch 和 Jenny Choy 分別建議架構師要注重“溝通與推動”、“溝通與傾聽”及“建立聯繫”。這些也都是很好的建議，但並不一定是作爲工程師時學到的東西。您可能會想到如何構建應用程序的最好方法，但如果無法通過溝通將這些想法傳遞給團隊，說服他們按照您的計劃行事，您唯一的出路就是自己一個人完成所有工作。
|
|
Ali Arsanjani 博士是 IBM Global Services 的 SOA and Web Services Center of Excellence 的首席架構師，主要負責收集和制定 SOA 和 Web 服務的建模、分析、設計和實現方面的最佳實踐。他是內部的 IBM 全球 SOA and Web Services Community of Practice（擁有 4000 名成員）的負責人，是 SOA 的面向服務的建模和體系結構（Service-Oriented Modeling and Architecture，SOMA）方法的主要作者之一。他目前的工作重點是支持建模 (SOMA)、評估、策略與計劃、管理、體系結構和實現的 SOA 工具，以及其在 IBM 內部和外部的實際應用。請訪問他的博客：Best Practices in Service-Oriented Architecture。
Grady 是 IBM Fellow，曾參與過全球幾乎能想象得到的所有領域的很多複雜的以軟件爲中心的系統，在其中擔任架構師或體系結構顧問。Grady 編寫過六本暢銷書，發表了數百篇關於軟件工程的文章，其中包括在上個世紀 80 年代早期發佈的數篇論文，後來從這些論文中發展出來了面向對象的設計的術語和實踐。請訪問他的博客：Software architecture, software engineering, and Renaissance Jazz。
Sanjay Bose 是 SOA Requirements Hub 的程序總監，供職於 IBM Software Strategy 部門，負責 Enterprise Integration Design Center，該中心對 IBM Software 投資組合需求進行標識，並通過參與企業客戶和 IBM Software 產品開發實驗室的工作來開發解決方案組件和資產。他有超過 12 年的 IT 行業從業經驗，主要涉及創建產品體系結構、設計和細化技術策略以及使用分佈式技術設計企業應用程序系統。他擅長的領域包括 SOA、Enterprise Service Bus (ESB)、Web 服務、Java™ 2 Platform, Enterprise Edition (J2EE) 和電子商務技術。他與人合著了 SOA Compass 一書，並在 IBM developerWorks and Systems Journal 上發表了一些文章。他目前在賓夕法尼亞州匹茲堡居住和工作，業餘時間他喜歡參加哲學講座、讀書、看電影和玩 Sony PlayStation。請訪問他的博客：SOA, ESB, and beyond。
Jorge Diaz 是 IBM Software Services for WebSphere 的一位解決方案架構師。他的工作重點是提供中間件和分佈式系統集成領域的策略體系結構，負責歐美地區的相關工作。Diaz 先生與各個大客戶密切合作，幫助他們使用各種技術（包括 Web 訪問）來引入面向服務的體系結構。
Donald Ferguson 是 IBM 的 200,000 技術僱員中的 53 個 IBM Fellow（IBM 最高的技術職位）之一。Don 還是 IBM Software Group 的首席架構師。Don 是 SWG Architecture Board 的主席，該委員會監督 WebSphere、DB2®、Lotus®、Tivoli® 和 Rational® 產品的體系結構和集成。Don 原來曾擔任過 WebSphere 系列產品的首席架構師。他於 1985 年加入 IBM Research。他的興趣愛好包括帶他的孩子們、與他們玩耍、分佈式系統、簡化應用程序開發、系統管理、Web 服務、事務處理、性能以及空手道。請訪問他的博客：Middleware and tools。
Chris Ferris 是 IBM 的 Software Standards Strategy Group 的一位資深技術成員。他有超過 25 年的 IT 行業從業經驗，其中大部分時間都在參與分佈式系統的體系結構、設計和工程方面的工作，並從 1999 年後就開始積極參與 XML 和 Web 服務的開放標準制訂工作。Chris 目前是 WS-I Basic Profile Working Group 的主席；該組織負責開發 WS-I Basic Profile。他是 IBM 在 W3C XML Protocols WG 的代表，並在其中擔任編輯。他還是 IBM 在 OASIS WS-RX TC 的代表。他曾被推選爲 OASIS Technical Advisory Board (TAB) 的成員。此外，他還是 WS-Reliable Messaging 規範和 IBM RAMP 概要的作者和編輯。請訪問他的博客 Web services, distributed computing, and interoperability。
Kerrie Holley 是 IBM 的 Services Oriented Architecture and Web Services Center of Excellence 的首席技術官。他擅長的領域包括軟件工程、體系結構以及將業務要求轉換爲以網絡爲中心的分佈式解決方案的設計。
傑出工程師 Sridhar Iyengar 負責 IBM Rational Software 開發團隊的技術策略。他是 OMG Architecture 委員會和董事會的成員，對模型驅動的體系結構標準的發展進行指導。
Christina Lau 是 On Demand Development 團隊的一名架構師。她目前參與的項目包括創建 使用 Rational Software Architect 的模式解決方案 和試用業務創新和優化功能。Christina 一位高級技術人員，同時也是 IBM Academy of Technology 的成員。她還是 Introduction to IBM Rational Application Developer 一書的合著者。
Calvin Lawrence 是 IBM Software Group Emerging Technology 團隊的一位執行架構師。他的職責範圍包括通過關鍵策略活動的支持來推廣戰略 IBM 體系結構、技術和產品，以及使用 IBM 技術確保客戶實現成功。他是 IBM Software Group Worldwide Technical Leadership Council 的前主席。
Sridhar Sudarsan 是 IBM Software Services for WebSphere 的一位高級 IT 架構師。他曾負責過全球很多客戶的企業體系結構解決方案的工作，包括金融、政府機構、汽車和 SRM 等垂直行業的大公司。他是 J2EE 中的批處理編程模型（該模型現在是 WebSphere XD 中的一個組件）的創建者之一，目前正在向客戶推廣這個模型，並致力於構建此技術相關的最佳實踐。他目前正在負責一家大型保險公司的大型 SOA Center of Excellence 的工作。
Andras Robert Szakal 是 IBM Federal Software Group 的首席架構師，同時也是傑出工程師和高級認證 IT 架構師。他還是 The Open Group 理事會成員。
Bobby Woolf 是一名 IBM Software Services for WebSphere 諮詢師，負責幫助客戶使用 WebSphere 實現成功。他與人合著了 Enterprise Integration Patterns 和 The Design Patterns Smalltalk Companion 。請參閱 developerWorks 上 Bobby 的博客，以瞭解更多信息。
學習
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
- 瞭解關於 developerWorks 技術事件和網絡廣播的最新消息。
獲得產品和技術
- 使用 IBM 試用軟件開發您的下一個項目，可直接從 developerWorks 下載這些試用軟件。
- 從 IBM IT 架構工具包系列獲得大量體系結構資源，可直接從 developerWorks 下載這些套件。
討論
- 參與論壇討論。
- 參與 developerWorks blogs，從而加入到 developerWorks 社區中來。
關於作者http://www.ibm.com/developerworks/cn/architecture/ar-itio8/index.html?S_TACT=105AGX52&S_CMP=techcsdn
|
||
|
|
|
此內容是由 developerWorks 編輯團隊爲您提供。如有建議或問題，請通過以下郵件地址與編輯團隊聯繫：[email protected]。 |