SOA项目面临的一项重要挑战就是为企业设计的SOA需要同其他措施协同工作。除去Web服务，必须要处理的就是业务服务。除去业务服务，就必须处理业务流程。除此之外，还有业务流程、业务功能等。

　　令人欣慰的是SOA工具的扩展还在进行。但是不断扩充也会变成一种挑战。尽管UML批评声不绝于耳，但它却已经地位稳固，成为系统设计中通用的方法。UML的优点是其可扩展性。实践者目前正在将UML和TOGAF以及其他工具连同使用，从而构建出软件模型来解决业务构想变成工作系统的最重要的一步。

　　如何创建一个有用的工具集呢？专家的一些建议可以为我们提供一些引导。SearchSOA.com最近同Ramsay Millar进行了对话，Ramsay Millar是Integrate IT LLC公司的实践总监，该公司主要进行咨询和培训工作。 Millar为我们解释了SOA专家和解决方案架构师如何将模型套用到架构上，在这个过程中他们需要做什么以及要注意哪些内容。

　　Millar告诉我们，如今的软件和解决方案架构师经常干到困惑。其中一部分原因归咎于他们不能让一个已经确立的参考架构或者可用语言同企业中的各种利益相关者沟通。

　　“架构师是个很容易爬上去的职位，但是很少有人在上升的过程中拥有战略业务模型或者抽象德尔构造块知识和经验，”他说，“我们需要高度熟练的架构师，来创造业务架构参考模型。”

　　成功的软件架构师会发现和企业匹配的工作参考模型会成为他们自定制添加“工具”的框架， Millar表示。

　　Millar自己的工具包里面有什么呢？

　　他使用UML和可扩展的TOGAF 9.0参考模型。同时为了方便自定制使用还增加了OMG BMM、 BPMN和SBVR。

　　“SOA是用来连接业务的，然后驱动服务，”Millar介绍。他已经看到失败的SOA项目的结果。

　　“首先我会问，我的客户‘为什么你的SOA之旅失败了呢？’答案通常是‘业务端是个孤岛，不能和业务模型和战略相关联’。”但是IT端同样是孤岛，他强调。

　　“架构师需要能够更加的协作和灵活，包含自己的模型中所有的观点。他们需要走出玻璃房子，成为‘as is’和‘to be’业务转换之间代沟的关联，”他说。

　　目前，似乎很多人都在技术方面看待服务。他们也应该从业务角度来看看服务。直到一种为此而生的语言出现，各种工具可以很好地使用，从而提供一种处理成功SOA路上代沟的重要途径。

　　编者注：换句话说，他“使用统一建模语言和可扩展的Open Group应用框架9.0参考模型。在增加了对象管理组织的业务激励模型、业务流程建模标记和业务词汇和业务规则语义，从而满足其自定制使用。”