以下这些问题是在与某个客户交流SOA Service Modeling过程中收集的问题，下面的回答是我个人目前的理解，欢迎大家补充。
是否整个企业中的所有SOA项目共用同一个Service Model? 如果是这样的话，开发团队如何组织分工?
是的，我们应该维护一个(并且是唯一的)企业级的Service Model。SOA是一种架构风格，意味着很多新的业务流程都会基于SOA架构来实现，尽管在实际操作中对应着很多独立的IT项目，整个企业应该有一个唯一的Service Model来描述企业的所有服务，该服务模型保证了后续发现的服务不会出现冗余，并且每个服务都能维持一个适度的颗粒度。除了各个独立的IT项目团队之外，企业内部应该有一个专门的SOA架构团队来维护该Service Model。
同样的问题是否也适用于企业业务模型?
企业的业务流程是唯一的，所以我们建议每个企业也维护一个独立的业务模型，以后的新业务流程无非可以分为以下两类：
. 原有业务的改进
可以表述为原有业务用例的一种新的业务用例实现;
. 全新的业务流程
表述为一个新的业务用例，有它自己的业务用例实现。
这样，整个企业的业务发展和流程改进过程都可以在这个业务模型中被完整地记录下来;对客户来说，这是一种宝贵的软件资产。
企业业务模型和服务模型能否分属两个不同的RSA项目?
可以，RSA允许跨项目和跨模型的模型元素引用。一般情况下，不存在跨项目或跨模型的引用需求，设计者只需要参考其他模型就可以了。
所以在实际应用中，可以分别有一个业务建模(UML)项目、一个SOMA服务建模(UML)项目，以及多个具体的业务流程设计、实现、开发(J2EE或其他类型)项目。
是否能通过一种标准方法和手段来固化SOA的架构设计，即不同的人拿到同样的业务流程需求，按照这种方法和手段可以设计出一致的架构?
这就是很多客户都在寻找的“银弹”：是否存在一种工作流程，随便找一个人，只要他按照流程步骤去做就能把系统设计出来。而我们都知道“银弹”是不存在的，软件开发本身就是一件创造性的工作，需要发挥人的智慧和创造力，不同的人设计出来的系统是不可能相同的。SOA也只是给大家设计系统提供一个统一的架构风格，实现同样一个业务流程，可能甲用到了10个服务，而乙用到了5个服务，关键是看谁抽象出来的服务更易于重用。
从答案也可以看出服务不应该只是由某个人来确定的(Identification)，应该是通过一个团队(SOA架构团队)来集体讨论决定哪些业务功能被确定为服务，这样也能保证服务的可重用性以及适当的粒度。
