企业架构设计方法论- 企业架构的要素和思考(重塑世界观-XX第68期)

一、企业架构要解决的问题

“数字化时代是以软件为主要生产工具，以数据为关键生产要素，以协作为普遍生产组织方式，虚拟与现实深度融合的“超级体验”时代，个体将享受到空前的获得感、参与感，乃至幸福感。数字化时代已被软件“包围”并“填满”，软件开发量的增长已经预示了未来的趋势。据某知名机构预测，未来5年的软件开发量将超过过去40年开发的总量，那么，未来10年、20年、30年呢？随着软件技术在基础教育中的普及，“全民编程”时代距离今天也未必很遥远。对于企业端的软件开发而言，这既是好消息，也是坏消息。

企业的对外服务、对内管理大量依靠软件实现，即便是街边零售摊贩，也在使用软件收款结算。软件服务范围的扩大，直接导致“软件缺口”的扩大，且这个缺口没有因为软件开发速度的加快而缩小。越来越多的企业端软件，在提升单项工作效率的同时，也加大了总体管理的成本，增加了数据处理的难度，我们称这种现象为“软件混乱".“软件混乱”导致通过软件提升企业洞察力的难度加大，而这本应是数字化发展的关键方向。如果从业者人数、工作量的持续上升未能填补软件开发的缺口，反而加剧“软件混乱”，这就与开发软件的目标背道而驰了。软件本身要能够很好地解决问题，在此前提下才有商业利益可言。

凡是软件必有架构，这是由软件的生产方式决定的。无论采用面向过程、面向对象还是面向函数的编程语言，软件都只能按照某个特定的结构去实现，因为需求本身也有其内在结构。企业端软件面对的问题是在其开发过程中导入了因企业因素而产生的特殊复杂性，企业因素包括企业战略、组织结构、业务模式、外部协作、客户变化等，企业是一个特定的“问题域”。”

“清晰的软件架构可以降低复杂度的不可见性，问题能因为结构的分解而从“大”变“小”。架构是解决“软件混乱”的正确方式，企业端软件也不例外。针对企业复杂性这个特定的“问题域”，我们的解决方式就是“企业架构”。目前各类应对企业端软件开发存在的“软件混乱”而采取的措施，最终都会导向某种在整个企业范围内思考问题、寻求策略的倾向，其实质都是对“企业架构”的探求，仅在方法上有所区别而已。

二、企业架构应满足的基本要求

“1）架构资产的明确性：企业架构对其设计元素的表达、对架构资产的界定，应当尽可能明确，不增加额外的复杂度。

2）架构连接的清晰性：元素间的关系应当尽可能清晰，元素间的连接在存在的瞬间就是静态的，必须清晰。

3）架构组合的灵活性：架构从底层元素开始就要支持灵活组合，这是架构弹性的基础，然而灵活的组合会导致架构资产更难以定义，因此在架构资产定义时还需做权衡。

4）架构沟通的高效性：基于架构进行的沟通必须是高效的，否则，说明以上三项的要求未能满足，架构沟通是否高效检验了架构设计质量。

5）架构方法的友好性：架构具有一定的抽象性，但又是用来解决复杂问题的，因此其方法难免会有过度复杂化的倾向，企业架构是为企业战略服务的，是遵循由战略到业务再到技术的传导路线的，如果方法缺乏友好性，会受到业务和技术两端的“嫌弃“。“尤其是业务端，业务端的“嫌弃”会让通过企业架构促成业技融合的想法落空。”

三、企业架构的核心理念

“企业架构的核心理念包括：全面、结构化、灵活和演进。全面和结构化是有关架构设计的，但是在架构管控方面，需要具备落地的灵活性和适应长期变化的演进能力。

1.全面

企业架构设计强调全面，其根本原因是范围决定设计。企业架构要看到企业的全貌，设计范围自然要全面。而且，架构师看到的范围本身也会影响设计结果，就像梳理工作的优先级一样，5件事的优先级排序会是一个结果，事情扩大到10件又会是另外一个结果。架构处理的就是结构和关系，如果范围改变了，那么结构和关系都可能改变。架构的全面原则简单来讲就是“不谋全局者不足谋一域”。全面是一种设计要求，但并非一次就可以达到，因此可以从起点开始持续累积，逐渐达成。

2.结构化

结构化可以帮助架构更准确地实现。架构师不是为了画架构图而去研究架构的，而是要通过架构设计准确地复现一个已有的事物，或者准确地实现一个已有的想法。架构是要指导实践的，因而要找到准确的结构，才能保证实现结果的正确。结构化可以帮助认识复杂事物。结构化是应对复杂事物的有效办法，要想厘清太复杂、规模太大的事物，就要进行拆解，将大事化小，才能小中见大。”

