順序內聚指一個模組中各個處理元素都密切相關於同一功能且必須順序執行,前一功能元素的輸出就是下一功能元素的輸入。
“創建邏輯內聚對象”錯誤,分散式對象的爭論,軟體工程實踐的討論,實質性爭論,現代松耦合的概念,
“創建邏輯內聚對象”錯誤
正如同耦合（coupling）一樣，內聚（cohesion）對於分散式對象與服務來說仍然重要。例如，如果你僅僅因為一組方法具有相似的實現就把它們放在一個對象里，那么你將犯“創建邏輯內聚對象（logically cohesive object）”的錯誤。
分散式對象的爭論
考慮到向“新的”計算方式的轉變常常伴隨著對舊的方式的直接批評，所以如今對SOA的關注引起對分散式對象的激烈反對並不出乎意料。不幸的是，其實許多適合分散式對象系統的質量標準也同樣適用於分散式服務與SOA。因此，有些人為了順應潮流而被迫忽略它們是十分遺憾的。不過，也許不要緊，因為我們可以直接追溯到對象之前的時期，搞清楚像耦合和內聚這樣的度量標準，並重新運用它們。
軟體工程實踐的討論
這在近年來也許已經不怎么被注意了，直到Jim Webber最近寫了一篇關於“貧血的服務模型（Anemic Service Model）”的文章。Jim簡述了過去對良好的軟體工程實踐的討論，他說的一些話跟 Steve 先前的非常相似：
有些軟體是高內聚、緊耦合的。這意味著，儘管它經過合理的設計，但由於存在緊密的相互依賴關係，所以不容易被修改。那是很糟糕的；而且很不幸地是，這在企業套用中很常見。還記得若干年前的確給你留下深刻印象，但如今維護起來卻令你痛苦不堪的軟體嗎？原因就在於它是緊耦合的。
松耦合、低內聚的軟體是另一種糟糕的軟體。這意味著模組之間少有明顯的相互依賴；但是，沒有一個模組是在系統中某方面處於權威地位的。這進而造成需用“散彈法（scattergun approach）”來解決持續的系統演化，因為即使很小的改動也會波及多個組件或系統。也就是我們今天所認識到的SOA。低內聚導致難以閱讀代碼、維護、測試和復用。
接著，該文繼續討論目前的SOA思想完全與這一狀況相悖：
一方面，我們傾向於（而且確實在SOA那幫人的慫恿之下）認為這種架構是非常符合目標的，因為它是極度松耦合的。既然每個組件或服務都與其他別的組件或服務沒有耦合，那么應該可以像玩樂高積木那樣、按無數種方式來組織或調整它們。書上教我們用一組基礎服務來構建“業務服務（business services）”。事實上，我們甚至可以用BPM工具“選擇-點擊”來輕而易舉地達到那個目標，從而避免了如開發者與一直伴隨左右的變更管理這樣的開銷。是嗎？
不。實際上根本不是。[……] 這是對架構的幻想，在真實世界的企業系統里是不可能的。實際上，一個不解決業務問題的服務根本沒有資格進入SOA。
實質性爭論
現在這篇文章吸引了不少值得注意的評論。然而，由這篇文章引發的實質性爭論已蔓延到了別處， 尤其是Jean-Jacques Dubray的回應：
嗯，有人一直試圖單槍匹馬地用一種“面向其他架構（Something Else Oriented Architecture）”來推翻SOA，那就是MEST支持者Jim Webber。[……] 我覺得他這篇文章純屬誤導。也許有些地方我理解不當，但Jim說的是內聚與松耦合的關係。[……] 在我看來，內聚（cohesion）聽起來是個不錯的工程原則，它很像“依賴結構矩陣（Dependency Structure Matrix）”。[……] 松耦合（loose coupling）的目標正是降低內聚。一個互聯的（connected）系統是不存在內聚的。內聚和耦合不可能同時存在。即使在英語裡，把這兩個詞聯繫在一起也是很糟糕的。
松耦合的目標，是使得在不同時間、用不同技術、具有不同安全模型的代碼片斷可以一同工作。
SOA是要遠離內聚的系統、轉而支持更廣泛的重用場景。多層內聚的系統提供“多層”（像庫一樣的）重用模型：上層可以重用下層。不幸的是，它強迫我們以一種與理想的信息系統架構不兼容的方式來創建系統。問題出在內聚，而解決之道在於松耦合。Jim，你真以為人們都在試圖“把東西放在一個模組里”嗎？
Jean-Jacques提出，儘管內聚是一個被充分理解的軟體工程原則，不過它跟“當代”SOA並不相關：
有些人老拿他們5年前形成的觀念來看“SOA”，而那只是被他們自己錯誤理解的SOA，這種情形讓我覺得越來越不愉快。Jim所展現的是一幅陳舊的、並不能代表2008年的SOA的情景。
現代松耦合的概念
之後，Jean-Jacques 又繼續討論了Steve最初那篇文章：
