早期的国内应用软件产品，其扩展性都是相对较差的，尽管开发商也为此作过很多工作，包括二次开发工具包等等。主要原因就是这些应用本身框架的局限性，不具有可扩展性，在设计时我们关注的只是应用程序的实现，没有关注我们的应用应该构建在一种开放的框架上。（当然开发语言本身也有一定的局限性）
“开架式”软件设计是基于应用程序的可扩充性提出来的，是一种软件底层架构的实现方式。他更关注应用程序底层架构的实现，与具体应用程序的实现无关，或者说具体的应用程序是构建在这种架构定义的范畴之内的。
在这种设计思想下，我们的应用程序框架可形象比喻成书架一样，我们提供一个架子（规范），书架内容的不断丰富，就好像将不同的书（功能/插件）放在架子上一样，当然书需要满足我书架尺寸的要求。
在这种框架下，提供的是一堆服务和资源以及调用和扩展这些服务及资源的规范，而这些服务和资源也是可扩展的，你可以在一个组件中编写一些服务和资源由框架加载并与其他的组件分享。组件的功能是由框架加载并执行，它可以访问框架提供的资源和服务，如可以访问界面元素，访问数据库、文件，调用日志服务写入日志、访问多语言信息等等。
大概的运行时框架如下：
图中的组件A和B可理解为系统提供的组件或者应用程序功能性组件。
其中的关键就是要提供一种机制：
1、 保证组件可以被框架加载并运行，
2、 将组件中包含的资源和服务注册到该框架中，
3、 组件访问框架中的资源和服务的透明性。（也表现出组件间、组件和框架间的协作性和可访问性）。
有了这样的应用程序框架，我们可以任意扩展应用程序的功能组件，只要他遵循框架定义的规范。我们可以新增加一个组件，可以提供新的资源和服务（如果愿意），可以访问框架中的资源和服务就好像这些都是该组件自身具有的，而组件中提供的功能可以通过配置插入到恰当的菜单或工具条供用户调用。而这些对用户是透明的，他们不知道界面中的某个功能究竟来自于那一个组件。组件和组件之间是彼此独立的离散的。
远景：
将产品发布成为这样一套框架（标准）和预先提供的功能组件，用户可以到网上直接下载组件进行程序的升级，用户可以根据框架定义的规范自行开发，甚至有第三方软件公司根据框架的内容和标准专门开发特有的功能，如软件对GPRS、视频会议的支持等等。也可以支持OpenSource，开放标准提供给网上大量的开发者开发功能组件，作为用户可以在网上找到需要的功能组件。这些或多或少已经是一种商业模式的问题了。
优点：
1、 扩展性极强，可以到甚至
2、 因为组件和组件之间是彼此独立的离散的，带来的升级也是方便的，
3、 程序更新只需要下载和替换相关的组件即可，
4、 程序的架构是严密的，
5、 架构本身的升级比较容易。
缺点：
1、 性能的影响。高扩展性必然以牺牲一定性能作为代价的。
2、 功能扩展的不定性。
3、 高度共享带来的安全性也是一个要考虑的问题。
（注：本文为我同事杨舰的几年前的稿件，该文从项目经理的角度提出了一种新的开发框架，供大家参考）