There's a cost hiding in your data organization. It doesn't show up in dashboards. Nobody budgets for it, and your teams have learned to treat it as normal.
A marketing team needs to track a new loyalty tier. A data analyst onboards and can't find the fields she needs. A campaign is ready to run, except the schema isn't. A ticket gets filed. A developer gets pulled. A few days pass. The developer makes the schema change, and the campaign finally runs.
This happens dozens, maybe hundreds of times a year. The individual cost looks small. Aggregated across a year and team, it's a significant, invisible tax on your engineering velocity, paid by the developers who should be building, and by the business teams who learn to expect less. If you’re running Optimizely Data Platform (ODP), we looked at that gap and decided it was worth solving.
The access problem is an engineering problem in disguise
The ODP schema layer (the structure that governs how customer data is organized, extended, and related) is sophisticated infrastructure. Managing it requires API knowledge. The platform is built this way by design. APIs are how production systems should work: precise, permissioned, and auditable.
The problem is that the work itself is often not complex: adding a loyalty rewards object, linking a mobile identifier to a customer record, inspecting what fields already exist before building something new. These are routine operations being handled through a bottleneck that wasn't designed for volume.
Companies may approach the challenge in a variety of ways. At SoftServe, we created Opal ODP Tools to remove the bottleneck. A user opens the Opal tools interface and says:
Create a loyalty rewards object with fields for points, tier, and membership status. Link it to the customers object.
Opal tools return a preview of the planned change, including field types and relation mapping, plus a confirmation step. The user confirms. The schema is live.
What this changes, team by team
The productivity story varies by role, but the shift in each case is the same: people who understand what they need now get it without routing through someone else.
Marketing and campaign teams stop filing tickets for data model changes. Need to add a mobile app identifier before a campaign goes live? Ask for it, confirm the preview, and it’s done before the meeting ends.
Data analysts and scientists onboard faster. Instead of reverse-engineering an undocumented schema or interrupting an engineer to ask what the events object contains, a new analyst asks: "What objects do we have?" Then: "Show me the customers object with all its fields." The analyst gets a complete picture of the data model, all from a conversation.
Engineers and developers get their time back. The team that needed it now handles the work that required API access. Developers move from fielding low-complexity requests to building what requires their expertise.
The safety model is designed for production. Every create operation returns a preview of the planned change and a single-use, time-limited confirmation token before anything executes. Cryptography binds that token to the original request. If anything changes after it's issued, the system rejects the request. Think of it as the natural language equivalent of a pull request review.
Why this architecture works in practice
We applied our Opal ODP Tools to cover 11 operations across all four core ODP entity types (objects, fields, relations, and identifiers) with list, inspect, and create capabilities across each. That covers the full lifecycle of schema management, from exploration and onboarding through active extension.
The integration layer handles resilience, per-request credential scoping, and a consistent error pattern. These aren't afterthoughts; they're what separates a compelling demo from something you'd trust with production data.
One deliberate investment deserves attention: each of the 11 tools ships with rich descriptions, use cases, and examples, the kind of semantic depth that makes a conversational interface reliable. When a user says "tables" or "dimensions" instead of "objects," Opal tools map the request correctly. That behavior is built into how the tools are described.
The bigger shift
Our Opal ODP Tools are a specific solution for a specific platform, and it's also evidence of something worth watching at the strategic level.
AI investment in this space has gone toward conversational BI, letting business users ask questions of data that already exists. That's useful, and it's also the easy half of the problem. It leaves the underlying platform (the schema, the structure, the data model itself) locked behind the same API wall it always was. What's missing across the industry is conversational operations: AI that doesn't just answer questions about the platform, but acts on it, safely, on behalf of the people who depend on it.
From our experience, the real value comes from AI that operates the platform, not one that only queries it. Query layers give teams read access. Operations layers give them the ability to shape the system.
This solution exists for Optimizely Data Platform today. But the pattern isn't unique to ODP. Any platform with a complex API, such as a CDP, a CMS, a marketing cloud, an analytics tool, creates the same problem for the business teams who depend on it. And the same solution applies.
Enterprise software is opening up to a new class of operator: whoever builds the layer that makes the API disappear.
See where your platform's API bottleneck is costing you velocity. Talk to our Optimizely practice about an assessment to get a high-level analysis of where you stand.
