架構面向服務的技術
在其新作《架構面向服務的技術》中，Philip Wik 總結了使用面向服務的技術搭建解決方案的三大阻力：
- 復雜性
如何在恰當的細節和抽象層次上為復雜的事物建模？
- 溝通——設計元素
服務技術架構（Service Technology Architecture，后簡稱 STA）的基礎元件是什么？
- 執行——為成功而做調整
如何提升 STA 解決方案的速度和質量？
在 Wik 看來，最重要的事情是，要記住在處理實際問題時:
……我們必須承認，有些問題是不需要答案的，我們也無法弄清出所有事物的本質，因為思維和符號是有限的……我們必須面對高深莫測的未知。但是，我們只能在這迷一般的世界里行動，不過我們有框架的幫助。框架是藍圖，它指引我們想象、計劃、開發、測試、部署并穩固我們的架構。
Wik 認為，面向服務技術解決方案的兩個最重要的框架是開放組織服務集成成熟度模型（OSIMM）和開放組織架構框架（TOGAF）。
OSIMM 之所以重要，是因為它一個用于創建增量 SOA 實施路線圖的流程，而且它清晰地定義了每個階段的業務收益。此外，它還包含一個用來評估當前及未來的 SOA 成熟度的量化模型。至于 TOGAF ，其企業架構框架有助于回答下列問題：如何構建可達成業務目標的系統？
接著，Wik 介紹了 STA 設計的兩個基本元素——原則和模式。他說：
原則是強制性標準……他們來自于常識及人們的共識。原則又是一個先驗命題，可能合理但卻無法證實……即便我們未能符合某個原則，或者我們忽略了它，它一樣在那里。
談及指導 STA 的主要原則時，Wik 搬出了著名的《SOA 設計原則》，其中包括服務松耦合、標準化服務契約、服務自治、服務無狀態化以及服務可組合性等。Wik 提醒，在使用這些原則時：
若基于這些原則的具體應用去搭建架構，而忽視了原則本身，這樣的做法是不對的。因為，它會走向追逐技術和鎖定技術的境地，而非向業務目標前進。
談到設計模式時，Wik 再一次力薦廣為接受的《SOA 設計原則》。
最后，在談到為成功而做調整時，Wik 建議使用敏捷開發的每天的 scrum 改進責任劃分和溝通；通過 XP 的結對編程改進質量和速度。他斷言這些都是根本要素，因為它們支撐著那些引領 STA 走向成功的高層原則，如透明性、溝通、質量和速度等。
Wik 在文章末尾說道：
面向服務的技術的根本是，簡化系統以符合企業目標；簡化流程以實現目標。我們不反對人們花精力去掌握那些有助于實施 STA 的工具，但是，為了實現目標，可能需要我們放棄一些舊工具。TOGAF、UML 和敏捷/XP 是很好的工具，然而有時候我們需要扔掉這些工具才能正確地看待這滿世界的服務。
盡管本文不乏許多有趣的觀點，但是有些想法卻令人迷惑。首先，Wik 為何棄用“SOA”而采用“SOT”就未交代清楚。而 SOT 這一詞匯通常指那些諸如 Web Services 或 SCA 之類的東西，即能夠簡化 SOA 實施的技術，可是 Wik 把它與 SOA 混用。事實上，本文中的大多數引用、原則和模式都借用自 SOA。再者，文中很大篇幅在關注業務目標和業務驅動力。從前，技術的主要驅動力不是它們，而是實現的簡單性。
另一個問題來自本文的標題，我們通常無法架構技術，而是使用技術。所以，對技術的架構的含義也不是一下子就能理解的。
最后，盡管諸如敏捷、XP 和社交工程在軟件開發中都非常重要，這些東西如何直接應用于架構也不是那么顯而易見。盡管有無數的出版物討論這一話題，但這仍然沒有定論。
此文在英文站一經發布，即引來了眾多讀者的回應，現摘錄幾篇評論以饗各位：
讀者 Roopesh Shenoy 說到：
在我看來，這聽起來像是把簡單問題復雜化，可是根本不需要這么復雜。我一直認為，架構師使用 OSIMM、TOGAF 或其他框架就如同開發經理們執著于使用成熟的技術（如 java）一樣——沒有人會因為使用這樣的技術而被解雇。其實，我們可以從優秀的實踐中學到更好的東西，比如 Amazon 的整個 AWS 基礎設施。
讀者 Konstantin Ignatyev 說到:
本文再次對 IT 做了錯誤的假設：指導原則：“正確地做事”
目標：創新和質量
優勢：視野和紀律
對于極少數 IT 人來說的確是這樣的，但是對于大多數人來說并非這么回事。據統計，人們習慣于安于“現狀”——現狀會使他們感到舒服。IT 比業務更抵制創新的原因也是如此。所以，使用 TOGAF 或其他框架的目的不僅是創造一份安定的工作，而且其真正意圖是讓 IT 變成一個受人尊敬的職業（如醫生和建筑師），有一組原則可教化從業者，使他們忠于工作，使業務人員不再因為要求走捷徑和其他傻事而自毀前程。
本新聞編輯 Boris Lublinsky 認為 IT 是令人尊敬的工作，他回復到：
暫不論我是否贊同本文作者 Wik 的話，但是我認為 IT 是值得尊敬的職業，所以我現在我已經干了 25 年了。而且，我也相信使用合適的框架的確是件好事。 IT 業中令人痛苦的一件事情是，“我比別人更懂”的態度往往導致人們一次又一次地打著“新技術”和“新方法”的旗號重復著 20 年前曾經犯過的錯誤。
Konstantin Ignatyev 這么回復 Boris Lublinsky：
只有當以下現象成立時，我才認為 IT 是一個令人尊敬的行業：1. 不再出現《傻瓜式 HTML》或《24小時速成c++》之類的書籍時。你見過《24小時速成外科醫生》和《一星期成為摩天大樓設計師》之類的書嗎？
2. 客戶會日常地地要求底層實現和架構應該做成什么樣。
3. IT 能夠為“近乎標準”的應用程序設定可預見的時間表；不再花幾個月的時間完成只需數周就能完成的項目。
Roopesh Shenoy 發表了他對 Konstantin Ignatyev 的不同看法：
我有點兒不太同意你的看法：
《傻瓜式 HTML》類似于介紹消化系統和呼吸系統的解剖方面的少兒書。它指引孩子們在成長為醫生的路上邁出第一步，同理，這樣的書能帶領新手們走出變成 IT 專家的第一步。
我不太理解你第二句話的含義，但是我猜測你所說的是客戶干預太多。可這幾乎是每個行業都要面臨的問題。
大多數有價值的項目都是非標準的應用。項目的開銷和價值本就不成比例，而且是復雜且難以預測的。
我的確同意，即便是小項目，它走向失敗也可能是正常的而不是意外，但這并不意味著每個與之相關的人都有錯——巨大的需求導致有新人不斷地加入，不斷地學習。如果有東西能夠證明變得優秀不是那么容易的事，那也就意味著這是一個值得尊敬的職業。
當然，成為開發者并不需要像醫生那樣需要多年的醫學院學習和住院醫的過程。但這也不是生死相關的行業，不是么？
查看英文原文：Architecting Service-oriented Technologies
來自: InfoQ