终于有人把企业架构讲明白了

作者：付晓岩

来源：大数据DT（ID：hzdashuju）

01 企业架构的概念与范围

企业架构设计的服务对象是企业，所以，“企业”是企业架构理论需要首先明确的概念，对于这一概念，笔者比较赞同TOGAF理论中对“企业”的定义，也即，企业是具有共同目标的一系列组织集合体。

尽管概念略有抽象，但是这一旨在界定涉及范围的概念有效地避免了关于企业性质的深入讨论可能会带给企业架构理论的混乱，也很好地拓展了企业架构理论的适用性。

基于这一概念，企业架构理论适用于任何组织形态，也不需要区分组织规模，并且强调“共同目标”对企业架构设计的指导性意义，实现“共同目标”是企业架构的使命。

确定了“企业”的概念之后，接下来要确定的自然是什么是“架构”。笔者比较认同ISO中对“架构”的定义：架构是指系统的基本组成部分，各组成部分之间及其与环境之间的关系，决定其设计与演进的治理原则。也即，架构主要包括结构、关系、原则（也可以理解为“规律”）。

这一概念同样也没有限制架构的适用范围，所以笔者曾在自己的公众号文章中提到，“万物皆有架构”，不仅我们设计的系统如此，诗词歌赋也一样。不同的词牌子有不同的字数、平仄、韵脚的要求，可以产生不同的节奏，每个词牌子都是一种“架构风格”，不同的“架构风格”适合不同的主题、抒发不同的情感，颇像技术领域常说的设计模式。

那么把这两个概念结合起来，笔者认为，作为名词的“企业架构”的概念应当是“具有共同目标的组织集合体的基本组成部分及其内外部关系与治理原则”。由此，企业架构设计就意味着：

• 根据共同目标分析、设计相关组织集合体的基本组成部分和内部关系；
• 企业架构治理的核心则是持续形成和完善用于指导设计和架构演进的原则；
• 企业架构方法论则是根据企业架构的概念，为企业架构设计和治理的实现提供指导性的框架；
• 企业架构实施则是根据企业架构方法论提供的框架，针对本企业的特点进行的企业架构实施活动，包括架构设计与工程管理两部分，企业架构实施会带来企业架构方法论的改变，这种变化最终也可能会导致企业架构核心概念的变化，也即，企业架构理论是动态的、知行合一的理论。

按照Zachman框架的理念，企业架构是多视角架构的集合；TOGAF将其内部划分为“4A”架构，即业务架构、应用架构、信息架构（数据架构）、技术架构。

笔者也认为企业架构不是一张包罗万象的“大图”，而是多视角的集合，笔者建议应当将TOGAF“4A”架构中的业务架构与信息架构整合为新的“业务架构”，理由是业务和数据应当在架构设计过程中整合考虑。

这并非要取消数据模型，而是数据模型不应再是单独的设计过程，应该与业务模型一同设计，并形成更紧密的关系。一方面有利于提升业务架构的结构化、标准化程度，另一方面也便于业务架构与应用架构的衔接。

因此，笔者建议的企业架构在内部分类上包括业务架构、应用架构和技术架构，信息架构则分别融入这三个架构的设计过程中。

每种架构都有自己关注的部分，但是，作为整体而言，构成三者之间衔接关系的则是对相同内容的审视，这个相同的内容就是对架构组成部分和原则的认知。而这三种视角认知的背后，则是企业战略、组织和企业文化的影响。

因为每种架构最终都要为实现战略服务，而各个架构都会不同程度地受到企业组织结构的影响，在这方面，“康威定律”的作用已经被广为接受了，尽管不太合理，但是，即便是离业务相对较远的技术架构，其平台的规划设计也难免会受到组织因素的影响。

企业文化作为一种不可见的“软因素”，其对企业的影响更是渗透到企业的方方面面，围绕企业架构开展的各种活动都是企业活动的一部分，也必然受其影响，因为一切活动最终都是人的活动，企业架构活动也不例外。当然，企业架构活动也会反作用于企业的战略、组织和文化。

三个架构中，重点是业务架构，这是实现业务与技术深度融合的关键部分。

企业架构方法论并非只关注理论的自洽，而是高度关注其实现能力，因此，企业架构方法论中，除理论逻辑外，应当包含实施建议或者指南、工具介绍。新理论可能在列举实施指南时缺少可供参考的实例，但是不能因此而停止对理论发展的大胆讨论，因为对待方法论研究的正确态度是积极思考、勤于动手、博采众长。

方法论实践是需要结合企业自身特点而不能简单照搬的，因此，实例对于理解方法论而言，虽然具有非常珍贵的参考价值，但不能完全按照实例去理解方法论，因为实例都是方法论的落地的“特例”。所以，理论上的研究也需要敢于大胆提出方向和设想，再去实践中求证。

