【为何写作本书】
社会早已步入“信息时代”，以A（人工智能）、B（区块链）、C（云计算）、D（大数据）等技术为代表的科技应用正逐渐改变社会与生活，而在数字化浪潮中，很多企业仍处在艰难的转型甚至是转型前的阶段。
企业是否一定要转型呢？有的人说，一些企业没转型，现在也运转得挺好。这个现象有点类似于人类社会，人类社会的发展是不均衡的，既有步入信息社会的发达地区，也有原始朴素、低生产水平的欠发达地区，那这些“欠发达”地区是否需要“转型”呢？这并非是一个要与不要的问题，如果这些地区想要保持原有状态，那么，减少与外界的接触可能是不得不采取的措施，因为接触会带来融合，融合会带来改变。
对于企业而言也是如此，企业无法脱离其生存环境，如果环境发生了改变，那么企业也不得不跟着改变，因为企业是不能靠与外界隔离来生存的。企业转型是必然的，无非是要考虑转型的时机等。在信息时代，转型的方向自然是信息化、数字化，实现业务与技术的深度融合，讨论这类内容的书籍并不少，但是，实践效果却难以让人满意，“众里寻他千百度”，依然不见“灯火阑珊处”。
企业级转型是一个很艰难的过程，它并非一个单纯的技术问题，因为转型涉及企业的方方面面，如果想走通这条路，尤其是对传统企业而言，充分认识自身、寻找适合自身的方法极为重要。笔者多年从事企业级业务架构设计与管控工作，有幸参与了一次历久弥新的企业转型工程，对业务架构在企业级项目和企业转型过程中发挥的作用深有体会，因此，笔者将对业务架构工作的感悟与自身的学习结合起来，超脱原有的工作实践和理论指导，面向可操作的一般方法论写作本书。
本书在写作过程中受个人经验局限，仍多以金融业务为讲解对象，但是其方法在读者自行学习后，可以引入到其他行业的实践中，而非局限于金融业，这一点在笔者运营的公众号（晓谈岩说）的读者交流中得到了证实。纵然如此，本书终归是一家之言的分享，期待能为各位读者带来些许思考和灵感，以共同促进业务架构、企业转型方面理论与实践的发展。
【本书主要特色】
本书希望能够成为一本让各类读者都可以读得懂的架构书，因此，书中没有让人拿捏不准的概念。殊少概念可能会因为追求易懂的效果而让部分读者觉得有失严谨，但是，“易懂”也是架构设计应当追求的目标之一。与概念较少相对应，本书的“感受”成分稍多，因为笔者相信融入“感受”比单纯写方法更容易引起读者的共鸣与思考。
本书的主要内容
完整的企业级业务架构实践应当包含两条并行展开的主线，一条为“行线”，一条为“知线”，如图1所示。
“行线”是读者在日常工作中通常会比较关注的，其覆盖了企业级业务架构设计、实现及后期管理的完整过程；而“知线”则常常容易被忽视，尤其是在架构师或其团队之外。架构师有责任和义务持续改进、宣传架构设计方法，推动架构理念在企业以及社会范围内的磨砺、传播，实现架构工作的“知行合一”。出于这种认知，本书在内容方面设计了5个部分，其中，基础篇、设计篇、落地篇介绍了“行线”；改良篇、业务架构与中台篇探讨了“知线”，具体内容如下。
业务架构基础篇（第1～3章）分别介绍了业务架构的发展历程、作用、与IT架构的关系及业务模型的相关知识。
业务架构设计篇（第4～7章）分别介绍了战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法，并以一个虚拟案例综合演示了业务架构的设计过程。
业务架构落地篇（第8～13章）分别介绍了业务架构方案制作、基于业务架构的实施、项目完成后的管理机制，并比较了与敏捷开发的异同，集中讨论了企业级项目的实施难度，最后，以一个设计实例展示了业务架构设计对提升企业开发效率的作用。
上述三部分完整介绍了业务架构设计的一般实现方法，并将企业级项目需要注意的问题及痛点融合在论述过程中，以供需要开展相关工作的读者参考。
架构方法改良篇（第14～16章）介绍了如何进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率，该部分属于对前文方法的改良设想，需要读者对此多加思索，切勿生搬硬套。
业务架构与中台篇（第17章）是对业务架构设计方法与当前热点—“中台”模式的一个比对。“传统”方法并不一定会因新技术、新概念的发展而黯然失色，对方法论的深入探索和积极思考往往会让“传统”焕发新的“生命力”，深度思考比追逐热点更重要。
附录部分收录了笔者做业务架构设计期间撰写的两篇读后感，希望对读者了解业务架构设计的作用、扩展设计思路有一定的帮助。
【如何阅读本书】
本书适用于如下几类读者群体。
●企业管理者
管理者决定着企业的发展方向，以下内容都适合其阅读：本书第一部分中对业务架构发展历程和业务架构作用的探讨；第二部分中对企业战略的分析，对标问题的分析和组织问题的阐述；第三部分中对企业级项目实施、实施后管理和企业级难点的集中论述。实施问题虽然涉及项目中一些琐碎的工作，但是这些琐碎工作对项目的成败却有较大的影响，需要管理者在推动转型之前就有充分的认知。目前，很多企业在转型方面遭遇困难，这些企业并非不善于设计“战略”，也并非不精通“业务”，而是不熟悉“架构”，不清楚如何将战略通过架构落实到业务和技术实现中，企业需要具备“架构”能力，而这种能力应该由管理者带头，从业务架构能力开始，自上而下地建立起来。
●实施管理者
实施管理者通常为项目总监、各级项目经理、业务经理、技术经理等在项目实施过程中担任具体管理工作的人员。本书的前三部分对企业级业务架构设计及落地的阐述有助于实施管理者将本书的方法论引入其企业级项目工作中。第五部分的对比分析，也有助于各位实施管理者认真思考，寻找适合自身的方法论。第四部分则需要各位深入思考其方法与自身行业的适配性。
●技术人员
在实现业务与技术的融合方面，技术人员自然是需要向业务侧多迈出一步。相信很多技术人员对自己到底是在实现“业务人员”的要求，还是在实现“业务”的要求产生过困惑。本书前三部分论述的方法有助于技术人员掌握一种可以与业务人员更好地进行沟通的方式，也能够在项目中，尤其是在企业级项目中，从“业务人员”的众多要求中抽离出“业务”的要求。后两部分则有助于促进技术人员对方法论的深入思考。
●业务人员
在实现业务与技术融合方面，业务人员可能会更“痛苦”一些。一般业务人员在进行技术知识方面的学习时往往会更关注垂直领域，比如AI、区块链、大数据等，属于以应用为导向，但是很多人却忽略了对软件构建过程的关注，正是这种忽略导致了在开发中出现大量 “冲突”。本书作为业务架构设计方法论，技术门槛相对较低，有助于业务人员了解如何结构化自己的思维。通过对本书，尤其是前三部分的阅读，辅之对其他软件工程经典著作的一般了解，业务人员足以对软件的设计与实现有一个清晰的理解，使业务人员与软件的交互度更高。
●希望成为业务架构师的读者
业务架构师并非一定要技术出身，但是技术实力雄厚的人显然具有基础知识方面的优势。业务出身的业务架构师需要克服更多的技术障碍，本书虽然不能帮助你学习更多垂直领域的技术知识，但却有可能是你成为业务架构师必读的一本书。
资源和勘误
由于笔者的水平有限，书中难免存在一些不准确的描述，恳请读者批评指正。如果读者有更多宝贵的意见，欢迎通过邮箱yfc@hz.com联系笔者，期待读者们的真挚反馈，以在探索业务架构的道路上互勉共进。本书部分资源可在笔者的微信公众号（晓谈岩说）上获得。
致谢
非常感谢InfoQ中文站的编辑杜小芳女士，是她的积极支持促成了本书前身《中台之上》系列文章的连载，也感谢InfoQ中文站的郭蕾老师和Linda老师对笔者的长期支持。
