Services vs. Capabilities: What’s the Difference and Why Does it Matter?

From our experience, we have seen organizations require their lines of businesses (LOBs) to define a service catalogue to let other LOBs know of the services. The LOB can be internal to the organization or be outsourced. To be clear, a capability is an ability that an organization possesses – what the organization does – whereas a service helps implement a capability – how the organization does it. Some organizations – even with an enterprise architecture group – skip or gloss over the definition and specification of capabilities. With this understanding, why is this distinction important and why should an organization define their capabilities?

The problem with just defining a service catalogue is that the traceability to the organization’s strategic intent and business goals are not clear; the missing link is the definition of the organization’s capabilities. Furthermore, a service catalogue is better understood by the professionals of the LOB and therefore has less meaning by those outside of the LOB; please see the blog “Is Enterprise Architecture a Profession?”

As an example, consider the IT security department of an organization that delivers online pay for play games. The organization’s business goal is to provide an enjoyable and secure online gaming experience for their players. That is, the security of player’s personal and financial information has a high priority to the success of the online gaming delivery and its protection requires a reasonable; so how does the organization determine what is reasonable effort?

In the absence of an enterprise architect, the leader for the security department would advocate for a budget to perform intrusion detection, encryption of all data at rest and in transit, have sophisticated security events management, penetration testing, vulnerability management, file integrity and other security services. These services greatly increase the costs stated in the business case which upsets the plans of other departments in the organization such as IT operations, marketing and player experience. Department leaders accuse each other of over-kill of their services to accommodate apocalyptic scenarios and therefore inflate costs of delivery. Senior management becomes frustrated with the lack of execution on their business goals and try to determine a culprit to account for the poor performance.

An enterprise architect would have a different approach to this problem. Before evaluating the services of each LOB, an architect would define and develop the necessary enterprise capabilities required to achieve the business goals and provide expertise based in leading the exploitation of those capabilities until the intended outcome is achieved. Through discussions with key stakeholders, an architect would be able to determine the expectations of each stakeholder and be able to communicate at a level of detail understood by each department leader. For instance, senior management may agree that personal financial information and transactions will need very strong controls to safeguard but the threshold for other information such as a screen name or city of residence disclosure would be significantly lower and allow for a more flexible architecture for IT operations and marketing. The architect would identify the capabilities needed to support the architecture and what each LOB leader would be responsible for.

It is not the role of the architect to be a subject matter expert for all LOBs but to have enough knowledge to understand each LOB’s delivery capabilities and devise architecture that everyone can work with. With such realizations, an architect can better communicate expectations and how they can deliver on the capabilities identified to the LOBs and allow them the flexibility to align their service delivery to the identified capabilities. From this insight, the architect is also best able to identify risks of the architecture in terms understood by senior management and leaders of the LOBs and align the capabilities to eliminate, mitigate or accept the risk. Capabilities therefore complete the traceability of strategic intent to service delivery.

By understanding how an organization’s services support their capabilities and strategic intent, an organization achieves a strategic advantage from its competitors and is better able to achieve success. At QRS, we are launching an IT Architecture for Business Capabilities course that will train your enterprise architects on delivering business value through information capabilities to your organization.