Join our exclusive webinar - "Unlocking Urban Mobility: The Mobility as a Service (MaaS) Revolution" on September 20, 2023! Register now.

Admiration and Modernization: A Lesson from Vacation

Because I love my job, I cannot stop thinking about software engineering even when I am on vacation. My recent holiday in Rajasthan and Varanasi in Northern India provided an opportunity to truly admire some enterprising inventions of the ancient times that are now outdated. I believe this attitude of respectful admiration can help companies in the Digital Economy as they begin the process of software modernization.

Allow me to show you some artifacts that I came across during my vacation which beautifully showcase the engineering and innovation of the 16th, 18th and 19th centuries.

The holy city of Varanasi is one of the oldest living cities in the world. In Varanasi, we saw craftsmen weaving fine silk designs using a 19th century Jacquard loom.

How do they do it? First, an artist draws a design of the pattern to be woven. Then this design is encoded, line by line, onto a set of metal “punch cards”. Each card represents one line of weaving, and each circle in a card has one of two states, present or punched out, indicating whether the corresponding thread should be raised or lowered for that line. The chain of cards is then laced together into a continuous sequence which controls the loom, and the various colored warp threads are loaded.

The human operator has a relatively simple job – advance the loom to the next line, and then pack the lines tightly together. In the West, a modern loom is controlled by computer, which automatically scans the patterns to be woven, reducing the setup time to zero. But in Varanasi, the card-controlled Jacquard loom lives on, continuing to produce dazzlingly complex patterns in silk, and in the process supporting thousands of local artisans.

Next is the 16th century version of the Internet: carrier pigeons. We saw the case for the carrier pigeons at the City Palace in Udaipur, a lake city in the desert state of Rajasthan.

A carrier pigeon has an innate ability to find its nest, and can travel over 1,000 miles at an average speed of 50 mph. The kings of Udaipur harnessed the capabilities of the pigeons to create a highly efficient communication system a few centuries ago.

Here is how the system worked: A message was written on a thin light paper and rolled into a small tube attached to the bird’s leg. The pigeon then carried the message to the recipient. Obviously, this system had its limitations. For example, it worked in only one direction, when the sender possessed one of the receiver’s pigeons! But, for its time, it certainly was an ingenious way to maintain long-distance communications with other kings.

Another invention in the City Palace was a 19th century steam powered fan, imported from Italy to keep the kings cool.

The apparatus in the king’s room looks very much like a modern fan. But, there is no electric cord. Instead, a pipe leads to an adjacent room, where boiling water was used to create steam which powers the fan. In order to maintain a pleasant temperature in the king’s room, the fan operator next door had to labor in nearly unbearable temperatures! Though this contraption is no match for a modern air conditioner, or even an electric fan, one has to really admire the ingenuity of the inventor two centuries ago.

Coming to the city of Jaipur, the capital of Rajasthan, also called the ‘Pink City’, we saw the Jantar Mantar, a collection of nineteen architectural astronomical instruments, built by the Rajput king Sawai Jai Singh in the 18th century. The instruments measure time, predict eclipses and track the location of major stars. Among other artifacts, it features the world’s largest sundial, which rises 88 feet high.

Although not much in use at night or on a cloudy day, the sundial is a testament to the level of astronomical knowledge and expertise achieved by a remarkable civilization, long before the era of atomic clocks.

As I reflect on these inventions, I am filled with admiration for the creativity, insight and the innovative spirit of man. At that time, each of these inventions was a remarkable achievement, which enabled the impossible. Of course, I do not recommend that you actually use any of these artifacts today – they have all been replaced by far more efficient, convenient and reliable alternatives. But this does not diminish my respect and appreciation for the inventors of these devices, who created breakthroughs using the technologies at hand in their time.

How is all this relevant to software modernization? Many companies today find themselves on the cusp of deciding whether to modernize their existing software stack. While interacting with these companies, I find that a major impediment towards initiating a modernization project is what psychologists call “ego investment”. Someone chose the technology that now needs to be modernized, and any criticism of that technology is perceived as a personal attack on that someone. If a software system needs to be modernized, says this not-so-correct logic, then it must have been a mistake to install it in the first place, and whoever was responsible for that decision made an expensive mistake. The discussion then becomes emotional rather than rational, with unpredictable results.

