在技术型的组织里，好多Leader能脱颖而出，除了得有扎实的技术底子，对业务的熟悉和理解也相当重要。尤其在像阿里那样的公司，P7以上的技术人员要想升职，深度理解业务就特别关键。而且，级别越高，对业务理解的要求也越高。
可能有人觉得理解业务没多难，在某个领域工作久了，自然而然就了解熟悉了。但其实，了解熟悉和深刻理解是不一样的，有深度和广度的区别。
比如说，大家都用美团点过餐，流程和操作看着不复杂，就推断背后的系统应该不难。可实际上，上千万的订单、几百万商户和骑手以及餐厅和餐品的数字化、交易流程等等，这背后是一整套业务体系和复杂的系统在支撑。光一个骑手的调度、接单、抢单、超时的问题，就很不简单！所以我说，了解熟悉某项业务，顶多就是"知道"这业务，但并不代表"深刻理解"它。
**关于理解业务，有一个不得不提的词，那就是------业务架构（BA，Business architecture）。要想快速理解业务或者深刻理解业务，业务架构都是个不错的工具。**今天就来聊聊它。
首先要说的一点就是：虽然业务架构，被TOGAF归在IT战略里，看似属于IT的范畴，但从实践经验来看，业务架构对业务人员的帮助同样也很大，完全可以从IT战略中独立出来，更多的面向业务人员，以充当业务与技术之间的桥梁。
再来说说，业务架构到底是怎么一回事？
业务架构是一个整体性的视角，它描述业务做什么？如何交付利益相关者价值？如何沟通，以及如何组织的？...简单来说，就是用一种标准化的视图对业务进行抽象、分层和简化，描述其运作模式以及各元素间的关系。
而我们所说的做业务架构，很多情况是指做业务建模抽象的工作，就是把业务拆解为表现层、逻辑层、数据层，并对每一层的关键技术重点识别和把控，比如把业务中共性的部分抽象出来，避免"重复造轮子"；再比如关注数据规模、访问量等，这些指标对方案设计影响很大。再有就是考虑业务发展提前做架构规划，以及考虑技术选型的那些事。
一些常见的业务架构模型，如下图：
最后，说说业务架构图该怎么画。抛开那些"细节"的图不说，就以揭示业务整体运作模式的"全景图"为例。
网上搜了下，很多都只能称其为IT系统的功能罗列，谈不上真正意义上的业务架构全景图。
真正的业务架构全景图，是什么样的？应该怎么画？**商业画布是一个不错的参考。商业画布，虽然只有一页纸，但其将业务模式中的元素进行了标准化，并强调了各元素间如何相互作用，且高度抽象。**只是这"关键业务"的部分，过于精炼，未能展开描述。
我们以商业画布的逻辑为思路，画一个简单的业务架构全景图（作为模板）：
-
以"运行"为中心，描述关键业务的运作，形成粗粒度的价值流；
-
左侧罗列资源开发活动和合作伙伴的能力；
-
右侧罗列业务的渠道通路；
-
上方是业务策略规划和管控活动。
代入一些具体的业务，比如电商业务，比如采购招投标业务，就获得如下全景图：
当然，这种简单的全景图，只能帮助对业务有个初步认知，还需要从全景图再展开逐一分析，再去梳理其更多的实现细节，业务架构建模的工作就是这样。
说了这么多，其实业务架构的实际工作还不只是这些，其范围还要更广泛一些。究其原因，就是因为业务架构必须发挥从战略向实施过渡的桥梁作用------上衔公司战略，下接IT实施和非IT实施。
如果你想系统的学习，小艾老师推荐大家参加艾威的CBA业务架构师认证培训课程。因为在业务架构领域，如果要讲"一个标准"，或者说值得大家认真学习的体系，那就是BIZBOK，就是CBA认证。
