From Business Processes to Business Capabilities

The process map is not the system

Every integration engagement starts the same way. Someone shares a swimlane diagram: quote-to-cash, order-to-delivery, hire-to-retire. Twelve boxes, four systems, three handoffs that “usually work.”

For twenty years we integrated by wiring that diagram. Each arrow became a point-to-point call, an ESB route, or an iPaaS flow. It worked as long as the process stayed still and the only consumer was the process itself.

Neither is true anymore. Processes change every quarter, and the new consumer is an AI agent that does not follow a swimlane. It reads a goal, looks at the tools it has, and decides the path at runtime. Give an agent a hard-wired process and it can only replay it. Give it well-defined business capabilities and it can compose new paths you never drew.

This post argues for a shift in the unit of integration, from the business process to the business capability. It takes the view of the person who has to make that shift real on site: the Forward Deployed Engineer. And it shows where Ikanos, the open source capability engine, fits.

On the left, each process carries its own copy of the wiring. On the right, the wiring lives once, inside named capabilities that any consumer can compose.

A process is a path; a capability is a place you can stand

A business process describes how work flows: in what order, by whom, through which systems. A business capability describes what the business can do, whatever the path: Check Credit, Reserve Inventory, Issue Refund.

Ulrich Homann put it this way in 2006: capabilities “remain stable while the processes, or business implementations, change.” We traced that lineage in From Data and APIs to Capabilities. The point here is practical. If processes change and capabilities persist, you should integrate at the level that persists.

Processes do not disappear. They become one way, among many, of composing capabilities. Some still need a durable engine, with long waits, human approvals and compensation. The rest, which is most of the day-to-day, can be composed on demand.

The Forward Deployed Engineer sees the gap first

The Forward Deployed Engineer (FDE) is the engineer who ships inside the customer’s environment, not beside it. They sit with the operations team, get VPN access on day three, and find out the real system of record is a spreadsheet nobody mentioned.

That proximity gives the FDE a view the process map hides. Three patterns come up in almost every engagement:

• The same capability hides inside many processes. “Check credit” appears in order entry, contract renewal and partner onboarding, wired three times against the same ERP.
• The process map is aspirational. The documented flow has twelve steps. The real one has nine, two workarounds and a Friday batch job.
• The hard part is never the logic. It is SSO, OAuth scopes, firewalls, an undocumented SOAP endpoint and a rate limit nobody wrote down.

An FDE who automates the process as drawn ships something brittle. One who extracts the capabilities underneath ships something the customer can reuse after the engagement ends.

That is the real job: turn tacit knowledge into named, governed, reusable capabilities, and leave them behind as assets the customer owns. The process map is input. The capability catalog is the deliverable.

Agentic integration composes; it does not replay

In classic integration, the path is fixed at design time. In agentic integration, an agent receives a goal (“this customer wants to upgrade, make it happen”) and chooses which capabilities to call, in which order, based on what it learns along the way.

That only works if the capabilities are shaped for it. An agent pointed at raw APIs sees hundreds of CRUD endpoints, burns its context window on payloads it does not need, and guesses at side effects. An agent pointed at a process gets one big tool that does exactly one thing. Neither is integration.

What an agent needs from each capability:

1. A business name and a clear description, so it can pick the right one.
2. Typed inputs and right-sized outputs, so it spends tokens on the task, not on the payload.
3. Declared semantics: is it safe to retry, does it change anything, can it be cached?
4. Governance at the boundary: authentication, scopes and an audit trail the customer controls.

Where Ikanos fits: the capability becomes the artifact

Ikanos is the open source capability engine for Spec-Driven Integration. One YAML file describes a slice of the business. It consumes the HTTP APIs the customer already has, aggregates and orchestrates their operations into business functions, and exposes them as MCP tools for agents, Skills for structured discovery and REST for apps and partners. No code is generated or compiled: the spec is the runtime contract.

For an FDE, that maps cleanly onto the job:

• Consumes is where the on-site mess goes. Upstream calls, credential bindings, auth (bearer, API key, OAuth 2.1) and format conversion (XML, CSV, Protobuf to JSON) are declared once and visible in review.
• Aggregates is where the capability lives. A function is defined once, with its steps, mappings and semantics, and referenced from every adapter.
• Exposes is where the consumers plug in. The same capability serves the agent over MCP and the portal over REST.

The messy part and the reusable part sit in separate sections of the same file, so each can change without touching the other.

