企業IT如此複雜的原因 - architectelevator
企業的IT部門被很多事情困擾著,但過度的複雜性一定是在名單的首位。任何試圖描述平均IT景觀的努力,最終都會在應用、硬體和相互依存關係中變成無法解讀的義大利麵條。這幾乎就像企業IT受到熱力學第二定律的制約,該定律的結論是一個(孤立的)系統中的熵永遠不會減少--在最好的情況下它可能是恆定的,但通常它是增加的。
請繼續閱讀關於這種複雜性起源的一些想法,以及另一條定律,不是關於熱力學,而是關於複雜性。
複雜性的代價
過度的IT複雜性導致了一些嚴重的問題。
- 它提高了成本,因為管理更多的部分需要更多的努力,通常也需要更多的專業技能,而這些技能的價格更高。
- 它降低了可靠性。複雜的、高度相互依賴的系統往往有很難理解的故障狀態和大的故障域:很難知道什麼會出錯;如果真的出了問題,也很難知道實際發生了什麼;如果一個部件壞了,問題就會以多米諾骨牌效應的方式連帶出現。總之,複雜性導致了更短的故障間隔時間(MTBF)和更長的恢復時間(MTTR),這兩種情況都降低了系統的可用性。
- 它促使脆弱性增加。簡單的系統通常比複雜的系統更安全,因為複雜的環境更有可能存在一個薄弱環節,例如,一個沒有打補丁的系統或一個隱藏在某個早已被遺忘的系統元件中的預設密碼。
- 瞭解到現代IT的大部分都是由安全、正常執行時間和成本驅動的,複雜性絕對是IT的頭號公敵,因為它損害了所有這三個因素。
與複雜度共存
意識到複雜性帶來的嚴重損害,我們應該期望IT經理和決策者用他們所有的精力來對抗它。但奇怪的是,很多時候他們似乎不願意接受這樣一個事實,即複雜性是企業IT生活中的一個事實,如果你願意的話,是某種因果關係。不過,在大多數情況下,我們發現複雜性的存在並不是因為CIO不努力。而是因為CIO周圍的大多數人都沒有什麼真正的動力來讓它消失。
供應商
大多數企業都正確地遵循了 "購買大於建設 "的方法,這意味著他們執行的大部分軟體和硬體都是從企業供應商那裡購買的,而不是在內部建立的。這種企業軟體並不便宜--許多IT組織將其預算的1/3用於許可證。不過,軟體供應商在幾個方面從複雜性中獲益。
他們傾向於用長長的功能清單來競爭,這增加了產品的複雜性。這並不完全是他們的錯,因為他們知道,IT組織透過功能的存在給競爭的解決方案打分,即使使用者實際上可能永遠不會使用它們(這是另一個禁用迴圈的好例子)。
不足為奇的是,成功的供應商都很擅長銷售。"你已經有了一個應用效能管理框架?我們的更好,而且能與你現有的解決方案整合!" 企業的複雜性在很大程度上源於針對同一問題的多種產品。
供應商也在產品策略上創造了複雜性。如果市場營銷部門在6個月內沒有創造出一個新的流行語或定位一個新的和改進的解決方案,銷售管道就會有風險。
最後,硬體供應商從複雜性中獲益,因為他們可以用更多的硬體來解決許多問題,而不是對軟體解決方案進行合理化或簡化。
系統整合商
需要建立的軟體或購買的軟體的整合通常由系統整合商(SI)完成。他們發揮著重要的作用,因為他們提供了內部IT部門可能不具備或不符合要求的專業技能組合。系統整合商一般不銷售產品。他們賣的是一種服務,由顧問提供。雖然可能被包裝成各種協議,但在一天結束時,這些顧問按小時計費,因為員工小時是諮詢經濟學的基本單位。
一般來說,更多的複雜性意味著更多的工作,從而意味著更多的收入。這不一定是故意的或狡猾的--自我保護是馬斯洛需求層次理論的基礎。
顧問
系統整合商SI是企業的幫手,而顧問則是被僱傭的大腦。他們解決複雜的問題,制定IT戰略。但他們也想繼續受僱,所以他們可能幾乎完全解決一個問題,只留下足夠多的工作來完成。在這裡,自我保護同樣佔據主導地位。在顧問的術語中,這被稱為範圍界定或期望管理。
IT人員
但並不是所有的手指都應該指向組織之外--恰恰相反。內部的IT人員喜歡複雜性。在太多的組織中,擁有更多預算和更多活動部件的人仍然被認為更重要。具有諷刺意味的是,複雜性是事業的助推器。
這也是一種自我激勵。許多IT經理喜歡讓你知道他們的操作有多複雜(讀作複雜)--消耗大量的硬體給人以吹噓的權利。"一個大男人(人),一個大IT基礎設施"。也許他們正在尋找一點讚賞。IT是一個艱難的工作,所以想讓人們知道它到底有多難,是可以理解的。
最後,內部藩籬會導致重複工作--這是一條通往不必要的複雜性的捷徑。
管理複雜性
目前的技術發展速度一直在增加新的移動部件,而CIO周圍有太多的人對一點點的複雜性感到很滿意。如何處理這個問題可能足夠寫另一篇文章了,但為了避免典型的懸念,這裡有幾個我見過的有效建議。
透明度。複雜性如果不為人所知,就會變得加倍糟糕。獲得整個IT產業的透明度是控制複雜性的第一個關鍵步驟。
架構。正確的架構可以開發出隱藏不相關複雜性的模型和抽象,使我們能夠做出更好的決定。畢竟,你無法管理你無法理解的東西。
標準。介面標準使多樣性本地化並減少複雜性。
不要把思維外包出去。把你的IT控制在公司內部,根據你的計劃匹配供應商的產品,而不是反過來。
格雷戈爾定律--做出決定
不過,並非所有的複雜性都是由外部各方造成的。有些完全是自己造成的。其中一個關鍵的罪魁禍首是一個組織沒有能力做出有意義的決定:一切都必須是多平臺、多雲、可移植、與傳統系統整合,併為所有可能的選擇進行定製,以防萬一。這個主要的陷阱把我們引向了最後的洞察力。
格雷戈爾定律:過度的複雜性是大自然對無法做出決定的組織的懲罰。
複雜性不會消失,但你可以做很多事情來減少和管理它。而且,如果你這樣做,你會發現IT變得更加有趣。
相關文章
- 今天的IT如此複雜,其背後原因是什麼?
- Kubernetes為何如此複雜?
- 系統困境與軟體複雜度,為什麼我們的系統會如此複雜複雜度
- Android開發 - 掌握ConstraintLayout(十一)複雜動畫!如此簡單!AndroidAI動畫
- 當數字化遇到轉型為什麼會變得如此複雜
- DDD之理解複雜度、尊重複雜度、掌控複雜度複雜度
- 複雜度分析的套路及常見的複雜度複雜度
- 企業部署實施CRM的四個原因
- 企業需要CRM系統的幾點原因
- 現代電信企業:極低延遲與複雜決策如何兼得?
- 檔案型別多又複雜難以管理,使用Yotta企業雲盤型別
- 複雜連結串列的複製
- 全球各城市、企業、園區的數字需求呈現出複雜、多元的樣貌。
- 業務複雜度不夠,如何深挖複雜度
- 企業需要六西格瑪的原因有哪些?
- 方案分享:F5機器人防禦助企業應對複雜攻擊機器人
- 企業的雲遷移的原因與注意要點
- 如何減小ABAP業務程式碼的複雜度複雜度
- 降低程式碼的圈複雜度——複雜程式碼的解決之道複雜度
- InnoDB併發如此高,原因竟然在這?
- 時間複雜度跟空間複雜度時間複雜度
- 複雜性Complex與複雜Complicated區別 - Sonja
- 時間複雜度與空間複雜度時間複雜度
- 時間複雜度和空間複雜度時間複雜度
- 密碼的複雜化密碼
- 複雜背景的缺陷提取
- 企業展廳推行數字化建設的原因
- 害怕軟體的複雜嗎?其實複雜性是必須存在的 - ferd
- 企業需要專業電子郵件地址的4大原因
- 複雜度分析複雜度
- 為什麼React Native如此受歡迎的7個原因React Native
- 一個複雜的json例子JSON
- JAVA 解析複雜的json字串JavaJSON字串
- JPA的多表複雜查詢
- 展示BPMN複雜流程的案例
- Istio的複雜性揭祕
- 時間複雜度O(n)和空間複雜度時間複雜度
- Kubernetes 複雜嗎?可以不復雜