在企业传统的系统开发中，企业在设计架构时往往采用紧耦合的形式，是封闭的、自成体系的。这种架构下的MRP、ERP、OA等产品很难适应或快速响应市场或客户灵活多变的需求，以及后续的扩展。在这样的市场和客户需求下，诞生了一种新的软件产品设计或架构理念：面向服务的架构（SOA架构）。
SOA架构是一种粗粒度、开放、松耦合的服务结构，要求软件产品在开发过程中按照相关标准或协议分层开发。通过这种分层设计或架构体系，软件产品可以变得更加有弹性和灵活，并尽可能与第三方软件产品互补和兼容，实现快速扩展，满足或应对市场或客户需求的多样化和多变性。 。
SOA架构带来的要点是业务驱动IT，即业务驱动与业务联系更加紧密。以粗粒度的业务服务为基础，对公司的业务进行建模，可以产生简洁的业务视图和系统视图；基于业务服务实现的IT系统更加灵活，更容易复用，也更快地响应企业业务需求的变化；基于业务服务，以显式的方式定义、描述、实现和管理业务级粗粒度服务（包括业务流程），提供业务服务模型和相关IT，为业务之间提供更好的“可追溯性”，缩小业务之间的差距它们，并且可以更轻松地将业务服务的更改传递给 IT。
使用SOA架构进行开发时，其基于松耦合的特性可以给企业带来很多好处：
第一，更容易维护
业务服务提供者和业务服务消费者之间的松耦合以及开放标准的采用保证了该功能的实现。 信息系统是基于SOA构建的。当需求发生变化时，无需修改提供业务服务的接口。您只需调整业务服务流程或修改操作即可。整个应用系统也更容易维护。
第二，可用性更高
这一特性是在服务提供者和服务使用者之间的松耦合关系中得到发展和体现的。用户无需了解提供商的具体实现细节。
三、更好的可扩展性
通过依赖业务服务设计、开发和部署中使用的架构模型来实现可扩展性。这使得服务提供商能够相互独立地进行调整以满足新的服务要求。
现在，国内很多企业都采用了SOA架构，但是否真的没有缺点，答案显然是否定的：
SOA 的缺点
SOA作为一种有发展前景的应用系统架构，目前还处于不断发展之中，肯定还有很多需要改进的地方。随着标准和实现技术的不断完善，这些问题将很容易得到解决，SOA的应用也将更加广泛。
缺点之一：可靠性
SOA还没有完全拥抱事务的最高可靠性——不可否认性（nonrepudiation）、一次性交付（once-and-only-once Delivery）和事务撤销（rollb） ack) – 做好准备，但距离标准和实施技术足够成熟以满足这一需求已经不远了。
缺点2：安全性
过去的访问控制只需要登录和认证；在 SOA 环境中，由于一个应用软件组件可以轻松地与属于不同域的其他组件进行通信，因此确保不同但互连的系统之间的安全性要复杂得多。
缺陷三：安排（或胸部）
统一和协调分布式软件组件以构建有意义的业务流程是最复杂的，但它也是最适合面向服务类型的集成。显然，基于 SOA 构建的应用软件被设计为可以根据需要进行拆卸和重建。组装服务。作为当今业务流程管理 (BPM) 解决方案的核心，编排功能使 IT 经理能够集成新的元应用程序 (meta-application) 进行连接。事实上，最大的挑战不是构建模块化应用程序，而是改变这些系统表示其处理数据的方式。
缺陷4：遗留系统处理（遗留支持）
SOA 中提供了用于集成遗留系统的适配器。遗留应用程序适配器屏蔽了许多专用 API 的复杂性和模糊性。精心设计的适配器与精心设计的 SOA 服务具有相同的功能：它提供一个抽象层，将应用程序基础架构的其余部分与各种棘手的问题隔离开来。一些供应商专门从事将遗留应用程序“语义集成”到基于 XML 的集成架构中。但整合遗留系统的工作始终是一个挑战。
缺点之五：语义
定义事务和数据的业务意义一直是IT管理者面临的最困难的问题。语义关系是设计良好 SOA 架构的核心元素。目前还没有任何技术或软件产品能够真正解决语义问题。为特定于行业和功能的流程定义和实施功能和数据模型是一项繁重的任务，最终必须由业务和 IT 管理部门共同承担。然而，预制组件和经过验证的咨询技能可以简化许多挑战。
使用 XML 技术可能是一个好主意。许多公司越来越意识到为其行业开发 XML 标准的重要性。例如，会计行业建议使用可扩展业务报告语言（XBRL）来描述和审查总账类型记录。重要的是学习如何将基本业务流程表示为服务。改变开发方式需要文化变革，而解决技术问题则需要智力练习。
性能（performance）：SOA的第六个缺点？
SOA 的批评者经常将性能视为采用的障碍，但技术的标准化总是需要在速度上做出一些牺牲。这种怀疑通常针对两个方面：SOA 的分布式特性和 Web 服务协议的开销。
不可否认，任何分布式系统的执行速度都不如单机系统快。这完全是由于网络的限制。当然，有些应用无法容忍网络引起的延迟，例如实时性要求较高的应用。因此，在应用SOA架构之前，了解其应用范围非常重要。
除了以上几点，笔者认为还有两点值得关注：
松耦合和敏捷性要求之间的权衡困境：
松耦合的服务设计实际上是一把双刃剑。它带来敏捷性的同时，也给业务建模和服务划分带来了困难。这就是为什么业务建模总是在 SOA 讨论中引起最多争论的原因。
跨系统集成挑战：
面向服务的架构设计将跨越计算机系统，也可能跨越企业边界。我们必须考虑使用互联网时的安全能力和要求，以及如何链接合作伙伴的安全域。互联网协议并不是为了可靠性而设计的（保证提交和提交的顺序），但我们需要确保消息提交并处理一次。如果无法做到这一点，请求者必须知道该请求尚未得到处理。
其次，还有个性化的问题。 SOA确实通过所谓的粗粒度服务接口和分类提高了效率。实现流程后，确实简化了开发难度。如果这个流程不适合我公司的实际情况，我还是需要个性化开发。国内中小企业占企业总数的70%。他们的需求非常个性化，更关心价格因素。事实上，这与SOA高度集成的本质是不相符的。
-->
