Gartner的Pace-Layered Application Strategy使IT組織可以根據業務需求構建一些用於快速更改的系統，而其他一些則用於穩定性。 我們將探討CIO如何組織其應用程序團隊，以利用步調分層的概念。
關鍵挑戰
- 各地的IT組織都迫切需要在選定的業務領域中更快地交付系統。
- 組織應用程序團隊進行速度分層提供了一種方法，可以在需要它的區域提供速度，同時在最重要的區域保持穩定性。
- 儘管沒有“一種方式”來組織應用程序團隊（或任何團隊），但中心輻射模型最適合大多數按節奏劃分的應用程序團隊。
- 交付創新系統的人員（最注重速度和變化的系統）可能位於IT部門內部或外部。 如果他們住在外面，新興的首席數字官（CDO）將越來越扮演提供創新系統的角色。
推薦建議
- 即使是小型應用程序團隊，也應該考慮如何根據變化率組織交付，而不是使用相同（通常是折衷）的方法和流程來對待每個項目。 CIO需要確定速度最重要的地方，以及企業爲獲得速度最願意進行哪些權衡。
- 現在，CIO應該決定在IT組織內部（而不是企業中的其他地方）交付創新系統對他們有多重要。 CDO的新興角色通常駐留在IT組織外部，並與之一起提供類似創新系統的產品。這在經歷深度數字破壞的行業中是可以的，甚至是理想的。但是，首席信息官應該對創新系統的位置採取主動而非被動的態度。
- 首席信息官應注意，在內部管理所有三個進度層（記錄系統，差異化系統和創新系統）時，需求治理，關係管理和體系結構的最低限度的成熟度是必需的。
介紹
組織設計的黃金法則是圍繞要優化的內容進行組織。 對於Gartner的“分層式應用程序策略”，應用程序團隊正在嘗試優化以交付具有不同變化率的系統，以便IT組織可以緩慢而穩健地交付某些系統，而快速而靈活地交付其他系統。 這項研究的重點是Gartner認爲應該將步伐分層的應用程序團隊組織起來。
組織起搏層意味着以不同的速度交付
放下手，當今IT部門面臨的最大問題之一是速度問題。 IT必須更快地滿足業務需求。 但是在所有系統中交付速度並不是普遍必需或不希望的。 CIO需要了解需要快速交付和變更的系統與不需要快速交付和變更的系統之間的區別，並且他們需要圍繞每個系統進行組織。 輸入Gartner Pace-Layered Application Strategy，該策略將根據應用程序更改的速度對應用程序進行分類。
在“如何使用速度分層來開發現代應用程序策略”中，我們定義了速度分層：
- 記錄系統-支持核心事務處理並管理組織的關鍵主數據的已建立的打包應用程序或舊式本地系統。 變更率很低，因爲這些流程已經建立並且對於大多數組織來說都是通用的，並且經常要遵守法規要求。 記錄系統的生命週期最長，爲10年或更長時間。
- 差異化系統-支持獨特公司流程或行業特定功能的應用程序。 它們的生命週期中等（一到三年），但是需要經常進行重新配置以適應不斷變化的業務實踐或客戶要求。
- 創新系統-臨時構建的新應用程序，用於解決新的業務需求或機遇。 這些通常是使用部門或外部資源以及消費者級技術的短生命週期項目（零至12個月）。
爲應用程序團隊構建層級應用程序策略意味着要組織快速交付某些事情，而緩慢地交付其他事情，而隨之而來的是治理，需求流程，文化和開發方法方面的所有差異。 有關各層之間的主要差異，請參見圖1。
| 屬性 | 記錄系統 | 差異化系統 | 創新系統 |
|---|---|---|---|
| 變革的步伐 | 緩慢，不頻繁和增量。每六至十二個月更換一次。 | 中度且更頻繁。 可配置性是關鍵。每三到六個月更換一次。 | 快速，非常頻繁且特別。 “一次性”定製。每週更改，有時每天更改。 |
| 生命週期 | 10年以上 | 1到3年 | 0到12個月 |
| 計劃範圍 | 7年以上 | 1到2年 | 最多6個月 |
| 治理模式 | 正式的和全局的 | 反應靈敏且以業務爲主導 | 靈活而特別 |
| 利益相關者/所有權 | 高級企業主管的參與; 業務與IT戰略之間的一致性。低端用戶的參與，並從業務到IT正式交接。 | 高業務主管的參與度，但受業務範圍的驅動。最終用戶的參與度適中，業務參與熱點，而IT填補了空白。 | 適度的業務執行人員參與，並得到一些贊助商的支持； 戰術上的。最終用戶的高度參與，通常是通過業務用戶甚至是規避IT來實現的。 |
| 資金 | 資本支出（資本支出），以及相應的運營支出（運營支出）。 公司或部門資金。 年度預算。 | 資本支出和運營支出的混合。公司IT預算或部門支出預算。 全權委託。 | 主要是運營支出。 部門支出預算。 創新基金。 |
| 架構 | 大型的模塊化設計以正式的前期藍圖階段爲主導。 | 面向服務的體系結構（SOA）和基於雲的服務，包括服務使用者和生產者。 通過組裝新的和現有的打包及自定義應用程序來增加複合應用程序的使用 | 輕巧而新興的服務於消費者。移動和云爲主。 |
| 應用程序生命週期管理（ALM）方法 | 瀑布接近（有時間限制）爲70％。交互式和增量開發（IID）達到30％。 | 瀑布接近（有時間限制）爲40％。 互動率和IID爲50％。 敏捷和精益方法論佔10％ | 瀑布接近（有時間限制）爲10％。 IID爲30％。 60％的敏捷和精益方法論。 |
大多數應用程序團隊僅通過默認所有系統的最慢方法（即記錄系統方法）來避免以可變速度交付的問題。 如前所述，這種策略不能長期有效，因爲隨着越來越多的數字業務機會，與記錄方法系統相比，業務需要更快的速度。 數字營銷活動，衆包競賽和許多移動應用程序都是創新系統的示例，如果採用記錄系統的方法，創新系統將遭受損失。
分析
本文檔的某些部分基於歷史信息； 但是，最重要的最佳做法仍與領導力的發展階段有關。
輪輻模型最適合按步調應用策略組織的應用團隊
這裏的中心問題是：“鑑於各層之間文化，開發方法，技能和方向的深刻差異，應用程序團隊應如何組織以交付記錄系統，差異化系統和創新系統？”
正如我們在“應用程序組織設計：概述”中指出的那樣，很少有“一種方法”來組織應用程序團隊。當理解和評估時，只有一組權衡可以計劃和/或防範。但是，有一些驅動程序會迫使組織以一種或另一種模式（筒倉，系統集成商或工廠）進行設置。圍繞速度層概念進行組織就是其中之一，因爲速度層在各層之間具有根本不同的治理流程（請參閱“用於治理和變更管理的分層應用程序策略”），並且速度層專注於業務流程，而不是任何特定的商業組織模型。
CIO需要一種組織方式，以保持各層之間的一致性，同時留出足夠的距離，以使創新系統，差異化系統和記錄文化系統獨立發展。 Gartner認爲，實現這種微妙平衡的最佳選擇是輪輻式組織模型。
通常，在中心輻射型模型中，有一箇中央資源團隊專注於在所有業務組之間共享（或應該共享）的通用應用程序。通過使用速度層，我們會將其擴展到具有通用治理，計劃和管理功能的應用程序。圍繞“ Pace-Layered Application Strategy”組織的應用程序團隊從該中央團隊或中心提供記錄系統。這類似於Gartner的“運行”，“增長”，“轉換”模型（其中差異化系統大致等同於“增長”，而創新系統則等同於“轉化”）。
記錄系統是創新系統和差異化系統所汲取的樞紐
這種結構的中心支持記錄系統。 該小組支持以相對可預測的變化速度使業務流程自動化的應用程序。 這並不意味着沒有資金分配給這些應用程序或它們對業務不是至關重要的（例如，工資單是由記錄系統自動化的，並且肯定是關鍵的業務流程）。 這確實意味着變更通常針對成本優化或效率，這有助於制定可預測的長期財務計劃。
該組可以由任何主要組織類型（筒倉，集成商和工廠）組成，並且可以完全是內部，外部或兩者的組合。 該中心圍繞應用程序交付過程的成本優化進行組織。 集線器並不意味着從輻條到集線器的報告線，而是一個可以從中抽出輻條的公共平臺（請參見圖2）。
集線器還負責在各層之間提供連接組織。 鑑於各層之間的治理存在深層差異，我們建議每個步伐層分別報告，並且沒有層報告到另一層。 有一些問題，我們在下面概述。 本質上，無論一個創新系統小組是向CIO還是向企業中的其他部門報告，關鍵的事情是面向客戶的差異化應用程序應位於一個團隊中，並且該組不能在應用程序之間共享。
Gartner在“我們所知道的瀑布的盡頭”中警告要在同一團隊中使用不同的流程，尤其是因爲敏捷和瀑布式（或迭代式）方法之間的主要文化差異。 這些應用程序通常還需要專門的業務技能集，而這些技能可能無法在各個業務組之間共享。
分離模型各層有四個關鍵問題：
- 首先，大多數組織將無法放棄其當前的應用程序組合，並且許多應用程序跨越各個層次，尤其是在記錄系統和差異化系統之間。這使得很難確定哪些應用程序適合哪個組織。實際上，可能需要重構現有的應用程序，以便某些部分可以成爲記錄系統，而另一些可以成爲差異化系統。
- 其次，很多時候，各層之間將需要大量集成，因此，連接組織和設計合理的閾值的重要性。例如，開發人員需要知道在體系結構遵從性方面的限制。
- 第三，大小很重要。如果整個應用程序組很小，則不可能以中心輻射狀模型進行組織。
- 最後，應用程序將根據其支持的業務流程的移動而在堆棧中移動。這就需要一套功能更強大的體系結構標準和文檔，這些標準和文檔在各層之間是一致的。這意味着，如已指出的更改，將需要在中心和分支之間傳遞應用程序交付和支持。
創新系統和差異化系統需要與他們服務的業務組更加緊密聯繫
創新系統和差異化系統的治理與記錄系統的治理顯着不同，後者更多地側重於靈活性和速度，而較少側重於可預測性和可控制性（見圖3）。
| 記錄系統 | 創新系統 | 差異化系統 | |
|---|---|---|---|
| 應用程序組合管理 | 評估成本，風險和業務適合性 | 評估是否仍然分化 | 評估是否準備好產品化 |
| 項目和項目組合管理 | 優先考慮業務需求和ROI | 優先考慮業務戰略需求 | 優先考慮機會 |
| 人員配備，技能和採購 | 專注於可靠，經濟高效的交付 | 專注於業務知識和速度 | 專注於實驗設計 |
| 財務分析與預算 | 專注於可靠，經濟高效的交付 | 隨着項目的進展按預算進行迭代 | 風險資本式融資回合 |
| 體系管理 | 確保數據和流程的完整性 | 利用記錄系統和新流程 | 嘗試新技術和新結構 |
| 軟件流程 | 主要是瀑布（有時間限制） | 主要是增量和迭代 | 大多敏捷 |
| 運營與支持 | 嚴格控制的變更管理 | 每個系統的流程簡化 | 團隊控制“殺戮開關” |
| 供應商管理 | 大型穩定的巨型供應商 | 同類最佳，BPMS和複合應用程序 | 無論如何 |
| 商業參與 | 正式流程 | 日常參與 | 做許多工作 |
通常，差異化系統應在IT組織內部進行報告，因爲許多差異化系統實際上是較大記錄系統的一部分。 整個工作需要各層之間的高度完整性。
創新系統並非總是如此，在某些情況下，創新輻條系統可以而且應該位於IT組織外部。 當IT組織沒有深入的業務知識或複雜的需求管理時，尤其如此。
如果IT組織對以下兩個或多個問題的回答爲“否”，則創新交付系統可能會正式或非正式地駐留在IT組織外部：
- IT能否以創新的步伐交付系統？ 例如，應用程序團隊是否設置爲在不到六週的時間內一致且重複地交付系統？
- 當出現新想法時，IT組織與企業的距離是否足夠近以能夠出現？ 例如，IT開發人員是否定期參加正在討論新概念和想法的會議？
- 影響企業業務模型的技術破壞深度是否如此之大，以至於業務模型本身受到威脅？ 換句話說，它的收入來源或任務是否由於數字化而受到迫在眉睫的威脅，例如報紙或旅行社的收入？
- 如果IT對以上兩個或多個回答“否”，則創新交付系統的大部分機會將嵌入業務部門，而不是中央IT組織。
在中心和分支之間建立明確的閾值
無論創新系統在哪裏報告，都必須在與保持後臺運行相關的控制和風險管理實踐以及與前臺相關的機會主義，以收入或任務爲中心的文化之間保持距離。這意味着在輪轂和輻條之間建立閾值，以瞭解哪些是必需的，哪些不是必需的。建立的最重要的閾值是數據完整性和過程完整性。
關於這些閾值，有幾個方面需要注意。首先，應用程序團隊需要能夠依靠成熟的體系結構來闡明閾值。在這種情況下，“成熟”是指一種架構，該架構反映了有關需要在整個業務（樞紐）中共享和共享的元素以及需要區分的元素（輻條）的一致且被接受的觀點。
要牢記的一個好的經驗法則是，標準化本身並不會帶來普遍利益，差異也不是。旨在標準化商品流程，這是差異化不會給企業帶來任何回報的業務領域。這是通過使用集線器作爲通用標準平臺的記錄系統方法來完成的。在這種情況下，數據和流程完整性的閾值非常高。
同樣，在差異創造價值的領域，例如在差異化系統和創新系統中，要允許差異化的流程和系統。 在區分系統中，通常仍需要過程和數據完整性來確保整個系統的一致性。 但是，負責整體差異化系統的團隊在組織上是分開的，他們使用不同的方法，時間表和治理來實現其業務目標。
創新系統連接到其他層的閾值通常在數據中，而不是過程中。 例如，針對數字營銷活動的創新系統可以使用不同的流程，非企業供應商，敏捷方法或新的融資模型，但是創新的最終系統幾乎應該始終能夠從主客戶數據中獲取信息。 換句話說，爲了保持創新系統的變化率，您可以容忍從一個業務部門到下一個業務部門的重複解決方案，但不能重複數據。
瞭解業務需要標準化以及需要差異化的地方是瞭解創新系統，差異化系統和記錄系統之間需要多少完整性的第一步。
組織差異化系統來交付產品而不是項目
對於大多數組織而言，衡量，管理和交付的容器是一個項目。項目交付新功能，或逐步修改功能，或兩者兼而有之。如前所述，在許多組織中，企業內部對項目驅動的資金的不滿程度日益提高。
在“特立獨行研究：從項目到產品的轉變將推動應用程序組織的重大變化”中，我們提出了一個不同的比喻，即應用程序成爲支持全部或部分業務流程的產品。在基於項目的組織中，工作是按時間片分配的，稱爲任務。可以根據個人的可用性將其分配給多個應用程序。該項目是中心組織原則，而不是應用程序。在基於產品的組織中，創建了個人團隊以長期支持產品或產品組。當然，人們來來往往，但有兩點要記住：團隊的任務通常很長（超過18個月），並且通常是全職的。團隊成員可以處理多個任務或功能，但是它們在團隊中，而不是多個項目和多個經理。這有助於對應用程序團隊內的業務流程進行更深入，更一致的理解。
由於步調組織中的重點是支持業務流程的應用程序或產品，並且差異化系統和創新系統需要更靈活的治理實踐，因此它們適合這種產品視圖，在該視圖中，計劃和交付側重於將在產品的下一個版本中（或儘快）將產品的次要關鍵業務功能納入產品。
本質上，這裏的需求治理是在業務流程級別上。 每年，都會爲該過程制定預算。 通常，與此預算相關聯的還有一組主要業務功能，可以映射到版本中。 如果在一年中的任何時候出現了對差異化或創新至關重要的新功能，則可以將該功能放入適當的版本中，而無需等待一組項目完成。 記錄系統不需要這種更精細的需求管理。 這對於差異化系統和創新系統至關重要。 而且，由於這些變化發生得相當迅速，因此大多數差異化系統或創新系統將使用敏捷或緊密迭代的方法來交付。
在您的各層中建立良好的需求治理，以實現組織一致性
在“應用程序組織的四個支柱”中，它討論了運行良好的應用程序組織的四個要素，第一個關鍵支柱是需求和關係管理。任何組織結構要想成功，必須首先考慮這個支柱。應用程序組織結構應與業務運作方式相匹配。如果整個企業有靈活的需求並且只有一個預算池，那麼系統集成商結構將是最佳的選擇。如果每個企業都有自己的預算，那麼就很合適。步調層的組織通常專注於流程孤島（也就是說，每個業務流程都有一個或一組應用程序對它們進行端到端的自動化和優化），而很多企業卻沒有。
試圖以不同於業務合作伙伴的方式構造自己的組織的組織通常會遇到失敗，除非他們採用非常結構化的方式來管理需求和關係管理。換句話說，他們需要在其運營模型中明確解決需求和關係管理方面的差異。由於業務組可能會使用駐留在多層中的應用程序，因此可能需要從管理結構中拉出需求治理和關係管理以實現此解決方案，並在業務組及其應用程序對應方之間提供單一聯繫。例如，用於應用程序交付的其他集中式操作模型將具有明確的，分散的需求管理器，與業務部門或部門保持緊密聯繫，以反映部門的更自主的操作方式。在許多方面，這就像我們在“應用程序組織設計：內部系統集成商”中描述的那樣。
此外，組織需要在其治理實踐中具有基本的成熟度，才能使任何組織結構正常工作。在“應用程序組織的ITScore概述”中，Gartner列出了必須考慮的八個學科類別。學科不會在有節奏的組織模型中發生變化，但是爲滿足這些學科而執行的特定活動將會改變。實際上，一個成熟的應用程序組織具有一組定義明確的過程，可以根據需要從中進行選擇。
如前所述，治理實踐將根據所支持的層而有所不同。基本成熟度（第3級或接近3級）對於使進度層正常工作至關重要，因爲治理將使這些相對獨立的團隊聚在一起。對於遷移到步調分層的組織模型而言，這並不是特別特定。如果治理不好，那麼在任何模型中都無法很好地管理。
共享組織方面的內容以在層之間創建連接
與我們一樣，許多人會注意到該模型已經過嘗試過。 在某些情況下，它工作得很好。 在其他情況下，沒有那麼多。 在“分層應用程序策略”結構中進行管理的能力基於對業務流程和支持它們的應用程序的理解。 因此，通用且結構化的業務流程和應用程序架構至關重要，尤其是在短期內，在這種情況下，組織通常會將混合在一起的應用程序和流程混合在一起，但意義不大。 在整個業務中，這種通用視圖對於避免過去嘗試中出現的混亂狀態至關重要。 有關層之間的連接組織的更多信息，請參見“用於步速應用策略的連接技術”。
結論
IT組織迫切需要解決其流程和運營模型中的速度問題。 具有節奏的應用程序團隊是邁向更高速度的一步，因爲它使IT組織能夠圍繞不同業務流程所需的不同變更率進行組織。 創新團隊的系統可能不一定位於IT組織內。 但是，即使不這樣做，也需要成熟的需求治理和強大的體系結構才能使不同的移動部件作爲一個整體凝聚在一起。 儘管沒有一種組織應用程序團隊的方法，但是輪輻模型可能是追求進度層的應用程序團隊的最佳選擇，其中記錄系統提供了樞紐，創新系統和差異化系統是該樞紐 畫出最低程度的一致性，同時保持足夠的自由度以快速移動。
個人總結
本文主要講的是通過分層的方式，將公司的業務做劃分，並分別採取不同的策略分配公司資源，實現企業的經營和管理。
這裏提到的劃分層級的思維方式，對企業調度資源，維持業務發展，很有借鑑意義。
原文鏈接
https://www.gartner.com/binaries/content/assets/events/keywords/applications/apn30/pace-layered-applications-research-report.pdf