根据过去的经验，大多数现有的 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 和用况建模活动之间的强链接。
在设计层，OO 的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造，其行为就像它们建模的真实世界的实体。例如，顾客 (Customer) 将有名称和联系信息，并且还可能有一个或多个与之相关的帐户对象。从 OO 的角度看，每件事情都是对象。
OO的基本原则是：
文章来源于领测软件测试网 https://www.ltesting.net/
