请描述组织的定位/愿景
这些公司或软件正在使用我们的开源软件：
如果您觉得我们的开源软件对你有所帮助，请扫下方二维码打赏我们一杯咖啡。
}
接触业务架构工作之后，除了单位提供的方法论外，为了做好这项工作，认真学习了软件过程、系统分析与设计、架构设计、设计模式、Java
语言等内容，并研读了敏捷开发、领域驱动设计、工作流分析等方面的书籍，为了拓展对新技术的理解，在人工智能和区块链两方面也阅读了一些著作，总体而言，不够系统，都是为了能够更好地理解企业级业务架构的方法论及其向技术端的传导。
除了恶补基础知识，更重要的当然是实践，珍惜每一个设计任务，珍惜每一次与业务人员、技术人员的沟通机会，让他们来检验自己的理解和方法，逐渐形成自己的体系，把零散得来的知识最终融合成体系化的设计与表达。多写文章，提升思维逻辑性，让经验固化成为知识，当然，固化不要僵化，业务架构师应该是很善于应对变化的。
首先，业务架构师的核心是架构，不是业务也不是技术，是形成业务的架构，这一点很重要，要多学习架构设计知识。笔者对企业级业务架构的定义是根据企业战略，对企业能力进行整体规划并将其传导到技术实现端的结构化分析方法。这其中有三个关键词，整体规划、结构化分析和传导。业务架构师的核心能力是将复杂的业务体系进行整体性的结构化设计，无论你对
IT 技术或者业务有多熟悉，没有这一项能力是做不好业务架构师的。此外，由于有“传导”这个职责，这种结构化设计需要跟 IT 设计有机结合，因此，学习系统分析与设计知识就变得很重要，熟悉技术的读者能够理解，这些知识虽然偏技术，却与语言能力无关，可以脱离语言去学习其设计思维。
其次，要多了解软件过程。其实很多技术出身的读者对软件过程也只是了解个大概，日常工作中也不很注重软件过程管理，忽视了这一点，就无法了解、掌控整个开发过程。开发的目的是为了高质量的交付，而非仅是完成任务。如果不注重软件过程，连自己的专业领域都无法持续优化，那又如何跨出一步去做个好的业务架构师？对业务出身的读者来讲，学习软件过程知识就更为重要了，因为你必须了解你的下游是如何运作的，业务架构是桥梁，业务架构师的作用不是“铁路警察各管一段儿”，而是要将业务和技术衔接起来。
再次，要学习流程优化等流程管理知识。业务架构通常不是为了现状进行设计，会涉及到整合、优化现有流程，需要掌握一定的流程优化知识，这样业务架构师才能更好地为业务提供有价值的建议。但是笔者认为，流程优化虽然很重要，却不是专业书籍可以提供多少帮助的，还是比较依赖实操。学习下经典理论，再学习下 BPMN
之类的工具知识就可以，多注意实战，这部分切记不要“迷信”书籍，因为流程优化是没有标准可言的，倒是多总结自己的心得更重要。
第四，学习建模技术。业务架构的结构化设计通常是通过模型方式来展现的，因此，多学习不同的建模方法，流程的、数据的，甚至 DDD 的，互相取长补短，提升自己的模型表达能力，使设计结果能够更好地展现出来。
第五，关于跨界的注意点。从业务出发想做业务架构师的读者至少应该学习一门主流的计算机语言，不需要达到很精深的程度，主要是理解技术落地的实现方式和技术人员的思维习惯，学习一门计算机语言，才能帮助你完成跨界转型，哪怕后边你又把它忘了（不经常写代码自然容易忘）；从技术出发想做业务架构师的读者至少要先深入地学习一个业务领域，再去跨领域搞企业级业务架构，就像所谓的“T”人才，先有垂直的一竖，再做拓展的一横。
最后，日常多养成从整体出发看问题的习惯。说夸张点儿，前看十年、后看十年地去分析问题，包括看书也是，看历史书、军事书，乃至花鸟鱼虫，看什么书、学什么知识都养成全面分析的习惯，时刻注意整体和部分的关系，架构处理的就是结构和关系，日常生活、工作的方方面面都会用到架构分析能力，不是仅有系统设计会用，养成了这种习惯也会让你的设计由“实现”变成“涌现”。
敏捷软件开发》（Mike Cohn 著）。
（三）流程优化。这方面笔者也觉得很难说哪些书非常适合，流程优化除了流程管理层面的技术知识外，更重要的可能来自于管理学，不妨多读读管理类书籍，拓宽思路，再考虑具体的流程优化。推荐《目标》（Eliyahu M.Goidratt 著）、《凤凰项目 - 一个 IT 运维的传奇故事》（Gene Kim,
（五）扩展阅读。业务类书籍，建议多读些具有多年从业经验的人写的具有一定“感受”性特点的书籍，单纯的教材类书籍可能代入感稍微有些欠缺；历史、军事、经济、哲学类书籍其实很有助于从更宏观、更本质的层面了解社会的运行，有助于从更开阔的视角理解业务，不过很多读者可能精力有限，难以广泛涉猎，但还是建议各位读者适当阅读此类书籍，无论你是否对成为业务架构师感兴趣。
以上是个人的一些浅见，欢迎大家多批评指正，也希望有更多的读者一起思考如何做好业务架构，成为一名优秀的业务架构师。
}
点击联系发帖人
