Gartner organized its Application Architecture, Development & Integration Summit in Mumbai recently. Highlights of 2 key sessions at the Summit:
Gartner organized the Gartner Application Architecture, Development & Integration Summit in Mumbai, on 2 March 2019 where Gartner research experts, application leaders from across industries and solutions providers helped participants to master an application leader’s role with research-backed sessions and create strategies, models, architectures and applications that can lead organizations into the next decade.
Two sessions at the summit were notable – ‘The Cultural Impact of Microservices’ presented by Mark O’Neill, and ‘Chatbots and Virtual Assistants: Past, Present and Future’, presented by Magnus Revang. Both are vice president analysts at Gartner.
Addressing the delegates comprising application leaders, architects, integration professionals and program and portfolio management specialists, Mark O’Neill said there are 3 critical success factors that help deliver microservices effectively and these are product mindset, organization and skills. “Product mindset requires that you research customers to understand their needs, prioritize capabilities/features on a product roadmap, deliver product experiences that maximize value and solve customer problems better than the competition. For example, competitors may be bypassing the API and directly accessing the database. You must be able to deliver over a sustained period using dedicated teams,” he added.
O’Neill explained that microservices are typically called through APIs so that one may change the microservices. However, one should avoid changing APIs. The product manager, he said, must effectively be an API product manager and he or she should sit between 2 sets of developers – one set creating solutions using APIs and the other set creating microservices that expose the APIs. “So the API product manager must define and enable business goals, manage the API roadmap and coordinate developer relations,” he stressed further.
Elaborating the implications of microservices on the organization structure, O’Neill quoted Melwin Conway’s Law which stated that ‘any organization that designs a system will produce a system whose structure is a copy of the organization’s communication structure’.
He pointed out that developers have a tendency to build a microservices platform as opposed to just the microservices, making decisions on frameworks, automation toolchain, API gateway, managed containers, service mesh, backing services, telemetry, etc. This, he is of the view, must be handled by the platform operations team. “That team should be responsible for the outer architecture of the microservices,” he said.
O’Neill said API governance frequently created bottlenecks and developers should avoid governance becoming a bottleneck in general. “Aim to have one API management platform, rather than several.
Agile and DevOps are the prerequisites for microservices,” he added.
O’Neill also advised that microservices are not for everybody. “If you cannot develop software in small, easily testable increments, or you are unwilling to deliver incrementally, do not go for microservices,” he emphasized, adding: “There is no such thing as a microservices project. There is only a product.”
Discussing the topic, ‘Chatbots and Virtual Assistants: Past, Present and Future’, Magnus Revang highlighted that language is a big issue for technology companies. “Objective of the technology is to determine the intent of the user and often this is done through supervised learning and it need not be in real time” he said.
He pointed out that a chatbot has to integrate with a variety of backend systems, raising level of sophistication. Its development course is like chatbot (tell the bot what to do) -> Virtual Agent (tell the bot what you want) -> Virtual Assistant (the bot anticipates what you want), he explained.
Discussing a scenario where the bot can get the intent wrong, Revang said it is the responsibility of the solution creator to ensure that the bot gets the intent correctly. “Quality of implementation is more important than the technology platform used. When people use chatbots, they spell phonetically, they use slang and abbreviations. Also, dialects of many languages change across different parts of the world. English in India is different from English in the US or UK or Australia or Africa. You can scale on intents, users, locales, languages, use cases, etc,” he told the developers.
Revang is of the view that specialist users are easier to satisfy than average users, as they know what to ask and say and make fewer mistakes. It is, therefore, wise to limit the need for integration
with multiple systems in the organization, he added.
He pointed out that tasks can range from informational to transactional. The level of engagement can range from explicit information to interactive conversation.
He envisaged workstreams for creating a chatbot:
1. Deciding what intents to answer
2. Training the chatbot to recognize
those intents
3. Designing the dialogue and answers that the chatbot will give
4. Integrate with the system to execute actions required by the intents
He also cautioned developers that if they change the chatbot technology, designing the interaction does not change. And one also has to design the personality of the chatbot. “You do not want your users to go away ASAP,” he quipped.
Revang felt enterprise vendors will compete to become the master chatbot in an organization. He told enterprises planning to set up chatbots that they must devise an exit strategy for vendors, preserving training data and dialogue design. “Catalog your intents and organize them for scalability. Perform an audit of applications that will be integrated with the chatbots,” he told them.
