Chatbot developers will be a new breed of developers equipped with technical and social skills. After all, chat is a language based UI. Unlike typical development, Chatbot development needs constant tweaking and modification to improve bot behaviours. Chatbot developers are also required to understand social behaviour and interactions.
Coming from traditional software background, I soon realise that I will need to discard my old views of UI to develop Chatbot effectively. Your bot platform should seamlessly recognise different queries naturally and combine that information to provide and answers. It is like a conversational approach to address or solve a user query. Technically, this is called natural language processing (NLP).
Chatbot must Agile
Chatbot development must adopt Agile to deploy your bot effectively. Afterall, language comes in different flavours. It is difficult to anticipate your user responses if they are coming from diverse backgrounds and geographical locations. It is recommended to target your bot development using a fixed architecture that enable localisation deployment. This way, you can Agile your bot for different variety of products and users.
If you are starting your bot journey, it is time to approach your chatbot development approach with a different view. You will be expected to adopt NLP using Agile methods.
While dabbling with MS (Microsoft) Teams Chat, I realise adaptive cards are being using for their bot framework. That will explain why “\n” or CRLF is not working on its chat display. So, if you are working with MS Teams bot. You will need to look into adaptive cards UI. Now, there is another new UI framework to have fun!
Why Adaptive Cards
It seems adaptive cards will be used for the MS Teams as the standard for card object. Adaptive cards are JSON serialised object model. This model describes text with images similar like your name cards. Developers can send content in these cards in JSON format. This will mean you can use code with Adaptive card format in ODA (Oracle Digital Assistant) bot framework. The content will be rendered in the look and feel of the host applications like MS Teams. This sounds cool, right?
Designing Adaptive Cards
Adaptive cards will be in JSON format. There is a designer portal which allows you to preview the JSON codes and format. It may take you a while to familiarise with the adaptive cards because it is mainly properties and configuration. You will need a lot of trial and error to render the adaptive cards properly.
Adaptive card is a MS driven approach for target system to share cards into MS products with a better UI. In a way, this provide a richer feel for just pure text in Chatbot. This will also give you a reason to invest in Teams bot framework.
Chatbot can be challenging for the different channel unless you are going for full text display. Channels are chat application like WhatsApp, Teams, WeChat, Telegram or LINE, Users are so used to text formatting and GUI that they are spoilt for these display. Chatbot channel is like the days of SMS where you can only display limited important text is a straight line.
Chatbot Channel Consideration
If your Chatbot is going to be suitable for different channel, you will need to consider a universal full text or code for different channel. What will be your choice? There are so many types of channel or chat applications around. How should you choose and select the right channel to focus on? These are some quick tips to help you make your choice.
User Base Location – different countries adopt chat application locally eg WeChat in China.
Ease of Customisation – Telegram is customised friendly and popular with developers.
Cost – Some chat application like WhatsApp needs a paid business account.
The major efforts of Chatbot Channel development is actually spend on testing. There will be a lot of trial and error as you attempt to develop a single view for different channel. What looks great on emulator will differs in laptop and mobile? You will need a lot of time to tweak spacings for each channels on different devices.
Welcome to Chatbot development! Be patience and happy testing.
Dates format are a nightmare for application if you are handling a global system. Most application provide a certain level of configuration for user preference. OTM (Oracle Transportation Management) is one such application that allows you to configure date format for users. However, this can be quite painful because the date format can vary in each module. These are the OTM portions where you should take note.
OTM Date Configuration
You can configure date format with user preference. The user preference can also be superseded by the preference in contact module. Some of the OTM fields are in date type. There is also attribute date fields as placeholder. Report parameters date format can be overwritten by date format in report library.
Dates to Take Note
You will find many painful points when you are using character field for dates. This can be in the form of refnum or integration xml. Many of the reports required dates filter. You may want to consider the usage of date field for these filter instead of character data type. You will find a lot of conversion format between to_char and to_date in your report query.
Whether you are upgrading or migrating, the impact on date format is very huge. OTM is one such application with flexibility on date format usage. This caused a challenging task for technical team who will be maintaining a global system. Should you standardise your date format instead?
If you are an Agile practitioner, you will realise that there is always a gap between Agile and Management. Not much have been stated on Agile for Management. Unlike Waterfall model, Agile is not big on reporting and generating of status report. Here are some tips on engaging management with Agile projects.
Waterfall model is so entrenched that entire reporting structure to management revolve around this perspective. The first step is to educate Agile and the differences between the Agile and Waterfall to the management. You need to set Agile expectations with your Agile champion. These champions must preferably from top management. You need to have a holistic approach to share the Agile approach to users as well.
One of the best part of Agile is lesser admin reporting. This leaves you more time to focus on what is to be done. Of course, Agile is timebox at duration that management can participate as observer. For example, management can join in daily stand up that should last between 5 to 15 mins. The most suitable updates for management will be the sprint review where they are invited for their feedback. This typically last two hours for a two week sprint.
Agile does not require formal reporting to management. We should always seek to educate management on Agile events like spring review. This is where management can provide feedback on the product. After all, this allows the Agile team to focus on delivering a “done” product.
Your Stack Setup
If you do not have budget and time to overhaul your architecture, you may consider focusing on your endpoints and gateway. It is common to setup integration gateway to manage the translation of XML to JSON. This provides backward compatibility to your legacy architecture. In another words, you gain more time to progressively upgrade your stack. The good part is that these integration gateway can serve as a command post to manage your endpoints.
The switch from XML to JSON is a time consuming effort. If you do not have legacy system with XML, you may want to consider having a technology stack that favors JSON. However, those with legacy and XML integration may want to lower risk with the setup of integration gateway to manage your endpoints and translation of XML to JSON.
Having an oversea sites can run into all sorts of networking issues if you are accessing these websites in China. This is because of the well known firewall of China. You will need alternative solution if you have users in China that use websites outside of China. If no, you will be running into countless uncontrollable risks.
Time to Locate a Mirror in China
Unlike other countries, it is favorable to have a mirror sites in China. You can consider this option if you have a large user base in China. Although there are conditions to setup a website, the returns will outweigh the risks of blocks from China firewall. The mirror site can also serve as your redundancy or CDN (Content Delivery Network) for high availability and added performance.
If you do not meet the conditions for a mirror site in China, there are other options for you to consider. You can transmit your data real time via your VPN instead of the regular internet. Using VPN have its advantages with faster latency. However, there are also risks because they will be subjected to firewall blocks and it will also cost more. You may also consider store and forward method where you accumulate your data for transmission. Although you may not have real time data, you can manage your user expectations and controlled your data transmission at a lower cost and systematic manner.
Having users in China is a tricky approach for your website. If you have a large user base in China, it is worthwhile to invest a mirror site within China. Otherwise, you may consider lowering user expectations and opt for non real-time or less availability solutions.
Hypercare is a process in Waterfall SDLC (Software Development Lifecycle). It is very similar postcare you receive after a major operation. For many teams who makes the switch from Waterfall to Agile, management still demand the need of hypercare process. Is there really a need for hypercare for Agile SDLC?
Hypercare is Just a Sprint?
Hypercare is often regard as a warranty period whereby traditional waterfall all accommodate a degree of big fix due to scope creep. In Agile, there is no such process. Instead, the deviation. or gaps are recorded in the backlog. The backlog items may be selected for the next sprint. This render hypercare unnecessary in Agile. Effectively, management or users become concern for this missing warranty! Thus, you may find some Agile project do state a period of hypercare. However, this is actually the same as a sprint.
The Emergence of DevOps
Another key reason that hypercare is unnecessary is due to the rising popularity of DevOps. In fact, DevOps functions like a hypercare process with its quick turnaround, speed and rapid delivery. Agile and DevOps works hand in hand and you may consider DevOps in place of hypercare period. Therefore, your users and management will have a similar assurance that is given in the form of hypercare.
It is noteworthy that hypercare may no longer be required in the Agile and DevOps world. There is a need to educate and align users and management on these understanding. This may also include the change in future RFQ or procurement whereby hypercare could be removed. As a result, you will see a lower cost with the removal of hypercare process.
If you have done many application projects, it is common to find that exceptions are often being provided as a rule by users. This is a key reason for major scope creep when you try to cater to exception. Is exception a rule? Can this be considered as a rule?
Exception is a Process
The first approach to exception handling is educate users that exception is a process to be managed. It is not a rule that system is able to followed. A rule existed from known set of variables. On the other hand, exception represent special scenarios and unknown variants. Thus, this distinguish exception from a being rule.
Exception is Unpredictable
The second key characteristic of exception is the nature of occurrence. It is unpredictable and sporadic. In fact, some exceptions break the established rules. This is where users demand that exception be made as a rule. That exception will conflict with existing rules. If you attempt to fit the exception as a rule, scope creep will occur.
User education is important to distinguish exception from a rule. Exception often break existing rule and must be handled as a process. Usually, users cannot determine the frequency of exception. After all, exception is not a rule!
We had an outages yesterday that was totally unexpected. It was so big that the major news reported them i.e. Akamai outages. It was surprising because we would have thought this type of outages were a relic of the past. How should outages being handled in a world where users cannot tolerate 5 min of downtime?
Formation of Outage Team
Do you have an outage team? It is likely majority of organisations do not have an outage team. Neither are outage drills conducted in large scale for the organisation. You can relate this like a fire drill where you will have a fire drill team for your entire buildings. This team is usually cross functional and well drilled in various skillsets from infrastructure, security and applications. Although this team could be costly, it is worthwhile to note that outages may cost a 100 times more.
Outage management is different from disaster recovery. Disaster recovery usually deals mostly with internal applications or related downtime. These SOP (Standard Operating Procedure) could be formal processes with your external parties. When outage happens in the old ways, it usually starts with a Sev1 (Severity 1) and manage with standard incident management process. It will take an hour or more before this is deem an outage. The slower pace and passive nature of incident management may not suit today’s outage.
Outages are no longer isolated in nature due to Cloud and networked environment. Case study like Akamai outage will lead organisations to consider a need for outage team who are highly trained and focused to manage outages swiftly.