在应用编程“茹毛饮血”的上个世纪八九十年代，Servlet和JDBC大行其道，一个会写jdbc的程序员拿着不菲的工资，被开发商和大众们奉若神明。那时程序员的数量稀少，编程是名副其实的高科技+高薪职业。随着信息化的水平不断提高，信息技术迅速向社会的各个行业渗透。金融、商务、教育、政府、工业，人民生活国家运作的方方面面都插入了信息化的影子。软件的需求爆炸式增长，带动IT行业的人员数量和开发技术快速增长。各种培训机构如雨后春笋般涌现，向IT行业输送了大量生力军。IT行业从“单枪匹马打天下”的个人英雄时代向商业化、团队化、标准化、持续化的方向发展。新的开发语言、开发方法、开发框架出现了，IT不再是单纯的技术行业，而是综合了市场、运营、管理、架构等多种因素的现代化行业。
需求的增长，原始的servlet和jdbc的开发方式变得相对笨拙而低效，技术人员不仅需要编写冗余繁杂的代码，调试各种技术错误，还要理解日益复杂的开发需求。企业的开发成本飙升，技术人员也变得疲惫不堪。然而“所谓的高手都是一群懒人”，将重复的技术工作组件化，使开发人员的注意力都转移到业务需求上来。在这一初衷下，开发框架、技术产品、软件架构横空出世。发展至今，各种开源和商业框架产品多如牛毛。结合各个行业的不同情况呈现出两种不同的发展方向，一种是根据行业的业务需求进行深度沉淀，比如财务系统、人资系统、CMS系统等；另外一种不针对具体的行业，在技术层次上进行封装改良，讲究通用性，比如Apache基金会下的各种产品，各种中间件及.Net
Framwork等。这些框架大多有着强大的社区和商业公司支持，久负盛名，历久弥新。
国内也有不少研发自己技术框架和产品的公司，如金蝶、用友、长城医疗这类的，这类公司走的是行业沉淀的路线，根据自己公司的行业特点研发自己的产品，不少已经在相应的行业里面取得了垄断效应。还有一类研发通用性技术框架的，这种公司基本上是跨行业经营，大一些的项目公司基本上都有自己的那一套。但不管框架产品怎么发展，都偏离不了它们的初衷：剪除重复劳动，提高生产效率。不少中大型的企业成立自己的基础平台研发部门，就是意识到了这一点的重要性。
谈到基础平台研发部门，这些部门里往往集结了企业中的才俊，但中国企业中的这些部门大多处境尴尬。从大环境看，技术的潮流主要操控在国外的大公司、行业协会的手里，他们的技术储备先于市场需求很多年，走技术带动市场的路线，从消费概念到物资生产全面垄断，市场被带动以后又反过来投入更多在技术研发上，形成良性循环。国内的情况则相反，技术上常处于被动带领的位置，只能依靠其他行业的需求来改进自己的技术；软件行业的利润总体上仍不如工业等传统行业，企业利润低，拿不出富余的资金做研发；即使拿的出来，又面临计算效益的难题，一个技术产品不是项目，很难短期内盈利，在某些情况下甚至很难计算其盈亏。
所以平台研发部门在很多企业里面看起来都“一事无成”，其他部门的员工吐槽说“没看见搞出什么新技术”，BOSS觉得“投了那么多研发资金没发现市场效益”。有些平台研发部门意识到自己的尴尬，玩起了闭门造车，脱离一线研发，力求“高科技”，结果搞出的东西反而招致更多吐槽。还有的只是图个“标新立异”，偏离框架产品研发的初衷，炒作各种概念“忽悠”BOSS以求经费。这两种做法，第一种脱离现实，产品的效益最终还要靠最终用户的反馈，脱离了一线研发这个最终用户便没有效益。第二种不负责任，框架产品的研发是个长期改良的过程，BOSS又不是傻子，他看不破你的的技术迷魂阵难道还看不懂财务报表么？他自己不懂技术难道他不认识懂的人么？最后还是逃得了和尚逃不了庙。
综上，一个好的框架产品是一个面向业务的产品，它可以屏蔽大量的技术细节，又不失自定义的余地。因为任何一个框架产品都不可能涵盖所有的用户需求，更不能反过来限制需求，所以“默认实现，开放修改”是个增强通用性的好办法，像Struts、Hibernate、MyBatis这样的著名框架都含有这种思路。
界面化开发、配置文件可以屏蔽实现细节，但同时也限制了需求的灵活实现，它们可以减少代码的数量但永远不可能取代代码的作用；有人倡导全面配置化，希望在运营层次上取代技术研发的过程，但从现实来看即使是如微软、IBM这样的IT巨头，仍然拿不出可以完全“去代码化”的解决方案；即使有这样的产品，仍然需要极专业的培训和技术理论基础才能掌握其配置方法。这方面Spring框架给我们提供了非常好的思路，Spring对各种第三方工具进行封装，以配置文件和注释形式为开发提供了很多解决方案：小到文件上传、跨数据库事务，大到负载均衡，OSGI，可谓无所不包，你可以自由选择使用这些方案或者不使用——无非是几行配置，也可以在默认实现上定义自己的代码实现特殊的功能——遵守Spring规范即可。Spring简单、优雅、开放、轻量的特点，体现了产品研发者兼容并蓄、实事求是的胸怀，是它受欢迎的重要原因。
框架产品的研发应该比其他研发更加认清自己所处的大环境，更多实事求是，更少故弄玄虚。框架产品的研发，重需求收集、重产品决策、重人员素质更重技术服务。因此专门的产品经理或者运营经理是不可少的，技术研发和产品运营本质上是不同的工作，研发看重细节和持久的投入，产品运营则看重总体走向和产品服务。因此身兼多职必将影响效率发挥。平台研发部门应该在人数上保持较小的比重，“麻雀虽小五脏俱全”，毕竟这方面研发失败的风险很高。