The catalog is the easy part. The plumbing behind it is not.
Most organizations can stand up a service catalog. Far fewer can make it deliver, because the request is the easy part and the fulfillment is where everything breaks. A clean portal that asks for a new laptop, a new hire’s accounts, or a contractor’s building access still has to reach into the ITSM tool, the HR system, the identity provider, the procurement platform, and a facilities system that may not have an API at all. When those handoffs are manual, you get the status quo most IT and operations leaders live with today: requests tracked in spreadsheets, approvals chased over email, and the same data re-keyed into four systems by hand.
This is the third post in a series on the enterprise service catalog. Part one defined the business service catalog; part two made the case for taking it beyond IT. This post is about the architecture underneath, and where a workflow orchestration platform fits.
Kinetic Data is an enterprise workflow orchestration platform that acts as a modernization layer: it sits on top of your existing systems of record, orchestrates work across them, and gives users a single front door, without ripping out the ITSM, HR, or ERP systems you already run. That is the part of the service catalog architecture this post is really about.
Forrester’s three levels of catalog maturity
In the Forrester report Master the Service Catalog Solution Landscape in 2013, analysts Eveline Oehrlich and Courtney Bartlett describe three levels of catalog maturity:
- Level one delivers IT services through a standard set of choices and requests.
- Level two automates enterprise services beyond IT.
- Level three turns the catalog into a service broker, coordinating fulfillment across many functions.
The valuable work happens at levels two and three, and the reason is simple: the requests that matter most are rarely single-system. New employee onboarding is the canonical example. It is not an IT task. It pulls in HR, finance, facilities, security, and IT, each with its own system of record, each with its own owner. A catalog that only files an IT ticket has solved the smallest slice of the problem.
That is also where the architecture stops being a portal project and starts being an orchestration problem.
The three layers of the architecture
Forrester frames the catalog as a demand side from the business and a supply side from IT and other functions. In practical terms, the architecture has three layers, and most catalog efforts only get the top one right.
The front end: one simple door, many tailored views
The demand side is the portal users actually touch. It should be simple, intuitive, and written in plain business language, not the vocabulary of the system fulfilling the request. The standard most people quietly hold it to is consumer software: the request, the status tracking, and the personalization they get from any major retail site, applied to enterprise services.
One front end does not mean one identical view. The look and feel stays consistent while the choices adapt to who is logged in. A line employee should not be able to requisition a new hire. A travelling salesperson and an office-bound analyst can be shown different hardware options. The catalog presents the right menu to the right person and hides the rest.
The middle: consumers, roles, and interfaces
The middle layer governs who sees what and how requests are routed. This is role and entitlement logic, not cosmetics. Tailoring the interface by login is what keeps a single catalog usable across a workforce with very different needs and permissions, and it is what lets one portal serve IT, HR, and finance without becoming a mess of conditional forms.
The bottom: integration with systems of record
This is where most catalog projects quietly fail, and where orchestration earns its place. Forrester puts “integration with IT systems and business applications” at the lower level of the architecture. That bland phrase is the entire game. It means passing data securely between systems, automating approvals and resource scheduling, and eliminating the redundant manual re-entry that makes service delivery slow and error-prone.
You can buy connectors. Every vendor in this space ships them, along with no-code builders and self-service portals. Those are table stakes, not a strategy. The hard part is orchestrating a request that touches five systems, in the right order, with approvals and rollbacks, and an audit trail that holds up when someone asks what happened and why.
Where Kinetic fits, and why it is different
Two things separate a workflow orchestration platform from another catalog tool, and they are the two things competitors cannot credibly claim.
First, the modernization-layer architecture. Kinetic does not try to become your new system of record. It sits above the ITSM, HR, identity, and ERP systems you already own, orchestrates work across them, and owns the user experience on top. You modernize the front door and the cross-system workflow without a migration, and without forcing every service into one backend’s data model. That is “modernize without rip-and-replace” in concrete terms, and it is how an onboarding request can fan out to five systems and report back as one clean status.
The catalog your users see should never depend on replacing the systems that fulfill it.
Second, a government-grade security posture. Kinetic has spent more than twenty years in defense and intelligence environments, with IL5 authorization and CAC support. For enterprise and government IT leaders, that is the difference between a catalog that handles a laptop request and one cleared to orchestrate sensitive provisioning and access workflows.
The value chain is straightforward. Because Kinetic layers on top of existing systems instead of replacing them, organizations such as the USDA and the Defense Innovation Unit have deployed orchestrated request workflows without standing up a new system of record first. The catalog becomes the visible part of a deeper modernization, not a standalone tool bolted onto the side.
AI belongs in the steps, not in the wheel
A modern catalog will field AI questions, so it is worth being precise. AI is genuinely useful here. At design time it accelerates building and configuring workflows. At runtime it works well as a discrete step inside a workflow: classifying an incoming request, extracting fields from a free-text description, recommending the right catalog item, or summarizing a long approval thread for the person who has to sign off.
What AI should not be is the thing that executes the request. Provisioning accounts, routing approvals, and fulfilling across systems of record needs to be deterministic, repeatable, and auditable, especially in regulated and government environments. The principle is simple: build with AI, run with Kinetic. AI advises, humans decide, and the workflow executes the same way every time, with a record of what happened.
What this means for your roadmap
Forrester’s authors predicted the term “service catalog” might eventually feel too small, because the real work is managing the full life cycle of services the business consumes. That is the right instinct. A catalog initiative that stops at a portal solves the visible problem and leaves the expensive one untouched.
If you are evaluating or rebuilding a catalog, judge it by the bottom layer, not the top. Ask how it orchestrates a request across the systems you already run, how it handles approvals and exceptions, and what the audit trail looks like when something goes wrong. That is where service delivery is won or lost.
See how the modernization layer works in practice, explore service delivery use cases across IT, HR, and facilities, or look at how government and defense teams put it to work. If you want a concrete starting point, onboarding is usually the request worth orchestrating first.
Share this article