似是不變的事物實則變化萬千。

 

俗話并不完全是這么說的，但這句話應該刻在每一扇通向IT的門上。這肯定比“進入這里的人們，放棄所有希望吧”要好得多。

 

自從我們早期開始以來，一切并沒有發生太大的變化，那時IT就像電子數據處理（EDP），而程序員就像玻璃建筑里的大祭司。

 

一切都變了就這些事情沒變。

 

幸運的是，IT早期的很多基本知識如今仍然適用，只是披上了一個不同的，現代化的幌子。下面來看看十個有助于你了解下一代IT的老一套原則，以及你應用這些原則所顯示出來的根本區別。

 

 

舊版本：“沒有人會因為購買IBM的產品而被解雇”

 

新版本：開源可以提供相同的優勢

 

你所購買的技術對你來說是一個長期的承諾。你希望這對供應商來說也是一個長期的承諾。

 

為了安全起見，IT過去往往從大型供應商那里采購。而現在呢？開源不僅具有同樣的安全性，有時你可以從IBM或其它大型供應商那里獲得開源的東西。

 

并非所有的開源技術都能得到足夠廣泛的支持，但很多技術都得到了支持。例如，如果PHP能夠勝任這項工作，那么，鑒于其糟糕的安全跟蹤記錄，你會謹慎考慮Java嗎？然而，世界上最大的軟件公司之一甲骨文（Oracle）是支持Java的（也許說“提供”會更準確）。

 

這也算不上全新的事物。畢竟，如同開源一般的SHARE庫可以追溯到20世紀70年代。

 

 

舊版本：把硬件鎖起來

 

新版本：這不一定是你的上了鎖的房間

 

我們總是將硬件鎖起來，只讓少數員工使用數據中心，并保留這樣的自動日志——誰進入了數據中心，何時進入的。現在，并非所有上了鎖的房間都是我們自己的房間。

 

對中小企業而言，它們會有可替代的方案，例如交給托管（co-lo）設施和完全遷入云端。

 

但是，不要把本該用來擴建數據中心而節省下來的錢都存起來。請將其中的一部分錢用于與你的異地提供商建立低延遲，高帶寬的網絡連接。更理想的情況是：應用另一個老掉牙的原則——千萬別什么東西都只有一樣。建立彼此的網絡連接，因為在建筑物的兩側都要有入網點（point of presence），所以即使鏟土機在不該挖洞的地方挖了一個洞，你的業務也不會受到影響。

 

 

舊版本：庫存安全威脅和對策的實施

 

中期版本：將臺式機鎖起來并保護周邊

 

新版本：加強對資產的保護，也要加強對周邊的保護。

 

在過去，阻止安全威脅主要意味著使客戶信息控制系統（CICS）的會話超時，因此黑客就無法接入并繼承這些會話。然后個人電腦、分布式系統、互聯網以及更多威脅開始登場了。我們要通過這樣的方式來做出回應——鎖定臺式機并用越來越復雜的防火墻來保護周邊。

 

很多人仍然認為最好的對策是將一切封鎖起來，不讓任何人發揮創意。但是，企業要么生于創新，要么死于創新，創新可不僅僅意味著人們想要出售的新產品。創新意味著創造性思維，以及在業務中所及之處實施這樣的思維。

 

如今，我們應該花更多的時間來加強對資產（而不是周邊）的保護，甚至花更多的時間積極地為用戶提供支持，因為在創新上沒有得到允許的勞動隊伍才是最大的威脅。

 

 

舊版本：維護三個環境——開發、測試和生產

 

新版本：將大量測試工作移至云端

 

回歸和壓力測試將專業人士與業余愛好者區別開來。回歸和壓力測試一直在做這樣的區分，現在還是這樣。回歸測試可以確保新東西不會破壞舊東西。壓力測試可以確保這樣的情況——當每個人都開始施壓時，一切都會表現得很好。

 

由于IT所具備的專業性，它至少要維護三個環境——開發、測試和生產。這意味著什么東西都要購買三樣。并對這些東西進行維護。這可不好受！

 

現在，即使你維護自己的數據中心，在云端啟動測試環境往往也很重要，因為你只要按需付費就可以了。依據你的生產環境的不同，云端也可以很好地用于回歸測試。

 

壓力測試？還沒做。變量實在是太多了，至少目前是這樣。

 

 

舊版本：正式的變更控制流程

 

新版本：正式的變更控制流程

 

開發人員輕松將新代碼投入生產的日子已經一去不返了。我們要經歷一個過程。實際上沒有人喜歡這個過程，但這無關乎人們是否喜歡這個過程。這是為了確保變更不會擾亂生產，如果變更確實破壞了生產，這就關系到人們要有一個撤銷計劃。

 

