數字經濟時代，數字化轉型成為社會的普遍共識和行動，越來越多的業務運行在數字化基座之上，軟體系統正成為業務創新的價值核心和創新引擎，在這一趨勢下，軟體產業面臨著許多新挑戰和新機遇：一方面，萬物互聯下軟體系統規模和復雜度持續增長；而另一方面，業務的快速變化對軟體交付效能的要求卻不斷提升；軟體構建和交付方式亟待變革，
要解決問題，先直面問題，為更好地厘清波濤洶涌的數字化轉型浪潮下軟體產業所面對的機遇與挑戰，6月29日，阿里云云效與阿里云開發者評測局欄目，聯合特邀了InfoQ極客幫副總裁付曉巖、南京大學軟體工程學院教授張賀、Thoughtworks全球數字化轉型負責人肖然、國內精益產品開發最早實踐者何勉（阿里云云效解決方案負責人），阿里云資深技術專家陳鑫（云效平臺負責人）以及阿里云高級產品專家張裕（云效平臺產品架構師）共6位領軍人物，一起圍繞數字化轉型浪潮下的技術變局進行了深度的研討，
數字環境下，各界如何看待科技發展與業技融合？
當前，央行側重提升產業的整體數字化，同時還提出了更高的要求：希望業務系統或者業務創新能夠實作跨角色、跨流程的自由編排和組合，這個要求即便對互聯網企業來說都非常高，銀行業等傳統企業如果想通過企業級的工程，來整體提升業務和技術能力、實作業務和技術的融合，更是一件困難的事情，所以，需要一些新的方法論或工具來支撐，
今年年初，中國銀保監會與人民銀行發布的《關于銀行業保險業數字化轉型的指導意見》已經明確指出，在數字化時代要做到“業技融合”，同時BizDevOps這個詞也已經被寫入央行《金融科技發展規劃（2022-2025年）》中，這兩份檔案已經為銀行的數字化轉型提出了具體的要求和方法，變成了行業轉型的參照，
金融行業天然走在數字化的前沿，已經享受到了數字化的紅利，但是，還有很多產業和行業仍面臨挑戰，比如，生產線的出現可以讓企業既得到質量又得到了效率，但一定程度上犧牲了體驗，而數字化天然可以解決這個問題，如果用戶需求的獲取、還原、設計、生產、交付和服務等環節有數字化的支撐，就有可能在整個環節里滿足用戶的個性化體驗，
我們已經看到，很多企業通過數字化技術打造獨特的體驗，創造差異化價值，物體經濟正在逐漸向資訊化的世界遷移，未來，所有的物體經濟都要做數字化，甚至未來所有的企業都會成為軟體企業，未來任何業務想要有競爭力，都必須運行在數字化基座之上，
那么，數字化的引擎是什么？是軟體，軟體的燃料是什么？是資料，
因此，整個數字化轉型浪潮對軟體開發提出了非常高的要求，如何端到端、全鏈路地去看而不是只看單個階段或者單個產品？如何建立最本質的模型，從物理世界過度到數字世界，并反過來影響物理世界？如何構建順暢高效精準的交付模式？這些問題都變得非常重要，
作為一個大的數字經濟體，阿里巴巴在業務與技術融合的發展程序中也經歷了三個階段，
- 第一階段，向技術要效能，那時候，企業面對的是如何將技術自動化，實作技術本身的提效；
- 第二階段，不僅向技術要效能，還要考慮技術如何更加高效地去支撐業務，于是，中臺的概念被提了出來；
- 第三階段，也就是這兩年，阿里希望頂層戰略可以順利傳達到業務和技術團隊，特別在意業務和技術的協同，開始討論如何通過方法和工具，將技術和業務的協同形成標準化的實踐，
開發工具本身是為了幫助一線同學提升幸福感和效率，作為開發者，關心的是如何能夠專注而高效地作業、高效開發和測驗，但更重要的是，保證自己做的是正確的事，
現在有一個趨勢：做底層研發的越來越少，軟體研發的方式和習慣在發生變化，
現在，開發做的不再是一個通用工具，而是要隨著業務不斷演化，
為什么一定要從DevOps走向BizDevOps？
如上文所述，作為加快金融服務智慧再造的重要組成部分，BizDevOps成為重塑智能高效的服務流程的核心能力組成，但BizDevOps也不是另起爐灶，而是DevOps的自然擴展，從打破IT內部的墻，到打破IT與業務的墻，
DevOps于2009年被提出，主要是為了打破Dev與Ops的墻，當時的墻還是比較明顯的，Dev關注的是快，物件是代碼，Ops關注的是穩，物件是機器，兩者目標天然有矛盾，部門墻由此建立起來，這當然不利于IT 價值的最大化，
2009 年，在美國舉行的第二屆Velocity大會上，來自Flickr 公司的John Allspaw和Pauk Hammond發表了一個演講《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》，在這個演講中，Allspaw和Hammond以角色扮演的方式，生動地表現了開發與運維之間的各種沖突，演講中出現很多金句，如“It's not my code, it's your machines!”，這深刻反映了Dev和Ops關系的現狀，接著，他們又展示了開發團隊（Dev和運維團隊（Ops如何通力合作，借助工具消除雙方間的壁壘，
這次演講是DevOps發展歷程中的標志性事件，它提出了正確的問題：為了更快交付和實作價值，必須彌合開發和運維之間的鴻溝，并給出了解決方案：為了彌合開發和運維之間的鴻溝，需要在文化、工具和實踐方面的系列變革，
而在今天的大環境下，我們面臨著一個新的問題：如何打通業務（Biz）與開發運維（DevOps）之間的墻，以更好地應對數字經濟下的挑戰，
仍以阿里為例，今天阿里的中臺也面臨兩個問題，第一個是協同問題，阿里中臺本身是一個大部門，大的業務線和小的業務線從前臺傳遞到中臺有優先級，但大家都覺得自己很重要，這就是一個典型的大型企業協同問題，第二個問題就是如何不讓技術、中臺本身成為瓶頸，阿里希望業務可以自己去做技術，這樣有價值的想法和創新可以得到最快的回應，
“你們團隊是業務主導還是產品主導？”技術人都不希望被當作資源去做事，而是希望可以和業務合作以達到業務成功，其實，業務和技術應該是共生合作的關系，
在零售和金融行業，這種關系比較明顯，比如銀行的業務占絕大多數，大概有90%，如果有業務研發一體化的系統，技術可以滿足更多的業務訴求，那么業務就能更快地完成作業，
如何落地 BizDevOps？
DevOps運動還沒結束，仍在繼續發展，DevOps運動有很多可以給BizDevOps借鑒的地方，
首先，是在目標上進行統一，DevOps為了統一目標，借鑒了精益管理、敏捷管理、看板等作業方法，打通了整個DevOps流程，產生了非常好的對于管理方法的驅動，其次，DevOps在開發和運維之間找到了共同點，大家關注的是應用，以應用為中心去做開發，演變成了阿里和微軟的OAM模型，因此，既要有理念和方法上的改變，還要用技術手段來解決問題，這是我們需要從DevOps運動中學習和借鑒的，
那么，業務和技術的共同目標是什么？在流程中有什么共同關注的東西？共同的目標、共同的關注點，有效的技識訓者工程實踐，是BizDevOps落地的關鍵，
首先，要把業務、DevOps統一起來，統一語言非常重要，業務和技術有墻是正常的，因為業務間本身可能就有割裂，以銀行為例，每個部門畫圖的標準不一，統一業務的語言就有難度，業務之間先統一語言，然后和IT用統一的語言溝通，然后統一資料和業務，從基礎語法到長期熟練地使用語法，制定業務標準、資料標準，行業上下游企業定義好標準，這個程序的整合需要時間，
對于軟體行業來說，DevOps代表第一生產力，資料代表軟體下的生產資料，DevOps發展多年，相對來說已經很成熟，因此成為快速迭代、試錯的實驗系統，在已經有這套系統的情況下，Biz就更應該好好利用這個系統，
現在，可以把Biz放在DevOps前面，后續也可以把Biz放在DevOps后面，這意味著業務不是拍腦袋做的，而是有資料驗證的，Biz、Dev、Ops這三個單詞不應該是在一條線上，而應該是一個環，加入資料這個生產要素之后，我們可以用實驗精神來創造一些商業機會，
當前能做的是，借鑒DevOps的經驗，有一定的工具來承載最佳實踐和方法，固化到流水線上幫助落地，
有的企業搭了一下就覺得自己在做DevOps實踐了，其實我們還是要有更高的追求，從文化上解決和改變作業方式，短期內是無法做到的，更加合理的方式是去培養復合型人才，DevOps讓開發要懂測驗，DevSecOps讓開發要懂安全，Biz加進來以后，開發人員也要懂業務，事情沒辦法一步到位，也許在過渡期中，一個比較好的方式就是產學研聯合去培養復合型的人才，
最后仍然要強調一下，BizDevOps最大的機會點還是在需求本身，在構建數字化的生態本身，
BizDevOps的產品應該如何打造？
特斯拉的Elon Musk曾說 ，“比起造汽車來說，設計這條流水線的難度是它的100倍，”那么，如何做才能把BizDevOps的流水線做出來？
阿里云云效平臺負責人陳鑫提到，在服務眾多云效客戶的程序中發現，科技部門對于DevOps比較有共識，同時也欣然接受，例如大家都會理解一體化研發運維平臺、走向云原生這樣的一些概念和說法，DevOps的標準和方法實踐都在逐步收斂以適配開發者需求，
但是，業務部門還完全沒有達成這種共識，現狀是只解決技術部門的效率問題，很難改變業務的創新效率問題，如果有一個工具可以讓業務看到工程活動和業務之間的關系，那么業務部門就可以作出判斷和行動，很多企業有非常多的工具可以用，但沒有可以實作數字化目標的工具，
打造BizDevOps工具有很多難點，比如目前市面上有很多DevOps工具，但企業還是會再造一個工具，為什么？因為各個工具的資料模型并不一致，因此要想打造一個BizDevOps平臺，首先要保證資料一致，大家對一些最基礎概念的認知要拉齊，當前不同的人對于“應用”的定義和理解都是不一樣的，如何能形成通用規范？
另外，DevOps需要不同的人協作，BizDevOps作為一個工具或者平臺，如何讓多個角色有統一的視角，避免互相傳遞各自視角的資訊導致低效，也是非常關鍵的，此外，工具不是為了改變而改變，工具是用來解決問題的，工具本身不能對用戶的狀態進行假設，必須適配用戶在各種條件下的狀態，而研發自身也需要做數字化轉型，研發程序中也會產生資料，產品研發本身實作數字化轉型，才能更好地支撐更大的數字化轉型，
整體來說，BizDevOps在概念、流程、方法上如何標準化，需要業內一起努力，共同推動在產品上的落地，
如果BizDevOps真得發生，未來會如何？
BizDevOps對業務的創新速度和有效性會產生很大的作用，資料會變成基本常識，業務和開發之間的分別也會模糊起來，一定會有部分業務人員愿意往開發上靠近，開發人員抽象分析問題的優勢也會給業務人員帶來很多的價值，
將來的業務更多是從用戶的視角去打通鏈路，建立本質的認知和數字化模型，一切業務資料化，一切資料業務化，業務能夠以更自然的方式向研發過渡，一個人的職業發展方向也可以有比較大的選擇，人才培養上也會有一些變化和創新，
如果BizDevOps真的發生了，可能業務之外的組織上的各個function會成為最大瓶頸，其他BU的決策程序可能都要做相應的調整，未來，企業肯定要跟著BizDevOps做轉型，
下一步，我們怎么做？
經過深度研討，產學研6位專家在時代挑戰與機遇、BizDevOps重要性與必要性、落地方法與方式上達成了共識，他們希望圍繞BizDevOps的探討不僅僅停留在這個層面，而是可以繼續從產學研界的共同努力著手，推動BizDevOps真正發生，為軟體產業的變革貢獻力量，
因此圓桌會后，6位老師共同起草了一份《BizDevOps行動倡議書》并聯名簽署，這意味著接下來，產業、學術、研究等各方將進行長期的協作和努力，共同推動軟體構建與交付方式的變革，
《BizDevOps行動倡議書》掃描件首頁
《BizDevOps行動倡議書》掃描件尾頁
如果這篇文章對您或者團隊有啟發，歡迎轉發給更多人，點擊下方鏈接觀看《BizDevOps：數字化轉型浪潮下技術破局之路》直播回放，也歡迎加入 BizDevOps 交流釘釘群，群號：44686237，
直播回放地址：https://developer.aliyun.com/live/249329
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/498928.html
標籤：其他