成功 SOA 的兩個最重要的教訓：共享及與其他部分和諧相處。組織中曾經完全不同的團隊會發現自己在 SOA 實現中共享服務、成本和資源。事先了解所有相應的關系連接需要出現在哪些地方，是確保大家都獲得成功的最好辦法。
團隊協作
SOA 切實地發生著。采用 SOA 時，將影響整個企業，而不僅是 IT 部門。
企業內不同的組織(可能到目前為止都采用相當獨立的方式運作)突然被要求重用其他人的服務，并為創建共享服務提供支持。企業內可能會對這個新的“共享”安排有所顧慮。例如，組織 A 創建了關鍵型服務 X 來支持他們的某個解決方案。他們并不希望將服務向其他組織的應用程序公開，因為他們并不控制其他應用程序，擔心這些應用程序可能會使得此服務崩潰。此外，如果組織 B 的應用程序使此服務崩潰，則可能會導致組織 A 的解決方案也停機�？梢赃@樣說，就像將所有人都將雞蛋放入同一籃子一樣。
這個顧慮非常有道理，事實上必須對所需的需要與給定共享服務關聯的服務質量進行積極評估，從而對其加以處理。不同的組織可能會依賴于相同共享服務的不同服務質量，如果差異足夠大，從財務角度(不是管理角度)來看，認為應該部署該服務兩次。
現在，在組織開始對共享服務的最優服務質量吹毛求疵前，可能會希望對共享服務接口的情況達成一致。如果組織 A 和組織 B 均在過去創建了類似的服務，無疑將會就 A 的服務和 B 的服務如何進行組合以形成共享服務的接口進行討論。此類討論總是會相當激烈，兩個組織都會非常在意其一直依賴的服務的接口中采用所需更改而需要進行的工作。通過部署在之前已經存在的服務與新共享服務間進行轉換的 facade 服務，可以簡化此轉換工作。
很可能在服務調用者和提供者之間存在某個業務實體。誰應該定義實體的表示方式?間接來說，“業務部門”應該負責此工作。應該制訂業務術語表，以文字的方式描述“供應商”和“項”之類的業務概念。還應該捕獲每個概念的動態方面的信息，類似于如何在業務內對其創建和使用之類。將由“業務部門”在數據架構師的幫助下從術語表中派生出邏輯業務信息模型�？梢詮倪壿嫎I務信息模型派生出持久性模型(可以采用 DDL 表示)和服務信息模型(可以采用 XSD 表示)。
正如您所看到的，不僅不同組織的 IT 人員必須開始彼此交流，而且其對應的業務人員也將進行類似的溝通。和 IT 一樣，這些人員很忙，可能需要讓他們確信他們在定義服務接口的過程中扮演著一定的角色(雖然是間接的)，但在業務級別達成此一致前，IT 僅僅是對需求進行猜測而已。
耦合和分離處理新關系
好，現在每個人都在彼此進行交流，而且我們都在扮演著自己的角色，那就可以創建該死的共享服務了，對吧?是的，從技術角度而言的確如此，但由于每個組織目前都負責自己的 IT 支出，那誰將為共享服務提供資金投入呢?共享服務是否可以承載于某個依賴組織的 IT 部門，或者是否將創建某個共享服務組織以某種方式為其提供資金投入呢?如果由現有組織承載，其他組織是否要為服務實現的擴展做出一定的貢獻，以便此實現能夠支持所有依賴組織的需求?如果服務由共享服務組織承載，該組織是否將采用集中方式提供資金支持，或者從依賴于共享服務的各個組織的預算中提供資金支持?談到資金投入，共享服務的成本模型是什么樣的?如果給定服務需要 IBM® WebSphere® Process Server 之類的新技術，且該服務是驅動對此新技術的需求的第一個服務，則此新技術的全部成本(人員、培訓、輔助監視、管理、維護成本等)都歸于此新服務，還是采用攤銷方式分攤到使用此新技術的后續服務?
可以采用很多方式處理這些事實，雖然“正確”解決方案將會根據組織不同而有所不同，但重要的是要認識到解決此方面問題的需求并加以計劃。此組織耦合是由于希望重用服務和更好地保持 IT 與業務的一致性而引起的，可能會從組織變更方面的專家的幫助獲益，例如通過 IBM 全球業務服務部提供的專業指導等。
我們已經討論了 SOA 技術增加耦合的領域，接下來我們將注意力轉向組織之間耦合減少的領域。在這種情況下，兩個組織都是 IT 部門的下屬部門。我將以應用程序開發團隊和數據(或信息)管理團隊為例。
文章來源于領測軟件測試網 http://www.k11sc111.com/