集成的故事 - 人

人们在讨论信息系统项目成败的时候，常常会不知不觉的陷入一些老套的话题。比如某某信息系统做成了，是因为我们搞定了某个院长，某某系统做砸了，是因为这个院长被别的公司搞定了。如果有人不谈论这些，而是说其实是因为某个用户界面设计得很方便，医生很喜欢，或者因为是系统里面有太多的over design，扩展性是好了不少，但是运行起来慢得一塌糊涂，那么这个人多半会被扣上不够成熟，有待培养的帽子。不知道在国外会不会好一点，但这就是中国的情况。

“技术人员的确要考虑政治，并且要充分理解政治，才能在设计技术方案以及软件体系结构的时候，把包含政治在内的尽量多的因素纳入你思考的范围，从而获得最好的平衡(trade-off)，同时在整个过程中与多方维持良好沟通。”

这是我在一位不认识的业界同行的技术博客上对一个类似讨论的回复。回头想想，其实也还是很老套，平衡，是任何工程领域的永恒法则，沟通，也是任何项目需要管理的最大成本。如果软件架构师真的能deserve架构师（Architect）这个头衔的话，他或她的确应该象建筑师那样，在建造一座宫殿的时候充分理解当地的政治，历史，以及文化。

---

好了，先不扯远，其实我是想讨论一下集成里面一些更加困难的问题，这些问题不光跟技术更是跟人有关。

集成的工作常常是处于系统的边界，这个系统不仅是指各种异构的机器系统，还包括与集成相关的各种人类组织。也就是说，我们需要协调来自不同部门甚至不同公司和医院的资源，并在混沌的边界上建立起有序的沟通。这种协调是如此的不容易，却又是所有集成方案得以实施的前提。因为集成往往要打破原有软件系统的边界，在原来封闭的系统上增加一些接口调用或者事件通知，以及跟这些系统的维护者商讨我们之间消息的时序。修改陈旧的代码，应该是大多数程序员最不愿意做的事情之一，你要说服他们，说服他们的领导，然后约定一个时间，心平气和地做下来一起联调。当然这所有的一切必须首先得到医院的支持，来自医院的统一压力，是防止由于公司之间的利益之争而产生过度内耗的有力武器。

解决了人的问题，我们已经成功了一半。按照质量工程的思维方式，剩下的两个要素就是方法和工具。在组织内部，代码的质量可以通过开发过程来得到比较好的控制，在我看来，这种过程多半是常规的项目管理方法在软件工程上的特别定制，因此它与跨组织的IT项目实施过程相比应该也有许多共通之处。总感觉在现场需求的变数可能会比平时在办公室里要多得多，如果是这样的话，可能更适合一步一步摸着石头过河的敏捷方法了。如果有些管理者担心敏捷方法的可控性太差，至少迭代是必须的。

另外，跟那些繁琐的文档、评审、例会相比，采用好的集成工具也许更能事半功倍。好工具的一个重要特点就是在集成的时候几乎不需要改动代码，大多数时候只需要在用户界面上进行配置，比如设定一下两个系统之间的字段映射关系，或者最多是用脚本定义一些略微复杂的数据转换规则。毕竟在集成现场没有象公司内部那样完整的过程支持，我想那些在现场做过客户化开发的人应该印象深刻，由于缺乏配置管理，几天内你的代码就会变得头绪错乱杂草丛生。采用好的工具相当于把本来需要在现场进行的代码修改工作，前移到一个质量可控的体系内部。

---

其实在集成项目的实施方面，我的道行还远远不够，所以很难对这些经验做一些的系统化整理。不过系统化的整理的确是个有趣的方法，很多其实什么都不懂的人，把自己的经验套在一个已有的概念体系里面反复推敲，便成了一篇看起来很牛但没有任何实用价值的学术论文。想当年我的系分论文就是这样写成的，为了讨论软件项目风险，就把自己跟风险有关的项目经验往RUP上套，幸亏我大致记得RUP四个阶段分别干的是什么，于是洋洋洒洒几千字，写到手都酸。

希望能继续积累一些EAI和医疗信息系统集成方面的经验，改天也可以用同样的方法冒充一下大牛。