When building a chatbot, it may seem overwhelming to state that one source of data and microservices can be leveraged across all platforms. Constant changes and fluidness of each platform make for difficult development. However, all chatbots follow similar structures, data utilization and microservice logic and fulfillment applications. They do have their own processing engines and AI, which are the major differences between the platforms. One thing they all have in common is the ability to send a user laterally in the tree — hopping branches, so to speak — based on AI and NLP (Natural Language Processing). Here is a sample conversation:

            User: What time does the planning office open?

            Response: The Planning Department is open between the hours of 8 a.m. and 5 p.m.

            Response: Can I help you with anything else?

            User: What is the phone number to the Health Department?

Here is the lateral change in the conversation with no redial or hold. The AI and NLP made a decision that does not follow any normal tree structure and without the user having to re-engage with the entity, moved them into an entirely different conversation.

            Response: The phone number is 123-456-7890. 

            Response: Can I help you with anything else?

Now, what is similar and how can we leverage these concepts on the development side of a chatbot to reduce duplicate work? The first commonality is that of the conversation: All chatbots follow decision tree or conversation tree theory. Each platform has proprietary naming conventions for the artifacts and slight functional changes, but at the end, they are much alike. This is why we can begin to design single sources of data and construct a service bus architecture to leverage back-end data with RESTful API calls back to the on-prem solutions. (A RESTful API is an Application Program Interface that uses HTTP requests to GET, PUT, POST and DELETE data.) Essentially, any solution that can expose RESTful APIs can be used within just about any chatbot platform, not to mention other system integrations.

Using single data sources reduces the amount of duplication between environments. However, it should not be discounted that each platform will always require some level of independent work on the front end — Alexa, Google Assistant, Cortana, etc. Another clear and present issue, especially for governments, is Role-Based and Row-Based security requirements.

Government entities are usually broken down by a somewhat static organizational structure. This can be used in the data implementations of chatbots to apply Row-Based security/filters. Adding this data arrangement adds one small requirement to the structure that makes it somewhat relational. The problem is that data sources such as the Google Cloud Datastore are NoSQL, schema less, high-performance databases that do not follow the typical relational database design. This is a great approach when large data sets are required, but leads many government agencies to the implementation of a somewhat hybrid database approach to provide management solutions that are secured properly, extremely accurate and sustainable for the long term. The performance of the NoSQL database is so good, I am not concerned that there would be any gross impact to this hybrid approach, until maybe you started moving into the millions of records, at which point indexing may become a requirement.

Role-Based security requirements can be accomplished in the same fashion as most previous development standards against Active Directory domains, for example. Using security groups can provide roles for modifications of chatbot data very similar to most any system out there today. An example of such roles might consist of read only, administrator, user, content editor and many others.

To conclude, building chatbots in a government environment is possible. It's not difficult; it just requires a bit of additional planning. It is, however, essential to take this step and apply proper organization and security within the chatbot to assist in management tasks.