技术构架在协同软件产品中的重要度

近段时间，在协同软件市场上， 易能协同OA以技术架构领先而名声在外。对此,笔者起初就很纳闷儿，软件产品应该以功能为主，功能才是软件产品的价值体现，跟 技术架构有何干系呢? 技术架构领先是一种炒作还是?带着疑问，笔者虔诚地向行内的专家请教，终于茅塞顿开。

技术架构是地基工程

区别于软件项目，做软件产品的台阶更高，需要对市场、销售、管理咨询、品牌、技术、售后、用户需求都有深刻的理解。统计数据表明，做软件产品的成功率很低，还不到2%。为什么软件产品的成活率这么低呢，其中一个主要因素是软件产品的技术构架不合适。如果软件产品是一栋建筑物，那么技术架构便是这栋建筑物的地基工程。起初，你预计建设三十层楼的大厦，那么“地基工程”就是以三十层楼为标准的。但是，一个重要的问题是软件产品一般都要持续五年至十年，这段时间内，客户的需求在不断的向前发展变化。换句话说，起初需要的是三十层建筑物，二年后，实际需要的是五十层建筑物，这便要求在现有的基础上加高二十层。没有良好的“地基工程”，三十层到五十层只能是一句空话，或者说是空中的楼阁。“地基工程”决定着建筑物向上发展空间的广度和深度。如果“地基工程”不好，必然会成为向上发展的瓶颈，这也是软件产品中技术架构重要的根本原因。

反过来看，协同软件技术架构涉及的技术，既不是高精尖技术，也不可能是拥有“当惊世界殊”的革命性技术，关键就在于对日后产品的发展和规划更具前瞻性,将初期的地基工程打的更坚实，投入更多的时间成本和经济成本。所以，好的协同软件的架构实质上是采用一些当前的流行技术和通用技术,每一项技术单独看起来都很平常，但是通过将相关技术有效的优化组合，在对产品前瞻性充分考虑和对未来较长时间产品发展方向正确预测后，并应用到自身产品当中，最终体现出自身独特的技术架构。

当前成熟的协同软件的困感

这些产品出道较早，在业内比较有知名度，市场和渠道趋于成熟，功能也算完善，只是限于产品自身技术的瓶颈，开发理念和技术无法与时俱进，不能取得更大的突破。这便如一个自身只能承载30层的地基工程，如今已经封顶，但在用户需求的推动下，建设者却想建设到40层或者更高。

这类产品目前的功能也许够用，但是，由于技术架构的原因，二三年以后，如果不进行必要的调整，企业的发展将会举步为艰，遭遇以下几个问题的困挠。

一、产品的重新开发和稳定需要一个较长的周期，至少得二年以上。不能拿出稳定的版本，就意味着两年的损失，公司的正常运营能否等待二年时间。

二、现在是个飞速发展的信息时代。两年的时间，意味着原有品牌的流失。而竞争对手决不会坐等你东山再起，他会利用这段时间占领市场，控制主动权，扼杀新兴的竞争者。

三、不同时代的人们对产品的需求也不尽相同，而二年后的市场需求和竞争态势都是未知数，公司必然要承担很大的危险，而这些都是协同软件厂商实现跨越、探索的痛处和难处。

技术架构不好的软件对客户的影响

软件产品区别于传统意义上的产品，在于管理软件在使用的过程中，会将管理的思想融入其中，是管理理念汇聚的过程，是企业知识积累的过程。所以，当协同软件成功实施以后，会与企业的发展紧密相连、不可分割。

技术架构好的协同软件能够与时俱进，应对自如。而技术架构相对落后，就会导致软件无法适应实际的需求。伦为鸡肋，食之无味，弃之可惜。如市面上是以PHP + MySQL平台上搭建的协同软件，由于PHP本身面向对象能力很差，只是一种网页的工具；而MySQL小数据量尚可，但是数据量大了后，根本无法承载。这种类型的协同软件，即使目前功能最能满足你的要求，但考虑到公司日后的发展壮大，这样的协同软件你能放心购买么？

或许，你会认为，到时候大不了再换个协同软件。实际情况并不是一个“换”字那么简单。换软件涉及到与原有数据的整合、员工的使用习惯，而且协同软件本身体现的是管理思想，更换软件的同时，需要大规模调整企业的管理流程。所以，更换软件的费用将是购买软件成本的数十倍。

企业在起初选取协同软件关注功能的同时，千万也要关注一下软件的技术架构。当前协同软件比较先进的技术架构是基于MVC 和SOA架构的，数据库能适应不同的要求,可挂接任何类型的数据库。在开发工具中J2EE无疑是最好的，而.Net平台是能接受的一个底线。像PHP和ASP等平台还是少考虑为妙。

最后，笔者幡然醒悟，原来华天动力协同OA的技术架构领先说并不是空洞的说教，而是具有一定的深度和内涵，是一个企业对产品前瞻性的一个体现。对于一个软件开发公司来说，要想走的更好更远，就必然要树立良好的技术架构，为自身的壮大发展保留一定的拓展空间。而对于广大软件使用者来说，为了日后的长期、稳定的发展，更应选取技术架构好的软件产品，以便在软件具体实施的过程中少走弯路。