Platform Engineering for the Non-Platform Engineer: How Low-Code Supports Internal Developer Platforms

An API-first enterprise treats every system as a service with a published contract. Applications connect through those contracts rather than through bespoke, point-to-point integrations. A low-code platform acts as the orchestration layer in that model: it consumes REST and SOAP APIs from systems of record, triggers workflows on business events, writes back results, and exposes its own APIs for other applications to consume. The result is a connected estate without the cost of custom middleware for every new connection.

The integration tax most enterprises are paying

Every enterprise architect eventually comes to the same realization during a planning cycle. The application portfolio has grown to several hundred applications. Each one needed to talk to a few others. The integrations got built one at a time, often by different teams, often with different tools, often documented only in the heads of the people who wrote them. Now every change to one system requires a hunt for the integrations that depend on it.

The numbers behind this are unforgiving. MuleSoft research finds that the average organization runs 897 applications, and only 2 percent of businesses have integrated more than half of them. Ninety-five percent of IT leaders report integration as a hurdle to implementing AI effectively. IT teams report spending 39 percent of their time creating custom integrations. That is more than a third of the IT budget for human effort going into the connective tissue between systems, before any new business capability gets shipped.

The integration tax is the single largest source of hidden IT cost in most enterprises. It is also the reason new applications take longer to deliver than the application itself would suggest. The application takes weeks. The integrations with finance, HR, identity, customer master, and reporting take months. Architecture leaders who want to bring those timelines down have to address the connective layer, not the applications.

Point-to-point versus API-first

The spaghetti comes from a design pattern, not from carelessness. Point-to-point integration is the natural response to "we need system A to talk to system B." It is fast on day one. The cost shows up later, when system C also needs to talk to A and B, and system D needs to talk to A, B, and C. The number of connections grows faster than the number of systems, and every connection is a custom artifact that nobody else can read.

API-first design inverts the question. Before system A is wired to system B, the architecture asks what contract A should publish for the world to consume. The contract is the integration. Other systems talk to A through the contract, not through a custom adapter into A's database. The number of connections grows linearly instead of combinatorially, because every system has one well-defined interface instead of N bespoke ones.

API-first is the prerequisite for a composable enterprise. Gartner predicts that 60 percent of finance organizations will seek composable applications in new technology investments. Composable architectures cannot work without published contracts. Every capability has to expose its functions through APIs, and every workflow that crosses capabilities has to orchestrate through those APIs. That is the operating system of the modern enterprise.

Where the low-code platform fits

API-first design does not eliminate integration. It eliminates the worst kind of integration. Bespoke, undocumented, single-purpose middleware gets replaced by published contracts that anyone can read and consume. But something still has to do the consuming. Something has to call the API, transform the data, route the result, and respond to the next event. That orchestration layer is where a low-code platform earns its place in the architecture.

A modern low-code platform sits at three points in the API-first stack. It consumes the APIs of the systems of record. It exposes its own APIs for other applications to call. And it provides the workflow runtime that triggers and chains those API calls together based on business events. None of this is "glue code" in the legacy sense. It is structured, governed orchestration described as configuration, not as developer-written integration scripts.

Gartner forecasts that 70 percent of new applications developed by organizations will use low-code or no-code technologies, up from less than 25 percent in 2020. A material share of that growth is driven by exactly this orchestration use case. The connective workflows that used to require a development project now get configured in the low-code platform, on top of the published APIs that the rest of the architecture exposes.

Three integration patterns enterprises run on low-code

Pattern 1: SAP plus low-code

The classic enterprise integration story is "the ERP needs a workflow that the ERP itself is too rigid to support." A vendor onboarding process needs to capture compliance documents, route them through finance, legal, and procurement, validate against the duplicate vendor master, and post the approved vendor record into SAP. None of that orchestration belongs inside SAP. It belongs on a low-code platform that consumes SAP's APIs for the vendor master and posts back when the workflow completes.

The pattern repeats across procurement, expense, capital expenditure, and master data. In each case, the low-code platform owns the workflow, and SAP owns the system of record. Both stay clean. Neither bears the burden of being something it was not designed for.

Pattern 2: Salesforce plus low-code

CRM workflows that cross from sales into operations are a common pain point. A new customer is closed in Salesforce; an onboarding workflow needs to trigger across legal, finance, customer success, and IT. Salesforce can model the customer record well. It is less suited for the cross-functional handoffs that come after.

A low-code orchestration layer listens for the "Closed Won" event in Salesforce. It then routes the onboarding workflow through the right approvers, posts the contract to the document management system, creates the customer success record, opens the IT provisioning ticket, and writes status back to Salesforce. The CRM remains the source of truth for the customer relationship. The orchestration lives where it belongs.

Pattern 3: legacy database plus low-code

Almost every enterprise has at least one critical system that pre-dates the API era. A custom database, an inherited mainframe application, a vendor product that exposes only a thin JDBC connection. The legacy system cannot be replaced quickly and often does not need to be. What it needs is to be made addressable.

The low-code platform reads from the legacy database, exposes the relevant data and operations as APIs, and lets the rest of the architecture consume them. The legacy system is not touched. The connective layer is added on top. New workflows treat the legacy data the same way they treat any other API. That is how legacy assets get modernized without a rewrite.

What changes when integration becomes a posture, not a project

