敏捷DevOps是反康威定律? - rna
是業務決定技術?還是技術決定業務?是人決定IT,還是IT決定人?這是康威定律與敏捷的區別:
一位叫Melvin Conway學者進行了社會學觀察:組織中IT 解決方案的結構遵循組織結構。弗雷德裡克·布魯克斯(Frederick Brooks)在他的開創性著作《人月神話》中將其命名為康威定律,而這個名字就一直存在。我認為康威定律——以及它正在發生的事情——表明我們的“資訊革命”正在經歷一個轉折點。
康威定律是指IT方案遵從組織中結構,也就是技術服從於人,也就是說“業務需求導致業務結構導致 IT結構”,由於人的適應性很強,我們越來越多地看到相反來的情況:“業務需求導致IT結構導致業務結構”。
這就是流行語“數字化企業”或“數字化轉型”所代表的意思:是我們(靈活的)人類適應世界上的大量(不靈活的)脆弱機器邏輯,IT不是適應我們人類願望,而是我們人類適應使用IT 需求。
我們越來越多地將自己組織成敏捷/DevOps 團隊,圍繞 IT 解決方案與“產品負責人”。我們將各種產品團隊組合成稱為“價值流”的組織實體(例如,在稱為 SAFe 的領先敏捷方法中)。換句話說,這不是康威定律提倡的讓 IT 解決方案反映組,而是迫使人的組織結構服從與反映 IT 結構。
邏輯的脆弱
邏輯儘管有其所有優點,但有一個主要的致命弱點:它是脆弱的。邏輯對正確的輸入極其敏感。我們人類可以很好地使用估計和近似值的地方,但是邏輯機器不能。一個小錯誤導致整個事情可能無法正常工作,甚至可能崩潰。
所有這些脆弱部分之間的依賴關係的複雜性超出了我們人類的處理能力。最重要的是,雖然我們是地球上所有物種中最好的邏輯學家,但我們人類的邏輯實際上很糟糕。我們創造了這種邏輯,但我們無法預見每一種組合,我們會犯錯誤。其中很多。
那麼,鑑於(機器)邏輯的脆弱性已經存在了一段時間,我們通常會做什麼來管理使用邏輯的問題?
我們新增更多邏輯!
例如:
- 我們新增了各種抽象:物件導向、面向服務的架構、框架、虛擬機器而不僅僅是物理機;
- 我們新增了更多相同的內容:例如,我們在“負載平衡器”後面建立了相同硬體的高可用性叢集,以應對單個伺服器的故障;
- 我們新增了額外的邏輯行為:輸入/狀態檢查程式碼、備份、監控、事件管理、更改期間的測試、分析,列表不斷。
換句話說:為了解決擁有大量互連的脆弱邏輯的麻煩影響,我們新增了更多(互連的、脆弱的)邏輯。當然,它本身具有額外的脆性。這裡有死衚衕的味道。
在“數字企業”中,所有機器邏輯中只有一小部分最終與“支付養老金”或“賣書”等主要功能有關。其中大部分是關於 (a) 防止整個邏輯大廈以某種方式分崩離析或倒塌,以及 (b) 保持能夠改變它。
掌控之中?
世界上脆弱的機器邏輯的數量激增。相互依存的邏輯行為的整個世界對於我們人類來說太複雜了,無法完全控制它。多年來,我們已經看到越來越大的自上而下的瀑布式方法來“改變”數字環境,但這種方法現在正在消亡。
相反,我們看到的是解決問題的自下而上的方法,例如敏捷/DevOps。這並不是全新的。軟體工程方法,例如物件導向(它應該在 1980 年代在應用程式級別為我們解決相同的問題)或面向服務的架構(它應該在應用程式級別為我們解決相同的問題1990 年代)長期以來一直表現出自下而上抽象的趨勢,作為處理相互關聯的脆弱複雜性的一種方式。
而現在,這些軟體工程誕生的、自下而上的方法已經到達觸及了人類組織的水平。IT——機器邏輯——的數量變得如此之大,所有這些相互關聯的脆弱性的慣性(“改變的阻力”)變得如此之大,以至於我們人類已經開始適應邏輯而不是試圖讓邏輯適應我們。畢竟,我們是具有靈活和穩健行為的人。
舉個例子:我們越來越多地將自己組織成敏捷/DevOps 團隊,圍繞 IT 解決方案與“產品負責人”。然後,我們將各種產品團隊組合成稱為“價值流”的組織實體(例如,在稱為 SAFe 的領先敏捷方法中)。換句話說,不是讓 IT 解決方案反映組織(康威定律),而是讓人的組織反映與服從於 IT 結構。
因此,過去是“業務目的導致業務結構導致 IT 結構”,但我們越來越多地看到“業務目的導致 IT 結構導致業務結構”,這就是“逆康威定律”。
接下來是什麼?
我們顯然還沒有適應的是:新的“邏輯行為的首要地位”對我們的社會結構的影響。就像工業革命最終催生了遏制其過度行為的政治運動一樣,資訊革命仍然需要發生類似的事情。
三個問題在我的腦海中。
- (1):在我們採取行動之前,過度(已經可見)會變得多糟糕?
- (2):鑑於我們人類的侷限性,我們是否能夠(明智地)採取行動?以及
- (3):在過度行為導致或導致無法彌補的損害之前,是否有足夠的時間來遏制過度行為?
相關文章
- 如何應對反向康威定律?- RomainAI
- 敏捷和DevOps:是敵是友?敏捷dev
- 敏捷與 DevOps:是敵是友?敏捷dev
- 康威定律的各種解讀 - ThinkingLabsThinking
- 微服務拆分到什麼粒度合適——康威定律微服務
- 每個架構師都應該研究下康威定律架構
- 結構優於制度,軟體開發中的康威定律
- DevOps與敏捷異同 - DZone DevOpsdev敏捷
- 使用DevOps強化敏捷(上)dev敏捷
- DevOps落地實踐,BAT系列,敏捷看板devBAT敏捷
- 什麼是Little定律(littles law)
- Devops與敏捷二者能否結合?dev敏捷
- 從敏捷開發到DevOps,殊途亦同歸敏捷dev
- Devops-01-devops 是什麼?dev
- 【敏捷研發系列】前端DevOps流水線實踐敏捷前端dev
- 敏捷是什麼?敏捷
- 華為敏捷DevOps實踐:產品經理如何開好敏捷回顧會議敏捷dev
- 華為敏捷 DevOps 實踐:產品經理如何開好敏捷回顧會議敏捷dev
- 【Azure DevOps系列】什麼是Azure DevOpsdev
- 什麼是 DevOpsdev
- 什麼是DevOps?dev
- Rosalind-002:DNA轉錄為RNA(Transcribing DNA into RNA)ROS
- 海康威視
- 康威生命遊戲遊戲
- 華為敏捷/DevOps實踐:如何開好站立會議敏捷dev
- 華為敏捷DevOps實踐:如何開好站立會議敏捷dev
- 神馬是敏捷?(4)——敏捷不能當飯吃敏捷
- UP還是敏捷方法?敏捷
- RUP是敏捷的嗎?敏捷
- 一款可以連結DevOps的敏捷開發工具dev敏捷
- DevOps|研發提效-敏捷開發之每日站立會dev敏捷
- 什麼是量子計算的內文定律?
- 設計模式是在運用構造定律設計模式
- 什麼是敏捷估計?敏捷
- 敏捷測試是什麼?敏捷測試
- circBase:環狀RNA資料庫資料庫
- 用敏捷的DevOps拳打研發低效、腳踢管控不足敏捷dev
- 華為精益敏捷專家:DevOps轉型中的那些坑敏捷dev