The QPath Blog
QuantumPath® and mitigating the impact of change on quantum computing vendors
We are living a continuous, and often dizzying, advance in the disruptive world of quantum computing. It is a fact that, along this new path that has opened around such novel technologies, it is a relevant element to foresee that changes will occur. From major breakthroughs in each technology, to the constant evolution of other established technologies, to the appearance of new manufacturers with new technological proposals, to possible changes of direction or potential abandonment of paths.
In any technological solutions project, change is a critical element that must be measured and controlled to mitigate situations that can greatly affect such projects. In the case of quantum technologies, where everything is being evaluated, investigated multilaterally, looking for new ways to evolve the current technology becomes a fundamental strategic element of risk management. Even if we catch it at a sweet moment in which we know that everything is still being analysed, measured, evaluated… it is still a critical element, with great impact, on which an entire project may depend.
What impact can a change in each quantum technology provider have? How many proofs of concept, demos, webinars, research, presentations, frameworks and products can be affected by a change like this? What is the impact if a change like this occurs and, due to business reasons, the use of this technology under these conditions suddenly becomes unprofitable and we are forced to look for technological alternatives? What happens if, suddenly, we detect that there is no alternative and we are forced to radically change our strategy, with a certain roadmap behind us and a certain time and costs already assumed?
Figure 1. Classical IT architecture that implement quantum hardcoded uses cases
No doubt there may be certain transition times, but it is undeniable that a change of direction of a given quantum technology has a potential impact on the industry. All those who had developed assets specifically for a platform under certain conditions may be forced to modify their strategy. And in many cases, this could mean a change in which limited options could lead to the failure of certain types of projects. And questions such as:
What happens to my developed assets?
What happens to all the results of my executions?
Do I have a similar technological alternative?
How long will it take me to adopt an alternative technology?
What does an alternative technology cost me?
What other options do I have to be able to keep my developments running longer?
For reasons such as these, among others, when designing and developing QuantumPath® we always strive for quantum computing vendor agnosticism, offering a development and execution framework that focus on the assets versus the vendor. All design and build tools, as well as the execution ecosystem, are based on this concept: making the algorithm layer independent from the execution layer. Leaving all the details to the more internal layers of the product which, thanks to its modularity and adaptability, takes on the challenge not only of facing technological changes from a provider, but also that the platforms themselves can evolve over time or even disappear at any given time.
Thanks to the agnostic core of QuantumPath® in the face of a possible change that may occur in certain events such as those mentioned above, the impact for the user can be reduced to almost zero. Why?
1) All developments made with gate or annealing technology are not totally dependent on a specific quantum provider/QPU. They are vendor-independent designs and abstractions. This allows all developments made with QuantumPath® to remain intact and the impact of the change is more focused on having technological options where the flows can continue to be executed. And there are options.
2) Both the construction of quantum assets and their exploitation in hybrid architectures are based entirely on the agnostic capacity of QuantumPath®. So, a change in quantum provider status is fully transparent to the upper layers. This means that, at the overall solution level, such a change does not affect the project. Our assets are maintained, technological alternatives exist, and we do not stand still.
3) All the added value and collateral elements of the project remain almost intact. Documents, publications, presentations, interactions… remain intact since the context of the project has not changed.
Figure 2. QuantumPath® isolates the low-level’s quantum provider details from the use cases
Of course, a change like this may affect the core of QuantumPath® as there are a number of low-level adapters for each quantum provider that are affected. But it is something that is assumed as part of the services offered by the platform. In other words, these risks are not attributable to the user, but to QuantumPath® itself. It is in our know-how to be prepared to always look for new suppliers and adapt to change. Removing this indicator from the elements to evaluate industry projects.
What this change can mean for QuantumPath® customers?: above all, always having information about the change, a managed and controlled cancellation of the affected suppliers from the catalogue of available suppliers, as well as the assisted cancellation of access to the solutions created. In addition, to provide a whole catalogue of alternative suppliers to associate with the solution – if they were not already associated with it – allowing the user to have alternatives so as not to be left at a standstill at any time. And most importantly, without losing the assets, telemetry and all the results obtained from the start of the project. It is even possible to access existing/historical results from the qSOA® API, thus democratising access to suppliers. This even temporarily makes it possible not to lose functionalities, even if the latest data is not available.
Recently, thanks to our experience and QuantumPath® agnostic resources, a real case of change in a quantum technology provider has been agilely mitigated in production for the users of its platform: until 17 November 2022 Amazon Braket provided its users with access to D-Wave QPUs through its cloud services. According to the company, on the same day Braket cancelled D-Wave’s Braket providers, which implied the cancellation of the URNs of the D-Wave computers, as well as all API references wrapping the Braket SDK for D-Wave.
For the recently case reported by Amazon Braket and the availability of D-Wave providers, the impact on QuantumPath® customers has been managed through the following steps:
· Make QuantumPath® native D-Wave providers available if they want to continue to have the technology available in the new context.
· Have the local OCEAN simulators (ExactSolver, Simulated Annealer Sampler) in order to be able to keep the same functionality, even if it is at stake to evaluate the costs and the continuation of using the QPUs.
· Have the new Q Agnostic QAOATM technology from QuantumPath®, which allows optimisation algorithms to be run on gate machines. Which may even be the same ones provided by Braket in its ecosystem. Therefore, taking advantage of all the gate providers offered by Amazon Braket.
All this, without losing execution history and without altering their quantum assets beyond altering the solution to set up a new connection configuration. Of course, all this without changing all the architectural elements built on this basis: all the hybrid classical-quantum systems would have remained unchanged. This is clearly a competitive advantage and a control of change by the users, who have not been affected by the change.
Vendor availability, hardware pauses due to maintenance, deactivation windows, API updates… are examples of situations that will occur along the path of incipient quantum computing. The evolution of technologies, the scaling of resources -such as those announced by IBM-, the creation of new providers or the disappearance of others, will mark a path of constant evolution and adaptation of which all participants in the industry will have to be aware. And at QuantumPath® we have the technology and experience to mitigate this. Our focus is always on providing a stable platform, adapted, and updated to the changes and that makes possible the creation of robust and vendor-agnostic hybrid architectures that will enable the continuity of projects while minimising the impact of change.
We should not end this article without commenting that the added value of QuantumPath® described above is not only for the user, but also for the participants themselves who motivate the change. The technology providers themselves can benefit and reduce the impact of change, given that QuantumPath® provides alternatives that can help the clients of both companies to define their lines of action, either because the changes are mitigated, or because existing resources are strengthened, which will allow them not to lose relationships, reuse already established contracts, and negotiate new conditions. This does not directly affect ongoing projects.
Taking advantage of this article to disseminate, also through this medium, the information guide that has been provided to QuantumPath® users to adapt to the recent change in the Amazon Braket ecosystem:
QuantumPath®, by having agnosticism in its DNA, provides a strength in the face of change that can provide enormous added value to quantum projects. This, coupled with many years of knowledge in distributed architectures, also benefits industrial designs to mitigate the impact of core technology changes thanks to the qSOA® API. Together with all the tools to come, they will provide a robust and reliable ecosystem ready for change, without impacting the business.
The technology-agnostic approach to quantum providers is a robust, realistic and forward-looking strategy that can be decisive in mitigating the risks implicit in changing quantum technologies, especially at times like the present, when changes in quantum technologies are the order of the day. That is why QuantumPath® is a relevant option for risk management of quantum software projects, since it is a platform that, thanks to its agnostic core, minimizes almost to zero the impacts that drastic changes in quantum technologies and providers could cause.
 Using D-Wave Leap from the AWS Marketplace with Amazon Braket Notebooks and Braket SDK. https://aws.amazon.com/blogs/quantum-computing/using-d-wave-leap-from-the-aws-marketplace-with-amazon-braket-notebooks-and-braket-sdk/
 In the following link Amazon Braket shows details on how you can still use the Amazon Braket SDK to describe annealing issues and how you can use Braket-managed Jupyter Notebooks to send these issues to D-Wave quantum processors: https://aws.amazon.com/blogs/quantum-computing/using-d-wave-leap-from-the-aws-marketplace-with-amazon-braket-notebooks-and-braket-sdk/