| 传统弊端 | 传统开发模式 | ET开发模式 |
| 黑箱 | 隐藏数据操作于底层代码中，对数据的处理和表现缺乏有效的外部查看和控制机制 | 开发完全通过组件构建实现，所有业务处理、数据操作和逻辑过程都是清晰、透明且可读的 |
| 有限隔离 | 数据处理和数据表现间缺乏明显界线，数据处理和表现的混杂导致开发复杂度增加、出错可能性增加 | 从设计上完全隔离数据处理和数据表现，降低开发复杂度，减少出错可能性 |
| 过细的粒度 | 软件通过编写代码实现，软件封装基于函数或对象，过细的粒度大大增大软件开发的复杂度，同时使软件的外部控制调整难于进行 | 依据对业务数据的高度概括和抽象，提供粒度大小适中的功能和数据，即具有细小粒度灵活方便的特征，又能很好避免开发过程的复杂度 |
| 高技术要求 | 基于编码的软件实现要求较高的技术能力，高技术要求使得人力资源成为软件开发瓶颈，同时也限制软件的大规模生产 | Extraction平台屏蔽几乎所有的软件开发技术，大幅降低软件开发的技术要求，解决软件开发瓶颈；特有的构建式开发模式具有天生的流水化生产特征 |
| 失调的投入产出 | 传统开发模式的诸多弊端使得软件的人力投入和产出不成比例，投入更多的人力却无法带来预计的效率提升 | 构建式的开发模式和极低的技术要求，使得软件开发更便捷、有序，即使投入新人也可以立即带来开发效率的提升 |
| 不确定风险 | 传统软件开发的风险极难确定，由于开发过程的复杂性，不可度量，不易理解的特征使得软件开发中存在时间风险，技术风险，人力风险等多种难于规避的风险 | Extraction平台的低技术要求，规避软件开发中的技术风险和人力风险；Extraction平台构建式、流水化开发模式可以快速进行软件开发，同时大大增加软件开发的可计划性，有效规避时间风险 |
| 质量难于保证 | 传统软件开发模式往往难于保证质量，由于技术的复杂性和开发的黑箱特征使得软件开发难于确定状态，难于保证质量 | 基于组件的构建式开发模式使得软件的开发基于已验证的组件，能够保证软件质量 |
| 难于维护和扩展 | 编码开发的软件系统在维护或更新扩展时工作量巨大，维护系统或对应用进行更新往往要影响系统的使用，并且大部分的工作无法在客户处完成 | Extraction平台软件的实现基于组件且透明、可读，便于软件的维护和更新，独特的流程模式使每个功能都独立存在，更新工作不会影响当前系统的使用；基于浏览器的图形化开发模式确保更新和维护可以在现场或异地（远程访问）进行 |