|
|
|
|
|
# 05 | 业技融合：如何打破技术和业务的壁垒？
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是付晓岩。
|
|
|
|
|
|
|
|
|
|
|
|
你可能经常听到人们说业技融合，那什么是业技融合呢？简单来说，就是业务和技术一起想办法解决问题。
|
|
|
|
|
|
|
|
|
|
|
|
不过，业务和技术一起谈如何解决问题，并不是现在常见的业务给技术提个需求、技术听完了去开发个软件这么“流程化”的事情，而是大家都把技术作为重要手段，一起去想怎么解决业务问题最好，这才是所谓的业技融合。能这样坐在一起聊，双方最好有个互相接近的思维模式，有点儿“共同语言”。不然，业务敞开了聊业务，技术满脑子都是技术，沟通效率自然很差，而业务架构就是一种能够提升效率的共同语言。
|
|
|
|
|
|
|
|
|
|
|
|
但是，目前我们对业务架构的实践普遍比较少，很多人不太清楚业务架构到底是啥，具体怎么做。所以，这两节课，我就来详细地给你讲一讲业务架构。
|
|
|
|
|
|
|
|
|
|
|
|
今天，我会先跟你聊聊业务架构是什么、有啥不足，以及它对数字化转型的独特价值。知道了这些，你就建立起了对业务架构的基本认知，下节课我再跟你聊聊具体要怎么做业务架构。
|
|
|
|
|
|
|
|
|
|
|
|
好，接下来我就先来说说业务架构到底是啥。
|
|
|
|
|
|
|
|
|
|
|
|
## 业务架构是什么？
|
|
|
|
|
|
|
|
|
|
|
|
业务架构是TOGAF最早定义的，**指的是企业的战略、组织结构、关键流程等内容**。
|
|
|
|
|
|
|
|
|
|
|
|
TOGAF给的是个枚举型的定义，也就是举例子说明业务架构应该包括什么，有什么样的战略有什么样的组织架构，遵循哪些业务规则，有什么样的关键流程。
|
|
|
|
|
|
|
|
|
|
|
|
TOGAF 9.0之后的版本，重点加强了对业务架构的介绍，它约定的业务架构设计阶段交付物有很多，如下图所示：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
从这个清单中，你应该能感受到，业务架构设计要是实实在在地做下来，一点儿都不虚，很实，还很有难度。
|
|
|
|
|
|
|
|
|
|
|
|
这里面的流程梳理、岗位角色识别与设置、数据建模、业务组件设计，都是既需要架构设计技巧又需要管理智慧的。因为大家争的往往不是你要梳理的那个流程，而是这个流程会代表的内部分工、责任边界。有时候，还会遇到没人拍桌子就会一直扯不清的东西。
|
|
|
|
|
|
|
|
|
|
|
|
你是不是还觉得这个定义还是不太好理解，没关系，我根据自己的业务架构工程经验，总结了一个偏操作性的定义：
|
|
|
|
|
|
|
|
|
|
|
|
> 业务架构是以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。
|
|
|
|
|
|
|
|
|
|
|
|
这里有三个关键词，“整体”、“结构化”和“传导”，这是业务架构的特点。我来重点分析下。
|
|
|
|
|
|
|
|
|
|
|
|
**1.整体**
|
|
|
|
|
|
|
|
|
|
|
|
业务架构看问题要全面，要从企业整体出发去设计业务架构。
|
|
|
|
|
|
|
|
|
|
|
|
以往的竖井式开发，我们通常都把业务所需要的东西全都做在一个系统内，不管各个业务领域之间是否有重复，这样的架构格局必然是重复较多，不太合理的。现在很多企业都意识到自己家的众多系统之间不协调、不一致，其实这个问题不在系统，而在于没有统一的业务架构设计，没有明确系统间的横向关系，没有把重复部分（比如客户、销售等公用功能）整合起来，而是把业务分散在各个领域进行完整而又封闭的设计，这就会导致很多问题。
|
|
|
|
|
|
|
|
|
|
|
|
对于这一点，业务架构的解决之道就是从整体出发进行合理布局。这样的设计是最经济的，但是难度相对也是高的，业务分析上，每个领域都不能只看自己家的领域。只要是跟你的领域相关的，都要横向考虑到。
|
|
|
|
|
|
|
|
|
|
|
|
此外，要落地企业战略，也需要看到企业的全貌，完整知道企业各个部分之间的相互关系，这样才好分解战略，不然，就可能出现对战略分解上的盲区，影响战略的落地。
|
|
|
|
|
|
|
|
|
|
|
|
全面是架构思维的首要特点，业务架构也是如此。
|
|
|
|
|
|
|
|
|
|
|
|
**2.结构化**
|
|
|
|
|
|
|
|
|
|
|
|
结构化是业务架构分析问题的方式。有了刚刚的对业务横向拉通的全面认知，还要把你的认知结果表达出来，这样才能把它们传导给要去做开发的技术人员。
|
|
|
|
|
|
|
|
|
|
|
|
表达可以有很多种方式，而用来跟技术人员衔接的最好方式莫过于结构化地表达，通过模型之类的手段，把业务架构设计成果表达成技术人员比较好理解的形式。在做模型的时候，如果有设计系统的支持就更好了。如果总是把方案搞成一大堆Word文档和PPT，谁也不好查找。
|
|
|
|
|
|
|
|
|
|
|
|
现在也有一些可用的建模工具和架构管理工具（比如可以用来与TOGAF过程配合使用的ArchiMate建模工具，有一套标准的、可相互集成的软件工具集支持的ARIS模型框架，等等），有些是架构管理的，有些是流程管理的。不过，相对来说，工具还是比较缺乏的，这主要是因为架构方法论的实践不够充分，再加上架构管理工具与软件开发全生命周期管理的衔接本身也不容易，所以这方面还需要逐步完善。
|
|
|
|
|
|
|
|
|
|
|
|
**3.传导**
|
|
|
|
|
|
|
|
|
|
|
|
**把自己对业务的认知准确地传导给技术，也是业务架构的任务**。
|
|
|
|
|
|
|
|
|
|
|
|
实现好的传导需要两个条件：
|
|
|
|
|
|
|
|
|
|
|
|
* **优质的内容**；
|
|
|
|
|
|
* **相应的机制**。
|
|
|
|
|
|
|
|
|
|
|
|
要注意的是，这两个不是并列的条件，而是相辅相成的。
|
|
|
|
|
|
|
|
|
|
|
|
在内容方面，业务架构要先帮助业务理清自己的环境、搞清业务痛点、设计出解决方案，这样才能向技术传导准确的东西，不然，大家都是一头雾水，就没办法进行下一步了。如果不能帮助业务一侧找到合理的解决方案，就不会有什么好的技术方案诞生。
|
|
|
|
|
|
|
|
|
|
|
|
但这一点，也正是机制上的一大缺陷。业务架构的工作方式没有走出技术圈子，没有走到业务人员中间去。实际上，应该让业务架构思维在业务一侧被广泛接受、使用，这样才能保证持续产生好的业务架构解决方案，促进业技融合，这并不是有了业务架构师就万事大吉了。
|
|
|
|
|
|
|
|
|
|
|
|
目前能做这种架构思维推广的人还很少，而人少的原因其实就是企业本身没有采用这种工作机制，自然也就培养不出这样的人。
|
|
|
|
|
|
|
|
|
|
|
|
现在，有了业务架构，战略、业务、技术这三个在企业管理中很容易出现衔接问题的东西，就被一根绳子串起来了，自然也就可以帮助业务人员找到可落地的业务解决方案，帮技术人员理解战略和业务到底要怎么实现，从而找到更好的技术解决方案。这就是业务架构的价值所在。
|
|
|
|
|
|
|
|
|
|
|
|
你想想，这不就是数字化转型的要求吗？大家要通过数字化创造新模式、新业态，要加强技术对业务的支持作用，要实现业务和技术的深度融合，说到底不也是这些东西吗？
|
|
|
|
|
|
|
|
|
|
|
|
当然了，业务架构不是“银弹”，更不是“无懈可击”，无论是企业还是个人，如果想有持续的进步，一定要有能力去发展和改进自己的工作方法。
|
|
|
|
|
|
|
|
|
|
|
|
想把它用好，也要清楚如何去完善它的不足，这样才能进一步提升你的数字化能力。那怎么改进呢？
|
|
|
|
|
|
|
|
|
|
|
|
## 业务架构的改进方向
|
|
|
|
|
|
|
|
|
|
|
|
以往的业务架构比较偏重于流程分析，对于现在这种极度追求软件开发效率的工作模式来讲，总会觉得花这么大精力去做个偏流程的分析，跟最后技术想拿来搞实现的东西是有差距的，作用不直接。
|
|
|
|
|
|
|
|
|
|
|
|
此外，业务架构要想发挥更大的作用，必须能被更多的业务人员使用才行。不然，它就是一个架构师圈子里小范围应用的技术工具，没法为实现业务和技术深度融合发挥更大作用了。
|
|
|
|
|
|
|
|
|
|
|
|
所以，关于业务架构的改进，主要有2个方向：一是业务架构设计思路的改善，二是建立合适的工作机制。
|
|
|
|
|
|
|
|
|
|
|
|
### 如何进一步改善业务架构的设计思路？
|
|
|
|
|
|
|
|
|
|
|
|
不知道你有没有想过这样一个问题：业务架构为什么很小众，不太受重视呢？
|
|
|
|
|
|
|
|
|
|
|
|
其实，这是因为“硬核”的技术专家们往往对这个不感兴趣。很多技术人员觉得它很“虚”，也就是跟软件详细设计的关系不紧密。技术人员好像可以通过这个更好地了解企业，但是又认为梳理出来的东西往往是偏宏观、偏业务的。可以当个背景资料参考，但是如果用它继续去做详细设计，总觉得差点儿意思。
|
|
|
|
|
|
|
|
|
|
|
|
这个问题的根源是，**当前的业务架构设计实践**没能把数据和流程很好地结合起来。
|
|
|
|
|
|
|
|
|
|
|
|
现在，大家都知道数据很重要，是新的生产要素，甚至还有“一切业务数据化，一切数据业务化”的口号。但是，具体怎么做呢？
|
|
|
|
|
|
|
|
|
|
|
|
当然得用笨法子一点一点做，骐骥一跃，也不能十步啊，咱们只能一个流程一个流程地去分析，把流程中要用到的、会创建的数据找出来才行。
|
|
|
|
|
|
|
|
|
|
|
|
虽然传统的需求分析也会这么做，但是做出的成果是分开的，流程的归流程，数据的归数据，该一起做的事情，却分成了两块。不仅分析过程可能浪费了时间，也达不到理想的效果。要是数据分析直接跳过与业务过程的衔接，跑到数据库表的设计层面，那就更糟糕了。
|
|
|
|
|
|
|
|
|
|
|
|
其实，**软件设计的核心就是分析行为和数据**，也就是软件的功能以及这些功能要涉及到什么数据。**把数据和流程一起说明白，是技术人员最愿意看到的业务分析结果**。
|
|
|
|
|
|
|
|
|
|
|
|
所以，**业务架构的改进方向之一，就是将原有的业务架构和数据架构融合起来，形成新的业务架构**。可以考虑把TOGAF中原来的业务、应用、信息（数据）、技术四个架构视角，去掉一个，让数据架构融入其他架构视角中。
|
|
|
|
|
|
|
|
|
|
|
|
当然，这不是说数据模型没了，而是业务模型和数据模型应该一起建，两者结合在一起考虑流程怎么切分、数据实体怎么切分，切分后的流程和数据实体到底是什么关系，这样才能更有利于对技术的衔接，同时又不至于失去业务友好性，让业务人员不好理解。
|
|
|
|
|
|
|
|
|
|
|
|
### 如何改进工作机制？
|
|
|
|
|
|
|
|
|
|
|
|
如果只改进设计思路，还不足让业务架构得到广泛使用，业务架构总在技术圈子里的打转儿是没前途的，得走出来，才能真正发挥出作用。
|
|
|
|
|
|
|
|
|
|
|
|
业务架构以往的工作方式，尤其是在TOGAF体系中，经常被认为是为了构建企业级系统而延伸出来的一个分析业务的环节。这就导致，在很多时候，业务架构会被当作企业级工程的一部分，采用的是类似于需求分析工作的管理模式，按流程坐等需求上门，忽略了独立应用业务架构方法，去解决业务人员落地企业战略、搞业务创新的可能性。
|
|
|
|
|
|
|
|
|
|
|
|
实际上，业务架构的核心价值，包括推动企业战略落地、通过架构设计提升业务协同性、促进业务与技术融合，这些都不是待在技术圈子里可以解决的问题，也不是待在技术圈子里就能培养出来的能力，必须得走到业务中间去。
|
|
|
|
|
|
|
|
|
|
|
|
那咋做呢？很关键的一点就是把业务架构师派到业务部门去工作，让业务架构师第一时间接触到业务人员的各类创新想法，并用企业的业务架构合理引导业务创新落地，帮助业务人员更好地理解技术可以带来的想象力。
|
|
|
|
|
|
|
|
|
|
|
|
当然，这也面临一个问题：现在大家都觉得好的业务架构师很少，无人可用，这个问题怨不得别人，只能怨我们自己，不培养，怎么会有呢？挖墙脚都没地方挖去。不能等有合适的人了再去做，而是要通过做起来去培养人。
|
|
|
|
|
|
|
|
|
|
|
|
而且，对于个人来说，这么好的时代机会摆在面前，在业务架构师如此稀缺的情况下，你具备了这样的能力，自然也就能走在别人的前面，关键是要有前瞻性。所以，你要经常训练自己的结构化思维和沟通能力，看到啥都想着用结构化的思路拆解下，经常模型化地思考问题，好好把自己的思路传达给别人。
|
|
|
|
|
|
|
|
|
|
|
|
通过设计思路和工作机制的改善，业务架构的桥梁作用还可以发挥得更好，而这座桥正是业务人员面向数字化转型最需要的。接下来，我再来说说业务架构对数字化转型最独特的一个价值。
|
|
|
|
|
|
|
|
|
|
|
|
## 业务架构对数字化转型最独特的价值
|
|
|
|
|
|
|
|
|
|
|
|
在数字化转型过程中，最艰难、最痛苦的很可能是现在的业务人员。现在技术变化太快，技术对原有业务形态的冲击很大。
|
|
|
|
|
|
|
|
|
|
|
|
比如，移动互联网兴起大约也就十年的时间，移动端的开发技术、安全技术变化都非常快，在业务侧，网约车、社区团购、黑客增长、私域流量等玩法纷纷涌起。技术的变化速度让搞技术的专业人员都应接不暇，感叹自己职业寿命太短，学不过来，那业务人员情何以堪啊？哪些技术哪天会替代一个旧工种搞出一个新工种，谁也说不清。
|
|
|
|
|
|
|
|
|
|
|
|
现在人们常说，“最可能击败你的不是对手，是新手”。一些跨界而来的人，带着新思维、新手段，还没有旧包袱，占尽天时地利人和，传说中的“降维打击”也都是这个道理。无论是企业还是个人，都会面临这样的冲击。
|
|
|
|
|
|
|
|
|
|
|
|
那数字化转型是要业务人员现在转行去学技术吗？当然不是，**提升对业技融合的支持能力才是出路**。就像我一开始提到的，想要实现业技融合，形成合力，就需要相近的思维模式和共同语言，这就是业务架构能做的事情，不然就会像修“通天塔”的故事那样，各说各话，最后导致修塔失败。
|
|
|
|
|
|
|
|
|
|
|
|
**提升业务与技术之间的沟通效率，是未来企业竞争的焦点**。你想想，如果经过数字化转型，大家都成为具有一定科技实力的数字化企业了，那最终我们要比拼什么？是不是又回到了谁家的业务人员能帮技术人员更快了解市场这个点上？而这个拼的就是沟通效率。
|
|
|
|
|
|
|
|
|
|
|
|
只要业务人员能够适当结构化自己的思维，好好利用、打磨业务架构方法，在不转行学技术的前提下，也能更好地跟技术人员沟通。
|
|
|
|
|
|
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
|
|
|
|
|
|
我们来小结下。业务架构最早是TOGAF定义的，关注的是企业的战略、组织结构、关键流程等内容。我结合自己的实践经验，给出了一个操作性的定义：“业务架构是以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。”
|
|
|
|
|
|
|
|
|
|
|
|
现在，业务架构的作用被忽视了，需要改进。方向有2个：一个是要把业务架构与技术设计衔接得再紧密些，把数据架构吸收进来；另一个是改进工作机制，走到业务人员中间去，把业务架构思维推向业务人员，帮助业务人员进行数字化转型。
|
|
|
|
|
|
|
|
|
|
|
|
这种两边“讨好”的方式，正是业务架构的价值所在，当然，它对业务架构师们也提出了不小的挑战，你要培养好自己思维的逻辑性，还要把自己打造成业务和技术两边都具备适当深度的复合型人才。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
|
|
|
|
|
|
你自己在工作中遇到过业务架构图和业务架构师？你是怎么看待他们的呢？
|
|
|
|
|
|
|
|
|
|
|
|
欢迎你畅所欲言，和我一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你分享给你的朋友或同事。
|
|
|
|
|
|
|
