松耦合系统通常是基于消息的系统，此时
客户端和
远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方。
松耦合通讯机制提供了
紧耦合机制所没有的许多优点，并且它们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能好处，便于在客户端和服务之间进行更为紧密的集成。
造成这个趋势的主要技术原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、发现和集成)等标准，
Web服务可以动态地发现和绑定到其他服务。
而主要业务原因是：
企业越来越需要灵活地处理业务流程的更改以及与合作伙伴的交互方式。松耦合系统的优点在于更新一个模块不会引起其它模块的改变。
传统上，业务流程是在企业范围，甚至在企业的不同业务单元内开发。这些活动在详细的实时信息的帮助下进行管理。跨多个业务单元或跨企业的流程必须更加灵活，以应对各种各样的需求。在这种情况下，可能出现更多的不确定性：参与者及其角色不断变化，所需的交互类型也不断变化。
在运营状况起伏不定的环境下，必须有一个松耦合架构，以降低整体复杂性和依赖性。松耦合使应用程序环境更敏捷，能更快地适应更改，并且降低了风险。除此之外，系统维护也更方便。在B2B领域，由于要求
业务实体之间独立交互，因此松耦合显得尤为重要。
业务合作伙伴之间的关系变化莫测，联合关系时而建立，时而又断绝，还需要在商业合作伙伴之间建立业务流程以满足市场的要求。两家公司在某一市场是合作伙伴，而在另一市场却可能是竞争对手。底层IT基础结构要适应这样的灵活性和独立性要求。
理想情况下，业务关系应当互不影响：在建立新型业务关系时，不对已有的业务关系造成影响。为一个业务合作伙伴提供的功能或许不应当供给另一个合作伙伴；与一个业务合作伙伴相关的更改不应对其他合作伙伴造成影响。一个商业合作伙伴不应为了等待一个同步响应，而阻塞另一个合作伙伴。IT系统的可用性也不应依赖于业务合作伙伴IT系统的技术可用性。
在软件领域，“耦合”一般指
软件组件之间的
依赖程度。那么，什么是依赖？各种依赖对[2]
耦合度和松散度有多大影响？软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中，为了确定系统的耦合程度，必须分析各个级别。表3-1简要介绍了这些级别，以及这些级别与
紧耦合-松耦合的关系。