Enterprise AR Interoperability Requirements Project

Purpose

The AREA Interoperability and Standards Program is conducting in-depth interviews with customer segment AREA members about their requirements for AR-enabling technology interoperability.

Technology interoperability refers to the degree to which software systems, devices, applications or components can connect and communicate with other components (entities) in a coordinated manner without effort from the end user. This is often related to things like data access, data transmission and cross-organizational collaboration. [source: TechTarget].

In addition to the connection and communication being automatic and programmatic (without effort from the end user), all the properties of the original data are preserved and/or all the available features of a component or system are exposed (readable).

It’s valuable to describe interoperability as a property of components within and between systems. Rather than an on/off attribute, it’s also useful to place interoperability between components or systems on a continuum.

Figure 1. Interoperability continuum and the place of interoperability standards

Interoperability is already key to integration of many value-added enterprise solutions with existing data management systems. For example:

• Learning management systems that integrate with employee human resources systems,
• Sales and marketing tools that integrate with financial models and accounting,
• Authentication tools that integrate with employee directories, and
• Resource management systems that integrate with site maps to calculate the transit times for people or materials.

Please see below a few examples of enterprise AR interoperability requirements to better understand the structure of statements that can communicate the enterprise’s AR interoperability needs.

Out of Scope

We do not seek to confirm if interoperability for AR to integrate with IT systems is important.

We are working on the assumption that lack of or low interoperability in AR solutions and integration with existing IT is a significant barrier to adoption. If this assumption is inconsistent with your information or experience, let us know! If you’re not the person responsible for integration, perhaps there’s someone else in your organization who is finding the AR and IT integration challenges a barrier to deployment.

We are not performing these interviews to capture AR system performance requirements. Current AR product features don’t meet all functional requirements for all enterprise AR use cases. We encourage members who have requirements documented for their organizations to contribute to the AREA Requirements Committee. The Requirements Committee is responsible for populating and maintaining the AREA Statement of Needs (ASON) database.

Scope

We believe that your company requires AR-enabling technological interoperability to more effectively and tightly integrate AR technologies into its IT systems and platforms. We seek to understand where and how low AR technological interoperability is preventing or reducing enterprise AR deployments. We are entirely agnostic and do not seek information about any specific platforms or tools your company is using or evaluating.

We are seeking “requirements” for interoperability. Requirements are short/simple statements that provide some details of the obstacles, interfaces or data compatibility problems, but do not include how to solve a problem. A requirement can be stated in a positive way: capabilities that are needed for two or more systems to interoperate.

It may help to begin with who or what has the “problem.” Using the word “must” also helps to shape the thinking around (tightening) the requirement. Another tip is to think in terms of flows of actions, data, people, or results.

Here are some examples of technology interoperability requirements for AR:

• Employees who use an AR display for experience that assistance in performing tasks must be authenticated and their identity verified with an internal directory and secure employee information (e.g., courses achieved, compliance certificates, etc.).
• Experience assets (content files) and coding for interactions with those assets in AR experiences must be stored in formats or containers that follow a data model standard that any of the AR engines used in the enterprise can read and/or ingest for the instantaneous production of experiences without translation and conversions, regardless of the asset’s storage, authorship or size.
• Any system that creates 3D maps of enterprise spaces must save the salient features of the maps in a format that is compatible with the format(s) that any AR system (or standard 3D program) can read and utilize features in the 3D map for anchoring, tracking real-world features and registering digital assets with the real world features in immersive experiences.
• The assets for AR experiences must come directly from internal data management systems without breaking or interfering in any other ways with the digital thread from design to end-of-life/issue closure.
• The AR experience that uses internal digital assets from our content repositories must have access to also record the “check out” of an asset and preserve information about any interactions that took place with the asset and the real world during an immersive experience.
• If you use AR in processes that require compliance validation, the recording that is captured from the AR device must be transmitted and stored in a tamperproof manner, comply with all relevant data retention policies (e.g., Personally Identifiable Information) and be openable/viewable in the compliance system.

Questions/Discussion Topics

• What are the technological interoperability requirements for AR components and content to be integrated with your IT department’s existing systems and tools?
  – What is the most urgent/pressing? Please prioritize the requirements
• Have you or anyone you know attempted to resolve the interoperability issues internally?
  – If so, how? We can go through each of the requirements.
• Have you discussed any interoperability requirements with the vendors from whom you purchase AR enabling technologies, products and services?
  – What have those conversations revealed?
• Have you discussed interoperability requirements with your partners or any suppliers that use AR but are not themselves in the AR ecosystem?
• Who supports (or will support) any interoperability initiatives in your company from a thought leadership and staffing point of view?
  – Are there managers responsible for driving integration and interoperability in general and in particular with AR integration?
• In establishing and maintaining a digital thread for AR content, which IT systems does AR content (or content that facilitates AR) pass through before it can be visualized by users (e.g., CAD programs, LMS repositories, AWS)?
• Which, if any, regulation, policy, or other governance structure (e.g., GDPR) affects how AR content is delivered, recorded, or stored in your organization?
  – How does your organization handle compliance with these?
  – Are there limitations your organization experiences until compliance is in place?

Confidentiality

All interviews will be treated as confidential and the AREA’s staff or non-competitive volunteer member will sign NDAs in preparation for interviews. We may need to interview multiple people in your organization before we reach our goals, and could have separate NDAs, if necessary.

The substance of interviews will be anonymized before it will be included in AREA program deliverables. All our information sources will remain confidential.

Expected Outcomes

By gathering insights across the AREA customer segment (and, perhaps beyond), we seek to reach three outcomes.

Requirements

The requirements that this project will identify will be compiled and summarized in tables. Tables will capture the type (category) of barrier or challenge this requirement would meet, the interface or data that are being held in proprietary formats and silos, and other information. Specific information around requirements will never be attributed to any AREA member company.

These requirements will be shared in blog posts and with organizations that can use them to develop standards or other approaches to addressing the barriers to interoperability.

Customer Dialogs with Vendors and Partners

In the interview, we ask about if/how interoperability discussions with solution and technology providers have begun, evolved and where the problems are perceived to be. The project will present the status of the dialog with vendors and propose some approaches to advance for win-win resolution.

Stakeholders/decision-makers

The project will summarize learnings about the roles of those who are perceived to be most supportive of working on interoperability (and perhaps those roles that might object or fail to see the benefits). This will assist advocates for interoperability in enterprise AR to identify those in their organizations most likely to commit resources for finding interoperability solutions and accelerate AR technology integrations.

Next Steps

The AREA Interoperability and Standards Program will reach out individually to AREA customer segment members and request their time to conduct interviews about the topics outlined above. The team will compile the feedback and knowledge shared by members into materials for different audiences and stakeholders who will find this information valuable.

If you are interested in participating in this program by discussing the topic of requirements with a member of the Interoperability and Standards Program team, please contact Christine Perey [email protected]