SaaS企业应用开发的挑战

笔者参与了SAP的第一款SaaS ERP的开发和实施服务, 因为SAP最受欢迎的Business Suite是rich client的产品，感觉大家一开始都把精力放在如何推出一个web UI的能够以business user的语言来进行实施配置的ERP，随着产品的开发进程以及同时期Salesforce的成功，多租户等关键的问题开始引起管理层的高度重视，最后还是依靠Netweaver为了支持多公司的的client的方式来进行数据隔离。产品release之后，在SaaS operation阶段，公司意识到了产品的运维成本问题，所以开始在自动化运维，生态等方面发力。

做过SAP ERP实施的顾问都会惊叹于SAP产品强大的扩展能力和灵活的配置，一套产品，经过一些配置和扩展开发，就能够很容易的满足各行各业各个客户的一些个性化的需求，从一个实施顾问的角度来看，每当把一个客户的个性化需求通过配置和开发实现以后，内心的那种满足感是很强烈的，所以SAP的产品经理们也对这种扩展性和灵活性充满了自豪感。到了SaaS ERP产品，大家自然也期望能够提供强大的灵活性和扩展开发能力，而且当时Salesforce也在一直宣传他们的产品如何灵活，客户可以随意扩展字段，能够定义定制UI，能够对业务逻辑进行配置。但是大家忽略了一个问题，我们做的是一个完整的从产供销到财务和人力的ERP，由于系统的复杂度增加，流程上的差异在不同行业不同公司显而易见，而且大家的mind set还停留在依靠产品的强大扩展能力尽可能满足客户的每一个个性化的需求上面。最终的结果是：任何一个补丁或者升级，都需要检查定制开发升级后是否还能够按照客户期望的方式工作，为了保证SLA，就必须clone一套系统出来进行升级验证，确保没有问题后，再进行生产系统升级，升级过程中各个部门必须协调，完成一些扩展开发部分的升级和配置调整，这给版本升级带来了极大的麻烦，而且产品部门也不敢轻易改变产品的逻辑，一不小心就带来了incompatible change。 我所在的部门是做客户扩展开发的，出于部门利益的考虑，当然希望产品的扩展能力越强越好，而且由于我们部门后面的大Boss比较强势，产品部门也承受了很大的源自于我们部门的压力。对于SaaS应用的扩展能力的认识直到我在一次和另外一家欧洲上市的SaaS CRM厂商的CEO进行商务交流的过程中，他提到：SaaS应用是为了以较低的成本实现Volume Business，所以只会提供必要的扩展性和灵活性，对于深层次的扩展定制有要求的客户应该推荐他们使用On Premise的产品。此时，我才恍然大悟，原来我们部门一直在要求产品部门提供更多的扩展开发能力是一个错误的行为。

后来笔者也和其他企业信息化的专家进行过陆陆续续的交流，最近接受了公司一个云应用开发架构最佳实践的培训，萌发了把过去的教训和心得总结一下的冲动。

首先我们要回答一个问题：什么样的企业应用适合Cloud？-----TBC