让企业架构方□□再演进一次
笔者从事企业架构实践多年，也一直在思考数字化转型，期间注意到了两个问题。其一，越来越多的人（包括笔者在内）认为数字化转型是企业乃至社会的整体转型，需要顶层设计，即企业架构设计，但是很多人对企业架构的理解仍然十分有限；其二，企业架构理论本身也存在很多需要改进的地方，对于如何更好地支持行业级大规模软件快速构建这一时代级的需求，目前的理论尚未与之形成呼应。
因此，我们现在正处于一个需要普及和演进企业架构理论的重要时期。笔者希望以微薄之力，推动对企业架构理论的新一轮研究与探讨，为企业架构理论的自主化投薪添柴，让本书所带来的星星之火点燃数字化转型过程中特别需要的一团熊熊烈火—掌控数字化企业的新管理思维。
企业架构是为企业服务的，企业适应了环境才能生存；环境的变化必然会引起企业的变化，企业架构则必须随着企业的变化而变化。在这一过程中，企业架构理论要对企业架构设计起指导作用，因此企业架构理论必须适时地演进。
以往的企业架构理论有哪些需要加强的地方？具体表现在五个方面：
□□，业务架构与数据架构的关系需要融合，这正是“一切业务数据化，一切数据业务化”的□好体现；
第二，业务架构与应用架构的衔接要进一步加强，以便使业务与技术的联系变得清晰且直接；
第三，企业架构的标准化和对开源化的支持要提升，这是适应大规模软件快速构建的必然要求；
第四，企业架构的灵活组合能力需要提升，这是通过架构韧性增强企业管理弹性的要求；
第五，架构的开放式设计需要提升，这是生态发展、连接深化的要求。
笔者致力于通过本书阐述的新方□□解决上述需要改进的问题，这一新方□□是“面向数字生态的构件化企业架构”（Oriented Digital Ecosystem Enterprise Architecture Based on Standard Component，ODEEA- BSC），简称“数字生态构件架构”（Architecture Based on Digital Eco- Component，ABDEC）。之所以称为“数字生态”，是因为未来的企业生态主要是以数字化企业基于数字化技术构建的生态。ABDEC以“构件”为企业的基本组成部分，通过构件关系形成企业架构，通过构件的灵活聚合形成组织、业务领域、业务组件、应用组件、物理组件等要素，使企业架构具有更强的弹性响应能力，支持企业从业务到技术的灵活调整，所以，本架构方□□又称为“聚合架构”（Architecture Based on Aggregated Elements，ABAE）。本书后续将统一使用这一名称指代本书所言的新企业架构方□□。
在数字化转型中，企业架构要适应深度生态连接和大规模快速搭建软件的要求，这需要企业架构的视角必须从企业内部延伸到行业与社会，推动企业顺应国家要求，开放企业的应用、源代码，形成行业级标准化构件，使企业架构实现生态化构建。
生态化构建包括两层含义，一层是采用开源标准化构件搭建企业应用，另一层是通过各种合作方式多方共建企业架构。生态化构建是现有及未来平台型企业、公有云和行业云服务平台所必须考虑的，而一旦这些平台开始考虑之后，所有希望在平台上获取应用的企业同样必须要考虑生态化构建架构的设计方式。
在对众多技术的自主要求中，架构理论的自主能力和企业架构设计的自主能力也是必不可少的。企业架构是解决所有“孤岛问题”的□终路径，无论企业多么犹豫和怀疑，都不能回避通过整体设计来解决这些问题的客观要求。犹豫和怀疑只会拖□□间，无论是对于企业还是个人，都不应推迟自己获得架构设计能力的时间，不应错失机会，因为架构本来就是一种必备的思维方式。
正因如此，本书希望读者“始于思维，止于思维”，集中在方□□思考层面。架构设计的结果是方□□在不同环境下的应用，可以参考、借鉴，但不能拘泥，更不要一开始就受制于某个特定的结果。阅读实例需要一定的“功力”，从思维入手，先适当增加“功力”，再去阅读实例，收获可能会更大。实现“知行合一”，将自己的认知和行为统一。
本书主要内容
本书集合了企业架构框架和企业架构设计方□□的知识。通常，“企业架构框架”指企业架构的设计过程与基于企业架构的实施过程，而“企业架构设计方□□”则专指企业架构的形成方法。本书将“形成方法”融入对“框架”的介绍，因此，如无特殊说明，本书介绍的“聚合架构方□□”就是同时指代这两者的。由于全面阐述以上两者的书较少，本书特意回顾了以往的主流企业架构方□□，以方便读者获取资料并开展更多的研究。
本书共分为五篇，具体内容如下。
□□篇为传统企业架构理论透视，包括□□、□章。□□章介绍了以往的8种主要企业架构框架或者方□□，第□章则在□□章的基础上综合分析了企业架构方□□的现状和改进方向。
第二篇为聚合架构方□□基础理论，包括第3～5章。第3章介绍聚合架构方□□的核心概念，第4章重点解释聚合架构方□□中的元模型，第5章介绍了常见的流程模型、数据模型建模方法以及一些建模原则与经验。
第三篇为聚合架构方□□设计指南，包括第6～11章，涵盖战略、组织、业务、业务构件、应用架构、技术架构的设计。
第四篇为聚合架构方□□工程管理，包括□□□～14章，阐述了项目实施过程中的具体问题、循环开发管理和工程实施难点。
第五篇为聚合架构方□□生态化构建，包括□□5～17章。□□5章介绍标准化的方法，涵盖企业内部的标准化和行业级的标准化两部分；□□6章介绍生态化的企业架构及其构建，并提出了完整的企业架构能力成熟度评估模型；□□7章重点阐述业务架构师的培养。
本书读者对象
本书适合多类读者群体。
1）企业管理者。本书认为企业架构是新时代的企业管理语言。数字化时代企业□需要解决的就是业技融合问题，而这一问题的解决离不开在管理层中引入企业架构思维。因此，对于管理者而言，本书是管理者学习架构思维、拓展管理思路，并领悟业技融合的新管理思维的“好帮手”。企业管理者可以重点关注本书□□篇、第三篇、第四篇和第五篇。
□）技术管理者。技术管理者往往承担着推动企业数字化转型的重任。对技术管理者而言，找到推动业技融合的工具和切入点是其履行使命的关键。建议技术管理者通读本书，以便在企业内部建立和推广业技融合的方法，并推动企业架构的演进，形成符合企业自身特点和需求的架构方□□，指导企业长期的技术发展。
3）企业架构师及学习者。这里的企业架构师也包括业务架构师，是各类架构师的统称。企业架构理论的分支不算少，但是鲜有能够综合论述且基于自身实践又能□□自身实践的理论，敢于大胆提出改进思路的书更少。建议企业架构“修行者”耐心阅读本书，并与笔者多讨论、多交流。
4）开发人员。笔者接触过的很多开发人员对于软件工程和企业架构的理解都不是很深入，但企业端的软件开发一定是过程与结果并重，而非不计后果只求速度。欠了“债”，迟早要还，欠的时候没有考虑企业架构，还的时候却不得不考虑企业架构。因此，建议开发人员通读本书，这样对软件工程和企业架构都能有一个初步的了解。
5）需求分析人员或产品经理。随着数字化转型的兴起，企业出于整体转型的考虑，会有越来越多的横向设计要求，以促成业务与业务、产品与产品之间的协同，以及客户体验的统一。因此，建议需求分析人员或产品经理重点关注本书第二篇和第三篇的业务架构部分，以及第五篇的标准化和对生态远景的展望。
6）业务人员。承受数字化转型考验压力□大的莫过于业务人员。业务人员不一定要学会很深的技术知识，但是有必要了解技术，这样才能更好地与技术人员协作。还有人建议业务人员要学习使用一定的“技术语言”。笔者认为，业务人员应当学习业务架构，进而形成接近软件设计需要的结构化思维方式，这才是□重要且有明显价值的，可以提升从业务创意到技术实现的转化速度。因此，建议业务人员努力阅读本书第二篇、第三篇和第五篇的标准化与生态远景部分。
7）架构理论研究者。本书综述了多种主流架构，并大胆提出了改进设想，对于对架构理论感兴趣的读者而言，本书应当算是比较难得的一本参
考书。
资源和支持
笔者公众号“晓谈岩说”载有笔者研究过程中收集和整理的部分资料，以及笔者以往的连载文章，可供读者借鉴。读者若对本书有任何建议或意见，欢迎发送邮件至yfc@hzbook.com。
致谢
特别感谢各位读者对笔者的宽容与支持。笔者的作品多有不成熟之处，而之前两本书均能取得过万的销量，全靠大家的信任，你们的信任也是笔者继续写作的动力！
特别感谢机械工业出版社华章分社杨福川、郭懿蒙、栾传龙、罗词亮等老师长期以来对笔者的支持！
感谢曾与笔者进行过企业架构方面探讨的各位朋友，感谢你们对笔者的鼓励和指导！
□后，感谢家人对我一如既往的支持。这本书是全家人共同奋斗的成果！
