IT部門承諾產品的交付時間大都基于一個進度估算，很多情況他們僅僅考慮了通過已有服務聚合產生新產品所需時間。當突然需要構建新服務時，交付時間就不得不隨之延長。對于業務人員和用戶，他們不關心產品是否采用了更為高效地開發方式，他們所想要的只是根據預期按時交付產品這樣一個結果。
因此，SOA同樣沒有解決如何令用戶滿意地交付應用和系統這個大難題。
管理階段
最后來看看應用生命周期的管理階段。在SOA出現之前，管理應用軟件開發項目實在不是一項容易的工作。采用SOA以后，根據SOA應用開發所采用的粒度大小，整個開發項目需要分解成若干小的部分，以便開發團隊能夠采用分布式地方式對它們進行開發。對于管理者，這同樣不是一件容易的事情。應用SOA本身對此并無幫助。而項目經理則開始需要應付諸如選擇工具、標準、可重用性和文檔等涉及開發的標準問題。
SOA應用給管理者們帶來了一個必須時時關注的服務庫，此外，他們還需要關注諸如SOA治理等問題，這包括了誰能“擁有”某些特定服務，服務的版本控制，共享服務的安全影響，以及這些共享服務的變化給其他應用帶來的影響等。
SOA沒有解決管理應用開發項目的所面對的問題。事實上，它反而加重了管理人員的負擔。他們不得不時刻留心某一變化對本身和其他與交付業務相關應用服務的影響。一旦應用程序交付，大部分的系統管理和服務管理技術都能幫助IT部門跟蹤瓶頸、錯誤或缺陷。相較于SOA部署，這些技術對于更多傳統應用基礎設施更為適用。
一個糟糕的SOA應用不如不用?
說了這么多，希望讀者不要誤解我的意思。正確地實施SOA確實可以產生巨大的效益，它的可重用、更容實現復合應用(或稱之為聚合)的能力，甚至對于業務和技術人員溝通語言的改善，都有相當的可取之處。但是，同樣也要看到，如果你不能首先控制應用開發最根本的挑戰，那么SOA將是比基于組件的傳統開發方式更大的挑戰。所以，一個糟糕的SOA應用不如不用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
