五招幫助企業將IT塔式體系轉變成云服務
譯文
由于眾多公司采用更多的IT云服務，接洽越來越多的云服務提供商，過去屢試不爽的IT塔式體系再也無法滿足要求。外包咨詢公司Pace Harmon的負責人Steve Keegan說：“原有的模式缺乏清晰的所有權，而想要左右橫跨傳統塔式結構的XX即服務方案方面的決定，需要清晰的所有權。確定誰有拍板權并非易事――是服務器團隊，應用開發團隊，還是數據庫團隊？”
IT團隊需要圍繞流程，而不是圍繞技術方面（比如基礎設施或應用程序）來進行重組。在流程驅動型IT組織，“大家致力于長遠來看有益于組織的活動，而且職責明晰，完成工作的效率得到了提高，”Keegan如是說。
但這種“規劃、建造、運行”的模式常常并不奏效，原因有好多。Keegan說：“決策過程仍然由應用開發團隊說了算。遺留應用軟件的負責人不希望其左右資源投入決策的權勢有所削弱。領導班子并沒有讓自己的管理人員負起責來、留意諸職能部門的邊界。架構職能部門缺少成功所需的資源，因而變得嚴格監管，沒有時間來做貢獻、為項目和計劃負責人提供規劃方面的真知灼見。”
那些確實成功改用“規劃、建造、運行”模式的IT團隊得到了領導層的明確支持，并且大規模實行變化，而不是讓某些團隊繼續采用一貫以來的方式來運作。
Keegan介紹了將IT轉變成流程驅動型組織的五個要點：
1. 征募一批業務分析人員。
這些IT專業人員應該能與業務部門處理好關系，而不是僅僅擅長處理應用軟件，從而處理前期規劃。他們會擁有業務流程方面的知識，而闡明應用領域所需要的變化，開發新的、一致的業務流程需要這種知識。Keegan說：“許多人以為業務分析人員外面多的是，實際上常常遠遠不夠。業務分析人員提供了一種核心競爭力，能夠讓支持業務的底層系統滿足業務部門對變化的需要。”
2. 別在規劃方面敷衍了事。
Keegan說：“最終形成商業方案的確定范圍和規劃的項目早期階段確實值得投入足夠的資源和精力，這不僅對確保投入的方向正確大有作用，還確保項目投入分配合理，因為其目的是確定范圍，為此制定計劃，并證明有必要投入開支以實現戰略性業務目標。”
計劃把大約5%到10%的項目時間（及成本）用于制定商業方案。Keegan說：“花更多的時間用在規劃上，不僅更加確信你會對結果感到滿意，你還知道當項目正式開工時，你不會對計劃做太多的變化。”
3. 讓架構團隊負責應用規劃。
Keegan解釋：“讓應用開發團隊負責應用軟件組合和路線圖規劃是好事――只要你不想停用應用軟件，或者簡化應用軟件方面的支持及因而產生的成本。傳統的應用開發負責人通常通過增添復雜性，增加應用軟件套件而導致許可和維護成本增加，并加大因而產生的支持的復雜性，以擴大其控制權――因為它們只負責交付一個個項目，而不是對支持所部署系統的成本負責。”
架構團隊肩負的使命是，優化應用軟件組合，降低總體擁有成本，以及將投入的資源最大限度地利用起來。應當鼓勵高效地利用應用軟件套件并加以合理化改動，停用和遷移不常使用或維護成本高昂的應用軟件及平臺，并且優化成本和質量。
4. 規劃充分、人員配齊后再開始項目。
Keegan說：“由于不了解或不清楚應用軟件組合方面的約束，企業高管及其他領導人插手干預，試圖確定自認為合理的預算和時間表，而這種時間表也許現實，也許不現實。”要充分利用應用軟件組合規劃職能部門，確定優先級，明確首先需要哪種XX即服務方案。
5. 在投入生產環境之前建立一種有效的閘門機制。
Keegan說：“明確服務轉變后歸誰所有的能力需要整合到模式當中，以確保進入生產環境的完全是準備得到支持的變更系統。”負責這些決策的那些職能部門應該獨立，但要與負責建造的職能部門和負責運行的職能部門協調起來。
“這種能力負責建造到運行的環節，確保一切都是正確的（以滿足業務要求），已記錄（那樣它可以重現和復制），可支持的（那樣電話打到求助臺后，工作人員知道該怎么做）。無論是什么變化，無論何時需要部署，起到把關作用的閘門機制都需要先考慮果真進入到生產環境后，運行部門有沒有能力支持這種變化。”
