许多的人注重开发效率，但是老鸟们不仅关注开发效率，更关注维护与技术支持效率，因为他们深深知道，一个有生命力的产品，维护与技术支持成本占整个产品开发运维成本的70%以上，也就是说开发成本只占不到30%的成本。
对于一个传统的MIS系统来说，别的不说，光数据库表结构的维护脚本就够受的了，设你的用户有几十家，或上百家，他们使用的版本可能是1.0到m.n中间的任何一个版本，设总共有x个版本。
这个时候一般有两种升级方法，一种是每做一个版本，就编写从前面任意一个版本到当前版本的升级脚本，这样脚本就有x套脚本，还要进行测试，如果这个时候还要跨数据库，比如：mysql,oracle,ms sql,informix,sybase,...，开发人员和测试人员无法承受之重，所以，按这种方法，工作量是越来越大，包袱越来越重。
那就说第二种方法，就是每次只做从上一个版本到当前版本的升级脚本。这种情况下，开发成本，测试成本可以相对得到较好的控制，但是升级的时候，就很麻烦了，需要识别当前用户的是哪个版本，然后再一个一个版本升上来，如果有自动化升级工具还好，如果没有的话，现场支持人员估计够受的，中间只出出现一点问题，可能就不知道后续应该如何处理了。
上面只说了数据库脚本，那么再说说程序，一般来说有个主线，还会有许多分支，根本不同用户购买的License不同，可能集成的内容也不一定相同，如果再有一些客户化开发，这里带来的问题，比数据脚本带来的问题还复杂。
曾经看到过某一团队，开发了一个系统，全在一个war工程中，结果就是开发效率低下，测试调试困难，没有人对整个系统全部熟悉。所以最后开发维护都无法维系，后续扩展无法继续，等待的结果就是一个，什么时候没有人能坚持的时候，它就可以死掉了。
所以，Tiny框架在设计之初，就在深入的思考这个问题。为此提出了业务单元的概念，就是把一个相对独立的模块合并为一个业务单元，一个业务单元包含了所以服务及界面展现以及数据初始化，数据库结构的各种资源及程序文件。
当然，业务单元也可以依赖其它的业务单元，如此就可以构建更大的系统及平台。在程序运行时，框架会读取BU中的数据库定义，初始化数据，等等，然后进行处理，保证不需要人工干预，就可以正确的运行。
这个时候，就实就引入了一个相当严重的问题，就是这些文件包含js,css,class,各种配置文件等等都放在java包，程序是怎么访问到它们的呢？？为此我们做深入的扩展，使得各种资源都可以分散到jar包文件中，由此才得以实现模块化的需求。实际上模块化的想法很早就有，但是一直没有落地，就是因为资源文件方面的问题无法解决。
因此，解决了数据库初始化，菜单初始化，程序分解与集成等各种问题，程序员们要做的事情就是：我只要保证自己运行是正确的，整个系统就是运行正确的。不会因为是开发期、维护期，版本数多少影响到工作量。
