The “build vs. buy” debate has a long and storied history in the Enterprise world. The big question being, “do we buy something that is close to what we want, but requires us to change how we do things? Or do we build something from scratch that does something exactly how we think we want it to work?” Then the Cloud came along, and suddenly the question was switched to “subscribe” vs. “build”, and the drivers to “build” became even more difficult to justify.
The advent of the Cloud was like “subscribe” slam-dunking on “build”.
The common consensus in the Enterprise world is to now always buy/subscribe, unless there’s a huge and compelling reason to build. These days, “build” has to justify itself, as “subscribe” is now the default decision.
Most organizations would prefer to focus on their main business objectives, and not get side-tracked into becoming Enterprise software development companies.
Building your own payroll system may sound exciting, but someone else has already done it, and you’re better off using what they built (and which the vendor will be committed to maintaining and upgrading forever).
OK, building a payroll system actually doesn’t sound exciting at all. But what does sound exciting is the idea of building a brain. But, builder beware…
Humankind’s fascination with the concept of AI goes back a very long way. Also, as anyone who has used Enterprise software will tell you, a “brain” for the Enterprise is a much-needed addition. In fact, the call center industry is built entirely on the fact that Enterprise software is too difficult for the average person to use – primarily because it seems to lack any kind of intuitive brain.
Today we are seeing some organizations embark on a journey to “build a brain” that understands and can interact with their Enterprise systems and the people in their organization. Not to rain on anyone’s parade, but we at IntraSee can tell you that this is not a simple task. And we know because we’ve done it. The brain is a highly complex organism and it’s a multi-year undertaking to replicate even parts of what it does.
While it might be tempting to open up LUIS (Microsoft), Watson (IBM), or DialogFlow (Google) and start to build your own Enterprise brain, we would suggest that you look at subscribing to a brain that is already built and understands how the Enterprise operates, and that can be configured to understand your particular Enterprise implementation.
Figure 1: What kind of brain do you want?
So, before we get into the mechanics of chatbot creation and the complexities it deals with, let’s discuss the types of chatbots that you could end up either creating or buying. Note: Don’t assume that what a vendor is selling is anywhere close to actually meeting your needs.
In doing so we’ve characterized chatbot implementations into three types of outcomes:
- Basic: aka Mr. Potato Head
- Frighteningly complex, unstable & unpredictable: aka Frankenstein
- Intuitive, reliable, knowledgeable: aka R2-D2
To paraphrase an old proverb, “The road to chatbot hell is paved with good intentions”.
- Mr. Potato Head
This is the most prevalent chatbot today. A chatbot that can do a handful of things with a moderate level of precision. But with absolutely no hope of ever becoming anything sophisticated enough to operate at the Enterprise level. Initially there will be some excitement at the novelty factor that Mr. Potato Head brings to the table, but ultimately he’ll be perceived as nothing more than a toy. And most definitely not the advent of a new era of AI.Mr. Potato Head is most likely just a very basic version of what’s called an FAQ chatbot, and not even capable of integrating with your own knowledge-base(s).
- Frankenstein
This is, literally, the most dangerous of all chatbots. Typically, the Frankenstein chatbot takes many years to build given its epic scope. Plus, costs lots of money (bye-bye ROI), and consumes masses of resources. The problem with the “FrankenBot” is that from a distance it looks like it might be able to do the job. And for a while it may actually function decently. But, like all ill-conceived monsters, eventually it will fall apart and begin to wreak havoc among your organization. Wrong answers, corrupt data, security breaches, instability, and an angry mob of employees are the future of the “FrankenBot”. And the temptation will always exist (given how much money was pumped into it) to somehow make one more fix that finally resolves everything. But the problem is that the more you add to it, the more unstable and unmaintainable it will become.Ultimately the “FrankenBot” will take your organization down a rat hole that will set you back years, and will also sow organizational distrust that the next chatbot implementation team will have to deal with.
Figure 2: The inevitable end of the “FrankenBot” project
- R2-D2
What’s not to like about R2-D2? A great example of how AI should be done. Let us count the ways:- Understands your Enterprise systems out of the box
(ex: it even knew how to fix the shield generator on the Naboo ship) - Multi-lingual
(actually, we’d need to add C-3PO’s linguistic skills to check this box) - A means of extending its knowledge-base by hooking into your knowledge base
(ex: R2-D2 was able to plug directly into the Death Star to answer the question, “where is the Tractor Beam power source located?”) - Reliable
(ex: always clutch in any situation) - Does more than just answer questions
(ex: was able to assist Luke Skywalker by fixing the stabilizer and adding power to the X-Wing) - Built in a modular fashion
(ex: was able to use some of C-3PO’s circuits after taking some damage in the battle of Yavin) - Highly secure
(ex: even when captured, R2-D2 would never reveal anything to the wrong people, though it could have used better encryption of its databanks)
Figure 3: A good chatbot needs to know how to plug into your systems and access your data in your formats
- Understands your Enterprise systems out of the box
In order to understand why building a chatbot from scratch is a daunting process (better suited for a “buy” decision). Let’s walk through what a chatbot actually needs to do, which can be broken down into three core competencies:
- Communication
- Understand the command of a human, and also understand how to relay a message back to the human. In potentially over 100 languages.
- Chatbot terminology: This means Intents, entity definitions, utterance training, and language translation.
- Thinking
- Contemplate the “command” and consider what the appropriate course of action should be. Taking into account what is “allowed” to be done, what “can” be done, and what “should” be done.
- Chatbot terminology: Dialog flows are used to determine which logic paths the chatbot should consider, and what decisions it has to make. Intelligent/intuitive branching logic is used to figure out both context and applicability in order that the optimal branch is taken.
- Instructing
- Ensure all the appropriate functions of the command are handled and any difficulties are dealt with in an elegant fashion.
- Chatbot terminology: API awareness, coordination and execution. Note: The chatbot can’t actually do anything itself (in the same way a brain is useless without a physical body to respond to commands). But it does need to know how to interact with an entire suite of Enterprise API’s (REST, SOAP, RPA, custom, etc.) – which for some commands can be very complex.
Chatbot development tools come delivered with a lot of capability in the “communication” realm of the chatbot. And, of course, some better than others.
Where many fall short is with the “thinking”and “instructing”. For various reasons chatbot vendors think it’s a good idea for everyone to have to create their own “thinking” and “instructing” components. At IntraSee we think that’s a cop out, and that’s why we built these capabilities for you, and deliver them out of the box.
Also, because chatbots rely so much on API’s, they require a rich catalog of API’s for every system the chatbot needs to communicate with. Oftentimes this catalog does not exist, or is woefully inadequate, which requires someone (you) to build it. Which is why we spent the past ten (10) years building Enterprise Adapters and API’s for the major Cloud and on-premise Enterprise systems. Just so you don’t need to.
Remember the golden rule: without all the appropriate Enterprise Adapters and API’s, the chatbot is just a “brain in a jar”.
Figure 4: It’s just a brain in a jar until it’s hooked up with your Enterprise systems
IntraSee has spent over ten (10) years building an extensive catalog of Enterprise Adapters that are API enabled. Even for systems that are “API-challenged”, like PeopleSoft.
The question, before any such project begins, isn’t can you do this (though very few people can)? It’s, should you do this? Is your IT organization ready to become an AI development shop, and spend the next 10 years trying to create the perfect chatbot that understands your entire Enterprise suite?
Figure 5: How NOT to build and maintain a chatbot
If someone has already done this, wouldn’t that be, as Gartner advises, an easier and better solution?
The unfortunate truth is that the vast majority of chatbot solutions were built by hand from the ground up. Every dialog flow is hand-coded, entities are manually defined, and integrations with data and content are created by a coder with no knowledge of how your systems actually work. Even business rules, and often core branching logic, is hard-coded, forcing dual maintenance in a system you can barely understand. The chance of this business logic being wrong is massive. And there’s no simple way for you to ever know without constant regression testing – every single day.
What has been created isn’t just spaghetti code, it’s multi-dimensional spaghetti code.
Figure 6: Is this something you want to manually build and maintain?
AI that is driven from manually coded IF statements is not AI
At IntraSee we don’t hand-build any chatbot solution. Everything is automated and generated from an engine that is already Enterprise-aware, and a pluggable architecture that operates like a neural network, communicating across multiple lobes of the “brain”.
In a similar way to how neurons communicate across the synapse by switching protocols (electric to chemical), we have adapters that manage protocol differences in the many systems the chatbot needs to communicate with.
If you are considering implementing a chatbot solution for your organization and don’t want Mr. Potato Head, or a “FrankenBot”, then please contact us to learn more…