最近我司的软件产品线面临其史上最大的因境，今天晚上坐班车时，与一位曾经共过事的同事，聊起现在的软件，感慨颇多。大家都认为我们镨过太多的机会点，现在面对互联网软件的直面冲击，以及运营商本身经营上的乏力，运营商这个领域的软件已经无力回天了。另外之前与其它的同事也聊过，我司本质是一家硬件公司，没有做软件的基因。凭着做硬件的套路，做了这么多年的软件产品，也实属于不容易了。做软件产品与做软件服务是完全不同的套路，软件产品是需要卖给不同的客户，交付形态存在多样化，定制不可避免。而卖服务给不同的客户，客户关注是的服务体验，并不太关心软件的本身，只要软件能搞定客户的问题就行，就不会像卖产品那样面临不同的交付形态问题。而目前我们最大的因境就是软件产品不具有可复制性，不能像硬件那样形成规模效应。
今天我们再来只谈谈做软件的不容易。基于传统的软件技术，传统的软件思维，做软件产品，我们会遇到如下三个矛盾，是非常难以有所突破的。
反复重建，架构无法持续演进
我们很容易想到我们国家的城市建设，是一个不断反复重建的过程，建筑的生命力非常的短暂。一个城市的规划师很重要，但再强大的规划师也是难以预见一个城市的发展未来，尤其是一个快速上升，充满经济活力的城市。
同样，面对软件的架构，上世纪60年代就有人提出“软件没有银弹”，再牛逼的架构师，设计出来软件产品，5到10年也必然面临着被推倒重来。原因很简单，软件是为业务服务的，业务在不同的时期，对软件的诉求也是完全不同的。业务的初期，大家对问题的本质往往看不清楚，考虑不全面，而此时很难做出具有非常前瞻性的软件架构，能够持续地与业务发展而演进。
软件技术可以借鉴，但软件本质是具有业务属性，一个软件产品不可能脱离了业务场景而纯技术的存在。就像建房子，中国建造方式与中东可能就不一样，因为他们面临的环境不同，使用人群的文化不同。纯技术的照搬，可能并不能解决实际的痛点，可能造就的是一个被人吐槽的烂软件。
同样，再拿房子做比较，房子一旦主体结构建成，接来来几年，想再来做水平或垂直扩展，很难实现，为了支持更广的使用场景，可能10到15年之后，又被彻底推倒重来。软件产品也是如些，看似年年卖的是房子，之前的老房子再怎么装修也难以拿出手来卖了。
金无足赤，功能无法完美支撑业务
业务本质是什么，不同的业务专家有不同的见解，我们往往被业务的表面特征所迷惑，这也导致我们的难以对业务进行抽象建模分析。虽然业界在一方面有一些方法论的探索，像领域驱动设计。但业务人员与软件开发技术人员之间往往存在鸿沟，他们之间的通用语言是什么，大家是否理解一致。双方参与的深度，也决定了软件产品的可用性。而做软件产品，恰恰最懂业务的却离软件开发很远。精通业务的人，不懂软件开发；而精通软件开发的，却不懂业务，隔行如隔山。
所以，软件产品通常功能大致满足客户诉求，但似乎又差了一点点，并不是客户心中其实期望的。软件即使三头六臂，也无法完美支撑业务。而一方面，软件不好用，是由于存在”数据孤岛“问题，为了不至于把软件做得庞大无比，必然会对软件进行边界的划分。一旦完成了边界设定，也是形成了一个”数据孤岛“。各个系统（数据孤岛）之间对接集成，都是非常复杂而棘手的问题。需要对接的系统越多，其复杂度是指数级的增长。
资源有限，软件无法满足需求无限
业务的需求是多样化的，并且是随时间变化的，这是需求的无限性，但软件要解决的问题总是有限的。同时，面对不同的客户群，众口难调，业务客户对软件的差异化是客观存在的，期望用一套标准，一套软件产品来解决所有问题，永远是一个美好的梦想。在这种情况下，要么无法满足大量的个性化的需求；要么成本巨大，导致软件产品无法承受。
而在传统的软件开发模式下，软件开发周期长，我们通常的做法，是收集所有的需求合并整理，形成一个功能繁多的超级大版本，看似你需要的功能都有。但对于某些个体使用者来说，众多的功能导致易用性下降，复杂度上升；而需要使用到的功能，却没有做到极致。
通常一个功能众多的软件，对物理资源的诉求也是巨大的，为了能按特性交付给不同的客户，我们又不得不对软件在架构层面进行划分。不管是纵向的切分而是模向的切分，都会导致软件的内部的复杂度，而因为切割带来的的复杂度是业务使用者不愿意看到的。