The Pursuit of Smartness in Software-based Systems

In this Fraunhofer IESE blog post series, we will explore the pursuit of smartness in software-based systems. In this initial post, we will discuss the concept of „smart“ within this context, pinpoint what lies at the heart of smart-based systems, and illustrate why context awareness enables smartness in such systems.

What qualifies someone (or something) as “smart”? General definitions of the word “smart” include “having or showing a high degree of mental ability” [1], “intelligent, or able to think quickly or intelligently in difficult situations” [2], and “quick at learning and understanding things; showing this ability” [3]. Interestingly, the Oxford Learner’s Dictionary also provides an additional definition that is specific when the adjective is applied to devices: In such cases, smart would mean computer-controlled (“controlled by a computer, so that it appears to act in an intelligent way” [3]).

Computer-controlled devices have been around for decades now; however, not all computer-controlled devices have been called “smart”. Consider, for instance, the term smartphone. It was coined in the late 1990s to refer to a new type of device that, although primarily intended to work as a regular phone, came with additional capabilities such as Internet connection, e-mail, calendar, and web browsing. Back then, these things qualified a phone as smart. Note, however, that mobile phones preceding the smartphone era were already computer-controlled (for example, the Nokia 3310), but were not perceived (nor branded) as smart.

While this example illustrates how the word “smart” has been used loosely in industry, in academia a more specific meaning is observed: Research on smart systems has been historically related to the development of Artificial Intelligence, for intelligence – be it artificial or not – underpins smartness, in a stricter sense.

Smartness in domains, devices, and applications

Nowadays, the word “smart” seems to indicate what everyone yearns for in terms of software-based systems. Let’s organize it in three levels: At the highest level of abstraction, there are smart domains; at the lowest, smart devices. We argue that between these two extremes and forming the core of smartness in software-based systems are smart applications.

Smart domains

It is not difficult to find industries where there are movements towards enabling smartness. Industry players and researchers alike want agriculture to be smart agriculture, they want manufacturing to become smart manufacturing, they want health improved towards smart health. The same holds true for mobility, cities, energy, construction, or government, to name but a few examples. Frequently, smart domains describe software infrastructures that enable the collection, processing, and distribution of data, which provides the basis needed for the development of smart applications. In other words, a smart domain is not smart in a strict sense, but it creates the conditions for (data-driven) smartness to flourish through smart applications.

Smart devices

At the other end of the spectrum, we could consider the device level as the lowest level. Internet of Things (IoT) developments have given rise to what has been called smart devices, usually for their networking and data collection capabilities. In a house, for example, there may be several smart devices, outlets, door locks, lightbulbs, and appliances. What characterizes such a house? First, the digital character of some of its constituent elements; next, the fact that these elements are connected, i.e., that they have the ability to exchange data; finally, the ability to provide a basis for smart applications working together to enable usage scenarios that we may refer to as use cases of a smart device.

One may argue whether labeling something as smart isn’t just a marketing decision rather than an expression of a well-defined feature. Is a door lock really “smart” just because it has an Internet connection and receives a signal to open or close? Similar to smart domains, smart devices act as enablers for the development of smart applications. In other words, what makes a software-based system smart, in a strict sense, is the development of smartness at the application level.

Defining smartness in applications

After taking a look at definitions of smartness at the domain level and at the device level, let’s consider what is at the core: the application level.

Applications are expected to be designed to support user tasks, and such support can be achieved in different ways. For example, it is possible to conceive of an application that provides the user with all the functionalities they need, but packs it in an awful user experience. Users want applications that not only work, but that work well. Users want applications that not only deliver the expected functionalities, but that also surprise them positively. As a matter of fact, industry players want to exceed their user’s expectations in order to keep up with the competition. One way to achieve this is to add intelligent behavior to applications – in other words, to turn applications into smart applications.

Another aspect to be taken into consideration refers to when the term “smart” is applied to a certain entity: What may have been considered smart then is no longer regarded as smart now. Anyway, independent of the level of abstraction and the time, the decision to add the term “smart” to a certain entity seems to be bound to exceeding expectations. This was true when the term “smartphone” was coined, is still valid today, and reflects the maturity levels of perceived smartness in applications.

