除了先前提過的幾點，SOA（服務導向架構）和 Web 2.0 有更多異曲同工之處，像是在開發方面。
敏捷、迅速應變的能力 (agility)，是目前公認 SOA 所能為企業帶來的主要效益；開發組合式應用 (composite applications)，來快速回應新的業務需求，是企業決定導入 SOA 的一大誘因。無獨有偶地，在 Web 2.0 的領域中，敏捷開發 (Agile Development)，也開始蔚為風潮。
敏捷開發被 Tim O’Reilly 等形容為永遠的 beta 版 (perpetual beta)，並認定是 Web 2.0 的一項重要精神和特徵。
有別於傳統大型專案的策略，其開發、實施期間往往需要耗費數年，SOA 和 Web 2.0 改採小專案、漸進式的做法，透過持續性的改進，讓應用的價值能夠一次一點地提供給用戶。漸進的做法，雖然無法一次將大量新功能提供給用戶，但卻能和用戶保持持續性、更緊密的互動，讓他們更快享受到新的應用服務所帶來的便利。幾年後算下來，點點滴滴積累下來的成果總合，往往遠超過不做則已、一做驚人的大型專案所帶來的效益。
微軟和 Google 分別是傳統和敏捷兩種典型的代表。微軟的 Windows Vista（之前稱作 Longhorn），歷經六年波折，終於預定將在明年一月上市（是否還會產生變數，不得而知）。多年下來，傳統套裝軟體開發的做法，是由上而下，先由一組象牙塔裡的精英工程師，預測未來趨勢，收集研判用戶需求，然後再一步步進行設計、開發；整個歷程相當曠日費時。對照之下，以 Google 為代表，採取敏捷開發策略的 Web 2.0 網路服務公司，三天兩頭不斷推出一個個小服務、小工具。雖然就個別應用服務或工具而言，沒有任何一項能和微軟功能強大的大型套裝軟體，例如 Office 平起平坐，相提並論，但卻能更快地將價值一點一點地提供給用戶；透過觀察用戶在線上對網路服務的使用反應，Google 能持續地修改這些服務，來更契合用戶的使用需求；多項服務聯合起來的價值總合，對許多用戶來說，可能不輸給一個大型套裝應用。相較之下，如果是傳統大型套裝軟體，用戶往往需要等下一個版本上市，才能等到更好用的功能，而這一等，可能就是好幾年；更何況，許多複雜的功能，對大多數用戶來說，其實是多餘、根本用不到的，但這些額外的功能卻延遲了整個軟體推出的時間，提高了開發成本（和售價）。此外，複雜度同時也增加 bugs 的數量和出現的機率。
如先前提到，Google 從制度面著手，將敏捷開發深化到整個企業文化之中 — 每位工程師每週有 20% 的自由專案時間。所以這些小型服務和工具的原始設計和創意，大都來自基層的工程師。前幾天美國商業週刊的一篇文章指出，Google 利用這種由下而上的開發策略，讓工程師們「百家爭鳴，百家齊放」，期待能有少數殺手級應用服務，從中脫穎而出（Google Map 就是一個成功的例子）；並事先作出心理準備，不排除將可能有多達半數以上的應用，會逐漸凋零。
除了微軟之外，許多銷售企業套裝軟體的公司，包括 SAP、Oracle 等，多採用傳統大型專案的開發模式。產品上市後，購買的企業還需要仰賴專業顧問服務，再耗費相當的客製工夫後，才能上生產線服務用戶。近幾年來，打著軟體服務化 (Software As a Service) 的企業軟體公司，如 Salesforce.com 等，採用敏捷開發模式，快速回應客戶需求作修改，已經開始讓傳統大型套裝軟體公司感受到威脅，紛紛計畫推出類似的網路服務型態產品來因應。
其實在十年前，劍橋大學和哈佛商學院的大衛顎普頓 (David Upton) 教授，就已經預見敏捷開發和強調模組化的 SOA 模式對企業的效益（儘管在當時，”SOA” 一詞尚未出現）。近幾年來，從 open-source 領域實踐 “release early, release often” 的信條，Web 2.0 新創公司採用的敏捷開發模式，到採用 SOA 企業的組合式應用，在在都顯示出: 強調漸進、持續改善的開發模式，終於開始被愈來愈廣泛地採用，顎普頓教授當時所提倡的理念也終於得到了伸張。
十年前正是 ERP 系統獨領風騷、方興未艾的年代。顎普頓教授研究製造業運用 IT 的效益，在一篇論文中，對曠日費時的大型 ERP 建置專案所可能帶來的問題，提出警語。他把這種不做則已、一做則人仰馬翻的大型 IT 專案，稱為做 “installation-based” 的模型。這類專案，往往由高層主管拍板定案、向下貫徹。企業員工在這樣一個「大耀進」的過程中，有如洗三溫暖般。基層 IT 員工被迫接受全新、ERP 相關的專屬語言及開發方式，往往無所適從。
顎普頓教授將另一種與 installation-based 對比的做法，稱做 “path-based” 的模型。在這個模型中，IT 開發被視為一條不斷綿延的路徑。各項科技（網路、系統軟體、應用等）在這條路上交疊、持續演化、相互依存著。如文中寫到:
在這種 [路徑做法的] 情況下，主要的考量放在發展整合新元素的能力，同時保持與既有系統的相容性。專案通常是小而快的，目的在迅速收成，方便區域性的實驗，並可沿路提供價值。用戶在整個過程全程投入。此一模型較不需要長程的規劃和大型專案管理的能力，偏重持續設定正確的方向，同時在作業過程中，需要專精的技術實力。
論文中指出，路徑模式的做法，其實和幾個先前在 AMT (Advanced Manufacturing Technologies) 領域中，已經歸納出來的特性，如模組化 (modularity)、可及性 (accessibility)，和包容性 (inclusiveness) 非常契合。過去日本汽車製造業者之所以能打敗美國底特律的昔日龍頭，與他們多年勵行持續精進的做法有很大的關係。
最後，引用軟體工程界大師 Martin Fowler 在探討 Continuous Integration 時，對敏捷開發的詮釋，作為結尾:
One of the most difficult parts of software development is making sure that you build the right software. We’ve found that it’s very hard to specify what you want in advance and be correct; people find it much easier to see something that’s not quite right and say how it needs to be changed. Agile development processes explicitly expect and take advantage of this part of human behavior.
