In this lesson, we will have a close look at interoperability. You will learn the different levels of interoperability, the link to business decisions, and how to express interoperability requirements using quality attribute scenarios. Now, interoperability is the ability of independently developed components to interact and cooperate with each other. And most of us have first-hand experience with things that do not interoperate. If we travel from Europe to the US, or to the UK, we need a bag of power plug adapters to charge the batteries of our laptop. It is complex, and it is costly. So for the software architect, interoperability is a degree to which independently developed software components, or systems, can exchange data and share services. Clearly, interoperability is a runtime quality attribute. Now, today's Internet of Things is really the modern version of the tower of Babel. The Internet of Things provides connectivity between people, processes, and things, but we are very far away from speaking the same language. Existing solutions cannot easily talk to each other. And this is probably the largest barrier for large-scale adoption of the Internet of Things, it's the lack of interoperability. It prevents organizations to deliver the value-added services that enable the full potential of a connected digital world. So, interoperability in software is important for a number of reasons. So, first of all, interoperability enables component-based software engineering and increases the levels of reuse. In the Internet of Things, we will often build integrated systems where applications use capabilities from other existing systems. For example, connecting medical sensors with systems that process the data, and with secure event servers that would send out alerts. On the other hand, application builders will use the service or the services of other Internet of Things systems that know nothing about them. And it's very much similar to the way we use Google Maps for location data today. Now, interoperability is not an all or nothing game and there can be different levels of interoperability. Systems can simply exchange data and call each other's functions, but they can also work together as a single business application with integrated communication channels, full-state synchronization and a common interpretation of data. An example of this can be found in the banking sector where the success of electronic and mobile payments largely depends on the interoperability with the back office systems of the banks and the secure handling of communications between them. Interoperability is also more than just a technical problem, because very often interoperability is related to management decisions or business strategies. Interoperability and open standards can potentially undermine the competitive position of technology giants such as Google, Apple, Microsoft, IBM or Cisco. Because each of those companies wants to leverage their existing customer base, and support their own equipment and protocols. So as a consequence, interoperability and standards will potentially lessen their differentiation versus their competition. And as we know, in most cases, a smartphone running on Android, or iOS, cannot control the smart lights without a dedicated app from that vendor. Now, when we know the systems we have to interoperate with, we can design those specific interfaces and protocols into the system. That's the easy case. However, in many Internet of Things systems, we will never know this up front. A smart city will evolve continuously, and expand by adding new systems for smart buildings, smart law enforcements, as the budgets and the priorities of each city and their major will change. So, for the Internet of Things, we have to create a genetic support for interoperability, to avoid technical silos in smart cities. This is more complex, and requires architectural design approaches such a service discovery, service control, and response handling at runtime. Now, interoperability, itself, is a runtime quality. But interoperability mechanisms can be provided or created at design time, build time, or runtime. The general scenario for interoperability defines the vocabulary and proposes metrics on the responses. The source is the external system that sends an information change request and the stimulus can be anything like raw data, control data, status information, or data in a business flow. Again, the environment specifies if the external system was discovered at the runtime, or if it was known prior to that, for instance, when we were building it. And the response of the system can either be accepted or rejected. But in the case of rejection, a notification needs to be sent. While in the acceptance case, the information should be correctly exchanged and normal processing continues. Finally, the response measure indicates the percentage of correctly processed information exchanges or the percentage of rejected exchanges. We will now apply this general interoperability scenario to the following use cases of the smart medicine cabinet that we are producing. A medicine cabinet is able to sense and alert to a doctor when an at-home patient supply of a drug runs low. The new prescription is verified by that doctor, forwarded to the pharmacist who now sends a new supply of drugs with a courier service. This use case has a large number of interoperability requirements. The drug recipient talks to the smart medicine cabinet. The medicine cabinet interacts with the doctor's patient system. And the pharmacist communicates with the dispatching service of the courier company. Now, to make it even more complex, there are many different ways to detect the supply level of a drug and the recipient, and there are many existent patient systems used by the doctors. We will focus on the interoperability scenario between a direct dispenser and a smart medicine cabinet. Now, we already know that pharmaceutical companies have different types of smart medicine bottles or pill strips. And this is also an area of innovation where new sensors and protocols are appearing on the market very regularly. So this implies that we will need runtime discovery. And we must also guarantee that we order the exact same medicine. So for this, we need to extract a minimum of data from the drug dispenser, and verify it with another data source that you have at our disposal. For example, the electronics description of the doctor. These considerations lead to the following quality attribute scenario for interoperability. A direct dispenser device could be a smart medicine bottle or a smart pill strip. Sends a direct supply low message to the smart medicine cabinet's local control system. The drug dispenser unit was discovered at runtime. And the smart cabinet accepts the response if the received data is complete and matches its local inventory database. For newly discovered drug dispensers, we want 95% of the notifications to be correct and complete, and at most 5% can be rejected with a notification to the smart cabinet operations support center. So interoperability is really a key quality attribute for the Internet of Things. And it needs to be addressed, to unlock the full potential, of that Internet of Things. An IoT application is often built as a system of systems and has a very dynamic nature. And this will require generic interoperability mechanisms, that support runtime discovery, and response handling. The general interoperability quality attribute scenario covers all those aspects.