Here is the shape, trimmed from the Ikanos tutorial. A business function resolves a record plus its related data in one call, and is declared safe and idempotent:

capability:
  consumes:
    - import: registry
      from: ./shared/registry-consumes.yml

  aggregates:
  - namespace: crew-resolver
    flows:
      resolve-crew-for-ship:
        description: "Resolve crew names and roles for a given ship"
        semantics:
          safe: true
          idempotent: true
        inputParameters:
          imo: { type: string, required: true }
        steps:
          get-ship:
            type: call
            call: registry.get-ship
            with: { imo_number: "{{imo}}" }
          list-crew:
            type: call
            call: registry.list-crew
          resolve-crew:
            type: lookup
            index: list-crew
            match: crewId
            lookupValue: "$.get-ship.assignedCrew"

  exposes:
  - type: mcp
    namespace: shipyard-tools
    tools:
      get-ship-with-crew:
        description: "Get ship details with resolved crew names"
        ref: crew-resolver.resolve-crew-for-ship

Swap ships for customers and crew for credit lines, and you have Check Credit. Three properties matter most in the field:

• It runs where the FDE works. A single Docker image, self-hosted inside the customer’s network, next to the legacy systems it consumes.
• It is reviewable. The capability is a file in a pull request. Security can read every upstream call before it runs, and Polychro can lint it in CI.
• It outlives the engagement. The customer keeps a catalog of specs they own, not a pile of glue code only the FDE understands.

Ikanos is deliberately not a workflow engine. Durable, long-running processes with schedules and human waits still belong in a runtime built for them. Ikanos supplies the capabilities those processes, and the agents beside them, call.

It is also request–response today. Event-driven triggers and streaming are not what Ikanos is for, so an FDE facing those still pairs it with the customer’s messaging layer.

A field playbook: from process map to capability catalog

Six steps take an FDE from the swim lane diagram on day one to a catalog the customer runs on their own.

1. Walk the process, then circle the verbs. Every step that reads “check”, “reserve”, “notify” or “approve” is a candidate capability. Name each one verb-plus-noun, in the business’s own words.
2. Count the repeats. List every process each candidate appears in. A capability used in three processes is worth building first; one used once can wait.
3. Find the real system of record. For each capability, trace which APIs, databases or files actually hold the answer. Expect surprises. This becomes the consumes section.
4. Declare the contract before the plumbing. Write the inputs, the right-sized outputs and the semantics (safe, idempotent, cacheable) first. This becomes the aggregates section, and it is the part the business can review.
5. Expose to every consumer from one spec. MCP for the agent, REST for the existing app, a Skill to group related tools for discovery. One source of truth, no fork per audience.
6. Hand over the catalog, not the code. The customer keeps versioned specs in their own repository, linted in CI, with an owner per capability. The next process, or the next agent, starts from there.

Discovery happens with the operations team. Steps 3 to 5 each fill one section of the Ikanos spec, and step 6 hands it to the customer.

The test of a good engagement is simple: when the next process change lands, does the customer edit one capability, or rewire a flow?

Integrate what lasts

Processes describe how a business works this quarter. Capabilities describe what it can do, whichever way the work flows. Agents make that difference concrete, because they compose their own paths at runtime.

The Forward Deployed Engineer is the person best placed to make the shift. They see the real systems, the repeats and the workarounds. With Ikanos, what they find becomes a declared, governed, self-hosted capability, and the customer keeps it.

Start with one process you are wiring this month. Circle the verbs, pick the one that repeats most, and declare it as a capability.

The takeaway

• Processes change every quarter. Capabilities persist. Integrate at the level that persists.
• Agents compose their own paths at runtime, so they need named, typed, right-sized capabilities, not replayed flows or raw endpoints.
• The Forward Deployed Engineer’s real deliverable is a capability catalog the customer owns, not glue code.
• In Ikanos, the catalog is a set of reviewable YAML specs: consumes for the on-site systems, aggregates for the business functions, exposes for MCP, Skill and REST.
• Keep durable, long-running processes in a workflow engine, and let it call the same capabilities the agents use.

Further reading

• 📄 From API-Led to Capability-Led Connectivity
• 📄 From Data and APIs to Capabilities
• 📄 Beyond iPaaS: Why Capabilities Are the Right Unit
• ⚙️ Ikanos · 🧪 Playground · 📖 Documentation · 🎨 Polychro