你認為云改變了很多事情？確實如此。云使變更控制變得更加困難，因為現在，如果你管理云提供商的方法不夠謹慎，他們可能會在不經過你的流程的情況下將他們的變更投入生產。

 

畢竟，這就是他們的基礎設施

 

 

舊版本：業務管理者和程序員反反復復地進行非正式的來回交談

 

新版本：Scrum：業務管理者和程序員反反復復地進行非正式的來回交談，不過他們有規則可遵循

 

在正式的開發方法遠未破壞IT的樂趣之前，業務管理者常常來回徘徊并提出這樣的問題：“你能讓計算機做到這一點嗎？”程序員會做一些嘗試，并把結果展示給業務用戶看，然后他們會做迭代，直到結果可行為止。

 

他們并沒有稱之為敏捷。而是稱之為“談論計算機應該做什么”，但這仍然算作敏捷。

 

然后出現了瀑布式方法。如果業務經理能夠完美地設想一個完整的工作系統并準確地描述這樣的系統，這些方法也很管用......但他們做不到，所以我們失去了30年的生產力。

 

然后Scrum登場了，它需要進行迭代和交互，并添加了足夠多的方法來破壞其它敏捷版本的方法所帶來的和IT有關的大部分樂趣。

 

 

舊版本：與其他高級管理人員一起管理關系是首席信息官的工作重點。

 

新版本：與業務的其他人員一起管理關系是所有人的工作重點。

 

在業務還沒有變成其它東西前，它們是所有關系的集合體。只要建立良好的關系，一切都可行。沒有建立良好的關系，一切都枉然。

 

在企業有嚴格的等級制度的那個時代，首席信息官與其他高級管理人員一起管理關系，這就足夠了。如果其他高級管理人員不信任首席信息官，IT就無法成功。就這么簡單。

 

但每當IT部門的所有成員與業務中的所有其他人進行交互時，這都會影響業務與IT之間的關系。這不僅僅關系到首席信息官和其他高管。如果業務中的其他人員不信任IT，那么IT就無法獲得成功。如果業務中的其他人員信任IT，那么IT的方方面面都會變得更加輕松。

 

不是變得輕松，而是變得更輕松。

 

 

舊版本：逐步累積自定義編程的批處理接口

 

新版本：帶有專門設計的實時接口的服務總線或等效的東西

 

較新的版本：與非IT驅動的軟件即服務（SaaS）解決方案集成

 

當人們將計算機生成的報告中的信息重新鍵入到顯示數據錄入的屏幕時，IT意識到，它最重要的職責之一是整合不同的系統，使數據保持同步。

 

所以IT創建了接口。大量的接口，所有接口都是自定義批處理的抽取、轉換和裝載（ETL）。

 

如今有這么多接口，混亂得難以維護。因此，明智的IT會投資服務總線或諸如此類的東西，并設計接口，因為僅僅將接口層層堆疊起來意味著閃亮的新技術又創造了新的混亂。

 

如今，很多與IT有關的事情都發生在IT部門之外，主要是業務管理者引進的軟件即服務，以此來實施局部自動化（island of automation）。最終，他們再也不會樂此不疲地讓員工重新輸入數據。請準備好面對這樣的事情。

 

 

老得像陳詞濫調的版本：不要為了技術而技術

 

新版本：提供技術領導力

 

為了技術而技術，這可不是什么好事。這并不意味著IT應該將其職責限制在工單的處理上。它必須實現超越并提供技術領導力。

 

所有未能提供技術領導力的IT部門（提出建議和討論，而不僅僅是接受和交付）都在根本上失敗了。

 

技術領導力還意味著為準備購買或構建自己的技術的管理者和用戶提供支持。現在是時候認識到“影子IT”是一件好事，因為它增加了IT的帶寬。

 

當然，風險是有的。一切值得做的事情都有風險。

 

IT必須利用一切可以利用的技術幫業務中的所有人取得成功，而不是扼殺所有“不是在這里發明”的東西。

 

 

舊版本：IT是推動整個業務變革的主要動力

 

中期版本：IT是業務變革的最大障礙

 

新版本：IT是推動整個業務變革的主要動力

 

當計算機煥然一新時，企業高管對它們寄予厚望，希望它們能通過這樣的方法在所有的地方推動變革——使業務流程變得更快，更便宜，同時減少人為錯誤。

 

這種情況會一直持續下去，直到IT必須支持很多互連系統，以至做任何新事情都是耗時、昂貴且有風險的。IT對瀑布式方法的依賴也無甚裨益。

 

我們終于又掙脫了。在這一切之間——敏捷的，更好的集成工具和發生在IT以外的IT，信息技術再一次推動變革，而不是追隨變革。