The clearest sign that an enterprise has adopted an API-first posture is how a new business capability gets delivered. In a point-to-point world, the conversation starts with which integrations need to be built, who will build them, and how long that will take. In an API-first world, the conversation starts with the business logic and the workflow, because the integrations are already there as published contracts that anyone can call.

Three things change measurably.

• Time to deliver a new capability shrinks. The integration work is no longer the long pole in the project plan.
• Cost of change drops. Replacing one application no longer triggers a hunt for every bespoke integration that depends on it.
• Architectural reasoning gets simpler. The dependency map of who calls what becomes legible because the calls flow through documented APIs instead of through a tangle of one-off scripts.

The architectural and operational benefits are connected. When integration is a posture, the architecture team owns the API standards, the governance team owns the security and lifecycle rules, and the business teams own the workflows that consume the APIs. That separation of concerns is what scales. Without it, the integration tax keeps growing every year.

Governance and observability

API-first design only works if the APIs are governed centrally. Without standards for naming, versioning, authentication, error handling, and rate limiting, the API catalog quickly becomes the new spaghetti. With those standards, the catalog becomes the operating system of the enterprise. Architecture leaders should treat the API governance layer as a first-class system, not as documentation.

Observability is the second half of the picture. Every API call, every workflow execution, every integration event has to be traceable. When a customer report shows up with an inconsistency, the operations team needs to see the path the data took: which API was called, which workflow ran, which transformation applied. A low-code platform that produces this trace by default removes a category of debugging work that used to consume entire teams.

The Kissflow approach to API-first orchestration

Kissflow is the low-code platform enterprise architects use to orchestrate API-first estates without building custom middleware for every connection. It consumes REST and SOAP APIs from systems of record, exposes its own workflows as APIs for other applications to consume, and runs the cross-system workflows that connect the estate together. Pre-built connectors handle the common systems (SAP, Salesforce, Oracle, Microsoft 365, ServiceNow), and a generic API connector handles the custom ones.

Every workflow on the platform is a blueprint, not generated code. The orchestration logic (which API gets called, with what data, under what conditions, and what happens to the result) is described as a structured, readable, auditable configuration. That blueprint is what an API-first architecture needs from its orchestration layer. The integration logic is governed by the architecture team, readable by the business owners, and stable across the application changes that will happen around it.

AI sits inside the build experience, not inside the runtime as opaque code. Where AI assists in Kissflow, it helps draft the initial workflow from a description, map the data fields between two APIs, or suggest the right connector for a system. The output remains a blueprint the team owns and the architecture team can govern. That is what makes the orchestration sustainable as the application portfolio evolves and the integration estate keeps growing.

Frequently asked questions

1. What does API-first actually mean for an enterprise?

API-first means every system in the enterprise publishes a defined contract (an API) before it is integrated with anything else. Other systems consume the contract rather than reaching into the system's internals. The change is architectural, not just technical: integration becomes a posture the architecture takes, not a project that runs once for every new connection.

2. Why is custom glue code such a costly problem?

Custom glue code accumulates faster than it can be maintained. Each integration is built once by one team, often without documentation, and lives until the system it connects to changes. By that point, the people who wrote it have moved on, the dependencies are invisible, and replacing the system means hunting through the codebase to find every place it is referenced. Multiplied across hundreds of applications, the maintenance cost becomes the dominant component of IT spend.

3. How does low-code differ from an enterprise integration platform like MuleSoft or Boomi?

Integration platforms are optimized for high-volume data movement and complex transformations between systems. Low-code platforms are optimized for the business workflows that consume those integrations. In a mature API-first architecture, both have a place: an integration platform handles the heavy data plumbing and the low-code platform handles the business orchestration on top. The two are complements rather than alternatives, and many enterprises run both side by side.

4. Can low-code handle real-time integration, not just batch workflows?

Yes. Modern low-code platforms support both event-driven, real-time integration (a record changes in one system, the workflow fires immediately) and scheduled or batch integration (a synchronization that runs every night). The pattern that fits depends on the business need, not on the platform's capabilities. Most cross-system workflows in an API-first estate run real-time because the underlying APIs are designed for it.

5. What about security and compliance for integrations built on low-code?

Security is enforced at the platform layer: encryption, identity, role-based access, audit logging, and compliance certifications. Integrations inherit those controls automatically. The configuration on top defines which workflows can access which APIs and which data fields, but the underlying security model is managed centrally. That is one of the structural reasons low-code is now an acceptable choice for enterprise integration scenarios that previously required hand-written code.

6. How do we govern the APIs themselves?

API governance is a separate layer from the workflows that consume the APIs. Most enterprises stand up a small API governance function (sometimes called an API platform team) that owns naming standards, versioning rules, authentication patterns, and the central API catalog. The low-code orchestration layer consumes from that catalog. Without the governance layer, the API estate becomes the new spaghetti, even with the right tools.

7. Do we need to wait for all our systems to be API-first before adopting this approach?

No. The orchestration layer can also serve as the API exposure layer for legacy systems that have not yet been modernized. Read from the legacy database or call its older interface, expose the relevant operations as APIs, and let the rest of the architecture consume them as if they were API-first. This is how legacy modernization actually happens in most enterprises: gradually, system by system, with the low-code orchestration layer wrapping older systems until they can be replaced or refactored.