3.1 企业架构的使命与要求
3.1.1 企业架构要解决的问题
数字化时代是以软件为主要生产工具，以数据为关键生产要素，以协作为普遍生产组织方式，虚拟与现实深度融合的“超级体验”时代，个体将享受到空前的获得感、参与感，乃至幸福感。数字化时代已被软件“包围”并“填满”，软件开发量的增长已经预示了未来的趋势。据某知名机构预测，未来5年的软件开发量将超过过去40年开发的总量，那么，未来10年、20年、30年呢？随着软件技术在基础教育中的普及，“全民编程”时代距离今天也未必很遥远。对于企业端的软件开发而言，这既是好消息，也是坏消息。
企业的对外服务、对内管理大量依靠软件实现，即便是街边零售摊贩，也在使用软件收款结算。软件服务范围的扩大，直接导致“软件缺口”的扩大，且这个缺口没有因为软件开发速度的加快而缩小。越来越多的企业端软件，在提升单项工作效率的同时，也加大了总体管理的成本，增加了数据处理的难度，我们称这种现象为“软件混乱”。“软件混乱”导致通过软件提升企业洞察力的难度加大，而这本应是数字化发展的关键方向。如果从业者人数、工作量的持续上升未能填补软件开发的缺口，反而加剧“软件混乱”，这就与开发软件的目标背道而驰了。软件本身要能够很好地解决问题，在此前提下才有商业利益可言。
凡是软件必有架构，这是由软件的生产方式决定的。无论采用面向过程、面向对象还是面向函数的编程语言，软件都只能按照某个特定的结构去实现，因为需求本身也有其内在结构。企业端软件面对的问题是在其开发过程中导入了因企业因素而产生的特殊复杂性，企业因素包括企业战略、组织结构、业务模式、外部协作、客户变化等，企业是一个特定的“问题域”。
清晰的软件架构可以降低复杂度的不可见性，问题能因为结构的分解而从“大”变“小”。架构是解决“软件混乱”的正确方式，企业端软件也不例外。针对企业复杂性这个特定的“问题域”，我们的解决方式就是“企业架构”。目前各类应对企业端软件开发存在的“软件混乱”而采取的措施，最终都会导向某种在整个企业范围内思考问题、寻求策略的倾向，其实质都是对“企业架构”的探求，仅在方法上有所区别而已。
3.1.2 企业架构还需要发展
“企业架构”是解决企业端“软件混乱”的工具，但工具本身也会增加复杂性，也可能导致混乱，因此，让工具本身清晰也是非常重要的。架构的实质就是在解释清楚结构和关系，因此，架构设计必须聚焦于关键设计元素及其关系的获取，架构开发中采用的方法、工具都要服务于这一目的，不要过度拓展架构解决问题的方式方法，导致架构方法论的混乱。
企业不应当被企业架构的庞大迷惑，甚至产生畏惧心理。清晰的企业架构方法是在解释企业的复杂性，企业的复杂性不会因企业架构方法而放大，反过来，企业的复杂性也不会因为不采用企业架构方法而减少。
企业架构会关注企业的战略、组织、业务、技术等方面，但是，架构在每个方面关注的都是其设计元素及相互关系的识别与表达，架构本身不等于架构设计对象，只是对架构设计对象的良好表达，借此澄清架构设计对象。为了达到这一目的，企业架构方法论必须阐明自己关注的设计元素，并且可以动态地调整这些设计元素及识别方法，这就是企业架构方法论的演进。
澄清架构设计对象虽然有助于解决“软件混乱”问题，但仍然不能保证软件开发速度的提升，无法解决“软件缺口”问题。“软件缺口”问题是更大的行业级别的“软件混乱”，这一问题导致行业通用功能既无法很好地由商业套件提供，也无法通过开源手段简单解决，因为这是语境、语义上的“混乱”，是跨企业的定义、标准、理解不一致产生的“混乱”。
由于架构方法的内在逻辑，企业架构有助于解决“软件混乱”问题，但这个问题不是单一企业的架构设计方式可以解决的，而是需要跨越单一企业边界进行标准化提炼，实现行业级的标准化。即便在同一行业内，对于不同规模的企业，其架构依然可以是不同的，所以，这是按照企业行业、规模等维度分层的企业架构。
基于对标准化分层企业架构的提炼，可以获得“量产”型的架构设计生产能力，当然，这并非绝对的“量产”，而是相对当前长周期、人力型企业架构生产方式而言的“量产”。在企业架构工具的支持下，少量架构师可以有效地指导架构设计工作。这里需要明确的是，架构师的工作是“指导”而非“生产”，因为企业架构设计不仅是架构师的事情，而是整个企业的工作。企业架构是数字化企业的思维模式，把一切事物结构化，进而数字化，把所有局部融合成一个有机整体，这是需要企业上下共同努力的事情。每个人、每个物品都是企业的一部分，也都是企业架构可以描述的一部分。
这种支持跨企业甚至跨行业标准化、“量产”的企业架构，也可以采用生态方式构建。像“开源社区”一样的“开源企业架构社区”会帮助构建架构，可以为行业提供民主化、分布式的架构设计能力，而非中心化的架构产品。
对于以构件为单位的架构设计，开源其架构构件、关系说明，可以为架构设计提供能够快速生长的“生态”。如果构件本身已经包含实现，这就是一个不以单一系统为生长边界的“开源企业架构”。当然，开源企业架构的发展离不开国家的支持和专利的管理，这样才有可能平衡社区的运营。《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》（本书以下简称《纲要》）中已经提到需支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系。
企业架构有助于解决企业端软件生产存在的“软件缺口”和“软件混乱”问题，但这并不是当前的企业架构理论可以马上解决的，还需要理论自身的发展，以及所有支持者、需求者共同而长期的努力。尤其重要的是，这不是一个在技术层面可以解决的问题，企业架构尤其是其中的业务架构部分，必须走出技术侧，能够被业务侧掌握且广泛应用，其全部价值才能被激发。
3.1.3 企业架构应满足的基本要求
企业架构自身需要发展，发展中应注意最基础的五项要求。
1）架构资产的明确性：企业架构对其设计元素的表达、对架构资产的界定，应当尽可能明确，不增加额外的复杂度。
2）架构连接的清晰性：元素间的关系应当尽可能清晰，元素间的连接在存在的瞬间就是静态的，必须清晰。
3）架构组合的灵活性：架构从底层元素开始就要支持灵活组合，这是架构弹性的基础，然而灵活的组合会导致架构资产更难以定义，因此在架构资产定义时还需做权衡。
4）架构沟通的高效性：基于架构进行的沟通必须是高效的，否则，说明以上三项的要求未能满足，架构沟通是否高效检验了架构设计质量。
5）架构方法的友好性：架构具有一定的抽象性，但又是用来解决复杂问题的，因此其方法难免会有过度复杂化的倾向，企业架构是为企业战略服务的，是遵循由战略到业务再到技术的传导路线的，如果方法缺乏友好性，会受到业务和技术两端的“嫌弃”，尤其是业务端，业务端的“嫌弃”会让通过企业架构促成业技融合的想法落空。
要达成这五项，必须非常重视元模型和业务视角（也即业务架构），这也是本书构建企业架构方法论与架构框架的核心要点。