以业务能力为中心
2016年6月8日
以业务能力为中心的团队是指其工作长期与企业特定领域保持一致的团队。只要上述业务能力与企业相关，该团队就会一直存在。这与项目团队形成鲜明对比，项目团队只持续到交付项目范围所需的时间。
例如，电子商务企业具有购买和销售、目录、营销、订单管理、履行和客户服务等能力。保险企业具有保单管理、理赔管理和新业务等能力。电信企业具有网络管理、服务供应和保障、计费和收入管理等能力。它们可以进一步划分为更细粒度的能力，以便由规模可控的团队负责。
以业务能力为中心的团队是“思考、构建和运行”的团队。他们不会将自己构建的内容移交给其他团队进行测试、部署或支持。他们端到端地负责自己领域的问题。他们还拥有主要支持业务能力的 IT 系统（应用程序、API 和数据）。底层技术平台（例如 Java、.NET）和应用程序平台（例如 Salesforce、SAP、Peoplesoft）可以在团队之间共享。
Sriram 的书更详细地介绍了如何以及为什么要构建以业务能力为中心的 IT 组织。
每个能力的团队规模会定期（例如每年）根据 IT 战略的指导进行确定。这是一种不同的投资组合管理方式，其中以团队能力形式存在的预算分配给一系列长期存在的业务能力，而在传统的投资组合管理中，以资金形式存在的预算分配给一系列相对短期存在的项目/计划。以业务能力为中心的团队需要以结果为导向，以最大限度地发挥其潜力。除非他们被授权朝着业务成果努力，否则他们可能会沦为以范围交付为导向。
以一个典型的应用程序环境为例，该环境混合了最新的和遗留的系统，一些自主开发的应用程序和一些商业现成 (COTS) 应用程序，一些 SaaS 应用程序，由一些新的微服务提供的异构 API 层，一些大型服务以及通过临时集成、企业服务总线和其他精品中间件组合在一起的所有内容。每个以业务能力为中心的团队都将拥有上述主要与其业务领域相关的 cohesive 子集。但是，某些应用程序本质上是跨能力的，例如电子商务应用程序中的端到端查找-结账客户旅程。他们可能需要一个自己的团队（或两个团队，一个负责移动设备，一个负责笔记本电脑）。在应用程序环境中划定界限并将其分配给团队并非易事。以结果为导向是一个很好的指导原则。考虑每个部分是否可以对业务成果或子成果（以业务指标表示）负责。
有些人担心，让一个团队管理业务能力内的多个系统会违背康威定律。但康威定律并不反对由一个团队负责多个相关的组件。它允许组件所有权的高度凝聚力和团队之间的低耦合，从而提高响应能力。
对人员编制的影响
与以项目为中心的执行模型相比，以业务能力为中心的配置可能需要略多的人员。这是因为项目的职权范围通常只是“构建、移交给支持/运营和解散”，而以业务能力为中心的团队的职权范围是“思考、构建和运行”，只要业务能力是相关的。这要求我们始终为每个业务能力至少保留一个最小的团队。事实证明，这出于多种原因是可取的。以项目为中心的模型最终通常会损害应用程序环境的架构完整性，因为每个项目团队只关心在承诺的日期前交付其范围。在此过程中，它可能会走捷径，例如
- 与其依赖的系统进行临时集成
- 与计划淘汰的系统集成或向其添加功能，因为使用替代系统这样做会花费更多精力。
- 在先前团队的工作基础上添加快速而粗糙的代码，并在此过程中使其成为维护噩梦。
其中一些可以通过企业架构的有效监督来避免，但这仍然是一个挑战，因为以项目为中心的模型通常会导致每个新版本都有不同的团队，而新团队必须重新学习业务规则以及周围应用程序环境的注意事项。外包使这变得更加复杂。
另一方面，当资金充足且项目在不考虑现有代码库和应用程序环境的承载能力的情况下被鲁莽地启动时，以项目为中心的模型对庞大的人员编制并不陌生。在项目组合级别缺乏在制品限制会导致许多项目开始，而很少有项目完成或交付预期结果。
战略能力和效用能力
在给定的时间范围内，业务能力可以分为战略能力或效用能力。有时，将能力中的几个子能力标记为战略能力更有用。另一方面，企业 IT 能力（如工资单、会计、法律、人力资源和工作场所协作）通常被归类为效用能力。尽管仍然组织为以业务能力为中心的团队，但效用能力通常使用打包软件（购买而非构建）来交付。因此，他们是“思考、购买、定制/配置/集成和运行”的团队，而不是“思考、构建和运行”的团队。效用能力也通常外包给由托管服务提供商提供的以业务能力为中心的外部团队。即使在内部交付，为这些团队配备保持正常运营的技能而不是一流的开发技能也是切实可行的。同样，尽管以结果为导向对效用能力很重要，但它们可以由级别较低的产品负责人领导。