在企业架构方法论中，除对设计方法的介绍外，也应包含方法论对工程模式适配能力的分析，工程模式是企业落实企业架构的必经之路，所有设计最终要通过工程能力实现，工程管理对于架构落地效果具有至关重要的影响。方法论要做到的是努力兼容各种工程模式，这对方法论而言是一种很大的挑战。

企业架构方法论不应当只停留在“当下”，应当对自身的发展方向有所指向，这是架构方法论在时间上的扩展性、适应性的来源，也是为对该方法论感兴趣的企业、读者提供创新思路的指引，也即，所有的架构方法论理论上应当是自洽的、闭环的，但思想上应当是演进的、开放的，方法论研究永远在路上。

因此，没有停滞不前的方法论，只有让方法论停滞不前的选择，也即，方法论的停滞通常是人的问题。

关于企业架构的认知，还有一点非常重要，企业架构是为企业服务的，但企业不是为企业架构而生的。做企业架构是为了更好地理解企业，提升管理能力，但不是为了用企业架构去“统治”企业。

企业架构是为了通过内部一体化、内外一体化的设计提升效率，但企业架构自身的述求不是企业必然会放在第一位去考虑的问题，当利益的需要与既有架构的工作方式、原则产生冲突时，企业很可能会把利益置于优先地位，这是可以理解的，尽管会对架构产生影响，甚至给今后遗留下问题，但是，企业架构和做企业架构的人都必须能够接受和适应这种“例外”情况。

笔者希望企业更多地通过企业架构引导自己的决策，企业架构反映的正是遵循秩序带来的自由，没有秩序的自由终将导向全面的混乱。临时的、局部的混乱也许可以为企业带来产生一定优势的“灵活”，但是，没有企业可以靠“全面混乱”取得长期竞争优势。

笔者提出的新企业架构方法论的主要内容如图3-1所示。

▲图3-1 新企业架构方法论概念图

如果读者对企业架构方法论有一定了解的话，可以发现，笔身并未新增概念，而是对已有认知的加强和调整，这也是对“奥卡姆剃刀原理（简单有效原理）”的应用，“如无必要，勿增实体”。

02 企业架构的使命及发展要求

1. 企业架构要去解决的问题

数字化时代是以软件为主要生产工具、以数据为关键生产要素、以协作为普遍生产组织方式，虚拟与现实深度融合的“超级体验”时代，个体将享受到空前的获得感、参与感，乃至幸福感。

这样的一个时代，是被软件“包围”、“填满”的时代，软件开发量的增长已经先于时代的到来提供了未来的迹象。据某知名机构预测，未来5年的软件开发量将超过过去40年开发的总量，那么，未来10年、20年、30年呢？

随着软件技术在基础教育中普及，“全民编程”时代距离今天也未必很远，对于企业端的软件开发而言，这是好消息，也是坏消息。

企业的对外服务、对内管理大量都在依靠软件实现，即便是街边零售摊贩，也在使用软件收款结算。软件服务范围的扩大，直接导致“软件缺口”的扩大，且没有因为软件开发速度的加快而缩小。

越来越多的企业端软件，在提升单项工作效率的同时，也在加大总体管理的成本，增加数据处理的难度，这可称之为“软件混乱”。“软件混乱”导致通过软件提升企业洞察力的难度加大，而这本应是数字化发展的关键方向。

如果软件开发由于从业者人数、工作量的持续上升却未能填补“软件缺口”，反而加剧“软件混乱”，那将与开发软件的目标背道而驰。软件本身要能够很好地解决问题，这之后才有商业利益可言。

凡是软件必有架构，这是由软件的生产方式决定的，无论采用面向过程、面向对象还是面向函数的编程语言，软件都只能按照某个特定的结构去实现，因为需求本身也有其内在结构。

企业端软件面对的问题是在其开发过程中导入了企业因素而产生的特殊复杂性，企业因素包括企业战略、组织结构、业务模式、外部协作、客户变化等等，企业是一个特定的“问题域”。

软件架构的清晰会降低复杂度的不可见性，会让问题的解决能够因为结构的分解而从“大”变“小”，架构是解决“软件混乱”的正确方式，企业端软件也不例外。

为此而需要针对企业复杂性这个特定“问题域”导入的解决方式就是“企业架构”，目前各类应对企业端软件开发存在的“软件混乱”而采取的措施，最终都会导向某种在整个企业范围内思考问题、寻求策略的倾向，其实质都是对“企业架构”的探求，仅是方法上的区别而已。

2. 企业架构还需要发展

“企业架构”是解决企业端“软件混乱”的工具，但并不是意识到这一点就可以了，工具本身也会带来复杂性的增加，也可能导致混乱，因此，让工具本身清晰也是非常重要的。

架构究其实质就是在澄清结构和关系，因此，必须聚焦于关键设计元素及其关系的获取上，架构开发中采用的方法、工具都要服务于这一目的，而不要过度拓展架构解决问题的方式方法，导致架构方法论的混乱。

企业不应当被“企业架构”庞大的“身影”迷惑，甚至产生畏惧，清晰的企业架构方法是在解释企业的复杂性，企业的复杂性不会因此而放大，反过来，企业的复杂性也不会因为不采用企业架构方法而减少。

