上一篇：决战Biztalk
上一篇讲了和biztalk的决战，这一篇要讲战斗的结果啦。先引用一句本人的格言：“深入，不是为了更加深入，是为了决定该不该及时退出”。实际上，biztalk具有非常丰富的功能，可真正适合我们的功能屈指可数。这里大概说一下我们用到技术点：
- 定义消息格式，即XSD
- 画数据流程图，实际上非常简单，也就两三个环节而已
- 将流程入口发布为WEB SERVICES
- WEB SERVICE将流程激活后将收到的消息再通过调用WEB SERVICES适配器发送给其它系统
- 其它就是利用BTS提供的管理功能配置一下适配器，或者将流程打包成MSI再发布
记忆里还能找的出来的也就这些了。那么，我们以前遇到的麻烦，甚至可以说成是苦难的原因是什么呢？实际上，我们把大把的时间都花费在了研究Biztalk平台本身上面去了。感谢我们的咨询、销售、感谢biztalk、感谢我们的团队…咱们做技术的成长全仰仗这些人、这些事了。
我们的客户是非常高档的业主，第一，因为他有的是钱；第二，因为他的钱用也用不完，所以他可以听风即雨地认为工欲善其事必先利其器，而且要用就用最利的器。而到了我嘴里这么一说，好像又有点艺不精怪器不利的味道了。是，我必须承认我们的技术水平还是有待进几步提高的。难道咱就不能通过提高自身的水平和巩固团队积累来玩好biztalk吗？作为个人，我可以努力去尝试做到。作为团队，我办不到。有如下原因：
- 知识面问题：前面已经提到Biztalk实际上是综合学科，能玩好综合学科的人有几个？
- 人才问题：Biztalk不是编程语言有教科书教你，它是解决方案，要求玩它的人之前做过很多系统的设计，还要有充分的动手能力，知道大型应用痛在哪里？这样的人才市场上有多少？培育这样的人才需要多长的周期?
- 地域问题：我们所在中部发展中地区，工资给的少，有经验的优秀人才都一个劲的往北京、上海等高薪地区跑，一般我们公司拿3K的到上海至少哪8K。于是，又有几个能在我们这里守着枯灯等天亮的？
- 模式问题：我们一个近10人的维护团队天天围着客户转，他们消耗的却是新项目的利润，客户至今没有给运维增加专项费用。于是，平台越是复杂，运维方面的投入就越多，资源就越不够用。
唉！一个发展中的公司的主要问题其实都通过这个项目暴露了，那就是“人”的问题。所以，在人的问题没有得到解决的之前，我只能另谋他法了。（下一章接着再讲）