1.不了解你不需要了解的
你不需要去了解的东西不会伤害到你
SOA范式的本质在于使得合作各方或系统之间达成最少限度的协议却可以实现最大程度的合作。这是一种巨大的优势，因为任何你不需要了解的东西既不需要被测试也不需要被维护。你不需要去了解的东西不会伤害到你。假设40%的系统开发成本用于测试上，而高达80%的信息系统生命周期的成本被花费到了系统维护阶段，任何SOA范式让你无需了解的东西都代表了你能节省的金钱。
元数据
你最不需要了解的就是结构、含义以及容许值——这些元数据——不会被系统中筛选、排序或执行计算的逻辑使用的数据。你并不需要去了解这些，因为SOA技术使得数据和元数据同时出现。你的系统可以实时解读元数据，所以如果你要做的仅仅是获取、呈现或传送相应的数据，你完全不需要为系统构建元数据知识。在有相当精密的表示(presentation)功能的帮助下，它甚至可以为用户实现各种各样特定的筛选及计算，且只使用与已有数据同时提供的元数据，而不是内部构建元数据。
通过解读数据相应的元数据，而不是把元数据构建到系统中，你的系统不需要随元数据的改变而改变。需要改变的仅仅是源系统。想想如果遵守该守则，你能在开发、测试和维护上节省多少金钱!记住，在两个系统上做更改，平均来说，其复杂度是在单个系统做更改的四倍，因为其中包含了所有各方的协作。
对于很多面对客户的系统来说，表示以及特定筛选功能基本是其主要的功能。这些系统只针对最基本的客户数据要求内部构建元数据。这并不包括当前或过去的订单、客户通讯录、照片、信函以及任何可用于展示的其他数据，所有这些数据都可以用一种不需要这些数据本质相关知识的方式进行表示，内建于系统中。
技术
许多你不需要了解的事情是与技术相关的。有了SOA，你不需要了解你正在接口的系统是否采用“软件即服务”(Software-as-aservice)，不需要了解实施该系统的计算机安放在何处，是哪种类型的计算机或者运行于何种操作系统，防火墙是如何配置，使用的是哪种数据库管理系统，亦或可以使用哪种交易管理系统。其他你不需要了解的事情是与你所通信的系统内部相关的。尤其是，你不需要去了解任何用于内部数据存储的元数据，因为任何其他系统需要同XSD一致的转换都是其自身的问题，而不是你的。
即便如此，使用SOA进行通信的各方必须达成一致的技术相关的标准还有很多选择。特别是有很多与Web服务相关的那些标准，SOA从业者将其统称为WS-*标准(*指可以使用很多可能的标签替换)。在一定程度上，这些标准提出得很恰当，因为SOA社区并没有满足于不去了解它不需要了解的东西;本文这个白皮书给出了一些指导以期降低由这些标准引起的问题的影响。遵守这些指导，SOA需要的先期协议将比其他方法要少得多。
设计稳定的接口
如果想获取SOA提供的种种好处，不去了解你不需要了解的东西会成为你的习惯。请铭记这点!比如说，当设计一个订货服务时，请记住服务请求者只需要知道，当他需要货物的时候该货物是否会有货，而不需要去了解当前的库存量。如果你的程序调用某一安全服务以判断请求活动是否被授权，不要在系统内构建任何超过其所需服务工作的知识。例如，如果安全服务需要使用输入到程序的安全证书，唯一必须做的就是传递该证书!对你来说，它们只是被封装在输入消息中的单个数据项。该证书是否是格式完整的XML也不要去验证。如果，由于某些只有那些负责安全的小鬼知道的原因，他们选择了违背标准的SOA操作或对证书进行了加密，那么这是他们的问题，不是你的。如果他们改变了任何与证书相关的东西，你的程序不应该为此做任何改变或调整。任何你不需要了解的东西不会伤害到你。当然了，除非你硬要去了解它，在这种情况下如果你们不想在SOA上浪费时间的话，其他人可能最好离远点儿。
不去了解那些你不需要了解的东西可能比你想象的要难。如果你开发专门用于与你通信的信息系统的信息检索服务，你的思路已经不对了，因为你已经把其他系统的知识归并到系统中了。需求中的任何更改将会迫使双方系统都作出更改。通常来讲，比较好的方式是采用数量有限的检索服务暴露系统数据，当检索服务结合在一起使用时，它们涵盖了所有相关服务的信息检索需求。例如，某个产品数据库可能通过好几个服务分别暴露出去：一个简单的仅包含编码、描述、部门以及产品定价的服务、一个暴露出所有该产品财务方面信息的服务，以及一个暴露出所有该产品物流方面信息的服务。许多系统仅需简单服务即可得到满足，大部分只需要部分数据而非全部，或财务或物流的服务，而有一些两者都需要，但此外没有任何一个需要特别接口的系统。这种工作方式被称为麦当劳方式：客户从标准产品中搭配出自己需要的产品。支持这种方式并不困难，因为不管怎样你都需要这些服务去支持面向客户的程序。你甚至可以用这种方式来支持非常特别的信息需求，因为那些不需要的数据可以在消费前就过滤掉。如果不想在巨无霸汉堡中放小黄瓜，扔掉它就可以了!这种方式的基本思路是提供过多的信息要比提供过少的信息遇到的问题少，因为接收方系统可以很容易通过程序过滤掉不需要的信息，但是如果缺少信息那就麻烦了。
不去了解你不需要了解的东西也会使得为支持业务流程所需的信息交互大大简化。在SOA的范式中，当你请求另一个代理为你做一些事，那就是你所需要做的全部。你不需要为代理提供可能有助于完成任务的或者是其必需的额外信息。在点菜时，确保有用于这道菜的原料是厨师的职责。你说出想要的东西，然后就可以静候佳音了。反过来，代理会使用信息检索服务来向你咨询所有信息，但是检索什么、何时检索以及从何检索，这些问题都应该由他来决定，你无须去了解，更不用将该知识归并至你的系统中。这样，在他那一端的更改几乎不需要你这边作出更改。比如说，如果他决定停止维护对你数据的拷贝，你什么更改都不需要做。
当然，不去了解你不需要了解的事情确实会导致效率低下。原本只需要一次交换即可实现的操作现在将需要多个步骤。麦当劳方式常常会导致原本一个服务即可满足却提供了多个服务的情况，另一边却还在检索信息，而这些信息又常常是冗余而非十分必要。总会出现一些情形，可以通过好的商业意识来优化这些通信模式。也会有很多场合你会想要优化用户接口，那也只是因为当前的表示设备并不擅长提供给用户吸引人的界面。但是在你优化之前，请考虑你会失去什么样的灵活性。另外绝不要想去优化那些尚未稳定的功能需求。
