开发者学堂课程【BizDevOps - 数字化转型浪潮下技术破局之路：BizDevOps：数字化转型浪潮下技术破局之路】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1076/detail/15549
BizDevOps：数字化转型浪潮下技术破局之路
BizDevOps：数字化转型浪潮下技术破局之路
2021年阿里云开发者社区推出了乘风者计划，1500名技术博主入驻社区分享技术实训与思考。
不久前，乘风者与名校合作，推出了DevOps评测大赛，收到了不少企业一线开发者宝贵的肯定与反馈。
在大赛的过程中我们也深切的感受到Devops作为全球IT组织基于惊异敏捷思想的方式得到了不少在数字化转型过程中企业和机构的认可。
然而在数字化转型浪潮下，devops也同时深陷如何发展的问题，如何让IT组织不再成为被诟病的中心而是成为效率中心或者创新引擎成为全球IT组织所面临的重大难题。
本节通过分享带领大家找寻如何推进业务发展的答案。
本次论坛的副标题开宗明义，提到数字化。我们是一个数字化时代，所以我们在谈bizdevops。该热词冒出后我们在银保监和人行在今年年初时发布了金融科技和数字化转型，属于银行和保险行业。但是其中已经指出我们在数字化时代要做到业绩融合，同时也指出了我们要做bizdevops。
- 时代背景下的感受，如何看待大环境，如何看待科技的发展和业绩融合？
转型工程一方面让自己选择了业务架构的专业方向，另一方面让我体会到在银行业中或者一些传统企业中，如果我们真的想通过一次企业级的工程去整理提升我们的业务和技术能力，并且实现业务和技术的融合，确实是一件困难的事情，需要有一些方法指导。此外也有可能企业推动力不强。
但是现在我们处于一个很大的背景，即国家提倡数字化转型，从十四五规划到2035年目标的开启，包括今年出的数字发展规划，为全社会都提供了一个数字化转型的愿景。
并且转型是以数据要素为核心，产生一个新的生产要素，通过这个新的生产要素，我们就有了新的生产工具，也就是软件。或者是说把原来这个软件做进一步的提升，让这个软件加工数据能产生更大的商业价值，然后再通过网络这种方式让整个社会协同起来，变成一个完整的数字化转型。这种国家大政策的背景指导下才有了我们说的产业数字化里的银行业这两个指导文件，一个是央行的金融科技发展规划，2020到2025；另一个是银保监会的数字化转型的指导意见。这两个文件分别从这个行业的宏观角度，以及对金融机构的具体要求的角度，提出数字化转型的方法，并且也带来一定的具体要求，所以它变成了一个行业的一个转型的一个参照，或者是一个指导。
其中，央行比较侧重关于产业的整体提升，其中也提到了bizdevops词，它是放在产品及流程服务改进该方面的，相当于数字服务方面，此方面除了bizdevops外还提到了mvp：我们常说的敏捷中传送的词，它有一个比较高的要求，希望我们的业务系统或者业务创新能够实现跨流程的自由编排和组合。
该要求很高，对于互联网企业来讲也很高，所以需要一些新的方法论，新的工具去集成。
这种转型慢慢偏向整体转型，将两份文件综合起来读，其实能看到这两份文件为银行的数字化转型画了一个大的范围图。阿里中的一篇文章从架构视角解读这两份指导文件，提到从房顶的角度来讲，要求所有的银行做好数字化转型的战略，在考核方面做好支撑，这是管理层面。
往下是实现层面，会提到两个支柱，分别是技术能力（一个银行自己在技术方面要达到什么水平，自己哪些技术一定要掌握）和生态能力（需要有人提供其他部分）。业务方面其实也要有生态，因为银行只有金融业务，但是如何想做其它拓展就需要有生态。有了技术能力和技术生态，两个中间还需要有架构能力，能让这些技术组合起来发挥作用。这两个文件也从两个不同的侧面提到架构问题，一个从总台的角度，一个从企业级已有平台角度都是新的挑战。
如果想要实现架构，还需要相应的人才，无论是业绩型人才还是专业架构人才，有了这些人和架构的管理才能将数据作为一种新的要素，作为一种能量迸发出来，之后流向后台，即数字经营、封控，包括组织经营一些绩效的考核。前台就是数字服务，需要打破数字鸿沟，创新新服务类型。这些都需要我们有一个体系化的集成，这就是我们需要找的东西。
以上仅仅从一个行业，该行业包括中国金融行业，包括中国的银行，实际上在信息化和数字化走得很前，所以我们把一个宏大的趋势展开了，以上讲的内容实际上是有bizdevops的。
- 如何看待未来的发展？
阿里巴巴发展多年都离不开技术去支撑技术的发展，所以说阿里一直在提技术创造新商业这个词，可见技术对整个商业的支撑是非常有利的，而且，互联网以及金融天然就是一个数字化的一个行业。
在该背景下，阿里在这方面也遇到了很多挑战以及做了相应的应对。在很早以前，阿里其实面对的是如何将技术去进行一些自动化，去进行一些提效相关的一些工作，那个阶段我们提出的一个口号是技术中台，也就是用的一系列的工具，自动化的平台，去将在技术角色里面的一些能力和效率进行提升。也就是大家比较耳熟能详的敏捷开发、devops，然后我们就通过一系列的工具去将大家整体的能力和流程标准化到这个平台上，然后最终形成了让整个集团的数万名员工整齐划一的去工作，这是第一阶段。
到了第二阶段时，我们遇到的问题实际上就是整个业务层去支撑业务如何能够更加高效，这个时候集团就提出了业务中台以及数据中台等这些概念。此时除了原来devops的部分，会发现所有的技术都要往业务靠近，即通过业务中台的方式。
此外去建立了这个业务跟技术之间的一些通道。到最近两年，这方面又发生了一些变化，是因为最近在提一些高质量发展，包括一些战略执行，包括各方面，从阿里的角度来讲，希望在顶层的一些战略可以顺利的逐级的去传达到下面的业务和技术团队，让大家在人力分配上，以及战略执行上，或者产品和项目组织上会更加高效。所以说整个集团又特别的在意整体的业务和技术的协同方面，现在我们也在讨论如何去通过一些方法和工具，能够将这个技术团队跟业务团队之间的协同形成统一化的一个方法流程，然后最终能够落地到这个工具上，形成一个标准化的模式，然后来提升效率。
以上展开了三个阶段，非常适合行业中进行学习。第一个阶段仅仅是向技术要效能，即技术技术要做得好；第二个阶段，实际上已经不仅要从技术要效能。此时阿里造了一个新词：中台。支持业务这件事实际上也是在支撑能力，为业务带来创收。
最后大家追求的包括上述为什么一直在提的bizdevops，实际上是要要求去创新，去引领市场，创造新的这个数字化商业模式。
- 从大学教育角度的思考或者顺应这种思考看到的契机是什么？
最早我们开始这个课程是从2017年开始，配套这个课程后面又建设了慕课，然后又有国内的第一本中文devops教材。今年我们和全国标准化信息技术标准化委员会制定出来的研发运维一体化成熟度模型国家标准，刚刚发布。
所有这些实际上都是以学术角度来推进devops在中国的发展。整个大的一个市场实际上是在全面进行数字化信息化的这样一个转型，国家现在也在倡导数字经济。
在这样的大环境下，我们在从实体的经济或者说是物理世界逐渐地向数字世界向信息化世界来进行迁移，属于一个移民的过程。在这个过程中我们看到在未来可能所有的实体经济包括一些服务业都需要做数字化，在某种程度上未来都会变成软件企业。可能我们自己不做，但是阿里会帮你做，美团会帮我们做。所以在这样一个趋势下，我们要把这些业务数字化。数字化的引擎是软件，数字化给软件的所谓的引擎的燃料是数据。
- 如何看待该趋势？
作为一线架构师，对开发者来讲其实他理想的情况是做事情的时候能够足够专注，能够不被打扰，能够聚焦在要做的事情上。但是事实上我们发现在还没有讲devops而是特殊自动化、持续集成前，都是在解决开发测的事情，即我们如何更高效的开发如何高效测试如何更高效的去集成发布。
但是那时大家有一种问题：做的很快但是不一定正确。我们团队很小但是我怎么样保证我做的是对的事情呢？就是一周只做一件事。小团队可以，但是放到阿里的大团队上不可能做该限制，那么如何聚焦到做正确的事呢？这对开发者是一个很大的挑战。思考如何与前面的业务进行联通，确保做的是一件正确的事。
另外一个特点：软件的研发虽然越来越发展，但是从比例上讲真正在底层研发的人比例越来越少，大家往往做的事情是偏向支撑业务。此时软件研发的方式和习惯也在发生变化，所以不是像以前做一个通用的数据库，而是要围绕业务需求去演进，这对一些开发者来说也是很大的挑战。
由于我本身是在做devops工具，所以就要思考自身做的devops工具如果做的足够好是否可以帮助到一线同学可以运用这种工具来提升他们的幸福感，提升他们整体的交付效率。
将上述两种观点融合可以推论：任何企业未来都是一个软件的企业，每个人都会成为开发者，而开发者体验就是非常关键的。从另外一个角度，从就业者的角度，我们今天讨论的话题是有意义的。
- 如何看待这种挑战？
从数字化的角度来看刚刚说的金融行业的确是走在数字化的前沿，因为它的信息化可能就在前面。但是最近的确看到一系列行业，那些真正开始尝鲜的人，已经享受到了数字化的红利。数字化在我们以前做工业时代就是流水线。
我们能够把质量和效率这两个统一起来，我们做生产线既得到质量也得到了效率，而不是以前的慢工出细活。但他一定程度上牺牲了个性化的体验。例如福特说的：你可以要任何颜色的车只要它是黑色的。它是以规模化和标准化为前提，得到了效率和质量。
但是数字化第一次让我们把个性化的体验拉回来，效率、质量、个性化体验同时得到。今年产能是过剩的，而我们对美好生活的追求对于个性化追求越来越多。所以谁能第一个掌握该技术，效率、质量和个性化体验都能得到，只有数字化才有可能。
所以此时很多我们已经看到的一系列企业无论是在物流领域还是房产领域等都通过数字化的方式将这个时代抛在了后面。
所以这句话：未来任何一个企业都是一个软件企业，或者说未来任何业务你要想有竞争力，就必须运行在数字化的基座之上。既然运行在数字化基座之上，对于你的业务的创新和发展，那就需要在这个数字化基座的本身这个软件上迭代和调整。
所以这对于我们软件的开发，提出了非常高的要求，比如怎么能够拉通端到端的全链路的观看而不是只看产品，怎么建立本质的数字化模型。上述讲的从物理世界过渡到数字世界，而且还要反过来去影响真正的物理世界，那么对于该事情的本质认知、模型建立要求就会更高。还要交付模式：交付的快慢、交付的精准性，直接影响业务迭代、业务创新的效率效果，这也是我们本节讲devops本身的一个大背景。
以上讲到了非常关键的一点：质量和效率。
每个行业都有追求，现在又加了一个维度：个性化体验。这是一个核心的数字化会给各个企业、各个产业、各个行业会带来同样的挑战。同样也是一个机会，抓住就能够成为数字化时代的佼佼者。数字化天然可以解决这些问题，从用户需求的获取、还原，基于还原需求的设计、生产，再去交付服务。如果没有数字化的支撑，是不可能在整个环节中做到个性化体验的难度。
- 回到这次论坛的主题：bizdevops。Devops已经成为软件工程行业的主流，那么外界会是什么感受呢？
我以前做的软件企业或者项目事实上都在做一些技术性的软件，不存在一个明确的业务方和软件隔离，它们都是技术性内容。但是在阿里后确实有一个明确的业务，会发现作为技术人员来讲不希望被当成一个资源在技术方面做事，是可以为该业务创造一些价值的。事实上希望业务和技术合作完成最后的业务。
合作关系不是业务主导或者产品主导，是一个共生合作关系。现在偏零售或者金融这种行业有非常明显的一个特点。在这种情况下对于一线的开发者来讲有一个要求，同时也有一个感受能知道这种现象的发生，对他们来讲更重要的是如何更好的融入到这种变化中，这个变化对于我现在有什么影响，该做什么事情融入这个变化。这就是我们的工具该帮助他解决的问题。
现在很多的开发团队实际上非常欢迎提出这种概念，因为他们日常已经在做这种事情。他们受到业务的反馈，如果做的事情不好，不是业务想要的，那么得到的反馈就是负面的，会被业务推着走。此时作为积极的开发者来讲，当然希望往前走一步，跟他更紧密的结合在一起，互相将结果拿到，这是一个很好的现象。
- 阿里起源就是在互联网时代，所以阿里的机遇是存在的。从业务层看待该事情，对该概念会有什么反应？
从业务角度来讲，例如像银行，业务占绝大多数，90%都是业务人员。在这样一个环境下业务会有蓬勃的需求。但是有些银行的层级比较多，实际上产生业务需求的人比较底层，他的需求逐级反映上来后已经存在了衰减。
即我们满足了很多的业务需求，但还有更多的业务需求没有满足，如果有一种业务研发一体化的方式，能够支撑我们快速的响应前台的需要，那么对于一线人员的支持会很大。
在很多银行中数据的应用有可能在中层管理以上，因为它是通过报表的形式来使用的，像一线经营时，目前可能有一些关于精准营销或交叉营销的推送。但是真正一线业务人员中使用数据的需求，我们的挖掘是不足够的。需要我们的研发体系可以更快的相应需求往下沉，这样对于客户来讲才是更好的。
更重要的一点，今天我们所说的很多软件或提到的一些名词例如业务架构，很多人不能理解，那么能否有一套更好的展示方式能够让我们直观的看到这些功能，例如像我们今天的rpa，其实不是一个很复杂的技术，但是能够让业务人员学会怎么拼一个流程、现场就能采集数据，这是我们所希望看到的。是否有这样的工具和平台或者研发体系能够将我们后台对于业务人员来讲等同于黑盒的内容白盒化的展示给前面，将业务与技术结合起来。
以上从一个业务的角度（业务是务实的，例如要完成一个api，如果可以让我更快的完成这件事情，提出这个概念还是很欢迎的）另外一个角度业务影响指导（现在的业务随着一代一代的人在数字化时代里生活，其实也想了解软件是怎么来的、如何开发的）。
- 中台与bizdevops有关系吗？
上述提到了两大类问题，第一大类问题其实是一种协同的问题。现在以一个中台的例子讲解一下协同的问题。其实中台是一个大的部门，需要支撑很多业务线，有大的业务线，有小的业务线，需求从业务人员处反馈的就非常多。
此时就存在一个问题：需求从最开始的业务人员基层开始反馈，一直上升到上面的业务设计人员，再从前台的部门传递到后台的部门，其中就有非常多层次的衰减。然后还有优先级的问题，到了中台后无法判断哪一个优先级更加重要，这是一个典型大型企业的协同问题。就是因为这种协调问题的梳理不通，没有一个标准化的类似于我们提出的bizdevops这样的方法理念就会很混乱，混乱就会导致很多有价值的创新的想法最终没有得到真正的关注。
甚至是高层想要投入一定资源做的事情，到了基层可能也没有投入足够的人员去反馈。另外一个是如果今天不让技术成为瓶颈，不让中台成为瓶颈，开发一些新的东西让业务同学自己做，包括rpa、中台，在中台上尝试搭建一些业务流程，将中台的组件组成一些流水化的内容，让业务人员直接编排配置。不需要再找技术人员，直接在上面用一个流程化的东西去配置。
这样的工具也可以解决bizdevops，业务人员和开发人员之间的协同问题，让创新更快的发生。无论是在协同方法上改进，还是直接左移的方式技术的方式去改进，都是想让一些有价值的业务创新可以得到最快速度的响应。
在谈中台时，很多时候还是由技术部门发起，发起的要点是科技师可以往前站一站，找到一些业务能力的提取，能保证在业务发展的过程中可以产生一些作用。甚至有一些不同的组合，一些业务的支撑的创新。当我们在提bizdevops时，它在牵引着我们的方向。中台这样长期运作下去，甚至于会产生阻碍创新的影响。因为是按照自己的优先级选择，并没有考虑业务的优先级，所以这就出现了一个新的弊端。
- bizdevops开展为计算机类专业课程，如果将课程改为bizdevops会对软件工程的学生有什么影响？
这种跨学科跨专业的融合已经在大学中出现，我们的计算机类的课程不仅仅是服务于本专业的学科。很多其他院系都会将计算机能力变成一个通修课程，并不只是在计算机类和IT领域。无论选择哪个专业，计算机能力可能都会成为一个必备的知识。尤其对于软件学院，开放了devops课程，还开发了敏捷课程，而且也有创新创业的课程。所以我们软件工程院系与计算机院系的不同是更面向于实践，更面向于工程，更面向于交付的价值。
- Devops在做工具或者做产业或者是做推广或者是在学校，虽然说得到很大的认可，但是该运动还没有结束，仍然在往前发展。在该运动过程中，devops运动中哪些是可以借鉴的，哪些是应该避免的？
Devops运动是在2009年左右提出，要打破dev和ops之间的墙。今天来看都属于IT或者技术部门，在业务角度看两者融合。但是事实上在当时两者之间的距离很明显，因为它们的关注点和目标不同，dev目标是快，敏捷运动，关注的对象是代码，ops目标是稳，关注的对象是机器。目标上有矛盾，关注的对象不同，所以devops运动提出后首先目标是要同一目标，要更快，其实也是对于业务或者客户需求的响应。产生了一些非常好的管理方法是打通了整个层到ops层的流程，借鉴了一些精益的方法，这点非常重要，借鉴了当时敏捷开发的方法，讲究端到端的流程以及反馈。这一点在协作上面非常好，但是最终要落到技术上。
落到技术上后，一个关注代码，一个关注机器，最终关注的都是应用。包括应用的代码、配置、环境、数据等甚至是流程，所以以应用为中心去开发。这成为最后阿里和微软指定共同推进的om标准，开放应用模型，将开发和运维人员关注的视角进行统一。
看到了两点，既要有理念和方法上的改变，但最终还是要有技术上的手段来解决，这是要借鉴的。对于bizdevops，要统一目标，所以业务和开发共同的目标是什么，这时我们需要思考的，如何让业务和开发在一个目标下进行工作。第二个我们在流程中有什么共同关注的东西，例如在devops中有共同关注的应用，而现在应该关注的是价值的交付。所以从bizdevops的目标来看，很有可能是如何打通业务、开发、运维、工程等的职能，能够实现业务价值的快速交付，形成一个有效的闭环，在数字经济情况下更有效的支撑业务的发展和激发业务的创新。
所以共同的目标找到共同的关注，最后再落到有效的技术或工程实践上，是我们要做的事情。总体上bizdevops是非常成功的，所以从借鉴的角度，bizdevops的智能扩展打破IT内部的墙的情况下，今天更重要的是打破IT和业务之间的墙，但要做的事情很多。
上述总体比较认可，如果将devops看作数字化时代的变革是比较成功的。该变革关注了两个原来利益不同方的共同目标，如何将价值拉通，最后形成一套有效的方法文件工具。该变革的模式放到今天bizdevops往前走有一定指导文件。
- 业务也领导很多devops，不仅仅是银行，其它很多产业也引导，那么业务侧理解下bizdevops有什么可以借鉴的？
首先大家要统一目标，其实企业中很多时候有一些有形或无形的墙存在，但是从墙的角度来讲，墙本身也是合理的。因为企业内部是分工协作的，既然要分工，肯定会产生专业化的内容。专业化会产生知识壁垒，自然就会有一道墙存在。技术内部有一些墙要弱化让技术统一起来或者协调起来，其实在业务侧也一样。
在业务层例如在银行条限稍微有点分割，但是这么多条限，大体上服务的客户是一样的。零售的条件都是服务那些个人客户，对公的条件都是服务那些公司客户。但是不同的部门其实对的客户是一样的。有这些分工，按理说也要协作，也要往一起走。
但如何将业务侧打通，但是现在又不仅是业务侧打通的问题，因为我们现在这个社会的需求变化快，客户不止接触银行，接触很多行业。有的人别的行业带来一些变化会让他的业务形态产生一些改变，这个业务形态的改变有可能跟银行协作时就会不同。这两年，电商拉起的销售的支付频率就相当于要求银行支付效率也上升，业务处理能力也上升，那这些就从业务侧传到了技术侧。
希望整个都能协同起来，我们希望能把这个东西传导好，能打通这个壁垒。但是业务间就有隔离，业务之间要统一自己内部语言。要先把自己统一起来，就有点难度。其实业务侧不是一点模型化思维都没有。例如银行的一个特点，我们发新产品之前要发制度，制度里带有流程图，所以它本身有这个流程化和结构化的思维，但是不同的部门画的的标准是不一样的，所以我们可以先通过一些业务模型的方式，让各个部门去描述自己流程的语法一样，这样业务内部语言统一后再跟IT对话时，大家都用相同的方式去表述流程，包括更重要的是用相同的视角或者定义去看数据，把数据和业务这两个东西统一起来。这样IT这一侧才不会项目组跟这个部门打交道，对这个数据和这个业务是某一种认知，换了另一个项目组，跟另外一个部门打交道的时候，相同的数据两边定义的不一样，然后到报表上一合成时就出问题。所以要想把业务到biz再到dev再到ops统一，语言是很重要的。但语言不是单一一个方法论一下子就可以解决掉的。从一个基础语法到一个长期熟练使用的语法，这样统一建立起来。
这样从biz到dev到ops之间就可以更好的进行关联，当然之后还离不开企业内部的标准化问题。
需要自己定业务标准，定数据标准，定义好这些标准后还得扩展到行业级别。同一级行业或者上下级衔接的行业都要互相之间定义好，有了这些标准化，整合起来还需要一些时间。
- 上述第三次提到很关键的一个词：数据。在开展包括devops相关课程时如何看待接下来的数据和我们工程实现的一个关心？
如果我们将使用生产关系生产力进行比喻，在现在全面数字化的时代，对于我们软件行业来说，devops实际上代表的是软件行业第一生产力。与此相关的数据就是生产力下的生产资料。因为所有的软件实际上都是要进行处理、输入数据然后产出数据。这些数据实际上变成了驱动各种业务的力量。以上讲述的将biz与devops进行结合，可能在biz方面需要做很多的支撑工作，如果导入bizdevops这可能是我们前期的一个目标。
devops本身已经发展了很多年，相对来说比较成熟，现在已经变成了一个我们来快速进行迭代、进行发布、进行试错的实验系统，已经使企业有了这样一个能力。以前没有devops时做不到该点，只能通过其它方式来解决业务的需求例如创新的问题。但如果我们有了这样一个系统，biz就可以利用该系统然后让它能够更快的响应市场需求，响应用户变化。这还是一个阶段，但是再往后发展，例如我们将biz放在devops前，再往后我们就可以将biz放在devops后即devopsbiz。它的立意是我们后面所有的创新实际上必须有数据支撑。现在遇到的很多问题是数据整体流通的环节比较多，决策的周期非常长。但是如果我们能够打通这个数据，那么我们就有充分的证据例如领导管理层就会更有信心的支撑我们的创新。
以上讲述的三个单词不应该放在一条线上，而是放在一个环中。我们最后在看数字化时代，如果我们加入数据生产要素后实际上产生更快甚至某种意义上以实验的精神来创造一些商业机会的。这个环节讨论的是devops运动可能还在继续，这个过程有些艰辛。特斯拉一个经典的言论：“比起造汽车来说，设计这条流水线的难度是它的一百倍”。
- 对于做平台和做工具的开发人员来讲正在做这条流水线，按照上述讨论的devops还未支撑好，现在使用bizdevops，会有什么感受？觉得平台和工具未来的走向是什么？觉得哪些是可以从bizdevops学习到的，展望bizdevops工具和平台如何做才能够将流水线做出来？
我们其实是从数据的角度来看是否可以做到商业的成功的。现在做的devops产品，本质上也是一个业务，服务的群体是一线研发工作者。在这种情况下，我们也要将它的整个数字化体系建立起来。但是事实上经过很多年的发展市面上有很多工具，大家往往真正在企业中做该事情时还是想办法再建立一个系统。
这个原因我们也在思考，发现大家在一个真正能够用的流程上能够将它做下来还是有很多要求。首先，是能够将整个数据模型建立起来的，该数据模型在各个工具中往往是不予批的。所以我们需要有一个共同的理解，保证业务说的模型与技术说的模型一致，这是一件很困难的事情。不同的人对于应用的理解不同，更不用说建立起一个数据模型将互相联系连接起来。有两方面需要努力的，一个是如何形成一个相对大家通行的规范，例如云原生逐渐有一个标准，但是devops目前还没有形成，正在形成该过程。另一个是devops的特点是将不同的人不同的角色协作起来，有没有一个统一的视角。上述也提到作为一个研发角色，或者作为测试角色经常被打扰。要与另一个人去同步一个信息或者需要询问一个信息，这件事情是非常影响工作效率的，也是数字化非常忌讳的一件事情。所以devops作为一个工具来讲如何提供多个角色作为一个统一视角，即我们现在是否可以进入一个应用视角，那么应用与协作之间工程与协作之间是否可以基于价值去连接，这是我们应该为之努力的。
以上两点中很重要的一点是，本身这个流水线就是有客户的，有多个客户。并且建立流水线时核心的逻辑不是流水线的供应而是它背后的数字模型。
从另一个角度来讲，现在也服务了很多客户。在服务客户的过程中发现，大家对devops科技部门工程师要做的事如何做是比较达成共识的。采用一个一体化的研发云平台，要走向云原生，甚至要建立流水线，建立这样一个标准模型，大家已经逐步形成共识。因为我们看到整个标准和方法实践都是在收敛的，收敛后做的工具相对来说很容易进行标准化，去适应开发者对工具的需求。这样工具就可以适配它的研发流程，大家有意愿将原来的工作模式迁移到新的方式上。在这个领域已经达成了共识，包括在金融行业，基本上都是要采购一体化的平台。但是我们进去后发现也只是相关的科技部门，对于业务部门影响力不够，但是发现只是解决这部分工程师的效率问题，其实很难改变该企业本身的业务创新性问题以及业务的交付效率问题，所以我们也在尝试与这些企业去讨论如何实现bizdevops面向业务价值或者面向业务成功的流程。但是在讨论这个流程的过程中发现大家从来没想过可能没想过通，但我们一想以后觉得确实是需要通。那么如何通？业务人员跟技术人员之间的对话的语言体系是没对齐的，甚至业务人员他本身可能团队比如说以产品为中心。为什么要以产品为中心，产品是什么？都没有提到。但一个产品下面是要建立多个交付团队，交付团队为一个产品负责他的职责流程如何去划分，其实不管是组织流程或者大家对于日志流程的概念，其实都没有形成一个共识。如果没有形成共识，那么工具上实际上很难去支撑它标准化的。所以也是大家需要思考的问题：devops如何在一些概念或者流程上能够逐步化的标准和收敛。
以上提到了很重要的一点，就是我们会看到一些比较有创新力的公司，不一定是初创公司，包括大家看到微软的起死回生，前几年就是彻底大转型。他们当时的工作方式发生了一个变化。当我们在谈这个词语的时候，很多人可能会觉得比较陌生。
- 我们稍微畅想一下，bizdevops往前看一看，如果这件事情我们推下去了，或者这件事情发生了，在工作方式上对一个组织，一个大的企业，或者我们一个团队最大的工作方式的变化是什么？
我觉得最大的工作方式的变化一个是与我们数字化转型方向的结合。首先是业务侧，当真的开始觉得数据有很大价值，然后也真的开始需要使用这个数据了，那么就需要去定义这个数据。那么从定义数据的角度来看，它原有的这种稍微模糊一点的工作方式就要变成比较精确的工作，这样才能去给数据下一个好的定义。同时，我们也都知道数据其实是模式化的，它并不只是说一个词是什么意思，它应该说的是若干个属性加在一起所描述的业务对象是什么。而且该业务对象，我们也知道根治上来讲是业务而不是技术人员。
所以从这个角度来讲，如果业务人员觉得数据有用就开始精准的去定义它，那么就会开始用数据驱动自己的业务。那么整个业务工作的流程的变化，或者说自身的创新，其实一定程度上都是来自于数据。我需要用这种方式重新看我的业务创新，业务创新并不仅仅是想个点子，写个字。而是我的业务创新本身就带着一定的数字化实现。即天然就需要业务和技术是一体的，我需要思维方式上一致。统一语言后面反应其实是思维模式，思维模式决定你的元素和方式。那从这个角度来讲业绩融合这种工作方式或者是一同创新，通过这种共同创新来更好的发现数据的价值对我业务的一个提升和变化，这应该是所有企业的一个变化。像我们说的一切业务数字化一切数字业务化，天然就带着我们bizdevops这个想法在里面。真正有一天这个数据这个生产要素被我们发挥起来了成为了每个人日常生产或者是我们工作中的一部分的时候，就自然实现了。
数据这个应用当然是我们的一个理想但是它是需要一些基础的。当我们看到在数据应用之前我们希望能看到什么东西，先从业务的角度来看，第一个它的视角会发生变化，在数字化转型下，业务的本身也存在一个条块之间的分割和墙，那么问题不能在问题本身的层面得到解决。所以必须跳出来看，只能站在将来的业务的设计或者业务的思考或者更多的是站在用户的市场，是打通整个用户需求被满足的价值链路来串通我们内部的业务流程，这是第一。那第二点在这个基础上，我们还要能够看到对于整体本质模型的深刻的认知，要建立起整个的一个数字化的模型。如果做到这两点的基础上，我们才能产生一个真正可用的数据，让可用的数据我们可以改成全量的，整个业务流程的数据都被记录，全要素就各个方面都会记录，还有实时这个数据不是候补的，而是在业务流程中就产生的全要素实时的数据。那么这个数据本身是中立的，数据产生一刻并不知道它应用场景，但是这时候我有了这些数据，那么这些数据的应用就是我们一些创新的机会。
我们业务的人员有自己的场景，还有自己的目标，自然能激发他这些数据的应用。从业务角度看，从研发的产品，研发和业务的合作，我们看到一个自身产品研发也需要数据化转型，也要站在用户的视角，这里面的用户视角就是刚才讲的即我们做一个平台，它的用户是什么？是产品的研发，我们要打通站在这个价值交付的时间来去打通产品研发和和运维。我们自己研发过程中也会产生数据，所以在这里面有一个根本的变化。首先我们要从产品研发本身实现数字化转型才能更好的支持好整个大的业务整个社会的数字化转型。
Devops在很多有一些这个组织中，科技高管会认为bizdevops本身就是科技的数字化转型，这是一部分。我们可以认为devops就是一个我们在整个企业甚至于说一个大型的机构中去数字化转型的抓手。其中有一个核心的一个矛盾点，就是我们怎么样才能改变业务的思考。科技这一侧实际上已经经历了一波，比如说之前包括敏捷在内都是一种工作方式的一个改变。
- 在业务的情况下有什么想法，畅想一下我们怎么样才能把业务的工作方式发生变化？
工作方式改变如果回顾devops的发展，最终促使他变化有两个要素。第一个是需求，从理念上去宣传。大家提出了这个需求，这个目标。第二个就是工具，不仅仅是软件平台包括方法建模方法等等，最终让这个事情变得可能。比如说我们现在在软件工程中有很多方法讲领域建模。
我们有这样的一个使命就是要真的能让减少业务和技术之间沟通的鸿沟。所以这个在于我们需要一套这样的方法，如果DPD可能要向前，要用更多的用语言去梳理我们的业务流程，然后用业务的视角去表达出来。这还需要做很多工作，例如业务的架构和技术的架构如何更智能的过渡。目前在业内有一些进展，在需求的驱动下进展会更快的发生，这是讲建模。协作上如何真正做到业务驱动去协作，例如有一个业务的需求，有一个业务的目标怎么表达怎么分解为业务的策略和需求。业务的需求又如何分解到各个产品。
分解完后，我们怎么为它提供一个在过程中还能看到它的整体的视图，当大家看到这些东西而且比较低成本的能用起来时，可能这个事情就更容易发生。
工具平台是促进它的生产工艺的一个变化，生产工具的变化会造成很多事情的变化，比如生产关系、生产力的变化，甚至一些产品的一个变化。
- 如果你有一个工具，可能别人会说我觉得不好用，你说的是错的，存在即合理，你需要适配我。遇到这个矛盾怎么处理呢？
我们回到这个问题的初心上来说，我们做工具不是为了改变你而改变你，实际上是希望通过工具来帮助你达到某个状态，或者解决某个问题，所以我们的工具是来解决问题的。当然对于具人来讲，不能对你有太多的假设，对你现在的状态是没法假设的。我必须适配你在各种情况下的状态，但是我会给你指引一条未来状态的一条路，这是我们工具要做到的事情。
所以可以从两方面来看，我们怎么去真正解决它的数字化的转型，它要利用数字化的技术来解决他商业上的成功，此时我要通过devops工具来帮助你达到这一点。这是我作为工具要解决的一点。另一方面，面对现在的现状必须有一条路径，这条路径能适配它现在当前的各种状态，而这个东西是工具不能假设的。工具一定是开放的，有实践和标准所承载的，有一定活性，但是还是需要坚守一些基本原则实践。
今天我们提供这套工具，目的其实是帮助产业团队实现自身的数字化，这个是非常明确的。不管我们讲原来devops还是今天的bizdevops，其实都是来实现数字化，只不过我们现在讲述的数字化需要覆盖业务、技术、运维、测试等整个产业链的人员工作的数字化，这是我们的目标。然后再看现在很多企业现状，有非常多工具可以使用，这存在着一个最大的问题，就是这些工具实际上并不是能够完成最终这个企业需要数字化标准的工具，就是一些单点的内容，没有完全串联起来。
今天我们讲bizdevops也是希望收敛该方法，能够收敛一些标准化的流程和实践，最终建立一个统一的流程的模型，该模型是企业数字化的根基。只要都在该流程上工作，那么产出的数据自然可以帮助企业去看清很多东西，例如每个重点业务目标的人员投入产出的效率以及它的整体过程。
例子：今天业务人员很多，遇到了非常矛盾的事情，手里有十个需求，但是另一边只有几个开发，当提一个需求不能知道另一方在做什么，所以就会导致需求不再提出。但是今天如果能够让业务人员看到所有技术的工程活动与自身业务需求的关系。就可以做两件事：一是提效率不够，建议使之提效，另一个是可以在这里提升优先级，进行一个更合理的排期。但是最重要的是能够让大家用整个数字化的方式进行探讨而不是一个个独立，所以今天我们工具平台是将bizdevops理念做定义的方法或者实现该定义的模型能够进行串联，而它具备开放能力，可以兼容原来的工具。所以说如果我们的工具在企业落地，不是将它现在所有的东西全部推翻重造，而是建立原来缺失的流程的数字化部分，做一个补充。
以上涉及到一个词改变。改变容易被抵制或者对抗。但是有一句话：人们从来抵制的不是改变，而是被改变。我们做的工具一定不是要求他改变的工具，而是帮助他去改变的工具。帮助他去改变肯定有一个我们与他形成共识的一个目标而不是直接修改行为。
现在biz与devops、业务与科技之间很重要的问题是互相看不见，都不透明，都还是一个黑盒。如果我们现在能让他们互相都看见，我们能看见业务为什么要做这件事，业务知道我们说的需求达到了什么程度，什么时候有步骤一步步在往前走，这是一个巨大的进步。之前我们提测试和开发互相看见，又提开发与运维之间互相看见，今天我们提作为科技要与业务之间看见。
之前所讨论的问题都是针对当下的问题，而对于高校，一个核心问题是解决真正意义上的认知和价值观问题。进了高校后得到第一个认知模型的建立，devops变成第一个程序去实践。知道这个理念的学生不需要工业层在再进行教学，当下需要解决的问题在在devops方面在这类大学生上是不存在的。
- 这个经验放到BizDevOps上，对于mba的学生（学经贸或者是学传统经验上的物流、甚至是学历史专业、学文科、学新闻的学生、都是需要教授这种东西），对于这个有什么经验可以进行教授使得他们认为这个理念很重要？
实际上考虑会有两拨人，一部分是业务人员，一部分是做传统IT业务的开发人员，大家使用的语言是不一样的。业务人员使用的是自然语言（中文、英文等），而开发人员尤其是编码人员使用的是编码语言，称之为是一种半形式化语言，完全形式化语言就是数学语言。虽然是半形式化语言，但也是有确定性的，把这个变量控制起来，就是把相同环境运用上一定会出来相同的结果，是有这种确定性的。但是业务人员不能够这样去描述问题，所以不一定可以描述清楚许多细节。可能就需要使用DTD的方法或者是低代码的想法，这都是从特殊角度去看待怎么帮助业务人员，可能会想办法丢失一部分细节，但一定要form这些内容，否则就会控制不住。即使做到这一点，但还是存在一定的鸿沟，它和devops两拨人还是不一样，这两拨人的语言还是一样的，可能一部分是编程语言，另一部分是脚本语言，但本质上还是半形式化的，还是可以达到一定共识的。前面的共识并不是说不能，而是有难度。
我们现在能够做的就是借鉴，借鉴devops成功的经验会有一定的工具来承载一些被固化被沉淀下来的一些最佳实践方法，将它固化到流水线上。流水线可能更容易在一个企业中更快落地。很多企业表明已经在做devops，但是实际上可能只搭建了一个工具链，真正要去实现devops，发挥出devops的能力要考虑更高的层面，在实践、过程的层面甚至于在文化的层面去解决。但如果我们考虑前面biz和devops之间鸿沟，工具肯定是不足够的，因为工具在两边的描述力度、严格程度不同。但是如果我们从文化上改变他们的一些工作方式，这肯定不是短期内可以做到的。现在我们更能够接受的一种方式就是培养这种符合型人才。
就像开发和测试人员如何进行妥协呢？即开发人员也要懂测试，提高他的能力。现在到了devops，开发人员也需要懂运维，到了bizdevops，还需要懂安全。其中让biz人员懂开发难度会更大，所以现在过渡期的一个方式就是培养符合性人才。符合性相对于学生是在做加法，而减法是一些标准的模型、工具平台，（以前是手动的，现在变成自动的），因为还需要考虑做减法，对于学生一直做加法，原来只学一门语言java即可，现在不仅要学习java，还需要学习函数式编程，还要学习脚本化部署的脚本，还要学习部署的运维运营策略。符合性也带来一个痛苦即需要学习的知识很多。但是现在这个专业的学生，他们的层级是越来越往上的，例如在90年代开发一个程序是从头开始编写，但是现在学生会直接使用一些框架，所以层次已经变高。
以上都说到可视化模块，实际上bizdevops也涉及到业务层下沉到平台上，技术层以服务的方式下沉到平台上，这两处东西可见并且可处合，这就是我们说的下沉，这样能够让业务人员腾出精力。业务人员往前走一步走到结构化的程度走到dev的程度一定要经过很多学习。业务虽然偏自然语言，有不确定性和描述方式，但是我们可以提供一些方式去半结构化。
某种意义上devops运动的兴起也是行业中的一致性认可，我们要做这件事情要抱着乐观的态度。
- 现在谈到细节，有很多困难，但是如果忽视这些困难，我们的机会点在哪里？展望如果我们突破它，未来会是一番什么景象？
最大的机会点还是在于需求本身。需求越来越迫切，在构建一个数字化的社会，数字化的商业生态，这一点对于我们的bizdevops融合要求是非常大的，一定会有一部分业务人员朝开发走的更远，而开发人员当devops解决了一系列工程问题后腾出手来也有自己的优势：形式化表达和结构化表达和抽象化表达、抽象分析的一些优势，一定可以给业务带来很多可能性。
现在国家很感兴趣的话题是如何做创新，上一次万众创新，创新创业后，我们现在相对于处于一个创新创业的低谷期，如何再次激活也是一个新契机。创新也是一个高质量发展，高质量发展也需要工具支撑。
作为研发人员或者业务人员，我们希望不会再被质疑业务导向还是产品导向。
大家都为业务来扶服务，都在为同一目标努力，此时肯定会产生一些变化。例如我们的运维监控和运营监控将来可能成为一个技术，只是用不同的场景、不同的语句和方法模式。可以畅想到那时，我们的业务人员靠近研发和研发人员靠近业务都会变成一个非常自然的事情。例如现在测试和研发的界限越来越模糊，所以此时对于大家职业上会有一些变化，甚至可以认为在开发语言、技术的一些底层设施上都会产生一些新内容。例如会为了偏向业务角色产生一些特殊的编程语言与研发更好的进行描述，就像云原生时代发生的事情一样，以上是可以畅想的一些。
云原生从某种意义上讲是开发和运维综合的产物。随着交叉越来越多，放到业务和科技也会产生像云原生这类东西。
随着业务与技术将来的转换变得容易，从业务需求过渡到开发设计之间也有可能变得更加容易。
无论使用哪种方式例如DTD等，业务还是业务，无论使用什么方式进行分析，业务都不会发生变化，所以我们要考虑是否有更自然的方式进行过渡，例如业务人员比较习惯分析自己的业务方式稍微结构化变成一种自然语言进行过渡。类似之前讲到的流程模型与数字模型之间的结合。当业务人员将行为加数据理解，那么两边就可以清楚。当业务层用这种方式进行过渡，从业务到技术变得更加自然时，其实还有一些问题，一个人员的职业发展方向其实可以有比较大的空间进行选择，那么如果bizdevops方式和可视化做起来后，一个人就更容易了解一个企业的全貌或者了解一个业务的全貌。知道每个不同的角色在做什么，自己可以往哪个方向选择。
包括我们现在的模型方式，将数字化的转型或者企业要做的战略架构、技术业务进行转变与每个人需要的业务能力进行结合，也是帮传统企业的hr以及每个人看清数字化转型中有哪些部分，哪些部分中都有什么样的技能，如果从这部分到另一个部分，技能要做什么调整。bizdevops往下发展，可能将其中一些业务处理的内容开发处理的内容都暴露出来，让大家可以在一个体系下看清技能之间的联系和技能之间的变迁，这样对于个人的成长也会更好。这与传统的培养人才方式之间会有一些变化和新的创新。
最近一两年可以明显感受到一个趋势，在软件行业中对整个公司的技术要求、产品要求以及业务的选择以及对于业务敏感度的要求是越来越高的。这与大家感受到的例如现在普遍在做降本增效或者高质量发展都是有衔接的。
实际上以软件团队来讲，要想往前走，必须建立产研数字化的整个链路，必须将每一个对于业务需求的传导、对业务资源的投资要更加精确化，并且对于整个产研的过程需要全链路来看，来优化效率。原来的粗放型管理堆积资本的模式已经不可取，这是一个外在需求，大家都感受到了压力。包括现在金融行业在面临的数字化转模也是有类似的背景，大家都要提升相关的效率，该背景下未来会越强烈。
另一个可能会发生的改变是企业内部会有人员积极拥抱这种变化，愿意接受这些新的方法，用一种半结构化的语言描述这种需求，能够希望快速的传到开发，让自己这种创新快速上市。
这一部分人会在企业中脱颖而出，会成为新型的符合型人才，关键也在于业务人员能否与技术人员真正紧密的衔接配合在一起。例如一个人在上海做社区团购，可以将一些互联网方法技术方法融入进去，数倍提升小区的团购效率，这是一个典型兼顾biz和devops的角色。这是一个非常小的例子但是在未来很有可能企业会有这部分人冒出，在企业中得到很好的发展。
该课程跨专业跨领域需要符合性人才，但是我们能够看到现在devops发展，畅想未来bizdevops，devops现在让我们看到例如云原生产品和系统越来越趋中心化，以微服务为主它的数字化从2022年开始90%的新的应用都会使用微服务，即趋中心化肯定是一个大的趋势，如果不做趋中心化，那么就没有办法进行devops。但是在这种情况下，我们做趋中心化时会围绕每一个业务或者服务来组织资源，有这种小的而自制的但是能够拉通的全功能的团队才能够好好发挥微服务的充分效能。
再推论到bizdevops，这个链路我们还需要再进一步拉伸到业务层，让业务人员与开发运维人员能够紧密的工作。但是这样一个需求不能在短期内很快满足。现在畅想的是bizdevops，那么下一步能够做到了可能会有业务之外的组织上的一些其他的方式可能会成为最大的瓶颈。如果我们做到了bizdevops，那么原有的预算就可能需要改掉，或者说决策的过程战略都需要做相应的调整。但是如果我们认可这样假设，现在在做数字化，未来都会是软件的企业，都会开展业务和其他的部门对接。
无论我们现在做不做，这个趋势都会发生，未来企业都要根据bizdevops进行企业转型，其他部门也要进行这样一个变革，这个结果其实就是一个逆康威定律，可以不做，可以抵制，但是其他企业做后就会有竞争。
未来微服务的团队就是业务天然和bizdevops一体化的，整个公司的组织结构也变成了一个微服务架构。
我们相信它能够真正意义上产生一些不一样的变化，也相信这一次的变革有与上一次devops变革的契机能够影响我们的产业甚至影响整个数字化时代。只有我们形成生态的时候这件事情才能发生。
