Business Capability Centric
8 June 2016
A business-capability centric team is one whose work is aligned long-term to a certain area of the business. The team lives as long as the said business-capability is relevant to the business. This is in contrast to project teams that only last as long as it takes to deliver project scope.
For example, an e-commerce business has capabilities such as buying and merchandising, catalog, marketing, order management, fulfilment and customer service. An insurance business has capabilities such as policy administration, claims administration, and new business. A telecom business has capabilities such as network management, service provisioning and assurance, billing, and revenue management. They may be further divided into fine-grained capabilities so that they can be owned by teams of manageable size.
Business-capability centric teams are “think-it, build-it and run-it” teams. They do not hand over to other teams for testing, deploying or supporting what they build. They own problems in their area end-to-end. They also own the IT systems (applications, APIs and data) that primarily support the business-capability. The underlying technology platforms (e.g. Java, .NET) and application platforms (e.g. Salesforce, SAP, Peoplesoft) may be shared across teams.
Sriram's book goes into more detail on how and why to build a business-capability centric IT organization.
The team size for each capability is determined periodically, such as annually, based on guidance from IT strategy. This is a different kind of portfolio management where budget in the form of team capacity is allocated across a portfolio of long-lived business-capabilities whereas in traditional portfolio management, budget in the form of funds is allocated across a portfolio of comparatively short-lived projects/programs. Business-capability centric teams need to be OutcomeOriented to maximize their potential. Unless they are empowered to work towards a business outcome, they may devolve to being scope-delivery oriented.
Consider the example of a typical application landscape with a mix of up-to-date and legacy systems, some homegrown applications and some commercial off-the-shelf (COTS) applications, some SaaS applications, a heterogeneous API layer served by some new microservices, some mega-services and everything tied together with a combination of ad-hoc integration, an enterprise service bus and other boutique middleware. Each business-capability centric team would own a cohesive subset of the above that primarily relates to its business area. However, some applications are cross-capability by nature e.g. the end-to-end lookup-to-checkout customer journey in an e-commerce application. They might need a team of their own (or two teams, one for mobile and one for the laptop). It is a non-trivial exercise to draw boundaries within the application landscape and parcel it out to teams. Outcome-orientation is a good guiding principle. Consider if each parcel can be held responsible for a business outcome or sub-outcome (expressed as a business metric).
Some people are concerned that having a single team manage several systems within a business capability will act against ConwaysLaw. But Conway's law isn't against a single team being responsible for multiple related components. It allows for high cohesion of component ownership and low coupling between teams and thus makes for better responsiveness.
Implications for Headcount
A business-capability centric configuration may require a slightly greater headcount than a project-centric model of execution. This is because a project’s remit is typically only to “build-it, handover to support/ops and disband” while a business-capability centric team’s remit is to “think-it, build-it and run-it” for as long as the business-capability is relevant. This requires us to maintain at least a minimal team at all times for each business-capability. As it turns out, this is desirable for a number of reasons. The project-centric model usually ends up compromising the architectural integrity of the application landscape because each project team only cares about delivering its scope by the promised date. In the process, it may take shortcuts such as:
- Ad-hoc integrations with the systems it depends on
- Integrating with or adding functionality to systems that are meant to be sunsetted because it would take more effort to do so with the replacement systems.
- Tacking on quick-and-dirty code on top of a previous team’s efforts and making it a maintenance nightmare in the process.
Some of this may be avoided with capable oversight from enterprise architecture but it remains a challenge nevertheless because the project-centric model often results in a different team for every new release and the new teams have to learn business rules and do’s and don’ts of the surrounding application landscape all over again. Outsourcing complicates this further.
On the other hand, the project-centric model is no stranger to huge headcounts when funding is plentiful and projects are initiated recklessly without regard to the carrying capacity of the existing codebase and application landscape. The lack of work-in-process limits at a project portfolio level leads to many projects getting started and few finishing or delivering desired outcomes.
Strategic and Utility Capabilities
Business capabilities may be categorized as strategic or utility over a given time horizon. Sometimes, it is more useful to label a few sub-capabilities within a capability as strategic. On the other hand, corporate IT capabilities such as payroll, accounting, legal, HR and workplace collaboration are usually classified as utility. Although still organized as business-capability centric teams, utility capabilities are often delivered with packaged software (buy over build). So they are “think-it, buy-it, customize/configure/integrate-it, run-it” teams rather than “think-it, build-it, run-it” teams. Utility capabilities are also commonly outsourced to external business-capability centric teams supplied by managed service providers. Even when delivered in-house, it is practical to staff these teams for keep-the-lights-on skills rather than top-notch development skills. In the same vein, although outcome-orientation is important for utility capabilities, they could be led by lower grade product owners.