业务人员或IT从业人员-如何转型为业务架构师并构建自己的知识体系

大家好，我是人月聊IT。

今年我个人公众号文章和视频分享的一个重点就是不仅仅阐述观点，而是围绕核心目标去探讨达成目标的学习路径，涉及到的知识点，方便大家构建学习曲线和知识地图。

也就是我经常说的，只有搞清楚了底层知识间的内在联系，你才能够更好地理解如何达成目标的过程，也更加容易融会贯通。

因此我今天选择如何成为一个业务架构师这个话题来进行阐述。刚好也是我前期两次整理过的内容。一次是阐述观点为主，一次是结合知识地图描述知识内在联系。大家也可以看下两者之间的差异和区别。

如何转型为业务架构师？

最近几天，有很多朋友私信问我，他们原本是互联网的产品经理，或者是软件公司里做 BA 的软件需求工程师，想了解如何更好地转型为一个合格的业务架构师。因为随着企业架构规划设计的火热，业务架构规划设计师已成为一个独立的岗位，那么如何才能成为一名合格的业务架构专家呢？

首先，我们来看业务架构的知识体系。大家是可以找到参照的，比如企业架构中的4A 架构里有专门一块讲业务架构，还有类似于BABOK这样的业务架构知识体系，都可以作为你参考学习的关键点，来梳理搭建你自己的知识体系，这是第一个关键点。

第二个点，我一直在思考，究竟是原来业务部门熟悉业务流程的业务专家，还是原来做软件开发或需求人员转业务架构更容易。

我个人理解反而是业务专家可能更容易。因为业务架构最核心的还是对业务流程、业务对象的深刻理解。所以，如果你原来是一个偏技术的人员，一定要意识到，掌握业务架构的分析方法只是其中一点，更重要的是围绕企业核心业务流程、业务价值链去熟悉业务。

接着，再来说说业务架构的本质。业务架构的本质是识别企业核心业务流程里关键的业务对象。这个业务对象不是简单的数据实体，而是包括了数据、行为、规则的一个融合体。你要识别关键业务对象，并分析其行为，包括业务对象的外在行为如何支撑上层业务流程，这就是业务架构最核心的内容。

业务架构在整个架构体系里，是一个承上启下的角色。作为业务架构师，首先要考虑如何与上面更好地对接。对接包括两点：

第一，做完业务架构后，形成的业务组件和业务能力、业务服务，如何更好地支撑上层的端到端业务流程。要回答这个问题，你至少还应该是一个流程方面的专家，懂得流程梳理、流程分析的基本方法。

第二，业务架构做完后形成的是一个个业务组件、业务对象，还要考虑这些业务组件如何组装成一个完整的产品。这就需要你在做业务架构时具备产品经营思维。

这是呈上的两个关键点。

而对于启下的核心内容，就是业务架构如何落到最终的应用架构和技术架构支撑。如何最终将业务架构设计内容落地到IT建设实践。

当前讲业务架构时，很多人会把领域建模的思路融入其中。但领域建模既涉及业务内容，又涉及技术内容，特别是偏技术的内容，已经涉及到详细的面向对象的类的设计方法、设计以及详细事件消息的设计和管理。

作为业务架构师，你不需要熟悉这些内容。你要抽象领域建模里与业务架构最关键的东西，简单理解就是，你如何通过事件风暴实现核心业务对象，如何基于高内聚松耦合的原则，搞清楚哪些业务对象应聚合在一起形成业务组件，再基于上层业务场景和流程需求，分析每个业务组件应对外暴露哪些接口服务，以实现组件间的协同，这才是你学习领域建模最重要的内容。而其他技术方面的东西，作为业务架构师，你没必要太多了解。

当然，作为业务架构师，你仍要熟悉整个软件工程软件生命周期。这和你作为需求工程师一样，虽然你不参与具体设计和编码，但要熟悉整个软件开发过程。道理是一样的。

简单总结一下，要成为业务架构师，如果你原本是业务人员，就要补充面向对象分析设计的思想和基础软件工程知识。如果你原本是技术人员，核心是要补充企业核心业务价值链、业务流程的知识，同时逐步形成流程思维和产品思维，这是你转型业务架构师最关键的内容。

业务架构师知识体系内在逻辑

业务架构是企业架构的核心，有专门的BABOK等规范指导体系。那该如何更好地理解业务架构涉及的核心知识点呢？

下面我围绕下面这个知识关系图来进一步说明。

举个例子，业务架构有两个方向的展开。一方面围绕流程分解展开，形成流程体系；另一方面围绕能力分解展开。先看流程体系展开，即构建企业流程架构模型。流程体系强调流程内容，但还需上层流程管理，所以涉及流程质量管理方法论。流程体系源于核心价值链，价值链含核心活动和支撑活动，共同构成企业核心流程体系，而价值链又源于企业核心业务战略，业务战略源于更顶层的企业战略。

回到流程体系，核心流程如研发、生产、制造、供应链物流、市场营销、售后服务及支撑的人力资源、财务等，是学习业务流程的必备内容。流程架构建设是分级的，从 1 级到 7 级，熟悉企业核心业务你了解 3 - 4 级流程就差不多了。流程体系在流程建模时，会涉及 5 - 7 级分解，这里暂不展开。

业务架构里还有业务需求这一核心概念，它不同于软件开发中的软件需求，更像IPD中的理解市场和细分市场，偏用户和市场需求。业务需求与流程体系分解到 5 - 7 级后关联紧密。

我将其分解，业务需求和业务流程的关联映射，重点是业务建模与 5 - 7 级流程的关联，将流程和业务需求联系起来。业务需求下面还涉及软件需求，这里先不展开。

再看右边，业务架构还做能力分解，形成业务组件，业务组件再与应用架构挂钩，因为应用架构里的应用组件与之有映射匹配关系。对于业务需求分析，有业务对象，而在企业架构的数据架构中，分析核心是数据实体，业务对象和数据实体之间相互关联。

业务架构知识源于上层企业架构，企业架构服务于企业战略，应用架构有技术架构支撑，这些共同构成4 A 架构内容。对于软件需求，有了数据架构后，还会涉及软件里的数据库设计。应用架构和技术架构还会细化到软件架构设计，软件需求、数据库设计和软件架构设计最终聚合到软件工程知识里。

梳理完这个图，大家发现关键点了吗？

学任何知识都有父知识和下游知识，父知识最终聚合，下游知识分解后通过关键对象或实体完成知识点映射管理。

理解这个图后，是不是容易明白业务架构不是纯技术或纯业务词汇，而是涉及业务、技术、管理多方面知识。业务架构知识体系分三方面知识融合：企业架构知识、业务域知识、软件工程知识。业务人员学业务架构要补技术软件知识，技术人员要补企业流程、质量、业务价值链、业务战略等业务知识。

我平时录视频强调如何熟悉业务、转型业务架构师，结合这个图，大家可能更容易理解业务架构知识体系是如何逐步逐层关联、展开的。

今天的简单分享就到这里，希望对大家有所启发。