你是創新的阻礙嗎？
關鍵要點
- 文化決定了風險規避和變革阻力。
- 不應該基於是否有助於抓住現有市場而做出決定，而應該要關注下一步可能出現的情況。
- 抓住從失敗中吸取教訓的機會。努力分擔責任，設定切合實際的期望，並履行現有承諾。
- 降低單個失敗導致整個行動崩潰的風險。
- 在內部培養一種以服務為中心的精神。
我們的行業時刻在發生變化。但是改變很難的——特別是當你已經建立了一套強大的已經可以滿足客戶需求和業務目標的工具和系統。隨著企業尋求進入新市場或滿足客戶新目標的機會，現有的架構將面臨嚴峻的考驗。“當我們採用N層方法時，就等於是採用了一種靈活的架構。SOA被認為是能夠為我們帶來更大靈活性的架構。我們怎麼知道採用微服務不會讓我們在未來五年內回退到原來的狀態？”
在商業領域，特別是在當今快節奏且越來越依賴科技的世界中，關於這一主題存在很多指責和嘈雜的聲音。一般的診斷是“老衛兵”，特別是在IT領域，變革很難。我參加過無數次會議，每當有人意識到讓IT團隊參與進來需要付出多大努力時，成功的好主意和潛在方法就會被迅速否決。
傳統的IT團隊掌握了現有系統的大部分知識，這給了他們大量應得的尊重和權威。但如果IT不擁抱變化，這種情況就不會發生。這對創新來說是一個不可逾越的障礙。
根據我的經驗，最好的IT人員善於規避風險和抵制變化，因為他們的首要任務是保持一切正常運轉。因為技術發展十分迅速，很多IT團隊發現自己被快速變化所驅使，而過度謹慎可能是反身的。擁抱變革並保持運轉的能力在很大程度上取決於所服務機構的性質。很多IT團隊都被上層管理人員反覆無常的想法所淹沒，管理層希望他們不僅能夠掌握市場上幾乎所有技術的專家級知識，而且無論發生什麼，都能保持資料流動。如果沒有坐在角落裡的憔悴的運維人員，沒有一個技術供應商會議會是完整的。
組織就像船隻——較小的組織可以更靈活，並且可以根據需要快速改變路線而不會有太多麻煩。較大的組織像遊輪一樣，無法靈活轉向。他們需要相當多的精力和計劃來進行徹底的改變。這一切都是關於動量守恆和水的摩擦力。以極快的速度改變路線對公司來說是很困難的——就像對人一樣，它也會導致混亂。但在這兩種情況下，穩定變革程序都應該是可行的和舒適的。
在上面的比喻中，構成水（及其伴隨的摩擦）的很大一部分是文化——整個公司的文化，以及在其中發揮作用的亞文化。例如，運維人員對變革有抵抗力，因為他們的績效不是通過創新來衡量，而是通過效能和正常執行時間來衡量。這培養了一種重視現狀的文化。隨著這種現實向開發人員轉移，你會發現他們的文化變得越來越關注破壞構建過程。這不一定是壞事：它鼓勵團隊進行強壯的測試並寫出更好的生產程式碼。但是，在新的業務需求或緊迫的最後期限中，即使對於曾經隨心所欲的開發者來說，變更阻力也會變得更大。有時候，更明智的做法是堅持安全的做法，避免可能帶來風險的創新。
風險規避融入到文化中，通常反映在結構、未說出口的價值觀以及支援它的架構上。這種架構非常冗餘，通常存在於由組織控制的資料中心內，並處於安全層和抽象層的保護之下。目標是為了保持穩定，但代價卻是停滯不前。
對額外複雜性的擔憂也會導致規避嘗試新技術的風險，即使對於小型非關鍵專案也是如此。通常，這些專案可以發展成其他系統所依賴的核心功能。具有敏捷思維模式的組織將隔離此類系統，並在API背後抽象其功能，但傳統的IT運營更願意完全避免它們，因為它們需要知識依賴性，這會讓招聘流程複雜化，並增加團隊獲得專業知識的工作量。這通常會導致扭曲當前的系統和程式語言，用以滿足不合時宜的需求，例如使用cron指令碼執行Java Applet來旋轉日誌。
當市場發生變化時，需要花費更多的時間、精力和成本來拆解這些架構。我們都看到各個領域的領導者落後於更靈活的競爭對手，這要歸因於多年來在在系統和態度方面積累的風險規避層（並且具有諷刺意味的是，這樣做事為了保持競爭優勢）。這就是顛覆的本質。
你無法採用單一架構來解決這個問題。多年來，N層架構打破了單體大型機，引入了應用程式和資料級的冗餘，可伸縮和麵向服務的架構解決了分散式程式碼庫所帶來的挑戰。今天，微服務和FaaS架構（例如AWS Lambda）被譽為最終解決方案，勤勞的組織開始跟風，將這些原則應用於他們的系統上。
這是一種“盲目崇拜”——模仿大公司的最佳實踐，盲目地應用它們，並期待同樣能夠出現奇蹟般的效果。在最好的情況下，這樣做可能可以帶來一點點幫助。在最糟糕的情況下，它會使工作環境變得更加惡劣，因為組織將一組嚴格的實踐替換為另一組，在應用這些原則時通常並不完全理解其目的或如何適應組織的獨特需求。
最好的組織是那些將敏捷作為核心價值和目標的組織。不應該基於是否有助於抓住現有市場而做出決定，而應該要關注下一步可能出現的情況。不要試圖去預測未來，而是開展“假設性”遊戲（如果……會怎樣）。
例如，如果可穿戴裝置捲土重來會怎樣？這對你的企業來說意味著什麼？機遇在哪裡？你當前的架構將如何解決它？要做到這一點你需要做些什麼？
我經常使用API作為回答這個問題的答案，而且有充分的理由。精心設計、管理良好的API與特定用例相分離，彼此獨立執行，並且能夠單獨擴充套件，幫助建立資料訪問環境，以便在出現新技術時快速適應新技術。但API只是最終能夠決定成功的大系統上的一個很小的層。
文化往往比技術更重要。你獎勵成功並懲罰失敗嗎？更有前景的敏捷是慶祝成功、分析失敗，並要求組織對每個人進行批判性研究，以便推動整個組織向前發展。這也意味著，如果你只能提供兩個9的可用性而不是七個，並讓你的系統可以優雅地處理停機時間，是可以被寬容的。
這與Facebook早期的口頭禪“快速行動和顛覆”不同——他們上市後就放棄了這個口頭禪。這是一個魯莽的口頭禪，他們也只是部分遵循。相反，我的建議是“刻意移動，擁抱失敗並從失敗中吸取教訓”。可能看起來不那麼吸引眼球，但確實是一種更現實的操作方式，可以促進增長並改進你的開發和部署過程。
當然，不要因為一粒老鼠屎壞了一鍋粥。IT仍然需要優先考慮優化效能和正常執行時間。沒有人願意成為將企業推向成功的貢獻者鏈中的薄弱環節。但這也意味著需要提供一種能夠優雅失敗並快速恢復的架構，同時儘可能多地提供有關其效能的資訊。
這是採用微服務架構的關鍵優勢之一。通過將程式碼庫和服務分解為多個相互通訊的小型獨立應用程式，可以降低一個小故障可能導致整個系統崩潰的風險。你還需要注意可能導致級聯故障的服務間連線。每個微服務不僅應該對自己控制的區域負責，在其他服務失敗時它也應該能夠優雅地失敗。這意味可以將程序內資料儲存在某處，等待故障服務重新上線時就可以快速獲取；為終端使用者提供錯誤資訊，讓他們可以採取其他行動（例如，解釋如何自行解決問題或將問題發給支援團隊）；積極監控效能問題，並在出現問題時提醒相關團隊（“DevOps”意味著開發人員也隨叫隨到）；記錄所有相關資訊，便於後續快速獲取和評審。
如果你卡在了經歷了多年制度化風險規避的遺留系統上，那麼仍然存在一線希望。現代ofollow,noindex" target="_blank">ESB工具 可以幫助你將單體抽象為微服務、緩解故障，並讓你的系統可以優雅地降級。使用這些工具，你可以開始識別問題系統，並根據需要進行替換和現代化，而無需花費太多時間完全重寫整個系統。
與此同時，所有新的開發可以採用更靈活的範例，例如通過現代Web服務API進行通訊的微服務架構。傳統的運營角色必須從謹慎的看門人轉變為以客戶為中心的服務提供者，主要客戶就是你自己的內部開發團隊。在真正的DevOps環境中，所有技術利益相關者都應該共同獲取這些系統專業知識。任何人都不應該只是一種或幾種技術的專家——每個人都應該至少了解驅動系統所需的所有技術。例如，如果你認為自己是Java程式設計師，而不是通用的“程式設計師”，那麼在你的職業生涯中，仍然有很多東西需要你學習。
變化是好的，但需要通過業務目標和資產現實來緩和。僅僅採用流行的敏捷策略是不夠的——你必須調整自己的文化，找到最適合你組織的敏捷模型。等待的時間越長，被比你動作更快的人取代的風險就越大。
積極的變化可以是自上而下的，也可以從開發團隊開始。你必須迅速獲得每個人的支援，並建立一種文化，將失敗和成功視為平等的學習機會，使其成為整個組織的習慣，才能確保長期的成功。
仔細反省並確保你和你的人不會成為眾所周知的信天翁並不會有什麼害處。考慮什麼是不可能的，以及為什麼——但不要有任何關於潛在成本、混亂和災難的反思性理由。問問自己，“你是創新的障礙嗎？”
關於作者
Robert Zazueta擔任數字平臺戰略全球總監，為TIBCO及其客戶提供有關數字化轉型的戰略建議、指導和思想領導力。他擁有超過15年的Web開發經驗和4年的業務開發經驗，他開發、設計、使用、支援和管理各種API和合作夥伴整合。他還負責維護NARWHL.com，該網站描述了構建適應性API的設計框架。