BlackBerry IVY is a cloud-connected in-vehicle software platform developed with Amazon Web Services to help automakers, suppliers, and third-party developers access, standardize, and extract insight from complex vehicle data. Our work focused on making that platform easier to understand, easier to integrate, and far easier to support.
BlackBerry IVY was built to unlock value from vehicle data, but getting started was difficult. Data lived across sensors, edge systems, and cloud services, making the integration path hard to follow.
Developers were not just learning a new platform — they were trying to understand how everything connected, how data moved, and how to confirm it was working properly. The biggest issue was a lack of clarity across the full journey.
Without a clearer and more standardized experience, teams faced slower onboarding, harder support, and more friction building on the platform.
We approached the problem as an enablement and information design challenge. First, we reviewed the end-to-end developer journey to find where users were getting blocked.
From there, we mapped the system visually and reworked the documentation structure in GitBook with clearer onboarding guides, standardized checklists, tutorials, reusable scripts, and troubleshooting flows.
Throughout the process, we collaborated with engineers and stakeholders to validate the experience and make the platform clearer, more repeatable, and easier to support.
This section shows the broader IVY ecosystem, the technical architecture, the enablement system we built around it, and the business value the platform could unlock.
IVY enables a wide range of use cases across OEMs, suppliers, and third-party developers by standardizing access to vehicle data and making that data more usable across connected services.
IVY ecosystem and service coverage across OEM, supplier, and third-party applications.
End-to-end view of how vehicle sensor data moves from in-vehicle systems through the IVY edge layer into cloud services, APIs, and developer tools.
End-to-end architecture from vehicle sensors to cloud services, APIs, and developer tooling.
A closer view of how IVY components communicate across edge systems, OEM telemetry, cloud services, APIs, and developer tools to support scalable connected vehicle applications.
Detailed component communication across IVY edge, cloud services, OEM systems, and developer tooling.
Structured onboarding guides, GitBook documentation, tutorials, reusable scripts, and support content designed to reduce integration friction and make developer adoption more repeatable.
GitBook-based onboarding and support system built to guide developers from setup through troubleshooting.
IVY showed strong potential to reduce operational costs while improving onboarding speed, integration reliability, troubleshooting efficiency, and deployment readiness.
Example outcomes tied to cost reduction, platform efficiency, and improved operational readiness.
Beyond usability and onboarding improvements, IVY demonstrated major potential cost savings by reducing the amount of storage, compute, and telemetry infrastructure needed to support vehicle insights.
IVY enables substantial reductions in cloud storage, compute, and telemetry costs by optimizing how vehicle data is processed and transmitted.
Through platform review and conversations with engineers and stakeholders, we found that the core issue was not just the technical complexity of IVY itself. The deeper problem was that developers could not easily understand how everything connected across sensor setup, validation, cloud data flow, and downstream usage.
We created architecture maps and system diagrams that showed how data moved across the IVY environment — from sensor connection and edge processing through to cloud transmission and use. This helped turn an abstract technical environment into something developers could understand at a glance.
We structured onboarding guides, reusable scripts, tutorials, support content, and troubleshooting decision trees so developers had a clearer path from initial setup to first successful data transmission. The goal was to reduce trial and error and make integration more consistent and self-serve.
The result was a stronger developer enablement layer around IVY. Setup time dropped by about 70%, troubleshooting time dropped by roughly 90%, integration reliability improved by around 55%, and deployment readiness increased by about 45%.
The work went beyond polishing copy. We produced architecture diagrams, improved information architecture, structured GitBook documentation, onboarding guides, reusable scripts, tutorials, troubleshooting playbooks, and support resources that made the platform easier to learn and easier to operate.
These deliverables helped bridge the gap between a technically powerful platform and a usable developer experience.
By improving how developers onboarded to IVY and understood the system, the platform became more scalable as an ecosystem. Better clarity meant faster time to value, lower support overhead, and a stronger foundation for connected vehicle features such as predictive maintenance, safety monitoring, insurance insights, and in-car services.
In other words, better enablement directly supported product adoption.
Tell us what you're building and we'll map out the right approach.