作为一个ERP，简单粗暴来说可以分为平台和业务子系统两部分。ERP平台架构的完备性如何评估，业务子系统架构的完备性如何评估，业务子系统功能的完备性如何评估，这都是需要讲与究的。
当然，从现代软件应用架构分层角度来看，有UI层（还细分为UI展示、UI控制、UI前置后置数据处理）、业务逻辑层（还细分为服务整合、领域实体、数据持久化）、数据存储层（还细分为数据视图、数据存储、数据ETL）。在这三层之间，每两层与层之间还有接口层，做调用对接和数据传输用，这些层都需要专门设计。我们一是需要这样的设计方法，二是需要把这些设计方法在日常应用子系统架构设计层面落实，这就需要专门的应用架构师，专门在业务子系统实现设计层面发力。他们既要精通实现设计方法，还需要对业务架构有一定功底，才能让做出来的实现设计符合业务粒度、业务演进。能有这两方面功底的都是宝贝人才。
ERP的架构，其本质是为了在大层面大框架上保证ERP软件在开发和维护演进过程中一直能在机制上底层上框架上保证质量和维护效率。没有专门的应用架构和平台架构设计，ERP软件就成了功能实现代码的堆砌，堆个五六年就藕断丝连按下葫芦起了瓢了，就跟打地鼠一样，越到后来地鼠越多越神出鬼没，最后几双手都按不住了，Game Over了。
当然，ERP的应用架构的完备性评估，ISO早就有好的标准体系，这就是标准和标杆的威力。你还在自己苦苦追寻、琢磨、看书、动手，人家已经有现成方法放那里了，所以不要乱摸索，尤其在计算机业，我们国内和外国差距少说20年，太阳底下无新鲜事，先学习人家的标准，而不要自己埋头瞎琢磨。
ISO/IEC9126是一个评估软件质量的通用模型，我个人也感觉是适用于ERP软件。毕竟，ERP也只是一个软件中的一种，它具有软件的基本特征。
看看ISO9126怎么说：
ISO9216把软件质量分为六大特性27个子特性
1. 功能性
- 适合性suitability
- 准确性accuracy
- 保密安全性security
- 互操作性interoperability
- 功能性的依从性functionality compliance
2. 可靠性
- 成熟性maturity
- 容错性fault tolerance
- 易恢复性recoverability
- 可靠性的依从性reliability compliance
3. 易用性
- 易理解性understandability
- 易学性learn ability
- 易操作性operability
- 吸引性attractiveness
- 易用性的依从性usability compliance
4. 效率
- 时间特性time behavīor
- 资源利用性resource utilization
- 效率的依从性efficiency compliance
5. 维护性
- 易分析性analyzability
- 易改变性changeability
- 稳定性stability
- 易测试性testability
- 维护性的依从性maintainability compliance
6. 可移植性
- 适应性adaptability
- 易安装性install ability
- 共存性co-existence
- 易替换性replace ability
- 可移植的依从性portability compliance
当然，这是全视角完备性来看。但我们可以裁减性的去重点关注，以及每个时期不断演进成熟不断转移关注重点。
一、在最基础层面：安全、性能、数据正确、功能正确，怎么在应用架构专业方法和流程职责机制上保证。不少ERP软件目前还重点关注在功能是否符合客户需要，功能是否符合设计要求。还没有横切面研究安全架构，也没有研究如何在架构方法层面保证数据正确性。要想开展研究，就得按横切维度，如安全，就按照ERP应用架构一层层去分析如何在每层的框架上保证安全。当然，深入更现实的一个具体的功能模块或引擎服务，也需要这个维度去定制化思考与设计。
还有一个维度也是最基础层面，但很多人容易忽略它。那就是可测试。业务逻辑层怎么测、UI层怎么测、数据层怎么测。
二、做到了基础层面，就进入了软件的持续维护改进阶段。可持续改进维护、可移植、可向下兼容、可对内对外集成是关键切面了。这也是需要应用架构层面专项切面来研究的。研究方法一样，仍然是按照软件分层来层层有专门的架构设计。
可持续改进维护，有两个小分支，一个是产品功能和业务模型不断演进，需要代码可持续改进维护。如何在架构层面保证。一个是客户定制代码可持续改进维护。尤其是客户定制代码和产品代码之间的解耦离合关系，以及客户定制代码升级与产品代码升级的相互影响关系，这两个关系需要巧妙的应用架构设计和实现设计。
可移植，一说是跨平台的移植，如跨UI技术、跨业务逻辑开发语言技术、跨数据库技术、跨硬件设备。二说是一个功能模块如何可移植到其他版本或特定客户。这也需要应用架构研究。
可向下兼容，我们经常会遇到业务模型本身就不兼容了，我们的代码如何最大化的保证向下兼容，这样代码维护质量和效率就高。在中国现状，业务模型本身不兼容是一件比较常见的事，毕竟在快速受到各方面各路子方法或思想的冲击，过去积累少，一下来的太多，选择的方法和自己的现状问题不匹配是很正常的。
集成，有对内集成，如自己产品线的各个模块；有对外的集成，要把其他系统的功能、引擎、流程、数据集成进来或输出接口API，这也需要考究的应用架构。
三、做完这些基础层和高级层，我们就需要关注到整个协作链条上的关注点了。
那就是可升级，可安装、可实施、易用性、可运维。
可升级，有四个分支：整体升级、子系统模块升级、定制开发专项升级、BUG补丁升级。
可安装，也有五个分支：演示环境安装、测试环境安装、生产环境安装、重新安装、灾难恢复。
可实施。实施人员往往配置业务参数、初始化数据\导入数据、配置流程、配置报表和查询。这些实施工具需要涵盖考虑。
易用性是相对客户而言的。很多人说ERP很复杂。但其实本质上并不是。因为很多企业主对自己上ERP到底需要明确解决哪几个问题，没有显性化的清单。对IT技术实现的软件的擅长面和不擅长面更是不了解，要么把ERP当做先进管理制度的显性产物来高捧看来，要么把ERP当做EXCEL或强大计算器在用。而且很多企业没有细致的显性化的组织岗位职责、流程、表单、报表、考核，即使有，也是现实和制度两张皮。这是企业方的问题，另外在ERP开发方，也没有按照业务场景来设计ERP，而是把各种业务场景都分析完然后整合成几个功能模块给客户，就如同一把刀做N种菜，当然高不成低不就，不易用就产生了。对于易用性的横切面研究，也需要一层层的按照架构来研究，而不是只局限关注在每个具体功能的易用性。要靠架构在框架上保证易用性，而不是在每个具体点保证易用性。这是关键出路。
可运维。你的软件安装到了客户处，你对你的软件使用情况和软件运行情况了解不？这就是可运维。需要在应用架构层面一层层考虑如何在各层增强可运维，提供可运维需要的功能和数据信息。
知道了这么多横切面维度，我们就需要按维度和软件分层做个二维表，看看每个维度每一层需要做些什么事，我们已经做了哪些事，哪些事还是一片空白，哪些事还需要改进。有这样一个大完备性清单了，我们就可以根据优先级来分步研究、落地了。