3.灵活

架构管理应该是灵活的。在现实的架构工作中，在企业架构设计完成后，往往会因实现过程中发掘了更多的细节需求和新需求而需要调整架构，经过适当的评估的调整是可以灵活接受的。灵活对架构思维而言非常重要，可以说是架构思维的“生命之源”。所以，不要把架构设计成刻板的管理。很多人都把架构看成是一种管控，甚至抱怨架构的约束、限制、死板，这其实是把架构的执行问题当成了架构本身的缺陷，这不是正确的架构理念。做架构管控虽然与做管理类似，但是别把架构管控和行政管理混为一谈。架构的落地不是完全靠严格的管理实现的，而是因为设计本身适应了环境和目标的要求。

4.演进

灵活可以被看作处理落地问题的原则，但是处理长期适应问题则要讲求演进。当业务发生变化时，架构也需要与时俱进。只有努力适应变化，提供价值，企业才能在竞争中保持领先，才会延续下去，这是企业架构必须遵守的原则。企业架构不是追求一次架构设计任务的完成，而是要支持企业持续的适应和生存，甚至要主动发起变化去适应。

四、业务架构的概念与价值

“业务架构设计必然包含企业的战略、组织、流程等关键元素。就其方法本身而言，既可以用于单个产品线或业务种类的领域级分析，也可以用于跨越产品线、业务领域的企业级分析。”

“不同于一般基于业务诉求的需求分析或产品设计，业务架构最大的价值在于提升企业的整体性，这是企业管理一直追求的目标，让企业能够像一个人一样控制自如，像人类的神经系统一样具备企业的“数字神经”。”

“此外，无论是多复杂的系统，都需要避免“失控”，企业更是如此。系统越复杂，越需要完整的管理视图；单个子系统的能力越强，越需要整体协同，否则整体的优势无法发挥，对应的解决之道就只能是“解体”了。如果因复杂性问题而停止了发展，企业也将止步于当前的规模，业务架构更是如此。

业务架构有利于实现业务与技术的深度融合，有利于打造能够让企业整体，尤其是业务与技术之间有效沟通的“通用语言”。“通用语言”的背后是“通用思维模式”，因此，业务架构必须是一种“结构化企业能力分析方法”，这样才能逐步为业务和技术建立分析问题的共同视角。”

五、业务架构与IT架构的关系

“业务架构从企业战略出发，按照企业战略设计业务及业务过程，业务过程需要业务能力支撑，从战略到业务再到对业务能力的需要，就形成了支持企业战略实现的能力布局，它是企业如何为用户创造价值的设计。业务架构设计会尽可能地以更为集约的能力实现更为多变的业务或服务。”

“1）应用架构重点关注的是功能布局和数据流向，与业务架构的关系非常紧密，是业务架构设计的“紧后工序”。

2）数据架构的主要工作是对数据的设计，包括数据定义、数据标准、数据模型、生命周期管理、数据资产的管理等。数据架构可以很复杂，但是数据架构应该与业务架构紧密结合，而不是单纯地进行数据设计，业务与数据是相辅相成的，尤其是对数字化转型而言。

3）技术架构主要关注技术平台的分层结构。对于大型企业的业务系统而言，一个逻辑分层很可能要通过多种平台才能实现，需要制定技术平台发展规划。技术架构与业务架构的关系不太直接，要通过业务特征、业务量等多种非功能性因素来综合考虑分层的合理性和平台选型。通常业务架构设计不会涉及这部分工作，但业务架构师应当了解本企业的技术架构及其特点。

“4）安全架构与业务架构的关系一般不十分紧密，但是目前安全架构设计的一个发展趋势便是向业务架构靠拢，或者说向企业战略靠近，使得安全架构设计更贴近实际业务需要，更符合企业发展方向，而不再局限于传统的网络安全、信息安全等防护型工作，需要体现出更多的“规划”特征。

从上面的介绍可以看出，作为“灵魂”的“容器”，IT架构中的应用架构与数据架构及业务架构的关系是最为紧密的。从实践的角度来说，如果企业没有很多的架构设计人员，那么应用架构、数据架构与业务架构可以合并，毕竟业务能力规划清楚之后，向部署延伸一些就是应用架构。如果将业务架构与应用架构合并，那么经验丰富的技术人员会更适合担任此项工作，但相关人员必须具有或者要培养良好的业务思维。数据架构可以融入其他架构的设计过程中。”

六、参考资料

- 聚合架构 面向数字生态的构件化企业架构