To break this dynamic, what is required is an attitude of respectful admiration for the system to be modernized. Don’t view it through the lens of what is available today – look at the choices that were available when that system was selected. You will usually find a lot to admire in the inventiveness and resourcefulness of whomever it was that cobbled the system together and was able to successfully overcome the existing technological limitations to produce a platform that answered the company’s needs.

The requirements have probably changed over time, and so have the technological choices, and that’s why the system needs to undergo modernization. But if you take a moment to respectfully admire the imagination and originality of the existing system, the entire modernization process will proceed far more smoothly.

Don’t Be Fooled By Facades – SQL Facades

When NoSQL databases first appeared, in response to the need to process high volumes of unstructured data, the “o” in NoSQL was small, and it meant that these systems had “No” SQL support – SQL was meant for traditional structured relational databases, not these new schema-less contraptions. But, developers know and love SQL, so these products soon developed SQL-like facades, and the “O” in NOSQL became capitalized – NOSQL meant “Not Only” SQL. These SQL facades, such as Phoenix for HBase and CQL for Cassandra, vastly accelerated the adoption of NOSQL databases, by lowering the barrier to entry, because developers could access the database via a language they already knew – a subset of good old SQL. But, a lower barrier to entry also creates a new problem – programmers have no idea what is going on behind the SQL façade, and, as a result, create programs that are wildly inefficient, far less efficient than the equivalent program in a traditional relational database.

Let’s take Cassandra as an example. In the old days, before Cassandra’s SQL façade, every Cassandra programmer knew that a Cassandra row key is different than a column, because a column is stored as a <name, value> pair, while the row key is stored as a nameless value. And, every Cassandra programmer knew that the only thing Cassandra sorted was the column names within a row – not the row keys, and not the column values. So, if you needed to retrieve sorted data, you had to place all the data in one row, and “promote” the data to be sorted so it was part of the column name. There was elegance in the simplicity of this model, and Cassandra programmers became experts in concocting column keys that sorted all the desired data within a given row in just the right order. Want to sort some columns (e.g., events) by time, and sort other columns (e.g. names) alphabetically? No problem – just encode some of the column names with timestamps, and some of the column names with text, and Cassandra will automatically sort them as separate groups.

Then, along came CQL, an SQL-like façade that makes Cassandra look like a relational database. The row key looks just like any other column. And, rather than requiring the user to manually concoct column keys, CQL lets the user define one set of hierarchical clustering columns whose values get “promoted” into the column keys automatically. So, instead of having different sorting strategies for different parts of the row (e.g., some by time and some alphabetically), CQL enforces a single sorting strategy for all columns in the row.

Nowadays, when I interview candidates who know Cassandra, I am amazed at how little they understand about what goes on behind the CQL façade. For example, few CQL programmers can explain why it is a bad idea to select a range of row keys, e.g., from January 10 to January 12, 2015. (Remember what I said about row keys being stored unsorted? To find the selected range, Cassandra will have to read every row in the table, which could take hours.) They have been fooled by the façade into thinking they are using a full relational database, and are disappointed to discover that their queries run much slower on Cassandra than they did on Oracle or SQL Server.

Don’t get me wrong. I am not proposing that we abandon the SQL facades for NOSQL databases – they make maintenance and programming dramatically simpler. But, don’t be fooled by the façade – always make sure you understand how the data is organized behind the façade, and make sure your queries are accessing that data efficiently. Otherwise, you are in for nasty performance surprises as your NOSQL database reads billions of rows from disk to answer what appears to you to be a simple query.

The Evolution of Chatbots: What’s being developed today and what’s on the horizon

Angshuman Patra, our head of NA Delivery; and Jay Sanborn, our AVP of Cloud Platform Engineering are both passionate about delivering solutions that exceed customer expectations. In the following Q&A, we ask them about the evolution of chatbot solutions – what Ness is delivering today and what Ness will be developing in the future as the technology matures.

What type of chatbots solutions are our clients looking for?

Our clients are looking for chatbots to automate business processes that are highly repetitive and to facilitate faster responses to customers, partners and employees. Customer support, customer self-service, IT support and employee self-service processes are some examples. As the technology matures, we anticipate Ness will build chatbots for more complex and intelligent interactions with end users when they work in conjunction with backend platforms.