企业架构会关注企业的战略、组织、业务、技术等方面，但是，架构在每个方面关注的都是其设计元素及相互关系的识别与表达，架构本身不等于架构设计对象，只是对架构设计对象的良好表达，籍此澄清架构设计对象。

为了达到这一目的，企业架构方法论必须阐明自己关注的设计元素，并且可以动态调整这些设计元素及识别方法，这就是企业架构方法论的演进。

澄清架构设计对象虽然有助于解决“软件混乱”问题，但仍然不能保证对软件开发速度的提升，无法解决“软件缺口”问题。

“软件缺口”问题的成因之一可以归结为“软件混乱”问题，是更大的行业级别的“软件混乱”，这一问题导致行业通用功能即无法很好地由商业套件提供，也无法通过开源手段简单解决，因为这是语境、语义上的“混乱”，是跨企业的定义、标准、理解不一致产生的“混乱”。

由于架构方法的内在逻辑，企业架构有助于解决这一问题，但这不再是单一企业的架构设计方式可以解决的，需要跨越单一企业边界进行标准化提炼，是行业级的标准化。但是即便在同一行业内，不同规模的企业，其架构依然可以是不同的，所以，这是按照企业行业、规模等维度“分层”的企业架构。

基于对标准化分层企业架构的提炼，可以孕育“量产”型的架构设计生产能力，当然，这并非绝对的“量产”，而是与当前长周期、人力型企业架构生产方式相对应的“量产”。

在企业架构工具的支持下，少量企业架构师应当可以有效指导一个企业的、快速的架构设计工作，这里需要明确的是“指导”而非“生产”，因为企业架构设计不是架构师自己的事情，是整个企业的工作。

企业架构是数字化企业的思维模式，把一切事物结构化，进而数字化，把所有局部有机整体化，这是需要全企业共同努力的事情，每个人、每个物品都是企业的一部分，也都是企业架构可以描述的一部分。

这种支持跨企业甚至跨行业标准化、“量产”的企业架构，也可以是采用生态方式构建的企业架构。专业咨询公司依然可以靠设计更高质量的企业架构赢取收入，但是企业架构也可以是“开源社区”一样的“开源企业架构社区”，可以是民主化、分布式的架构设计能力，而非中心化的架构产品。

以构件为单位的架构设计，其架构构件、关系说明应当可以开源，或者有偿提供构件级的产品，从而为架构设计提供可以快速生长的“生态”，如果构件本身已经包含实现，这就是更好的、不以单一系统为生长边界的“开源企业架构社区”，当然，这里也需要国家的支持力量和专利管理的发展，才有可能平衡社区的运营，《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》中已经对“开源”的价值有所肯定和期待。

企业架构有助于解决企业端软件生产存在的“软件缺口”和“软件混乱”问题，但这并不是当前的企业架构理论可以马上解决的，需要理论自身的发展和所有支持者、需求者共同而长期的努力，尤其重要的是，这不是在技术内部可以解决的问题，企业架构尤其是其中的业务架构部分，必须走出技术侧，能够被业务侧掌握且广泛应用，才能激发其全部价值。

3. 企业架构应满足的基本要求

企业架构自身需要发展，而发展中应注意对自身最基础的五项要求：

1. 架构资产的明确性。企业架构对其设计元素的表达、对架构资产的界定，应当尽可能清晰，不增加额外的复杂度。
2. 架构连接的清晰性。元素间的关系应当明确，元素间连接在连接存在的瞬间就是静态的，必须清晰。
3. 架构组合的灵活性。架构从底层元素开始就要支持对其进行灵活组合，这是架构弹性的基础，灵活的组合会导致架构资产定义的困难，这需要在架构资产定义时做权衡。
4. 架构沟通的高效性。基于架构进行的沟通必须是高效的，否则，说明以上三项的要求未能满足，架构沟通的高效性可以说是对架构设计质量的检验。
5. 架构方法的友好性。架构是具有一定抽象性，又是用来解决复杂问题的，方法难免会有走向过度复杂化的倾向。但企业架构是为企业战略服务的，是遵循由战略到业务到技术的路线传导的，如果方法缺乏友好性，会让业务和技术两端“嫌弃”，尤其是业务端，业务端的“嫌弃”会让通过企业架构促成业技融合的想法落空。

而对达成这五项要求非常重要的是对元模型和业务视角（也即业务架构）的重视，这也是构建企业架构方法论与架构框架的核心要点。

关于作者：付晓岩，IBM 副合伙人，全球企业咨询服务部大中华区金融核心锐变团队业务发展和交付总监。资深企业级业务架构师和数字化转型专家，具有12年银行业务条线工作经验和8年IT条线工作经验，是一位能将技术和业务深度融合的复合型人才。是国有大型银行企业级转型工程的亲历者，也曾在央行数字货币项目组中从事业务架构工作。