{"id":62,"date":"2026-08-25T20:24:38","date_gmt":"2026-08-25T20:24:38","guid":{"rendered":"https:\/\/terrydorsey.blog\/?p=62"},"modified":"2026-08-25T22:03:03","modified_gmt":"2026-08-25T22:03:03","slug":"the-enterprise-simplified-4","status":"publish","type":"post","link":"https:\/\/terrydorsey.blog\/?p=62","title":{"rendered":"The Enterprise. Simplified. (Part 4)"},"content":{"rendered":"\n

Business Capabilities Operationalize the Enterprise<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

This is Part 4 of The Enterprise. Simplified. In Part 3<\/a>, I covered enterprise information as a business asset.<\/em><\/p>\n\n\n\n

In the previous article in this series, I suggested that an enterprise is fundamentally represented through business entities and the attributes that describe them. Customers, products, suppliers, employees, contracts, and orders exist independently of the applications that manage them. As the business evolves, those entities accumulate additional attributes that represent what the enterprise knows about itself.<\/p>\n\n\n\n

That naturally leads to another question.<\/p>\n\n\n\n

If enterprise information represents what the business knows, what represents what the business does?<\/p>\n\n\n\n

I believe that’s the role of business capabilities.<\/p>\n\n\n\n

Capabilities vs. Applications<\/strong><\/p>\n\n\n\n

I’ve often noticed that organizations think about capabilities and applications almost interchangeably. Order Management becomes the ERP. Customer Management becomes the CRM. Human Resources becomes the HR platform. Over time, the application becomes synonymous with the business activity it supports.<\/p>\n\n\n\n

They’re related, but they aren’t the same thing.<\/p>\n\n\n\n

A business capability exists because the business performs work. Applications exist because that work must ultimately be implemented. The capability defines the business outcome. The application provides one implementation of that outcome.<\/p>\n\n\n\n

That distinction becomes clearer when we think in terms of business actions.<\/p>\n\n\n\n

Order Management doesn’t exist to expose an ERP system. It exists so the enterprise can create, modify, fulfill, cancel, and track customer orders. Customer Management exists so the enterprise can establish customer relationships, update customer information, and manage interactions. Finance exists to approve credit, issue invoices, receive payments, and manage financial obligations. These actions are business responsibilities before they become software functions.<\/p>\n\n\n\n

The question then becomes how those responsibilities should be presented to the rest of the enterprise.<\/p>\n\n\n\n

Consider something as familiar as an API.<\/p>\n\n\n\n

Most organizations think of APIs as technical interfaces between applications. I think they’re more interesting than that.<\/p>\n\n\n\n

An API such as Create Order<\/strong> shouldn’t be viewed as an SAP API. It represents a business action exposed by the Order Management capability. The API is simply the abstraction through which the enterprise requests that work be performed. Behind that abstraction, the implementation may validate the customer, reserve inventory, calculate pricing, invoke SAP, publish events, notify downstream systems, and initiate fulfillment. None of those implementation details need to be visible to the consumer because they aren’t the business action. They are simply how the business action is carried out.<\/p>\n\n\n\n

That’s an important distinction.<\/p>\n\n\n\n

The capability owns the business action.<\/p>\n\n\n\n

The API exposes the action through a stable abstraction.<\/p>\n\n\n\n

Applications implement the work required to fulfill it.<\/p>\n\n\n\n

The implementation is free to evolve without changing how the rest of the enterprise interacts with that capability.<\/p>\n\n\n\n

The same idea extends beyond APIs. A business action may be exposed through an event, a workflow, a message, or even an interaction with an AI agent. The communication mechanism is an implementation choice. What remains stable is the business action itself because it represents the enterprise rather than the technology.<\/p>\n\n\n\n

This also explains why enterprise information and business capabilities complement one another so naturally.<\/p>\n\n\n\n

Enterprise information describes the state of the business. Customers, products, suppliers, employees, and orders are represented through entities and attributes that accumulate enterprise knowledge over time. Business capabilities describe the behavior of the business. They create, modify, approve, fulfill, reconcile, and otherwise act upon those entities. One represents what the enterprise knows. The other represents what the enterprise does.<\/p>\n\n\n\n

That separation is more significant than it might first appear.<\/p>\n\n\n\n

When enterprise information and business actions are represented independently of applications, implementations become considerably easier to change. ERP systems can be replaced. CRM platforms can evolve. New AI capabilities can be introduced. Internal workflows can be redesigned. Yet the enterprise continues to present the same customers, products, orders, suppliers, and business actions because those representations exist independently of the technologies implementing them.<\/p>\n\n\n\n

The Enterprise and Its Applications<\/strong><\/p>\n\n\n\n

Looking back, I sometimes wonder whether enterprise architecture has spent too much effort describing applications and not enough effort describing the enterprise itself. We create application portfolios, integration diagrams, and technology roadmaps, yet those artifacts inevitably change as technologies evolve. Enterprise information and business capabilities evolve much more slowly because they represent the business rather than its implementations.<\/p>\n\n\n\n

Perhaps that’s where enterprise architecture creates its greatest value.  Not by documenting today’s technology landscape. But by ensuring that every implementation contributes to a stable enterprise representation that outlives the technologies used to build it.<\/p>\n\n\n\n

When enterprise information represents what the enterprise knows and business capabilities expose what the enterprise does, applications become implementation details behind stable business abstractions. That enables people, applications, partners, analytics platforms, and AI agents to participate in the enterprise without needing to understand how the enterprise happens to be implemented today.<\/p>\n\n\n\n

To me, that’s what it means to operationalize the enterprise.<\/p>\n\n\n\n

This is part of what I\u2019ll cover in the last article in this series, Part 5 \u2013 Why AI Needs Enterprise Representation<\/a>.<\/strong><\/p>\n

<\/div>

<\/path><\/svg><\/i> \"Loading\"<\/p>

<\/div>","protected":false},"excerpt":{"rendered":"

Business Capabilities Operationalize the Enterprise This is Part 4 of The Enterprise. Simplified. In Part 3, I covered enterprise information as a business asset. In the previous article in this series, I suggested that an enterprise is fundamentally represented through business entities and the attributes that describe them. Customers, products, suppliers, employees, contracts, and orders […]<\/p>\n

<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n","protected":false},"author":1,"featured_media":65,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-62","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"a3_pvc":{"activated":true,"total_views":6,"today_views":6},"_links":{"self":[{"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/posts\/62","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=62"}],"version-history":[{"count":4,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/posts\/62\/revisions"}],"predecessor-version":[{"id":83,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/posts\/62\/revisions\/83"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=\/wp\/v2\/media\/65"}],"wp:attachment":[{"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=62"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=62"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/terrydorsey.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=62"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}