If you are following the Oracle Autonomous Mobile and Chatbot Platform announcements you would have now realised that we have announced the availability of the Oracle Digital Assistant platform as a new SKU under the PaaS offerings.
In this post, I will delve deeper into the Oracle Digital Assistant offering and answer what I anticipate will be common questions about the changes.
So what is an Oracle Digital Assistant (ODA)?
It is synonymous to the earlier version of chatbots which is oriented towards having conversations with the human, however, the ODA recommends or completes certain task beyond conversations. The old chatbot framework was user-initiated, whereas, with the ODA, it can launch multiple Bots based on the incoming requests. So instead of friending numerous bots through a channel, I can now add ODA as my Admin or secretary and let it decide which skill to be initiated based on my needs.
In an enterprise context, there might be a need for a HR Bot/Skill that can execute HR related tasks like Employee Profile Update, Leave balance etc, a recruitment Bot for recruitment related activities, Procurement Bot that communicate with your backend procurement system and can place an order to acquire a new asset, a policy help desk to understand the company policies and procedures . Instead of rolling these multiple Bots on to the Company Intranet portal you can now add the Oracle Digital Assistant as an Employee Digital Assistant on your intranet page and let the digital assistant decide which skill to invoke based on the user input. So in a nutshell, Oracle Digital Assistant is a smart Multi-purpose Bot using AI for predictions and recommendations.
So what does that mean to the Autonomous Mobile Cloud Enterprise platform that Oracle had earlier? Well technically nothing has changed, we have decoupled the Mobile Platform and the chatbot Platform and now rebranded the SKU as Autonomous Mobile Cloud and Autonomous Digital Assistant. I think this the right foot forward, given that the Chatbot Development can focus on the Digital Assistant platform and make their releases happen while the Mobile Team can push their releases independently of the chatbot release. From a provisioning perspective, it is easy for customers who are focussed on Chatbot use cases can provision Autonomous Digital Assistant only and in use cases where there is a need to develop mobile applications customers can now provision the Autonomous Mobile cloud service.
All that is good, but what is going to happen with the Custom Components that need to be hosted on the Mobile Cloud? One of the key building blocks of the chatbot platform was this ability to connect to backend applications through the custom component framework. This allows to shape or build any custom business logic in Node.js and deploy that as a service on the Mobile Cloud platform. This pattern is still supported. However, an important thing to consider, there is a node container that is going to be embedded with the Digital Assistant so that the custom components can be hosted here. As I mentioned earlier, if the use case is around Bots, the embedded node container is sufficient, however, if there are requirements to take advantage of the Mobile platform like the location services, notifications, storage and have API’s that are common to Bots and Mobile apps as a best practice it would be good to leverage the Mobile Cloud Node container for the custom component deployment.
What about the Analytics? The operational insights for the digital assistant will be available within the Digital Assistant UI and the Mobile/Web Analytics are available within the Mobile Cloud Platform.
How long does it take to provision Autonomous Digital Assistant? Check it yourselves: It is incredibly fast for a platform that has to assemble multiple Docker containers on a Kuberentes powered infrastructure: Literally under 3 minutes.
What about Autonomous Mobile: Close to 11 min mark.
More details about the provisioning in the next post.
RedThunder.Blog 
Thanks but what about features like integration with Identity providers? Also from bot capability standpoint and feature point, are there any specific features that are not part of ODA? Perhaps a compartive Analysis will be very helpful.
Lastly, is there a possibility of allowing ODA deployment to customer env, in future roadmap?
Thanks
Amit
LikeLike
Absolutely. As the platform itself is running on Oracle Cloud underpinned by Oracle Identity cloud service, you can integrate with any Identity provider that supports the standard prototcols – SAML, OAuth etc. Didn’t get the compative analysis question? Compared to what ? Another Bot Platform? We have it in the roadmap to deliver ODA on the Customer@Cloud
LikeLike