其次，传统的做法需要加强业务建模。有些企业，在业务优化和创新的各种实践中，逐渐建立起了业务流程模型。但是大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践。这种缺乏，带来几个问题：一是业务优化、应变和创新缺乏形式化的基础，缺乏数字化的基础，很容易靠感觉办事。这种“拍脑袋”应变策略，往往带来很多问题，有些时候，这些问题的原因被强加到IT的头上。二是业务和IT之间缺乏“可追溯性”(Tracability)，在将业务的需求映射到IT的时候，使用模糊的自然语言，在操作的细粒度上交流(用例，usecase)，这种模糊性带来了翻译后的失真和变形。同时，细粒度的操作层次所定义的需求，受到变化的冲击大而快，应该在业务流程相关的更粗粒度、更稳定的层次上进行。这些问题最终会导致业务和IT在进行需求映射，尤其是在需求发生变化时，很难或者无法保证好的可追溯性，从而导致业务的需求无法准确地映射到IT，业务需求的变化很难被快速地定位到IT受它影响的地方，反之亦然。所以我们说，在传统实践中，业务建模这一环需要加强。没有好的业务建模和业务架构实践，业务敏捷性难以保证。
最后，传统模式需要引入新的IT架构范式和抽象层次。企业的业务活动/流程需要多个系统相互协作来支持，这些系统包括企业自己的，也可能来自合作伙伴和客户，甚至是互联网。如何集成它们?如何在集成的基础上，重用已有系统的能力和数据，协调它们来增值，也就是响应业务的新需求?如何让这种集成和增值发生得多快好省，说变就变?
首先，增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件(或者业务对象)之间交互的接口。在SOA环境下，也就是通常所说的“服务”，包括功能接口、服务质量约定(ServiceLevelAgreement)和业务策略等。它们是用于组件化地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗，而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时，有些变化通过改变服务的配置(如业务策略)来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。
业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。这种粗粒度的服务契约，将分解为人工活动和自动化活动，并进一步递次分解、影射到IT世界的组件和接口。所以SOA跟OO、CBD等过去的技术是包容和利用的关系，而不是取代的关系。
过去，服务和业务流程表现为一行行代码，隐于其中;新的抽象层次将服务和流程显式化，通过基于标准的声明式方式，来形式化地描述业务模型。这不仅仅为业务和IT的沟通奠定了一个好的基础，也为企业架构实践提供了一个好的基础;解耦业务和IT得到的灵活性，还为业务优化、应变和创新带来形式化、数量化、可模拟的基础。如“业务绩效管理”(BusinessPerformanceManagement)以及“业务活动监控”(BusinessActivity Monitoring)。这里的重点是标准化，业务模型元素的显式化声明以及业务和IT的解耦与变化时的可追溯性。另外，一个很重要的事情是建立高质量的业务模型，它确保服务的稳定性、可组装能力、安全、服务质量、策略的保证、同企业目标和战略的对齐，而这些牵涉到管控问题，也就是“SOA Governance”。
这个抽象层次需要具体技术实现形式的支持，它需要最大程度的标准化和接受程度来跨越异构技术环境的边界，有赖于互联网的发展和普遍接受。Web服务成为理想选择，因为它能够真正地做到“平台无关”。过去，CORBA等技术拥有类似的设计原则，但无法真正地做到异构兼容，从而失败。
这个新的抽象层次，同时带来了方法论上的改变。在SOA中，当我们启动一个项目，我们将首先从业务建模入手，通过对业务进行分析，来得到服务模型、流程定义等。通常，采用领域模型分析方法，对业务组件化，标识服务，定义服务的描述细节，检测服务是否符合业务人员的期望值，是否服务于企业的战略和目标。经过这个业务层次的建模过程之后，我们转向技术层次，也就是服务和流程的实现。如果我们没有什么遗留系统，一切是从头开始的一个应用，事情将很简单，我们会采用已有的方法论和技术来设计这些服务。比如一种可能的做法是，我们为每个服务建立它的用例，通过分析所有服务的用例，进入子系统和组件设计，然后是类和对象级别的分析与设计。但如果我们已经有了很多应用，这个时候，就可能需要多做一些事情。如果一个系统包含了业务建模中出现的某个(些)服务所需要的功能或者数据，我们怎么办?当然不能扔掉或者视而不见，我们需要重用它们，也就是要集成它们，所以我们开始面临一个企业整合的问题(应用、数据、安全等)。这就引出了集成架构的问题，请看下面关于集成架构的讨论。
一个新的集成架构负责将遗留系统和(或)新建的系统连通起来，让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互，这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI(EnterpriseApplicationIntegration)和MOM(Message Oriented Middleware)的最佳实践，比如“企业服务总线”(Enterprise Service Bus，ESB)作为一种架构风格元素，用于在分布式环境下提供松散耦合的集成基础，但是SOA使用了Web服务，建立在标准和开放技术的基础上，而不是私有的技术、标准和方式。新的集成架构还引入Service Registry，ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息中间件。
另外，在SOA的实践中，通常会创建一个数据服务层。而这通常会集成EII(EnterpriseInformationIntegration)的技术和最佳实践，不过也会建立在Web服务等标准和开放技术的基础上。
这个集成架构，要确保所有服务和应用在开发之时，能够跟其他的应用和服务，不管它们今天是否存在，互联互通、相互集成，也就是“开发即集成”。
我们这里继续前面关于方法论的讨论。由于SOA架构范式提供了ESB这样一种架构元素来支持一个基于服务的分布式集成架构，我们需要以这个它为基础来设计一些集成用的IT组件，来将我们需要重用的数据和能力从已有的系统中“引”出来，你可以采用任何你所熟悉的技术和方式，不过大多数情况下存在标准的做法，也就是Connector和Adapter。值得提醒的是，这里有一个很重要的设计原则就是ESB是基于“服务”的分布式集成，我观察到很多基于“细粒度”的接口和消息集成，这是不符合SOA的设计原则的，也将导致可能的性能问题。实现时，通过购买支持ESB和ServiceRegistry的产品，奠定基于服务集成的架构基础，然后，购买或者开发自己的Connector/Adapter来将各种应用连通起来，将功能和处理能力引出来。到此为止，我们有了：(1)业务建模而来的服务模型(2)对需要从头实现的服务，我们有了IT层次上的子系统、组件和对象模型(注意：这是一种可能的IT模型而已)(3)对于那些要重用已有系统功能或者数据的服务，我们有了Connector/Adapter来将需要的能力引出，如果它们并非恰好是我们所需要的，我们还需要进行IT组件的设计，这跟从头实现新服务是类似的(4)有了将分布的系统联通起来，基于服务来整合的集成架构。所以，我们需要开始转向实现。这就引出了应用平台的问题。
而在应用架构方面，新的SOA技术和标准，比如SCA/SDO允许你采用平台和语言相关的方式实现，但是组件实现的服务接口则是标准化的。复合应用(CompositeApplication)建立在其他应用的基础上，通过将来自Portal应用的人工活动、B2B的合作伙伴应用、数据服务和本地业务服务来快速形成新应用。基于BPEL等标准的流程引擎，使用“声明式”的方式来将服务编排在一起，在复合应用中起着重要的作用。这些都是在已有的应用平台上增加而来，比如IBM的WebSphereProcessServer支持SCA/SDO和BPEL，它是在IBM的J2EE服务器WebSphere Application Server的基础上实现的。
我们前面所设计的服务，实现它们的IT组件就表现为一些SCA组件，或者EJB、POJO组件，而业务流程则在IT层次上实现为BPEL或者一些SCA组件。这些服务和流程都有自己基于标准的形式化描述，保存在服务注册库(ServiceRegistry)中。
