|
相信凡是开发者对用户纷繁复杂的需求，都趋之如虎，从制度上，我们建立了严格的需求变更的process, 从技术上，我们寻求一种所谓的业务平台，寻找一个冶百病的良药，在市场上，有商业软件来推销自己的平台，更在平台上加一个业务两字，真有这种平台吗。
关键是我们要对“业务平台”这个词语都没有一个定义，这是个伪明题。
像那些平台软件，反复所说的，UI组件之类，这些是业务吗，是与业务无关的东西剥离出来的一种框架解决方案而已，更不能说是平台中的特色吧。
就是工作流引擎，也是为了将流程定制、跳转与业务逻辑剥离出来的一种设计思想的实施。
表单定制更不是业务，也是与业务剥离的一种方式。
而在现实开发当中，做为一个有成熟技术积累的行业软件公司，这些都是个屁，根本不值得一提，早就有了，技术含量也高不到那去。在Delphi时代，他们就有了各种VCL组件、框架，功能比这强大多了，现在WEB软件的MVC框架，甚至spring容器，都只是基础，我们真正关心、头疼的不是这个。
在现实当中，真正影响我们，耗费我们大量时间的，对我们进度有很大影响的，就是在现实中复杂的需求，业务逻辑，这些复杂的需求，难以封装，造成复杂的设计、复杂的库表关系，这些复杂的设计，我们都知道越复杂的东西，越不稳定，更容易遭受到需求业务逻辑变化时的冲击。（希望那些做增删改查的人不要跳出来扯淡）
比如我们在分销系统时，所基于一种价格、库存模型，如果算法本身发了变化，有的时候，设计不慎，就会造成很大的影响，如果要过早的考虑未来的变化，妄图要封装未来、不可预测的逻辑变化，就变成过度设计，库表结构、程序结构都会复杂的很。
做为开发者，我们不可能去避免这些事情，只有依赖自己，我们只有不断的去积累，让自己对用户的业务理解的越来越成熟、深刻起来，不仅能剥离出非业务的技术，实现重用，更能将业务做成可扩展的框架。
比如我们做一个电业局时，我们的设计是一种的设计，我们的可扩展性，特别是针对业务的可扩展性，考虑是有限的，但等我们做到5个电业局的单时，我们遇到了更新的东西，我们对用户的业务，理解更深刻了，我们的设计就越来越成熟，我们再做下一个电业局时我们的变动越来越小。设计也是不断进化的，平台也应当是可进化的，你对用户的需求、业务把握的越深刻，你就越主动，不会背动跟着业务走，很多行业软件公司的Consultant，都是来帮助用户来规划业务、流程的，这就扯到信息化了，扯远了。
希望做业务平台的，可以去了解一下金蝶的BOS平台，用友的U8所基于的平台，这是他们做财务、ERP的长期的业务积累，是他们在有中国特色的MIS，ERP的开发实施的经验积累，是吃了很多的亏，走了很多的弯路，所积累起来的，是给他们自己用的，不是给外人用的。
分层，Plug-in, component, framework, platform都只是一种分离粒度不同的技术手段，一种解决问题复杂度、降维的方式，而没有对业务的深刻理解，都是虚假的，而对业务最理解的，当然是你自己了，因为只有你奋站在用户的第一线上了，而不是那些厂商、Consultant，他们只想拿到钱就走了，并且不要单心需求变化，因为他们所谓的平台，是和需求、业务没有关系的，而且他们吹嘘的就在此，那就是通用，只需要配置就可以完成一切，其实这是他们降低自己运营成本是一种方式，而不是真正的来解决你的问题。
所以我觉得，真正的业务平台，要有生命力，要依赖自己，在技术的基础上，要加强自己对用户业务理解的深刻度，从一开始就打造自己的业务平台内核，在一开始是不成熟的，但要去积累，用孵化的思想，去建设、壮大适合自己用的业务平台。只有自己的平台，才有生命力。
|