大集中应用系统是复杂的，无论从技术、应用规模、业务关系等哪一个方面来看，都是这样的。
首先，框架结构的复杂性。所有大集中应用系统在建设过程中都要基于基础框架来开发，其目的是为了屏蔽底层的技术细节、为了简化业务编程，为了提供规范化的开发管理、为了… …等等。做一个类比，基础框架同应用系统和基础中间件的关系，就如同操作系统同应用程序和物理机器之间的关系一样。可能不准确，但比较贴切。操作系统复杂吗？复杂！应用框架同样如此！一个好的应用框架，绝对是多年实践经验的结晶，绝对不是依赖spring、struts等的简单拿来主义（声明：没有贬低开源项目的意思）。
其次，应用类型的复杂性。在一个典型的行业应用中，往往包含高频度联机事务、以数据查询为核心的操作型应用、以数据综合处理为核心的数据加工型应用、以交换和数据共享为核心的整合型应用等。不同的应用类型，其技术、架构、处理模式等都存在很大的差异。所有这些差异、这些类型的应用最终都要放在一个系统中，协调、有序地运行。
第三，是系统结构的复杂性。在一个典型的行业核心“大集中”应用系统中，不可能采用单机、单节点运行，往往是通过纵向和横向进行扩展部署。所谓“纵向”，是指将不同的应用逻辑单元分别部署到不同的设备上面，并根据其技术和业务特征做定向优化，实现网格化运算；所谓“横向”，是指通过集群化部署运行来提高系统的访问承载能力，在提升性能的同时，也起到预防单点故障的热备作用。
综合而言，系统的复杂性是多方面的，是综合了技术、应用、业务、运维管理等在内的综合复杂性。
尽管大集中应用系统在架构和技术上是复杂的，但在应用系统开发方面，则是相对简单的。
首先，应用逻辑是简单的。从用例的实现角度看，MIS累应用系统的单个用例的业务逻辑相对来讲都比较简单，每一个用例只关注特定场景的人机交互，对开发人员的技术要求相对而言要低得多。
其次，用例开发对开发人员的技术要求比较低。因为框架屏蔽了技术复杂性、提供了标准的API以及相关的开发、管理等技术规范和标准，开发人员只需要依此为基础，编写代码就好了，无需关注过多的技术细节。
比如在笔者参与主导的项目中，开发人员的所有开发工作均在tomcat服务器中完成，但最终的系统部署则是基于EJB容器，各个应用单元组成了一个复杂的拓扑网络图。
从上述内容可以看到，所谓的“复杂性”主要体现在系统的整体技术、结构和管理方面，而“简单性”则体现在应用开发方面。换言之，业务开发简单性是以技术架构的复杂性为基础的，技术复杂性是“因”，业务开发的简单性是“果”。
在大集中应用系统中，所有技术问题的解决均依赖于开发和运行管理框架。