以下经验将会让贵公司降低对ERP应用的依赖，不再受应用与供货商的牵制。你的公司将可开始在实时的环境下运作，从此批处理(batch)这个字也会跟打卡(punch card)一样进入IT部门的历史词汇中。

　　中间件不再是代罪羔羊

　　最初建立SOA时，我们把每样东西都放入中间件中，它可针对目标网络服务进行XSL转换，并向UDDI查询目标网络服务的位置，甚至还启动目标网络服务。于是，似乎只要出了任何问题只需归咎于「中间件」就行了

　　因此，我们决定绕过中间件，让中间件只当作连接应用程序的「联机管道」而已;中间件接受来源地的XML档案，并进行XML语法分析(parse)，找出意欲前往的目的地，再将XML传送给预定的目标，而预定目标则会负责转换XML的工作。

　　这里学到的教训是：移除所有可能在中间件中的东西，你只能把它当作商业流程，或作为传送XML的管道。

　　利用XSLT将数据转为任何格式

　　XSLT(可延伸样式表语言转换)对于跨应用的通讯来说是很重要的。我们还没有发现导入XSLT之后，系统和系统之间无法沟通的例子。XSLT是种典范转移(paradigm shift)，若你是第一次使用，你必须先从小部分功能开始着手，然后再逐步扩展。笔者推荐名为Beginning XSLT的工具书，作者为Jeni Tennison，该书包含9成常用的XSLT。

　　以邮件自动通知问题点

　　每天都会发生网络断线、数据库损毁、应用服务器当机、XML档案不完整、XSLT和你想要的功能有所出入，还有，你的中间件有些小问题。因此，要准备好能够每天自动处理这些问题，不要手动处理这类问题，否则要是相关人员度假去或改转移至其它新项目时就会出现问题。你可利用下列方式来处理：

• 　　以系统或是整合点(integration point)为基础来设定邮件群组
• 　　列出系统可能会发生的全部错误，和曾被你忽略的问题细节
• 　　允许使用者为他们的系统设定错误
• 　　以系统或是整合点为基础，允许使用者和开发人员管理他们想要被知会的错误信息

　　因为信息通知将会开始塞爆使用者的收件箱，可以预见，使用者将会央求解决所有的错误。当然，开发人员不能忽视且让这样的情况发生。

　　在建置完成的前几周中，我们统计了每个整合点的错误排名，藉此评估哪些错误应该优先处理。目前，我们的开发人员已经很少收到错误通知了。

• 　　我们建立队列(queue)和行动(action)来处理错误
• 　　我们使用先进/先出(first in/first out)队列来处理应用程序当机
• 　　我们通知来源系统重送那些没有被目标系统收到的记录