以業務能力為中心的
2016 年 6 月 8 日
以業務能力為中心的團隊，其工作長期與業務的特定領域保持一致。只要所述業務能力與業務相關，團隊就會存在。這與專案團隊不同，專案團隊只會持續到交付專案範圍為止。
例如，電子商務業務具有購買和商品化、目錄、行銷、訂單管理、履行和客戶服務等能力。保險業務具有保單管理、理賠管理和新業務等能力。電信業務具有網路管理、服務提供和保證、帳單和收入管理等能力。它們可以進一步細分為細粒度的能力，以便由可管理規模的團隊擁有。
以業務能力為中心的團隊是「構思、建置和執行」團隊。他們不會將建置的內容交給其他團隊進行測試、部署或支援。他們端對端地擁有其領域中的問題。他們也擁有主要支援業務能力的 IT 系統（應用程式、API 和資料）。基礎技術平台（例如 Java、.NET）和應用程式平台（例如 Salesforce、SAP、Peoplesoft）可以在團隊之間共用。
Sriram 的書更詳細地說明如何以及為何建立以業務能力為中心的 IT 組織。
根據 IT 策略的指導，定期（例如每年）確定每個能力的團隊規模。這是一種不同類型的組合管理，其中以團隊容量形式的預算分配給長期業務能力組合，而在傳統的組合管理中，以資金形式的預算分配給相對短期的專案/計畫組合。以業務能力為中心的團隊需要以成果為導向才能發揮其潛力。除非他們有權力朝向業務成果努力，否則他們可能會退化為以範圍交付為導向。
考慮一個典型的應用程式環境範例，其中包含最新和舊式系統、一些自製應用程式和一些現成商用 (COTS) 應用程式、一些 SaaS 應用程式、由一些新的微服務、一些巨型服務提供的異質 API 層，以及所有結合自訂整合、企業服務匯流排和其他精緻中間軟體的內容。每個以業務能力為中心的團隊都將擁有上述與其業務領域主要相關的內聚子集。但是，有些應用程式本質上是跨能力的，例如電子商務應用程式中的端對端查詢至結帳客戶旅程。他們可能需要自己的團隊（或兩個團隊，一個負責行動裝置，一個負責筆電）。在應用程式環境中劃定界線並將其分配給團隊是一項不平凡的工作。以成果為導向是一個良好的指導原則。考慮每個區塊是否可以對業務成果或次成果（表示為業務指標）負責。
有些人擔心讓單一團隊管理業務能力範圍內的數個系統將違反 康威定律。但康威定律並未反對單一團隊負責多個相關元件。它允許元件擁有者有高度的凝聚力，以及團隊間的低耦合，因此能有更好的回應能力。
對員額的影響
以業務能力為中心的配置可能需要比以專案為中心的執行模式略多一些員額。這是因為專案的職責通常僅限於「建置、移交給支援/營運，然後解散」，而以業務能力為中心的團隊職責則是「構思、建置和執行」，只要業務能力仍然相關。這需要我們隨時為每個業務能力維持至少一個最小團隊。事實證明，這有許多好處。以專案為中心的模式通常會損害應用程式環境的架構完整性，因為每個專案團隊只關心在承諾的日期前交付其範圍。在此過程中，它可能會採取捷徑，例如
- 與其依賴的系統進行臨時整合
- 與預計淘汰的系統整合或為其新增功能，因為使用替代系統執行會需要更多工作
- 在先前團隊的工作上加上快速而粗糙的程式碼，並在此過程中造成維護惡夢。
透過企業架構的有效監督，可以避免其中一些問題，但這仍然是一個挑戰，因為以專案為中心的模式通常會為每個新版本產生不同的團隊，而新團隊必須重新學習業務規則以及周圍應用程式環境的注意事項。外包進一步使這變得複雜。
另一方面，當資金充裕且專案在不考慮現有程式碼庫和應用程式環境的承載量的情況下魯莽啟動時，以專案為中心的模式並非龐大員額的陌生人。專案組合層級缺乏進行中的工作限制，導致許多專案啟動，但只有少數專案完成或交付預期的成果。
策略性和實用性能力
業務能力可以依據特定時間範圍分類為策略性或實用性。有時，將能力中的幾個子能力標記為策略性會更有用。另一方面，公司 IT 能力，例如薪資、會計、法律、人力資源和工作場所協作，通常被歸類為實用性。儘管仍組織為以業務能力為中心的團隊，但實用性能力通常會透過套裝軟體提供（購買而非建置）。因此，它們是「思考、購買、自訂/組態/整合、執行」團隊，而非「思考、建置、執行」團隊。實用性能力也常外包給由管理服務供應商提供的外部以業務能力為中心的團隊。即使在內部提供，讓這些團隊具備維持運作的技能，而非頂尖開發技能，也是實務做法。同樣地，儘管結果導向對於實用性能力很重要，但它們可以由較低階的產品負責人領導。