最近在交流中接触到一些对做业务架构师有兴趣的读者，笔者就结合自己的经历谈谈对业务架构师学习方法的认识，权供各位参考。
一、个人经历
笔者是业务出身，上学时学的也不是计算机专业，做了十几年的金融业务，从需求分析这个方向走进了开发单位。因为机缘巧合，一进开发单位就参加了公司集中搞的企业级转型项目，开始学习企业级业务分析方法，做流程模型、产品模型，也熟悉了数据模型的设计，经过六年的实践，才算对企业级业务架构设计有所了解，并将之前的心得通过连载《中台之上》系列分享给了各位读者。
从笔者的经历来讲，业务架构师可以不问出身，技术和业务两边都要有一定的熟悉，如果你是其中一边出身的，那就去多补另一边的知识、多接触另一边的人，才能让自己具备成为“桥梁”的资格。
笔者作为一个业务人员，之前因为兴趣和工作的原因，对计算机知识有些了解，但是并不深入。因为管理与央行的数据接口系统，自学了一些基本的数据库操作；因为负责信贷信息系统的管理，为了给下属单位做数据提取模板，自学了 SQL；因为经常去开发单位做项目，了解了软件开发过程、需求文档制作、测试方案制作、测试等工作内容。学的都是些简单的计算机知识，只能说对这个领域不陌生。
接触业务架构工作之后，除了单位提供的方法论外，为了做好这项工作，认真学习了软件过程、系统分析与设计、架构设计、设计模式、Java 语言等内容，并研读了敏捷开发、领域驱动设计、工作流分析等方面的书籍，为了拓展对新技术的理解，在人工智能和区块链两方面也阅读了一些著作，总体而言，不够系统，都是为了能够更好地理解企业级业务架构的方法论及其向技术端的传导。
除了恶补基础知识，更重要的当然是实践，珍惜每一个设计任务，珍惜每一次与业务人员、技术人员的沟通机会，让他们来检验自己的理解和方法，逐渐形成自己的体系，把零散得来的知识最终融合成体系化的设计与表达。多写文章，提升思维逻辑性，让经验固化成为知识，当然，固化不要僵化，业务架构师应该是很善于应对变化的。
二、学习建议
首先，业务架构师的核心是架构，不是业务也不是技术，是形成业务的架构，这一点很重要，要多学习架构设计知识。笔者对企业级业务架构的定义是根据企业战略，对企业能力进行整体规划并将其传导到技术实现端的结构化分析方法。这其中有三个关键词，整体规划、结构化分析和传导。业务架构师的核心能力是将复杂的业务体系进行整体性的结构化设计，无论你对 IT 技术或者业务有多熟悉，没有这一项能力是做不好业务架构师的。此外，由于有“传导”这个职责，这种结构化设计需要跟 IT 设计有机结合，因此，学习系统分析与设计知识就变得很重要，熟悉技术的读者能够理解，这些知识虽然偏技术，却与语言能力无关，可以脱离语言去学习其设计思维。
其次，要多了解软件过程。其实很多技术出身的读者对软件过程也只是了解个大概，日常工作中也不很注重软件过程管理，忽视了这一点，就无法了解、掌控整个开发过程。开发的目的是为了高质量的交付，而非仅是完成任务。如果不注重软件过程，连自己的专业领域都无法持续优化，那又如何跨出一步去做个好的业务架构师？对业务出身的读者来讲，学习软件过程知识就更为重要了，因为你必须了解你的下游是如何运作的，业务架构是桥梁，业务架构师的作用不是“铁路警察各管一段儿”，而是要将业务和技术衔接起来。
再次，要学习流程优化等流程管理知识。业务架构通常不是为了现状进行设计，会涉及到整合、优化现有流程，需要掌握一定的流程优化知识，这样业务架构师才能更好地为业务提供有价值的建议。但是笔者认为，流程优化虽然很重要，却不是专业书籍可以提供多少帮助的，还是比较依赖实操。学习下经典理论，再学习下 BPMN 之类的工具知识就可以，多注意实战，这部分切记不要“迷信”书籍，因为流程优化是没有标准可言的，倒是多总结自己的心得更重要。
第四，学习建模技术。业务架构的结构化设计通常是通过模型方式来展现的，因此，多学习不同的建模方法，流程的、数据的，甚至 DDD 的，互相取长补短，提升自己的模型表达能力，使设计结果能够更好地展现出来。
第五，关于跨界的注意点。从业务出发想做业务架构师的读者至少应该学习一门主流的计算机语言，不需要达到很精深的程度，主要是理解技术落地的实现方式和技术人员的思维习惯，学习一门计算机语言，才能帮助你完成跨界转型，哪怕后边你又把它忘了（不经常写代码自然容易忘）；从技术出发想做业务架构师的读者至少要先深入地学习一个业务领域，再去跨领域搞企业级业务架构，就像所谓的“T”人才，先有垂直的一竖，再做拓展的一横。
最后，日常多养成从整体出发看问题的习惯。说夸张点儿，前看十年、后看十年地去分析问题，包括看书也是，看历史书、军事书，乃至花鸟鱼虫，看什么书、学什么知识都养成全面分析的习惯，时刻注意整体和部分的关系，架构处理的就是结构和关系，日常生活、工作的方方面面都会用到架构分析能力，不是仅有系统设计会用，养成了这种习惯也会让你的设计由“实现”变成“涌现”。
三、参考书目
笔者将自己读过且认为值得花时间研究的一些较为经典的书籍推荐给大家，希望对各位的学习过程有所助益。
（一）架构设计方面。《系统分析与设计》（Kenneth E.Kendall ，Julie E. Kendall 著）、《设计原本》（Fredrick P.Brooks，Jr. 著）、《软件系统架构 - 使用视点和视角与利益相关者合作》（Nick Rozanski，Eoin woods 著）、《架构之美》（Diomidis Spenellis & Georgios Gousios 著）、《领域驱动设计：软件核心复杂性应对之道》（Eric Evans 著）、《实现领域驱动设计》（Vaughn Vemon 著）、《微服务设计》（Sam Newman 著）、《企业 IT 架构转型之道》（钟华 著）。
（二）软件过程方面。《软件工程 - 实践者的研究方法》（Roger S.Pressman 著）、《软件工程》（Ian Sommerville 著）、《人月神话》（Fredrick P.Brooks，Jr. 著）、《敏捷软件开发：原则、模式与实践》（Robert C.Martin）、《Scrum 敏捷软件开发》（Mike Cohn 著）。
（三）流程优化。这方面笔者也觉得很难说哪些书非常适合，流程优化除了流程管理层面的技术知识外，更重要的可能来自于管理学，不妨多读读管理类书籍，拓宽思路，再考虑具体的流程优化。推荐《目标》（Eliyahu M.Goidratt 著）、《凤凰项目 - 一个 IT 运维的传奇故事》（Gene Kim, Kevin Behr & George Spafford 著）。
（四）建模技术方面。除了软件工程、系统分析、架构设计类书籍中通常会带有的建模介绍外，《UML- 面向对象建模与设计》（Michael Blaha，James Rumbaugh 著）也建议读读。
（五）扩展阅读。业务类书籍，建议多读些具有多年从业经验的人写的具有一定“感受”性特点的书籍，单纯的教材类书籍可能代入感稍微有些欠缺；历史、军事、经济、哲学类书籍其实很有助于从更宏观、更本质的层面了解社会的运行，有助于从更开阔的视角理解业务，不过很多读者可能精力有限，难以广泛涉猎，但还是建议各位读者适当阅读此类书籍，无论你是否对成为业务架构师感兴趣。 以上是个人的一些浅见，欢迎大家多批评指正，也希望有更多的读者一起思考如何做好业务架构，成为一名优秀的业务架构师。
