根據過去的經驗，大多數現有的 EA 框架都在一個或多個方面有限制。例如，如果主要的問題是表示技術設備的低級構塊如何在宏觀層次互連，則無法獲得業務層流程或服務視圖。然而，在 SOA 的背景下，這種考慮問題的方式必須轉換為以表示業務服務的邏輯構件為中心，并且集中于定義服務之間的接口和服務級協定（Service Level Agreements，SLA）。
此外，許多企業級參考體系結構和框架是相當普通的，并沒有觸及設計領域。這樣的高級體系結構無法為架構師和開發人員提供具體的戰術意見，并且常常導致企業體系結構和解決方案體系結構之間出現根本性的分歧。
SOAD 必須幫助 SOA 架構師定義服務前景的整體業務級視圖。這是當今的 EA 框架所無法提供的，它們需要未來特定于 SOA 的增強；按需操作系統（On Demand Operating Environment，ODOE）是 IBM 針對這種趨勢制定的主要戰略。
BPM
BPM 是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的事件驅動流程鏈，正如 Barker 和 Longman 所定義的。這第二種技術使用了不同于 UML 的表示法。
此外，還有許多專用方法（如 BPM 技術）可能被咨詢公司和企業資源規劃（Enterprise Resource Planning，ERP）軟件包廠商視為具有競爭優勢。ARIS Implementation Platform 就是這樣的產品的一個例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM) 和 IBM 的組件業務建模（Component Business Modeling，CBM）戰略。
最近的趨勢是定義表示可執行流模型（如用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL））的標準方法。BPEL 將流程的范圍從分析擴展到實現。這樣的可執行模型引發了一系列的新問題，其中包括：
哪些方面應該用 BPEL 描述，哪些方面應該用 WSDL 描述？流程模型和傳統的編程模型之間的區別在什么地方？
如何將非功能性要求和服務質量特征這樣的方面加入模型之中？
同更傳統的編碼（例如在 J2EE 中）相比，在 BPEL 引擎的編程語言擴展中執行多少邏輯？
如何評定可執行流程模型的質量，其應用的最佳實踐是什么？
什么工作角色進行 BPEL 流管理；是業務專家（分析人員），還是開發角色（軟件架構師）？
必須利用所有現有的 BPM 方法作為 SOAD 的起點；然而，必須使用流程模型中用于驅動候選服務和它們的操作的附加技術來對其加以補充。此外，SOAD 中的流程建模必須與設計層用況建模保持同步，并且必須給出與 BPEL 有關的問題的答案。
OO 范式與面向服務 (SO) 范式
OO 分析是一種非常強大且廣為贊譽的方法，同樣，SOAD 應該盡可能多地利用 OO 分析技術。要將 OO 分析成功地應用于 SOA 項目，您就必須一次分析多個系統。用況模型必須繼續扮演重要的角色。然而，SOAD 必須主要是流程，而不是用戶驅動的。因此，SOAD 需要 BPM 和用況建�；顒又g的強鏈接。
在設計層，OO 的目標是能夠進行快速而有效的設計、開發以及執行靈活且可擴展的應用程序。對象是軟件構造，其行為就像它們建模的真實世界的實體。例如，顧客 (Customer) 將有名稱和聯系信息，并且還可能有一個或多個與之相關的帳戶對象。從 OO 的角度看，每件事情都是對象。
OO的基本原則是：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
