Hello all. Good morning. Good afternoon, and good evening. This is Lex McCann Kumar, an executive Director at JPMorgan Chase Bank. This is for Con 42 Quantum Computing 2025 event, and the topic is bridging classical and quantum computing. Let's start with a quote. Quantum Computing is not going to be a replacement for the classical com completing. It's rather it's a transformation. Classical to comp quantum computing and how we use it. So the kind of fundamentals is your mind mindset should shift considering it as a co-existence instead of as a competition between the classical and quantum computing. The reality is the shift is real and there are already major players like A-W-S-I-B-M and Azure have quantum computing areas. Example as the A WS bracket, IBM, quantum and Azure Quantum, and there are almost more than a hundred plus quantum related patents filed in 2023 alone. And there are many startups and enterprises, r and Ds prototyping, hybrid workflows between the classical and a quantum computer. It started with as a theory and it has become a lab and now it's all cloud native APOs available for quantum computing. And these are all the proof points. And let's think about what's between the classical and the quantum and what are the emerging needs. The classical system is well known for its performance, optimization, security, and reliability. The emerging needs, while we are shipping or running in a hybrid model of classical and quantum, would be quantum for the combin material optimization, machine learning acceleration, and molecule simulation. We need to have an interface to. Have the classical event talked to the quantum, using the driven event driven pipelines, and to start with, for enterprise architect to know how and what needs to be done. Here are some of the fundamentals that we need to think about. So the quantum 1 0 1 for classical architectures, the quantum core principles is about qubits, super position, entanglement and interference, and we need to understand. The classical computing works on binary, which are zeros or one, but the quantum is, can have a state which is simultaneously either a zero and a one. So it's also more than more as a probabilistic state than as a binary state. So your our thinking thought process should change, of considering a status as either or for as a binary instead as a probabilistic state. Next, what are all the challenges we have in this journey of com? Starting from the classical to the quantum computing? So the current state of the quantum computing doesn't fit into our existing DevOps stacks. Major missing pieces are the job orchestration, state isolation for quantum workloads, and also the latency tolerance. So these are the problems that needs to be solved, but I'm sure in the near future it'll be eventually solved and it will be in a very mature state. The next thing, let's talk about how a hybrid architecture for a quantum and a classical computing works together. So your application layer, the first tier could be all microservices with the APIs and in your middle tier or your orchestration layer could be for quantum job routers and cubes. And the lower backend services could be, classical computing and also quantum computing, or a combination of both of them together. So overall, still the problem for quantum not fitting into the DevOps stack is there, but still these models are workable and there are prototypes and solutions being done based on this model. Next, the major design patterns. What we need to consider for our quantum computing area would be quantum as a service, just like we have infrastructure as a service, software as a service, and everything as a service. Quantum as a service is another same pattern that's primarily being considered. And also we have to consider all the quantum triggers from the classical event cues like a calf cup. So when we club between the classical and the quantum. The communication medium could be a popup model where the classical can be producing an event to which a quantum needs to react based on the event that has, that classical has produced. And we also need to be predominantly working on the server serverless, quantum microservices. That's like a cell lambda, what we have a lambda can trigger AWS bracket. Next the middleware integration layer, what we talked about earlier the main responsibilities for those area will be on the session management job cuing, and the error ries result normalization. So the strategy would be to solve this problem area to decouple the quantum logic from the orchestra logic. So we should not combine them as a single com computation. Instead, it should be a two different segregation of duty and major tools as I mentioned earlier that would be used would be the a s bracket, SDK, the on time ci, GRPC and bridgers, and many more out there in the queue Now with. Cloud Naivity being the forerunner at this point of time. The cloud native abstraction for the quantum area could be in the areas of like containers running quantum for local simulations. Or you can have a ka jobs runners which can orchestrate your quantum flows and your serverless options. As I mentioned earlier, the A DW Lambda. Along with the bracket trigger and the DevOps quantum job linking CA CD4 quantum kernels in the future. So these are the cloud native abstraction that needs to be considered. And the more important thing of whether it is a classical or a quantum, would be on the security interoperability, abso and security, as I as mentioned in the slide, you can see the authentication across classical and quantum. Ty should be. We taken care very well. It should be a zero trust model. The interoperability between the classical and the quantum would be the protocol Standard issues like the QAR and the open quo vendor neutral interfaces are very important for the interoperability will be much easier and the observability will be for telemetry for the quantum jobs and the integration with the Prometheus and open telemetry, just like how we have integrated them in the classical computing today. Here is a practical roadmap for the enterprises to consider. First, the step one would be identifying the quantum able problems, like example, like a scheduling machine, learning model, tuning and more. And the step two, after once we have identified, is to build a dev sandbox for the emulators for the quantum. And once the emulators are already, the third step would be to integrate with chop orchestration. Message buses. So this message I mentioned earlier will be the one we should be to come a hybrid communication between the classic and the quantum. And the step four would be to come to the pilot state where we have a hybrid service, non-critical, in a non-critical path, and gradually promotion towards the production workflows as a step five. And that will be Itrate next future. Now, once we have all this in. Happening in our hybrid model the end state or the future state. To have a non-destructive strategy would be to have how we integrate modularly or adapt layers to existing system, and at the same time minimize the risk using the polyglot as DGen simulators. As well as a mature hybrid, CACD pipelines. So the goal would be to experiment without rewriting the stack. We should be maturing into the stage where this hybrid model will works well or any problems that will, we want to solve. Further to that, the next five years or even less is about the, is not about the quantum dominating. It's about. Quantum augmentation along with our classical, it's not a replacement. As I said at the beginning, it is going to be in conjunction with our classical. The quantum also will be working and solving the problem much better than just the classical solving or just the quantum solving. And with that, we come to a end and thank you for the opportunity. Thank you all.