平台所带来的问题

      今天上班遇到一个事，我觉得很有代表性，也让我对平台这个大家爱恨交加的东西有了更深刻的认识。

      先描述一下事情的背景。我们的产品是大的电信设备，机框上有主控板、业务处理板。设备的部分关键信息只能主控板才能获取，而这些关键信息需要在业务处理板的业务芯片初始化之前传递到线卡CPU。原有框架是有相关的通道的，但是原有通道扩展性不好，要加入新的信息需要更新单板的固件。对于已经发货的设备要进行全网的固件升级，这个对可靠性极高的电信设备是需要尽量避免的。为此大家想在线卡软件启动后，通过系统内的交换网来传递这些信息。好了，从理论上来说这是一个很简单的事情。主控上有个资源管理的进程读取一下信息，将此信息定时广播到线卡就好了，或者线卡启动时主动请求一下此关键信息也是可以搞定的。

       好了，问题来了。这个简单方案讨论了一周还没有结论。我在边上听了一下，之所以的这个简单问题几个相关模块很难达成统一意见，主要原因在于负责此信息传递的模块的开发团队已经从产品剥离，与其他产品独立成立一个xxx平台，此平台对于产品的特殊需求一般不与开发。再加上此平台扩展性不太好，消息通道没有做到平台化，相关的初始化时序控制也没有向产品开放，导致平台与产品耦合很深，产品的小改动就需要平台的参与和修改。没办法，产品自己想办法。芯片驱动模块决定自己从主控读取此信息，再通过一个可靠的机制传递到线卡。但是这个机制有时序上的问题，此信息必须在线卡初始化芯片前传递到线卡。有人就说了，这还不简单嘛，芯片初始化时等待一下不就行了？一切简单的问题在平台化面前都变的不好处理！芯片初始化的时序控制实在上面提到的xxx平台做的，让他们改，显然不可能，除非改动现有框架，提出一个新的通用框架，否则平台不会接受此需求，新的通用框架显然一时半会等交付的。于是让芯片驱动团队自己处理，芯片驱动团队说他们也要做平台化，这种破坏整体架构的无价值处理，他们拒绝实施！！！

       怎么办？两个平台的碰撞，产品需求无法落实！当然最后必然会有妥协的一方！是平台化的问题么？我觉得不是。这个问题是平台框架设计时没对产品的可能需求理解透彻，可扩展性太差导致的。如果考虑到芯片初始化会有依赖项，给产品提供依赖项的注册，这个问题也会皆大欢喜，让大家都满意！