南京之行

南京之行甚为奇妙。听说有个数据库迁移的项目，这个和BAM有点关系，于是就被卷入了。和GBS的销售开会的时候，也许太能忽悠了，被点名去南京见最终客户。本来是应该临时抱一下佛脚再去的，抱佛脚的资料都已经有了。只是有些更重要的安排，没办法，只能见了客户随机应变了，好在还有一个DB2的专家一起。西服领带大衣公文包，好像已经尘封了数年了，行头在身，熟悉的感觉又回来了，譬如武打小说中退隐的高手又重新捏住了剑，不过一般来说，这种高手往往是铺垫是牺牲品，不知老刘此行又会如何。很久不做忽悠人的工作，居然心里有点虚。。。。。。

客户很变态，上班靠打卡，一共有19楼，只有两部电梯，而且，打卡的地方一个在10楼，一个在15楼。而IT办公的地方基本在17，18楼。后果就是，到9点半快要上班的时候，电梯实在等不住了，于是一堆兄弟开始锻炼身体，先爬上10楼，然后再做电梯到17，18楼。。。。。。老刘是供应商，暂时不需要打卡，所以笃悠悠的到了18楼，穿过办公区，到19楼找到了会议室。会议室中已经有了8个人，一个看上去比较胖的，就是昨天GBS的销售左关照右关照的，客户的老大。旁边簇拥着2个小弟，另外一个高一点的，看上去不像小弟，应该也是可以说得上话的吧。在客户的老大对面，一看风格，就知道是IBM的兄弟，而且给老刘的感觉很好，所谓看上去特别顺眼。IBM的兄弟的旁边，坐着两个美女+一个留着山羊胡子的小弟。老刘坐下的第一个想法就是分析这些人的身份和情况。不过，这里，老刘犯了第一个错误，没有注意到真正的最终客户和客户另外的供应商的区别。表明老刘不做销售3年之后，观察能力有所下降。当然，美女们的作战技巧也让老刘丧失了最后一点警惕感。老刘到的时候，他们已经开始讨论当前数据库和DB2的优劣了，在老刘看来这个是没有意义的。除了Oracle，不知道还有什么数据库可以和DB2一较高下！所以老刘一言不发，就听了。当然，DB2也不是老刘的特长，所以老刘也不用在专家面前献丑。客户中一直发言的就是他们的老大，姓Ji，而美女中一直发言的姓Yuan；而他们相互之间的称谓非常熟悉，Ji总，Yuan总。所以老刘的第一判断是，今天客户这里2位是主角。而且这两位主角属于不同的部门，相互之间非常熟悉。在对数据库性能等的提问中，JI总一般不说话，都是Yuan美女在问问题，所以老刘做了第二个判断，Ji属于架构或者管理决策型人物，而yuan属于数据库部门
。数据库的问题问得差不多了，由于老刘的一言不发，让Ji总感觉有些不爽，所以特意来challenge老刘。老刘也没有多讲，就说，其实没啥好讲的，数据库的专家在这里呢。我要说的就是这次这个case，首先是能不能做的问题，其次是如何做的问题。能不能做由我们的专家和各位探讨，怎么做，我可以和大家分享。由于老刘的第一个失误，把美女们当作了最终客户的数据库部门的负责人，所以老刘上来就提出了全部铲除PB端，将C/S完全改造成B/S的方案。结果Yuan美女果然不是好对付的，居然说她同意这个方式。这使老刘彻底丧失了警惕性，因为这基本上意味着当前POS的供应商彻底出局。随后的讨论中，老刘为此付出了一定的代价。不过，好在这个不是致命的失误，只是让老刘丧失了一个反击的机会。但无论如何，察言观色的能力，分清敌我的能力，老刘是毫无疑问地下降了。由于对B/S架构性能的担忧，大家的方案迟迟不能落实。老刘就提出了一个把业务划分，performance要求不高的，客户端不会大量使用打印机，读卡器等硬件设备的非核心类业务先上三层，而核心类业务改造成链接DB2的二层的方案。于是大家开始review业务，到这时候老刘才发觉，原来美女们就是POS供应商，而且客户关系很深。可以说，客户把整个数据库和C/S架构的客户端都外包给他们的了。这时老刘才发觉有点麻烦，不过这样才真的有意思。趁大家在review一个一个业务，老刘就在根据他们你一言我一语的话语和说话的神情，分析他们的特点。然后看看怎么样才能找到一个大家都可以接受的切入点。具体的内容就不说了，最终老刘整理了5个方案，基本上定下来了下面的做法。看上去，除非在技术上有突破，否则必然是分步走的方式了，只是究竟是按照老刘的先对非核心业务上三层还是按照美女们先对核心业务上三层，有点争议。具体内容就不表了。这里要补充一下老刘犯的错误，真正的客户都带着客户的badge，而那几个美女没有！
不过，对老刘老说需要的是总结。首先是换位思考，如果老刘是客户的老大，只要做这么几件事情：
第一件事情：
1.让IBM说明当前的DB和DB2的区别在哪里；2.让POS供应商说明当前的Application用到了哪些当前DB的特性，这些特性，在DB2中怎么实现；3.根据上面的区别，可以估算直接迁移需要的工作量，称之为WL-A（WorkLoad-A）；4.由于PB不支持直接连接DB2，OK，采用ODBC或ADO或者DB2的其他桥接驱动，先做一个Pilot的项目，然后进行压力测试，看看性能损失有多少，记为PL-A（PerformanceLost-A）；
于是可以测算：1.这个PL-A是不是在可以接受的范围，如果不可以，那么就必须划分业务，以保证核心业务的PL在允许范围内；
2.这个WL-A是不是在可以接受的范围，如果不可以，也必须划分业务，看看哪些业务必须先上，以保证不影响日常的运营。
由上面的第一件事情可以看到，对于存在的WL和PL的risk，划分业务都是必须的，所以就有了第二件事情：
1.根据最终用户的类型及是否使用大量客户端硬件设备，把业务划分为核心和非核心业务
2.根据上述方案，要么核心业务走3层架构，要么非核心业务走3层架构，于是我们可以构筑一个pilot的项目，分别对这两种方式进行压力测试。根据WL-B和PL-B，WL-C和PL-C立马可以得到一个结论，到底采用哪个方案
所以，基本上来讲，不会发生需要大家在这里毫无头绪的发言的状态，尤其是，供应商之间还有各自的利益。当然了，老刘不是最终客户，而且说实话，老刘做供应商的时候就希望局势比较混乱。因为这样级别的客户不是一般的靠纯粹的关系就可以搞定的。所以一般来说，越是清楚，供应商就越挣不到银子。越是糊涂，越容易浑水摸鱼。。。。。。
其次是，对老刘来说是个警告，如果再温水煮青蛙的话，就要废掉了。居然观察能力都下降了，faint！
忽悠完客户，老刘就急吼吼赶回上海了，因为，上海有老刘牵挂的人儿～