A well-known model for framing user expectations is the Kano Model [4]. In general lines, the model says that there are three types of functionalities. The first (and most obvious) are satisfiers: These are functionalities explicitly expected by users, which they know they want, and which therefore make them feel satisfied when found to be working properly. The second type is called dissatisfiers: These are functionalities implicitly expected by users, therefore not always declared. If these functionalities are found in the system, they may not be noted at all; however, if they are not put into the system, their absence will, in fact, be noted and cause dissatisfaction. Last but not least, the third type of functionality is called delighters: These are functionalities that users expect neither explicitly nor implicitly in a system; if they are not put into the system, one will barely miss them; however, once they are implemented and delivered to users, these functionalities cause the so-called “wow effect” on them. One has to note that expectations change over time, and the delighters of yesterday are the dissatisfiers of the future. Consider, for example, touchscreen capabilities in smartphones: When Apple introduced the iPhone in 2007, scrolling over a list with a finger gesture caused a sound “woooow!” in the audience (delighter), but 15 years later, touchscreens with gesture recognition are more than trivial in the smartphone arena (dissatisfier).

Interestingly, while the expectations regarding a device may be fulfilled by connection capabilities and data exchange, in applications these things are commodities nowadays, and smartness calls for more. Taking up the dictionary definitions: for smart applications, it is not just about being computer-controlled, but about showing intelligent behavior.

Context awareness as an expression of smartness

One representative class of delighters are context-aware functionalities. Context-aware functionalities are functionalities that take context into consideration to produce a certain system behavior, typically an adaptation or a recommendation. By means of sensing the context of the interaction between the user and the system, a context-aware system is able to change its behavior as needed by the user, but without the need for explicit input from the user.

Although “context awareness” is not a well-known term among end users and even practitioners, research in the field has been intensive for decades now. This idea is well summarized in the following quotation from researchers Pinheiro and Souveyet [5]:

Before being considered as context-aware, applications such as those […] can be seen by consumers and non-expert designers as ‘smart’ applications, since they propose what can be perceived as an ‘intelligent’ behavior with data collected from the environment. Indeed, being able to observe the physical environment, to dynamically adapt its behavior without any human intervention are behaviors commonly perceived as ‘intelligent’ (or ‘smart’) by consumers.

Analytical research work on what characterizes a software-based system as smart also points to context awareness. In a recent study [6], researchers concluded that smart systems are characterized by communication (i.e., data exchange) capability, embedded knowledge, learning capability, reasoning capability, perception capability, and control capability. And, as a result of the interaction of these characteristics, context awareness appears as an emerging property of smart systems.

Context awareness in practice

There are plenty of examples of context-aware functionalities in the software-based systems most of us use every day:

• Several messaging systems (such as Gmail or MS Teams) provide users with text recommendations for 1-click replies based on the content of a received message;
• Online translators, such as DeepL, no longer require users to indicate the language of the message to be translated;
• Video-streaming platforms (such as YouTube) automatically adjust the quality of the streaming based on the user’s network connection;
• Map navigation apps in infotainment systems that we find in many cars use the current environment luminosity, the time of the day, or a combination of both, to automatically switch the appearance of maps between light and dark modes;
• Smartphone OSs (such as Android and iOS) switch to silent mode automatically when it’s evening.

Context-aware functionalities enable smartness in software-based systems and, for this reason, hold the potential to delight end users. Industry players want to go beyond user expectations and hope to discover great features for their solutions. Now, the question to be answered is: How to come up with such features? This will be the topic of our next post in this series: The engineering of smartness in software-based systems. See you then.

References:

[1] Merriam-Webster. “Smart Definition & Meaning – Merriam-Webster”. https://www.merriam-webster.com/dictionary/smart. Visited on August 09, 2023.
[2] Cambridge Dictionary. “SMART | English meaning – Cambridge Dictionary”. https://dictionary.cambridge.org/dictionary/english/smart. Visited on August 09, 2023.
[3] Oxford Learner’s Dictionaries. “smart_1 adjective – Definition, pictures, pronunciation and usage”. https://www.oxfordlearnersdictionaries.com/definition/english/smart. Visited on August 09, 2023.
[4] Kano, Noriaki. „Attractive quality and must-be quality.“ Journal of the Japanese society for quality control 31.4 (1984): 147-156.
[5] Pinheiro, Manuele Kirsch, and Carine Souveyet. „Supporting context on software applications: a survey on context engineering.“ Modélisation et utilisation du contexte 2.1 (2018).
[6] Romero, Marcelo, et al. „Towards a characterisation of smart systems: A systematic literature review.“ Computers in industry 120 (2020): 103224.