Building Scalable AR: The High Price of Going It Alone

Recently, I had the opportunity to visit the Silicon Valley HQ of a prospective customer, a Fortune 500 enterprise technology conglomerate with a name most people would recognize. They had expressed an interest in adopting the Scope AR platform, and we walked into the meeting assuming that would be the main topic of conversation.

Most of the people at the meeting, however, weren’t the usual folks who make software buying decisions. Instead, I found myself sitting across from a group of the company’s own software engineers. For the next two hours, they asked detailed questions about how Scope AR had solved some of our toughest technical problems.

I knew right away what they were up to: They wanted to build their own AR solution from the ground up. The real purpose of the meeting, it turned out, was to pick my brain for the technical know-how they needed to do the job.

I could have walked out then and there, but I didn’t. I sat through the interrogation, and I actually answered most of their questions.

Build your own: The alluring illusion of AR development

This might seem crazy: CEOs don’t earn their keep wandering the globe, spilling trade secrets to anyone who asks. But I’ve seen this before, and I know how this story ends. Sooner or later, I had a feeling we would reconnect—and this time, they would understand why so many enterprises choose to work with Scope AR rather than trying to build their own AR applications.

I also get why so many companies have to learn this lesson the hard way. Our team at Scope AR started down the same path, for many of the same reasons, a decade ago. We know why a DIY approach looks so alluring at first, and we also know why it’s easy to pour resources into what looks like a winning investment.

We also know why these projects, almost without exception, turn into the software engineering version of quicksand: the harder you work to stay afloat, the deeper you sink.

Going deeper: inside the AR development process

Let’s look more closely at why AR development looks at first like such a good fit for a DIY approach—and at why the truth is usually very different.

First, it’s important to understand that AR applications are a very real source of value across a wide range of industries and use cases. Scope AR customers, for example, include industry leaders in aerospace and defense, medical device development, knowledge and learning management, and advanced manufacturing, among others. They work with Scope AR because we give them a scalable, cost-effective AR platform that delivers the potential they already recognized in the technology.

In many cases, that romance with AR technology started with an internal proof of concept (PoC) project. These are intimate affairs by enterprise IT standards: funding for a couple of developers, often by way of a company’s technology innovation or R&D budget, and some enterprise-licensed seats for Unity, a real-time 3D development environment that has emerged as a de facto industry standard for building AR applications. Unity excels at prototyping cross-platform AR/VR applications. It has a solid toolset. It natively supports development in C#, which is a language most enterprise developers can pick up pretty easily. And while Unity isn’t free for enterprise use, it’s not very expensive, either.

Throw all of this into the enterprise IT blender, wait six months, and there’s a good chance you’ll get a proof of concept for an enterprise AR use case that’s popular with users and shows real value potential to the business, and even might interface with a corporation’s internal systems.

Before a successful PoC gets promoted to a production environment, however, it will need to do a number of things nobody asked it to do the first time around.

This is where reality starts intruding on the romance.

The many dimensions of running AR applications at scale

While there’s a lot to love about Unity as an AR prototyping environment, it’s a lot less lovable as a conduit for building scalable, production-ready AR applications. A team’s second time through the AR development process for a second use case will probably cost about as much and take about as long as the first one did. So will its third AR project . . . and its fourth.

What’s worse is that none of these applications are going to scale in any meaningful way.

When we talk about scalability, the conversation can focus on a number of topics. Is your AR application configured and optimized for its intended deployment? Can your provisioning workflow scale to hundreds or even thousands of endpoints for use cases involving front line workers? Has your application been tested and validated across every platform and device type in your company’s inventory, including those being purchased in the future? What about security—especially when your AR application handles data subject to PCI or HIPAA compliance?

Then there’s the development side of the equation. Is your home-grown AR application going to incorporate tools and UI/UX elements that allow non-developers to adapt it for new use cases? Or will it turn into yet another ongoing project, and another source of technical debt, for an overworked IT department?

But for now, let’s focus here on just one facet of scalability: your content.

The content conundrum for do-it-yourself AR: one company’s story

Most enterprises that adopt AR applications already manage a significant amount of content. And in one way or another, content will play a decisive role in the success or failure of an AR project.

One of the most vivid examples I can think of involves a global aerospace firm whose name you might recognize. This firm happens to be a prospective Scope AR client; our conversations over the past several months included a fascinating deep dive into the company’s technical documentation library. This content serves a mission-critical purpose: documenting every aspect of the company’s aircraft assembly, testing, maintenance, and repair processes, right down to the smallest individual components.

This company also happens to maintain a custom-built AR platform designed to help employees learn and perform a wide range of product assembly and repair tasks. Importing and integrating the company’s technical content will be a critical step towards making the system useful to its assembly-line and service teams—and to getting value from its AR development investments.

Unfortunately, that’s exactly where the company is running into one of its biggest AR development challenges: most of its technical documentation currently resides in a legacy product lifecycle management (PLM) system. The vendor of that system had already confirmed that it could facilitate the process of accessing, converting, and integrating that content with the company’s custom-built AR application—but only at a cost that even one of the world’s biggest aerospace companies found prohibitively expensive.

This story will have a happy ending: Scope AR has already created a tool that can perform exactly the same task: moving relevant content out of a legacy PLM system and into the Scope AR platform, where it will be far more useful and accessible to front-line workers. It’s just one of many similar ways that we leverage some very hard-earned lessons about building and scaling AR solutions—allowing customers to enjoy the benefits minus the cost, complexity, and pain that comes with any do-it-yourself AR effort.

Here’s the thing. There are countless ways for content to add cost, complexity, and risk to an in-house AR project. Most organizations don’t have just one content repository: they maintain multiple data warehouses, database systems, content management systems, and repositories for audiovisual, geospatial, and other specialized data types. Each will require a separate integration workflow and bring its own concerns over versioning, data security, compliance, and so on.

And then we still have to talk about the complexities of converting dozens of data formats into something that your AR application can ingest, manipulate, and display to end users. It’s an exacting process that will require endless experiments, false starts, and expensive mistakes—along with the ever-present risk that you might simply run out of time, money, or developer bandwidth before you see one dollar of ROI.

The best mistakes are the ones you never have to make

I mentioned earlier that I have watched, over and over, as companies try to scale AR projects that won rave reviews in their PoC stage. And nearly 100 percent of the time, I watch as those projects implode under the weight of technical debt, or stumble on issues integrating content and other enterprise applications, or attempt to scale by soaking up IT resources like a gigantic sponge.

And of course, our team at Scope AR, myself included, got the best seats in the house for one of these contests—because we were the ones making the mistakes. We learned hard lessons about scaling and succeeding with enterprise AR application development, and we slowly built the tools and methodologies required to deal with them, and built the most scalable platform for the many many use cases we’ve encountered over the years.

It was a slow, painful, often expensive process. And the only reason it made sense for us to solve these problems is because it’s how Scope AR creates value for our customers.

Like I said, I get it: Some companies only learn from the mistakes they make themselves. But when you’re talking about AR applications, trying to stay with a go-it-alone approach can be especially painful and costly.  And with Scope AR, we’re doing everything we can to give enterprises a better way to work with AR applications.

Interested in building AR applications more easily? Reach out to us to get started.  

‍