在SOA和其他开发努力所面临的众多新的挑战当中有些是属于传统的。一个典型的例子就是大家所熟悉的企业架构师和开发团队之间的沟通鸿沟。

　　2010年在加州洛杉矶举行的应用架构、开发与集成高峰会上，Gartner的分析师Nicholas Gall对如何处理这种脱节提供了一些实际建议。他说开发人员和架构师似乎身处不同的世界，但架构师不能不食人间烟火，必须与开发人员在处理SOA时所面临的现实问题进行接触。

　　他提供了如下一些提示：

• 　　一定要让架构师更像开发者，甚至可建议他们在结对编程期间是不是与与开发人员一起工作。
• 　　一定不要让开发人员更像架构师——重要的是这两组人都完成了他们被雇用时索要做的那一类型的工作。
• 　　一定要让开发人员理解更大的蛋糕——这意味着要对使用其软件产品的利益攸关者更加感兴趣，要意识到他们的存在。

　　交接的规范就是一个涉及到这一问题的领域，据Gall所言。今天，架构师干的最大一件事是“交付规范”，他主张说：“其中一个问题是它们并非用户友好型的文档”，他继续道。

　　“开发人员是架构师的最终用户。（架构师）应当竭尽（其）所能去取悦用户，规范文档应当结构良好且写作上乘”，他继续道，“只需具备必要正规性即可”。

　　Atom和Spring框架

　　作为结构良好的规范文档的例子，Gal提到了一些开源项目。这些例子包括IETF RFP以及Spring和Atom框架。他表示API是最为关心的地方。

　　我们相信蛋糕里最大的一块就是API。一旦它出现在应用与各种服务之间的接口上面时，需要进行协调最多的地方出现了。据Gall所言但架构师通常交给开发人员的是工具而非真正的API。

　　WS-*堆栈“不是API，而是一个工具包”，Gall如是说道。因此，开发人员就着手开发出“一根烟囱跟着另一根烟囱”式的应用，这种应用并不能进行有效的共享，这跟开发出可用于成百上千个应用上的API是背道而驰的。

　　Gall断言：“把WS-*工具包交给典型的开发人员几乎可以确定会导致烟囱式的接口设计”。

　　可理解的软件框架

　　“在API设计方面，我们还没有取得跟UI方面一样的进展，大多数时候API仍然令人头大得很”。他提到了一个云计算组织，该组织可把API的“动词”限制在大约12项的范围。他对比了自己参观过的一个组织，其手头上共有1700的WSDL文件。

　　他说诸如Atom和OData之类的框架的API想我们展示了如何去设计好的API。

　　与会者Michael Kinstrey指出，框架可成为帮助开发人员的一种手段， 不过前提是它们被证明确实是有效的。

　　“框架多如牛毛。好的框架是那些坚持到最后的”，Kinstrey说。他是通用公司全球研究中心的计算机科学家。

　　“成功框架的一个关键”，与同事一道创建出了一个供通用公司全球研究中心使用的服务框架的Kinstrey说：“是它并非强加于团队成员头上”。

　　Kinstrey表示：“重要的是供开发用的框架没有强加于人，相反而是提供了一种做事情的替代方式——这样的话大家会自行发现它的力量。”