Ness helps clients determine the best business uses for chatbot technologies, and then we help them select, implement, customize, and integrate chatbot technologies, including with other enterprise systems, to improve business processes and services.

What problems are these chatbots assumed to cover?

Chatbots can have an impact on call centers and the operational challenges they face, including increased caller volume, high rate of agent attrition and high cost of agent recruitment and training. Chatbots make it easy to respond to typical FAQ type questions without the user needing to search through the organization’s website or having to speak with a call center agent. At the complex end, chatbots can analyze sentiments and transfer customers to live agents, produce business optimized responses to questions or provide recommendations based on personal and group preferences.

What platform/software do we use when developing chatbots?

We have worked with platforms including Google’s DialogFlow, AWS Lex, Twilio Studio and Passage AI. Passage AI, an omnichannel, artificial intelligence (AI) digital communications platform, enables automated customer communications via chatbot, Facebook, SMS, Amazon Alexa, Google Home, Apple Siri, and other digital channels.

What technologies and capabilities are key when building a chatbot?

The technologies we find particularly valuable are AI, natural language processing (NLP) for 100+ languages, and text/voice capabilities. Additionally, the ability to integrate third party applications, data warehouses and telecommunications systems is important.

What could be improved and why?

Current chatbot technologies are primarily single-use applications. There are many advancements possible, from real person voice interaction (currently being pioneered by Google Duplex) to sentiment responses (based on what you feel) and optimized responses (based on what’s best for the business and the customer). Some of these improvements will require changes to the back-end system and their integration.

What do you like about the chatbot experience? What do you not like?

Chatbots enable customers to get the support and information they need faster.  Additionally, customers deem the information more accurate than interfacing with a customer support agent. The area of improvement for an AI-powered chatbot that would be useful to address is the NLP translation agent, which needs to become more intelligent to interpret questions better, improve accuracy of responses and get better at languages and dialects in a short amount of time. As with most technologies, we expect the capabilities of chatbot software solutions will improve over time.

SAP pro inteligentní výrobu

Výrobní podniky se často potýkají s vysokými provozními náklady a nízkou produktivitou práce. Tyto faktory snižují jejich konkurenceschopnost a ohrožují budoucí existenci. Řešení problému je překvapivě jednoduché. Přistoupit k modernizaci a investovat do digitálních technologií. Začít lze třeba s platformou SAP S/4 HANA.

Výrobní podniky používají pro svůj provoz různé systémy, ať už pro plánování výroby, řízení výroby a monitoring, systémy pro údržbu strojů, nebo nástroje pro reporting. Obecně lze doporučit, aby co nejvíce funkčností pokrýval ve výrobních firmách ERP systém, protože čím méně rozhraní obsahuje podniková infrastruktura, tím hladší provoz je zajištěn a tím méně nákladná je jeho údržba.

ERP systém realizovaný na platformě SAP S/4 HANA přináší informace z výroby v reálném čase. Sjednocení transakčních a analytických dat na úrovni jedné databáze dává možnost okamžitého přístupu ke všem datům pomocí předpřipravených struktur reportů a analýz a odbourává nutnost synchronizace transakčních dat do datových skladů.

Veškeré informace jsou dostupné bez zpoždění, v podobě jediné aktuální pravdy, což umožňuje rychlejší a přesnější rozhodovaní napříč celou strukturou podniku.

K významným benefitům, které taková integrovaná platforma přináší, patří zkrácení doby předvýrobních etap při zpracování zakázek. Samotná zakázka prochází podnikem efektivněji bez zbytečných zdržení a v co nejkratším čase. Je zároveň dosaženo kvalitního a přesného plánování, čímž odpadá nadvýroba a všechny zdroje, ať již lidské, majetkové či znalostí jsou využívány maximálně efektivně.

Z našeho pohledu systémového integrátora je účinné propojit vnitropodnikové systémy a řešení v jeden funkční celek.

Dostáváme se k vyřešení problému nízké produktivity a vysokých nákladů pomocí správných technologií, tj. vhodným výběrem ať již nového podnikového systému, upgradem dosud používaného či integrací stávajících systémů pro různé fáze výrobního procesu.

Na místě je zodpovědné zhodnocení situace každého výrobního podniku a naplánování investic do informačních technologií. Takové by měly být první kroky na cestě k transformaci v inteligentní podnik, jemuž patří budoucnost výroby.