SOA是企业架构的一个方面，本身并非一种技术，而更是一种规则。SOA最佳实践的精髓就是理解如何用正确的服务处理正确的问题。毕竟，IT是用来处理业务问题的，而不是实现技术方案然后用它们找出一些业务问题。

　　我们大家都知道金发姑娘与三只小熊的故事，这个故事讲述了想得到她的椅子、粥和床的三只熊的故事。就像能满足所有人的事物或不能让金发姑娘满意的食宿一样，很多早期面向服务架构的支持者都认识到他们必须测算服务的大小才能解决他们的业务问题，这样他们就能用复用最大化减少不必要的开销。不仅如此，这些早期的采用者还意识到他们必须处理服务基础设施的重要方面以及重新设计架构的最佳实践，哪怕是部署一小部分服务。毕竟，成功的SOA实践需要的不仅是正确的服务，还需要用正确的方式实现它们。

　　ZapThink反复强调的就是SOA是企业架构的一个方面，本身并非一种技术，而更是一种规则。SOA最佳实践的精髓就是理解如何用正确的服务处理正确的问题。毕竟，IT是用来处理业务问题的，而不是实现技术方案然后用它们找出一些业务问题。

　　识别合理尺寸的问题

　　正确识别服务的合理尺寸一个关键是识别SOA项目的适当范围，换句话说，就是解决正确的业务问题。在处理SOA项目时关注公司想要的所有潜在服务是非常危险的。这种方法实际上就是想把整锅水都烧开，其实是毫无意义的。毕竟，SOA的目的是处理公司面对的不可预测的经常性的变化。所以，我们没有必要试图通过识别公司需要的所有服务来处理一个非常庞大的业务问题，因为这些服务还是会继续随着时间变化的。

　　另一方面，ZapThink曾经鼓励公司应该首先处理最小的问题才能成功应用SOA。现在，这很容易被误解成鼓励公司只开发粗粒度的服务，甚至是解决每人实际关心的一些小问题。SOA领域一些著名的专家对这个问题也存在争论，但他们对此问题的解释是适用于市场的。事实上，我们赞同其中的很多观点，尤其是James Governor的。相反，公司想要的最后的东西是细粒度的服务集合。它们满足的业务需求很小以至于每个单独的服务几乎是没用的。公司需要合适粒度的服务来处理业务问题，但是业务问题又应该是多大呢?这个问题不同于服务的粒度或者实现服务所需的基础设施、架构和计划。

　　理解构建一个完全SOA的细粒度服务(或者相同风格的完全粗粒度服务)的错误很重要。我们喜欢使用LEGO拼装玩具作为SOA的隐喻来说明这个问题的答案。单从细粒度服务来实现SOA就好比只用最小的LEGO构建某种东西一样。当然，每一小块都有合适的接口使你能把它连接到其它的1×1块上。那就像拥有一箱马形状和车形状的LEGO。当然，它们有突起，而且与你想要的很相似，但它们不是可重用的，而且完全无助于构建其它任何马和车之外的东西。这个故事的道理就在于，你需要对服务合理分类，从细粒度的一直到粗粒度的，这样才能说明你特有的业务问题。

　　我们的首个服务需要多少基础设施

　　假如你正在启动一个SOA项目，你或许只看到了有限范围的服务功能。但这并不表示你需要限制基础设施。因为一个组织为他们的第一个项目可能实现一小部分服务并不意味着他们就能提供产品中成百的服务。事实上，拥有业务依赖的粗粒度服务是很重要，至少跟有成百个细粒度的，且每一个都能解决整个业务问题一部分的服务一样重要。所以，公司需要从一开始就考虑在整个生命周期内如何开发、部署、测试以及维护你的服务。

　　一个例子就是ZapThink对注册、存储、元数据管理和SOA控制的观察。在早期的SOA和Web services，根本没有人对基础设施构件感兴趣。这是因为注册和控制直到有足够多的服务在组织中被构建和部署时才会需要。然而，成功部署了SOA的公司发现实际上在服务部署过程中更早需要这些解决方案，因为尽管只有一部分服务被部署(甚至没有部署)，但更早地搭建架构上的最佳实践很重要，这样的话，控制和元数据管理就能尽可能早地实现。对安全和身份管理同样如此。事实上，对于任何SOA的业务问题，SOA的实现者都要意识到他们需要从用面向服务来解决他们问题的那一天起就考虑整体的SOA实现路线图。

　　从业务需求开始

　　没有公司采用SOA是不以处理重大业务问题为目标的。毕竟，如果我们所做的仅是为了用服务处理小问题，那么我们就会跌入我们构建。所有的软件项目都必须很自然的从业务需求开始，而对于SOA，主要的业务需求是“元需求”，它的目的是实现一个响应不可预见的变化的架构，一个本质上很灵活的架构。无论如何，架构师首先要意识到对IT的特殊业务需求，例如，一些新的业务功能，新的产品，新的业务关系或者新的预算限制。无论这些业务需要什么，面向服务的架构都必须铭记这样的需求永远没有尽头。

　　毕竟，SOA项目不是典型的IT项目。典型的IT项目以确定的业务需求开始，架构师或项目团队里的其他人可以和业务干系人(提出需求的人)坐在一起提炼出一套需求用例。但是，SOA项目的用例完全不同。它不会说明特定的“我需要系统这样做”一类的需求，而是描述很多用户想如何利用。于是，面向服务的架构必须允许需求变更而不是假定有一套固定的需求。解决方案必须不只满足业务的短期需求，而必须能够满足未来的需求。

　　ZapThink的做法

　　因此，我们说SOA项目应该以最小的业务问题为目标。这并不意味着最小的应用或最小的解决方案。就好比业务过程以组成服务的方式组合，也能包含更小的业务过程。业务问题也是组合的。公司可能会有如何更好服务客户的业务问题，但这个问题实际上由很多更小的问题组成，例如更好的确定他们客户的身份，改进客户支持过程或者减少支持客户的时间和费用。每个这种问题又是由更小的问题组成。

　　因此，面向服务的架构必须能为组织如何解决迭代式问题维护一个实用的思维模型，而不是维护一个单独的附带的组织架构。通过这种方式，架构师能用不大也不小的合适粒度的服务为业务问题构建SOA解决方案。

　　尽管我们的产业专家不会同意，但实际上我们正在谈论的东西是很能给人鼓励的。很长时间里我们没有谈论SOA为何物了，而只是谈论如何使用它。所以，现在的谈论正好帮助大家意识到SOA成功的关键并不在于选择合适的中间件，而在于选择合适的服务，并且用合适的基础设施使这些服务对组织产生价值。