Technology exists, and will keep evolving, to help achieve desired business outcomes. This is the ultimate fact. Business owners and investors always look for the following business outcomes when they run a company or invest in any business domain:

• Increased business sales, revenue, company value, the number of customers, and profits. In other words, an increase in the value of business growth with respect to the different business metrics we have just mentioned.
• Reduced business operational costs, which means the cost of running and operating the business must not exceed the value of the business profits by any means. Otherwise, the business is not considered profitable.
• The mitigation of different business risks such as new market disruptions and innovations, more competition, falling brand reputation (including an increase in the number of unhappy customers, extra product failures, negative social media feedback, and other factors affecting business brands), security risks, fraud risks, and operational risks (lack of automation, speed, and employee skills).

These are three common, well-known business outcomes every organization or business aims to achieve. There may be more, but this book does not cover economy or business theories.

Based on those aforementioned outcomes, it is clear now that no one will buy technology just to play with it; rather, they will buy technology that can help them achieve their desired business outcomes, or, in other words, they will buy technology that solves their business problems.

If you have been in business for the last few years, I am sure you've heard the term Digital Transformation a lot. Every organization nowadays is talking about its steps and strategies to transform its existing business into a digital-first business, especially after seeing the massive growth and business disruption of many large, digital, hyperscale companies such as Amazon, Facebook, and other tech companies that were born in the digital era, including Uber, Airbnb, and a host of other successful start-ups.

"Digital transformation marks a radical rethinking of how an organization uses technology, people, and processes to fundamentally change business performance", says George Westerman, MIT principal research scientist and the author of Leading Digital: Turning Technology into Business Transformation.

Many IT and tech companies offer business enterprises and organizations a complete, rich portfolio of services, solutions, and technologies that they provide to assess such enterprises in their digital transformation journey toward becoming digital-first.

Since this book is about technology (not people or processes), the question might be, how will technology help such a great digital transformation initiative? Or, in other words, what are the digital transformation technology enablers that each enterprise could use on such an exciting transformation journey? You might even ask why we are talking about business outcomes and digital transformation when this book is all about the IoT.

Regarding the last question, it is a valid one, and we will answer it soon. One thing to mention here is that we have decided to share with you the practical, or what is called applied, IoT experience that we have gained from being in the IoT field for many years. This experience stemmed from designing, delivering, and operating many large-scale and production-grade IoT solutions for many large enterprises around the globe:

Now, back to the question of what are the key technology enablers and solutions for enterprise digital transformation programs? And to answer this, let's look at the technologies and architecture paradigms that are considered key enablers for digital transformation:

Figure 1.1 – Digital transformation – key technology enablers

Let's explain these key technology enablers in more detail.

Transforming into cloud-native applications and solutions

Transforming existing enterprise systems and IT workloads into new and modern cloud-native solutions is a key enabler in the digital transformation journey.

There are many different views on the definition of cloud-native, especially when it is compared with other terms and trends such as cloud-readiness and cloud-enabled. We will cover this in more detail later in the book. However, for now, we will stick to the official definition of cloud-native as per the Cloud Native Computing Foundation (CNCF):

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

The benefits of transforming organization workloads into cloud-native workloads are as follows:

• Releasing software fast so that it can hit the market quickly with new features
• Reducing costs, and leveraging the cloud and different pricing models, for example, pay as you go or paying for what you consume
• Increasing the scalability, reliability, and availability of enterprise applications and solutions
• Avoiding vendor lock-in – in other words, increasing application and solution portability

Moving to the cloud

There are many benefits of migrating and moving enterprise IT workloads and systems to the cloud (especially public clouds). We'll mention a few here:

• Operational benefits, operational excellence, and operational efficiency: Efficiency means you get more for less. In the public cloud model, the monitoring and support of application workloads become much more effective and manageable. Public cloud providers offer lots of automation tools, different support, and monitoring services to help enterprise operation teams.
• Financial benefits and cost reduction: The move from the CapEx (Capital Expenditure) model to OpEx (Operating Expenses), or the pay-as-you-go model, helps you pay for what you use. With this model, by reducing the total cost of ownership (TCO), you don't need to worry about data center facilities, ongoing hardware maintenance costs, and support to maintain the required reliability and availability of your IT and system workloads; the cloud provider will take care of such things.
• Faster innovation or shorter time to hit the market: Leveraging different cloud offerings, such as IaaS, PaaS, and/or SaaS, that enable the enterprise to try and build a proof of concept (POC) of any new ideas very quickly without worrying about buying hardware, software, platforms, and so on.
• Manage business growth and regulations effectively and smoothly: Most key public cloud providers offer a large set of regions and data centers across the globe. In a couple of minutes or less, you could deploy your workload in any region or geography around the globe if you have business needs in a particular region or have to observe local regulations or compliance requirements, such as data not leaving the country where the business is operating.

Big data and advanced analytics

Traditional analytics and business intelligence technologies and tools have long been used in enterprises and organizations of different sizes. However, the amount, velocity, and different varieties of data generated by business IT (information technology) and business OT (operational technology) systems change the way data and business analytic solutions work. Now, we are talking about big data technologies and real-time or near-real-time data analytics solutions versus historical data analytics.

AI and ML

Artificial Intelligence (AI) and Machine Learning (ML) play a vital role in the digital transformation journey as enterprises in different business segments use different AI and ML models and solutions, including predictive maintenance, product recommendations, personalized marketing and promotions, chatbots, drag discovery, fraud detection, radiology image recognition, video analytics, content commissioning, content creation, auto-subtitling, sentiment analysis, self-driving cars, and many other interesting business cases and solutions besides.

Modern applications and architectures

Creating a powerful customer digital experience requires the availability and utilization of a rich set of modern applications and architecture paradigms. For example, in modern apps, the de facto architecture paradigms commonly used nowadays are microservice and two-tier architecture versus the traditional three-tier architecture. When it comes to compute, modern solutions and architecture paradigms will include things such as Serverless Event-Driven Compute (for example, AWS Lambda, Azure, and Google Functions), Containers (for example, Docker), and Container Orchestration (for example, Kubernetes).

When it comes to Middleware and Integration, modern solutions and architecture paradigms will include things such as API Gateway, GraphQL, Service Mesh, Pub-Sub Architecture (queues and Service Bus), and Event Streaming (Kafka). When it comes to Databases, it is not just a question of traditional, well-known relational databases or Relational Database Management Systems (RDBMSs); other database types have emerged recently, including NoSQL, object storage, graph databases, and in-memory databases. When it comes to Mobile Apps and Web Apps, modern frameworks such as React Native, Angular, Vue, and many other frameworks and technologies besides will be used to build such amazing modern customer or consumer apps.

Internet of Things (IOT)

IoT is a key technology enabler for digital transformation. In fact, IoT is the most important technology enabler for the digital transformation process as it is also a key enabler for some other key technology enablers, such as big data and advanced analytics, AI, and machine learning. How? Simply put, such technology enablers depend heavily on collected data and insights from the different data sources of a running business. IoT is one such enterprise or business operational data source.

In the next few sections, we will discuss the different aspects of IoT, in other words, we will discuss the what, why, and how of IoT solutions and technologies.

James Phillips, corporate vice president of Microsoft's Business Applications group, said the following;

It all starts with data; data is coming out of everything. If you can harness that data, make intelligence out of it, and use it to improve your business processes, you're in a position to transform your company and industry.

Have you heard about the Observe, Orient, Decide, Act (OODA) cycle that has been developed by a military strategist and United States Air Force Colonel, John Boyd? As the name suggests, it is a decision-making process based on a loop or series of steps or tasks. It all starts by observing or monitoring the target by collecting data from multiple sources, and then doing orientation by filtering, analyzing, and enriching the collected raw data. Next comes deciding, based on the insights collected and what actions need to be taken, and then finally executing such actions and assessing whether the decision taken was right or wrong. Such a loop continues endlessly.

Enterprises get insights from customer interactions, sales, and connected products to improve the quality of their products, find untouched revenue streams, increase customer satisfaction and retention, and improve the whole business process and operations.

As we can see, there is a strong relationship between IoT and data, so let's dive further into that relationship to understand IoT better.

The relationship between IoT and data

Imagine converting any physical thing around you into a smart connected thing and getting insights from that physical thing remotely. This would be awesome, wouldn't it?

How can I convert a physical thing into a smart thing, you may ask? The answer is by using IoT technologies and different IoT ecosystems, such as sensors/actuators, microcontrollers, connectivity, and IoT platforms.

Still not clear? Let's take an example. Suppose you run a waste disposal company. The trucks of the company currently travel once a week to different residential areas in the city. After a while, and based on some insights and data analytics, you realize that on some days, the trucks return almost empty as there is not much waste to be collected on those days. That is a business problem as you could save money on the fuel used and employee wages for those days, you could help to save the environment by reducing air pollution and toxic emissions, and so on.

To solve that problem, you need the waste bin to somehow talk to you or notify you whether it is full, halfway there, or empty. Interesting. So how can we do that? We could install in each waste bin a small low-power, constrained IoT device (or a microcontroller in short) equipped with an ultrasonic sensor (such as ultrasonic thru-beam sensors) to detect the level of waste inside the waste bin. You could have another sensor to detect how many times the bin lid has been opened. The microcontroller could have a radio communication module for short-range connectivity options such as Wi-Fi Bluetooth Low Energy or Zigbee, or long-range connectivity options such as cellular (mobile) network connectivity to provide internet or network connectivity to the microcontroller to send the sensor insights or data to the IoT Cloud backend.

Once you have the data in the IoT Cloud, then it becomes just another software or data analytics solution to get insights and act accordingly. Similarly, you could simply convert anything into a smart thing.

The concept of converting any physical thing into an internet-connected thing is really disruptive and has a big impact on the current internet infrastructure. Currently, there are billions of devices already connected to the internet, including laptops, mobiles, tablets, PCs, and other smart connected products, but with such a concept, we have to deal with massive growth in the number of devices connected to the internet network. In a single smart home, for example, you could have 100 devices or more connected to the internet.

The options in terms of dealing with such a massive number of internet-connected devices are either to extend the existing internet infrastructure or to have a dedicated IoT.

Definition of IoT as per Gartner

The IoT is a network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment.

Now that we have an idea of what the IoT is, let's move on to its impact on different industries.

Over the course of history, there have been different industrial revolutions that occurred in different eras. The first industrial revolution that occurred between the years 1760 and 1840 introduced machine power to replace hand power. At that time, this represented a significant achievement that disrupted and changed many industries, including mining, the iron industry, and agriculture.

Then, between the years 1871 and 1914, the second industrial revolution was enabled and powered by one of the greatest inventions and discoveries of humankind – electricity. Electricity fundamentally changed and disrupted different industries at that time.

In the late 20th century, the third industrial revolution was powered and enabled by the great invention of the computer. Computer systems and networking paved the way for the next and most recent industrial revolution, aka Industry 4.0.

The fourth industrial revolution (Industry 4.0) includes many technology enablers, such as IoT, cloud computing, automation, AI, ML, analytics, and cybersecurity, for disrupting a variety of industries and manufacturing processes.

IoT plays a critical role in shaping Industry 4.0 and impacts and disrupts any current industry and business. Let's learn how!

Manufacturing

With IoT technologies, different consumer products and services are not only classified as connected products, but they move to the next level of a business model where the following features can be easily introduced and bring great business value:

• New billing and revenue models: Think about smart bulbs, for example. What about buying smart bulbs on a monthly-based subscription instead of the current traditional model (that is, it is yours for just a one-off payment). In that new model, the consumer will not worry about ongoing maintenance issues with smart bulbs in their home as they will pay the monthly subscription to the smart bulb company, which will cover everything, including installation and ongoing post-installation maintenance. In other words, you rent the bulbs in your home instead of owning them. This new model enables and introduces IoT technologies, such as asset monitoring IoT solutions.
• Increased quality of products and services: A smart factory typically collects massive amounts of operational data that is generated by its connected devices, and also from the environment where those devices are deployed and operate. This helps the factory to undertake proper analytics on such massive amounts of data and introduce new features to the company's connected products or even predict failures in the connected products and act proactively in fixing those expected failures. This could be done by running predictive maintenance machine learning algorithms in the cloud based on the data collected by IoT sensors.
• Increased business agility and resource optimization: With IoT, companies or factory staff can run and maintain a company's connected products and services remotely using what is called a remote asset management solution. We saw during the COVID-19 pandemic in the year 2020 how companies that use IoT technologies in their products and services managed to survive and ensure business continuity during that difficult time. Also, with the concept of digital twins, workforce safety increased as staff no longer have to face some hazardous challenges during the manufacturing process.

Energy and utilities

Many challenges, such as connectivity issues, asset tracking and monitoring, safety, and security emanated from remote locations such as refineries and oil fields. Those challenges are addressed by leveraging IoT technologies such as IoT device management, IoT connectivity, edge computing, ML, and Analytics @EDGE.

Also, on the consumer side of things, IoT helps a lot in saving energy. Think about smart lights that detect a person's movement in a room and switch on only if there are people in the room. They can also detect brightness levels – whether it is daytime or during the night, and act accordingly. Other examples that employ the same idea are air conditioning systems and heaters. These kinds of solutions save lots of energy resources and reduce consumers' bills as well.

In the utilities sector, things such as smart meters are the first requirement for many utility companies.

Transportation

The IoT fundamentally impacts and disrupts the transportation industry. IoT technologies play a critical role in the following services and features in that industry:

• Connected vehicles.
• Autonomous vehicles and self-driving.
• Fleet management.
• Increased safety and security.
• Increased efficiency.
• Onboard entertainment.
• And many other interesting features and services besides. Recently, as a response to the COVID-19 pandemic, we have started to see trains and buses being equipped with multiple additional sensors to help train and bus companies enforce social distancing and other health-related rules that were put in place to help fight the pandemic.

Health care

The IoT fundamentally impacts and disrupts this industry. IoT technologies play a critical role in the following services and features of the industry:

• Wearable patient devices to remotely monitor blood pressure, heart rate, and many other biometrics. This helps in tracking the health status of old and lonely people to act immediately in the case of an emergency.
• Doctors can now diagnose their patients remotely as they get all the data that they need to collect from their patients through attached IoT devices or sensors. With the introduction of 5G (a super low-latency connectivity option), it will become possible to perform remote surgery, which will help save lots of lives in remote areas.
• Different hospital equipment can be tracked and monitored by IoT using IoT asset tracking solutions.

Retail

Have you heard about the interesting "Amazon Go" stores that have no staff working in them? Consumers just pop into the store and buy whatever they want and when they leave the store, payment is taken automatically? Interesting, isn't it? IoT and other modern technologies are behind those types of smart stores.

In retail, the IoT supports many use cases, such as the following:

• Real-time inventory management
• Personalization
• Safety and security, that is, video analytics
• Cost savings and operational efficiencies
• And so many other interesting features and services

Sports and leisure centers

The IoT supports many use cases in the sport and leisure center domain, such as the following:

• Real-time tracking
• Improved safety with video analytics
• Interactive fan engagement

Agriculture

IoT technologies introduce many benefits to the agriculture and farming sector, such as the following:

• Livestock and crop tracking.
• Improved crop quality and increased volumes.
• Increased farming process efficiency. Think about smart irrigation and how much water the farmer could save if they manage to detect soil moisture and see whether crops require watering. Also, in a smart irrigation solution, you could get input about the weather status and whether it will rain, so you could save even more water on this basis.

One of the interesting use cases in that sector was a case of a farmer complaining about an increase in the newborn cattle death rate (this is the business problem) that occurred because the farmer did not know exactly when cattle would give birth. During labor, human intervention may be required to help female cattle should a problem arise.

So, how could IoT solve that business problem? With a very tiny microcontroller equipped with a vibration sensor and a cellular communication module attached to the tail of the pregnant cattle, at a specific vibration rate (this specific rate indicates that the cattle is giving birth), a video call will be triggered with the farmer and the latter can watch the whole process from their home and intervene if needed. Through this solution, the volume of newly born cattle has increased significantly.

Supply chain

IoT technologies introduce many benefits to the supply chain sector, such as the following:

• Detecting counterfeit goods
• Improved product quality, that is, better control of products' expiration dates
• Real-time or near-real-time inventory management

Cities

Resource scarcity, or a lack of resources, occurs when demand for a natural resource exceeds supply. Therefore, in a modern economy, there is always a need for new and sustainable financial and service models.

Smart cities are a business initiative to offer a sustainability model and the best quality of life standards with fewer resources.

IoT technologies help a lot in achieving the vision of smart cities and completely disrupt lots of traditional citizen and council services. Here, we'll mention a few:

• Smart parking
• Smart street lighting
• Smart waste management
• Smart energy management
• Smart buildings

And so many more features and services.

Home automation – smart homes

With IoT technologies, the concept of a true and complete smart home is possible. Many products and services in homes are powered by IoT technologies. Here, we'll mention a few:

• Smart refrigerators, microwaves, ovens, coffee machines, TVs, and so on
• Smart lighting
• Security and safety
• Smart windows, doors, curtains, and so on
• Smart thermostats
• Smart gardens

And many other features and services besides.

Without any doubt, and as has already been stated, the IoT is everywhere and disrupts many different business sectors.

Important Note

What is interesting here is the fact that the IoT solution paradigm is very simple and very common. In any sector, you will have things or IoT devices equipped with sensors to sense the physical world and with communication modules to provide connectivity to send the collected generated data from those IoT devices to the IoT backend cloud for further analysis.

To conclude this section, the most important thing is understanding business problems, how IoT can solve these issues, and what benefits businesses will get from using IoT technologies. Let's now move on to understand more about IoT solutions and technologies and see how it all works together.

When an architect, designer, or developer starts thinking about solution architecture for a business problem, they usually start thinking about a standard reference model or reference architecture that has been used and tested, with proof of success, by other experts in solving the same business problem they have in hand.

In traditional IT systems, you go with well-known architecture paradigms such as three-tier architecture, Service-Oriented Architecture (SOA), two-tier architecture, and many more modern paradigms, such as microservice-based architecture and serverless architecture. Even at the software code level, there are software design patterns.

IoT solutions are not unlike traditional IT solutions in the sense of the need to have a standard solution reference architecture or solution building blocks for any IoT solutions. However, IoT solutions are different in the following ways:

• IoT solutions, by default, are End-to-End (E2E) solutions, from devices/sensors to web and mobile apps for end user use.
• IoT solutions contain so many architecture paradigms that in the IoT solution application layer, you could leverage one of the architecture paradigms we mentioned before, for example, three-tier architecture or serverless, while in the IoT solution analytics layer, you have different architecture paradigms, such as Lambda and Kapp architecture, with other IoT solution layers. We will explain those types of architecture paradigms later in this book.
• The footprint of skills and technologies required for IoT solutions is big compared to traditional IT solutions.

In Figure 1.2, we have tried to capture, to some extent, the standard or commonly agreed upon IoT reference architecture, or IoT solution building blocks, that can be used to address IoT solutions for different business problems in different business domains:

Figure 1.2 – IoT solution reference architecture

Let's examine each layer of the IoT solution reference architecture in some detail.

IoT devices layer

This layer of the solution focuses on the IoT devices and their ecosystems. IoT devices can be classified into two categories:

• IoT endpoint devices: This kind of device is usually cheap, low-power, or battery-based, such as constrained microcontroller devices that have sensors attached to them to sense objects in the physical world, or a wireless communication module to support short-range connectivity options (Wi-Fi, Zigbee, Bluetooth, and so on) to connect that device to an IoT edge or gateway device or to the IoT backend cloud directly using long-range connectivity options such as cellular, Ethernet, or satellite connectivity options. They also have a real-time operating system (RTOS) and different software stacks, Software Development Kits (SDKs), and embedded systems.
• IoT gateway devices: This kind of device is more powerful or bigger in terms of resources (compute, networking, and storage) compared to resource-constrained and limited IoT endpoint devices. Such types of devices usually run gateway services and have features such as the following:

a) They act as a communication hub/router, that is, helping IoT endpoint device-to-device communication or IoT endpoint device-to-IoT backend cloud communication.

b) Data caching, cleansing, buffering, and aggregation locally at the edge.

c) IoT endpoint devices go through the gateway to get internet access and don't directly connect to the internet, so such devices manage IoT devices' security.

d) They play a role in the edge computing paradigm as sometimes it is used for local data processing and analytics.

e) The IoT gateway plays a critical role in supporting legacy and protocol conversion. Old IoT devices typically run old IoT connectivity protocols. The IoT gateway can convert those old protocols to modern and supported IoT protocols that run in the IoT edge layer or the IoT Cloud.

We will cover this layer in detail later in the book.

IoT edge layer

The edge or fog computing paradigm, in short, is running data center workloads very close to the end user or devices. You can move a small data center workload or an entire workload to the edge; it all depends on the edge location facility size and the data center's supported capabilities.

Let's look at the three main drivers behind the need for the edge computing paradigm.

Latency

We can't beat the speed of light, right? This is physics. In other words, whatever the quality and strength of a fiber optic cable used for data transmission in a packet data network, the transmission of the data will not be done in zero or fewer milliseconds.

Think about an IoT device running in a car park in the Singapore region, with the IoT analytics and applications running in the IoT backend cloud in the USA region. We should expect – and we can't do anything about it – in the region of a 250 ms latency factor added to the overall application request-response latency. So, a request raised from the IoT device in the car park might take roughly 1 or 2 seconds in total (250 ms latency + application processing time + database processing time, and so on) to get a response, assuming the workload running in the IoT Cloud is well designed and implemented and will not add any further unnecessary latency to the response time.

In some applications, getting an answer or response from the IoT backend cloud in 1 or 2 seconds could be fine, but in other real-time or near-real-time applications, that time could be a big problem. Regarding the example we just discussed, imagine there is a fire in the car park and the drivers need to get out or escape as soon as possible. The car park gate is closed and waiting for a response from the IoT backend cloud to open. Getting the response in 1 or 2 seconds in this case (note: we are not discussing here a no-response scenario as that is a completely different case altogether) might be too late to save people's lives.

In network topology, data traffic goes through multiple nodes or hops till it reaches its destination. Besides the light speed latency that we discussed above, you could also have a number of network issues, such as the cable being torn or some congestion in one of the nodes in the network topology. All such factors could even make the situation worse in terms of latency or getting a response quickly from the IoT backend cloud.

Edge computing solves these issues and challenges by running the IoT Cloud workload required (for example, Apps, Analytics, ML, and Control) locally, that is, as close as possible to IoT devices.

Cost savings

Data is important and, in fact, the goal of any IoT solution is to acquire data, gain some insights, and finally, act upon those insights.

IoT devices generate, or can generate, massive amounts of data. You can have data generated in a very small time resolution, for example, one second or less. Domains such as analytics and ML usually require such big data to give proper analytic outputs or excellent ML model accuracy results, but processing and storing such an amount of data comes at a cost.

Edge computing solves that challenge by processing all (or part of) such IoT-generated data at the edge and storing only the relevant and required data needed for further analysis and applications in the IoT backend cloud.

In the edge cloud, you can do data aggregation first before sending the data or batch of data to the IoT backend cloud. You can run advanced near-real-time or streaming analytics on the edge and might be storing just the results of such real-time analytics in the IoT backend cloud for other historical analytics solutions (for example, trends). For example, running analytics on the last 10 or fewer minutes of usage of smart parking could be done easily on the edge with data stored and processed on the edge for such a time resolution, that is, 10 minutes. After that, data could be deleted or aggregated into a higher time resolution (for example, 1 hour or so) and that aggregated data is then sent to the IoT Cloud for historical analytics.

Edge computing solves the preceding issues and challenges by reducing the cost of storing and processing such massive amounts of generated IoT data in the IoT Cloud.

Data locality and privacy

Due to certain regulations or data privacy compliance requirements, you might have to store sensitive data such as personal data generated from IoT devices within the country or region where those IoT devices are deployed and operating. A problem may arise if you have a kind of centralized IoT backend cloud in one or more regions that differs from the highly regulated regions the IoT devices are deployed and operated in.

Edge computing solves that issue by storing and processing such sensitive data locally and might anonymize such data and push it later to the central IoT Cloud in an anonymized or masked form.

We will cover this layer in further detail later in the book.

IoT backend and application layer (IoT Cloud)

This layer is very important in any IoT solution as it covers so many solutions and applications. Let's look at these in detail.

Provisioning layer

Provisioning, in general, means setting up and configuring backend systems with all the required information and configurations the solution's upstream and downstream systems require to operate as expected.

In IoT solutions, IoT device provisioning can be done in many backend systems depending on the final IoT solution architecture, but here are common systems required in IoT device provisioning:

• A thing or IoT device provisioning: This system or platform is responsible for storing IoT device metadata in the IoT Cloud database – usually, it is called an IoT device registry solution. Metadata such as the device ID, device description, and so much other metadata that you could store about the IoT device will help you in the solution later; for example, storing the device's location (which floor of the building, parking lot, and so on the IoT device is installed on) might help in an end user's journey when it comes to searching for a smart parking solution and suchlike.

Also, IoT device identity details such as device credentials and/or X.509 certificates can be securely stored and provisioned in that layer.

• Connectivity provisioning: The IoT device might have one or more communication modules, for example, one communication module for Zigbee connectivity and another one for cellular (mobile) connectivity.

In the case of cellular connectivity, for example, you must configure or provision a Subscriber Identification Module (SIM) with the mobile network operator, otherwise such connectivity will not work.

Ingestion layer

This layer is the front-door layer of backend IoT Cloud solutions and services. In other words, this is the first layer that receives data from the IoT endpoint devices or IoT edge and ingests such data into the proper IoT Cloud storage layer. In that layer, you can have the following components:

• MQTT Message Broker: We will cover the Message Queuing Telemetry Transport (MQTT) protocol in greater detail later in this book, but for now, MQTT is a lightweight publish-subscribe (or Pub-Sub) network protocol that supports message transportation between devices, so one device publishes the message to a specific topic and the other device(s) or applications from the other end subscribe to that topic to get the published message. MQTT is considered one of the best IoT application communication protocols for a wide variety of reasons, which will be discussed later. But for now, the MQTT lightness feature is the most obvious reason to prefer MQTT over HTTP as IoT endpoint devices are usually constrained in terms of computing resources, so running heavy protocols such as HTTP might be a problem or not supported at all by the IoT endpoint device operating system.

A complete IoT solution should have a scalable, reliable, resilient, and secure MQTT message broker, or we can call it an MQTT server since the IoT endpoint, IoT edge devices, and IoT applications usually act as MQTT clients.

• Streaming Processing Engine: Data, in the case of powerful IoT devices, could come from the IoT devices directly in the form of data streams over the HTTP(S) protocol or, typically in large-scale and production-grade IoT solution architecture, you have in the front an MQTT message broker and that message broker sends or forwards such incoming IoT data (coming through MQTT) to the streaming processing engine for further processing if required.

A complete IoT solution should have – if needed – a scalable, reliable, resilient, and secure streaming processing engine such as Kafka to support IoT data streams.

IoT rule engine

This component is critical and crucial in any IoT solution. Why? Because this component is the glue between IoT devices on the ground and the IoT backend cloud. In other words, the component is responsible for directing incoming data from the IoT devices to their destination in the IoT backend cloud. There are so many destinations, such as the database (SQL, NoSQL, and so on), message queue/bus, data lake, or object storage such as Amazon S3, Hadoop, and a streaming engine for further processing or real-time analytics use cases.

Storage layer

In this layer of an IoT solution, there are so many different storage options, as we will discuss later in the book, but the most common one used in large-scale and production-grade IoT solutions is object storage solutions such as the famous Amazon S3 object storage service.

The concept of the data lake – usually built on top of object storage solutions such as Amazon S3 – is the recommended IoT design pattern where all data in whatever format coming from IoT devices will be ingested and stored durably and securely in that data lake storage for subsequent processing.

Further down the line of IoT solutions, you could have another process or system read such raw IoT data from the data lake for further processing and storage. For example, you could perform some data cleansing, preparation, and processing, and store the data in another data store such as a SQL database (for reporting) or a NoSQL database (for a real-time dashboard application).

Analytics and machine learning layer

This layer of the IoT solution covers all systems and components used in building a big data and analytics standard pipeline (collect->process->store->analyze->visualize).

It also contains systems and components used in building an ML pipeline (Data Extraction -> Model Training -> Model Evaluation -> Model Deployment).

This layer is so important because, as explained earlier, IoT is all about getting the data for analytics and insights.

We will cover this layer in further detail later in the book.

IoT applications layer

In this layer of the solution, there are many components. Let's briefly discuss them.

Compute services

You will write application code and you will need to deploy or run that code, so you will require compute services to host the application code. These are the typical options:

• Bare-metal or physical host: This option is so expensive and not often used in the era of public cloud and managed hosting services. It could be used only if you have legacy application code that has special hardware specifications or special software restrictions, for example, licenses.
• Virtual Machines: This option is the most used compute option whether applications are deployed in a traditional data center, a private cloud, or a public cloud.

Virtualization technologies have been a game-changer in the computing service domain in recent decades and are still valuable options in terms of modern application deployment.

• Containers: Container technologies are the latest compute services that offer the greatest benefits. We'll cover them later in the book.

Container technologies help a lot in achieving the desired benefits of new application architecture paradigms such as microservice architecture. Microservice architecture concepts were not new, but with container technologies, they become brighter and make much more sense.

Container technology introduces a need for a container orchestration platform to manage container deployment on a large scale. Kubernetes is an open source container orchestration engine designed to deploy and manage containerized services on a large scale.

There are other container orchestration platforms available on the market offered as commercial solutions, such as AWS ECS – Elastic Container Services, or open source, such as Apache Mesos or Docker Swarm. However, Kubernetes has proven to be the best and is the market-leading container orchestration platform with huge technical community support.

• Serverless: Serverless means there is a server, but the less part of serverless means you do not manage that server at all.

In the serverless paradigm, the application developer will focus on the code only, be it Java, Python, C#, and so on. Then, when it comes to deploying that code onto a server-side platform, the developer simply uploads the code artifacts to the serverless provider (whether it is a public cloud provider or a private cloud provider). The serverless provider behind the scenes will deploy that code to a server managed by that provider.

Serverless technologies, also called Function as a Service (FaaS), typically run and manage containers at scale behind the scenes to deploy and run the user's uploaded code.

Serverless usually follows an event-driven architecture paradigm. To execute the uploaded code, an event must be triggered to notify the serverless service to execute your code and return its result, or it can be triggered in a scheduled manner.

Examples of serverless offerings are AWS Lambda, Azure Functions, and Google Cloud Functions.

As part of the IoT solution design phase, you have to choose the compute service you require for your solution. You might prefer containers over virtual machines or vice versa, you might choose both for different applications' requirements, or you may prefer serverless for a quick start and to avoid server maintenance, and so on.

Database services

In modern applications, no one database engine or type fits all data and applications' purposes. Currently, there are lots of database engines for different uses and purposes, such as the following:

• Relational databases or SQL databases: This is the oldest and most well-known, with RDBMSs such as Oracle DB, Microsoft SQL Server, My SQL, MariaDB, PostgreSQL, and many more. Such kinds of database engines are usually used in traditional applications, ERP, and e-commerce solutions.
• Non-relational (or NoSQL) databases: As the name suggests, this other type of database engine emerged to solve some of the limitations associated with relational database engines, including scalability and availability.

There are many forms of NoSQL databases, including the following:

a. Key-value databases are commonly used in online gaming apps and high-traffic web apps.

b. Document databases are commonly used in content management systems and user profiles.

c. Graph databases are commonly used in social networking, recommendation, and fraud detection apps.

d. In-memory databases are commonly used in caching, session management, and gaming.

e. Time series databases are commonly used in IoT and industrial telemetry apps.

f. Ledger databases are commonly used in supply chain, registration, and banking transactions.

We will discuss these databases in more detail later and shed light on which one to choose during the design phase of an IoT solution. The IoT solution architect or designer should evaluate the different database options for the IoT solution based on the requirements at hand.

Middleware and integration services

This layer of the solution provides integration or middleware systems to connect IoT solution systems and integrate third-party and external systems as well.

There are many integration systems available, as per the following:

• Legacy middleware platforms: Such platforms were introduced earlier to support the integration of Service Oriented Architecture (SOA)-based applications. Such platforms host many integration services or features such as service bus, orchestration (the Business Process Execution Language (BPEL) engine), and many more integration features are included in the middleware platform, making it heavy or monolithic.

You might need one or two features out of all the included or built-in features of a single middleware platform. This makes decision makers think a lot before choosing between such kinds of platforms or the modern option, that is, an API gateway.

It is worth mentioning that companies behind such legacy middleware platforms have taken serious steps to modernize them to fit with new microservice and cloud-native architecture paradigms.

• API Gateways: With the new microservice-based architecture and API-first architecture paradigms, the need for a lightweight middleware-like component increased to avoid microservices' direct communication and to provide gateway features in terms of security, routing, and tracing. The API gateway was the component introduced into modern application architectures to offer those features. An API gateway can also be classified as a strong or a smart gateway.
• Event Bus / Message Queues: Message queues introduce significant benefits in terms of decoupling and scaling application components.
• Stream Processing Engine: The Pub-Sub (or publish-subscribe) pattern is one of the microservice-based application communications patterns. The other microservice communication pattern is the Sync pattern, where a microservice calls each other microservice's exposed APIs directly over the HTTP(s) protocol.

Pub-sub fits very well with microservice-based applications as microservices are usually developed, deployed, and scaled in standalone mode. Each microservice can trigger or broadcast events related to its operations and, based on the events triggered, the other microservices interested in such events can subscribe and listen to those events and act accordingly; for example, an order-created event triggered by a cart microservice. Then, other microservices, such as payment, inventory, and credit checkers that are interested in, and listening to, those kinds of events (that is, order-created events) can then start their functionality on the created order.

Apache Kafka is the most well-known streaming processing engine used on the market.

• Service Mesh: A new technology introduced to help service-to-service communications, the service mesh concept came into the picture to work side by side with API gateways in a very good and complete integration architecture pattern where an API gateway is used for external integration, while a service mesh is used for internal service-to-service communication. We will explain microservices, service meshes, and API gateways later in the book.

IoT applications and visualization

This layer hosts IoT applications, visualizations, and dashboards. In other words, this layer is the layer responsible for building what the end user will see and interact with, so it is an important layer in the whole IoT solution.

An E2E IoT solution is complex and requires many systems and solutions in order to be delivered. But if you think about IoT end users or consumers who will use the IoT solution in the end, you'll realize that those end users will interact mainly with the IoT applications of the solution in the form of a mobile or web app. Hence, the excellent customer experience that every enterprise or organization looks for will be driven mainly by that IoT application layer's Key Performance Indicators (KPIs).

To give an example, in your E2E IoT solution, you might have some problems in the connectivity layer, so, for the end user in that case, you could offer what is called a digital twin or device shadow to let the end user keep interacting with the IoT solution as normal, as if the IoT device is still connected. And when the device reconnects, it will read the instructions sent while it was offline from the device shadow service and apply what is needed. Or, let's say you have a problem in the device layer; for example, devices are not reachable at all and no telemetry is received from devices in the configured time.

In this instance, the entire IoT solution shouldn't go into stop or failure mode; you could still offer IoT application layer components to the end user, such as mobile and web apps, until you fix the device issue, but in that case, they will be in read-only mode, that is, the dashboards and reporting could still be offered to the end user. Yes, it will show out-of-date data, but that's better than shutting down the whole solution and losing end user engagement. The user might just want to check some historical reports or something.

In this layer, there are so many solutions and systems to be considered in building and delivering IoT solution applications. Let's briefly go through such components.

Dashboards and visualizations

There are many solutions when it comes to building IoT solution dashboards and visualization. Here, we'll mention a few:

• Ready-made IoT dashboard solutions: In this kind of application, IoT developers will be given a platform that has many built-in controls and widgets and they just need to configure or customize those controls and widgets with the IoT data source. This is a drag-and-drop kind of development.

There are commercial and non-commercial IoT platforms that provide such features as ThingWorx (commercial) and ThingsBoard (open source) and many others.

• Low-code solutions: Another option could be using generic low-code solutions to build the IoT solution dashboard and visualizations. Platforms include Microsoft PowerApps, Mendix, Appian, and many others besides

Usually, the two options above, that is, ready-made dashboards or an application built by a low-code platform, are used to quickly start the development cycle of IoT applications without the need for highly-skilled backend or full stack software developers to build the IoT applications from scratch.

• Do It Yourself (DIY) Apps: In this option, the company or the software vendor's developers will build the IoT solution dashboards, visualization, and apps from scratch.

Here, the IoT developers will use different frameworks and solutions to build IoT apps, such as the following:

a) Web and mobile frameworks – frontend.

b) Technologies and frameworks such as JavaScript, React, Angular, Vue, React Native, Ionic, Flutter, and so many others.

c) Microservices and backend APIs.

d) eTechnologies and frameworks such as Spring Boot with Spring Cloud, Flask, NodeJS, .NET, and so many other frameworks and technologies that are available on the market to build microservice-based applications.

e) GraphQL (read-only) works side by side with API gateways (read/write). It makes it easy for applications to get the data they need efficiently without chattiness between a client (for example, the browser) and backend server or backend API.

Now that we've discussed IoT applications and visualizations, let's move on to exploring IoT device management applications.

IoT device management applications

Managing an IoT device in terms of device provisioning, configuring, maintaining, authenticating, and monitoring is one of the mandatory IoT solution requirements. It is rare to find an IoT solution without a device management component in its architecture and ecosystems.

There are two options for IoT device management solutions:

• The buy option: There are lots of IoT device management solutions available on the market that cover most of the device management requirements and features.
• The build option: You can build an IoT device management solution in-house or with a software partner.

Without connectivity, there's no IoT solution. Connectivity is everywhere in an IoT solution and it acts as a glue between all IoT solution layers. Let's look at this in the next section.

IoT connectivity layer

Solution architects and designers should cover different connectivity options required in the IoT solution and how to connect IoT endpoint devices to edge devices and edge devices to the IoT backend cloud, which should cover which wireless (or wired) technology and communication protocols are to be used.

This layer will be detailed later in the book.

Security and identity and access control

Like connectivity, security and access control is a must-have requirement in any IoT solution. Different IoT solution components must incorporate security requirements into their design and delivery from day 1 or day zero. An IoT security breach is massive and dangerous in its impacts. Think about the hacking of connected cars and what could happen if a hacker has full control of a car while you are driving. What about switching off smart city streetlights or switching off electric grids and so on? It is serious, isn't it? We are now talking about systems that affect people's lives directly, not just traditional websites and online services.

Solution architects, designers, and developers should include all the required security and access controls in all IoT solution components. Topics such as authentication, authorization, malware protection, auditing, access control policies, and data protection in transit and at rest should be fully covered in the IoT solution.

Those are the five layers or the solution building blocks of any IoT solution. There are some other additional technological frameworks and tools used across all those layers, but they are mainly part of, or driven by, the delivery process used in the delivery of the IoT solution. For example, if the organization you are working in follows DevOps or DevSecOps practices, then developers and/or DevOps engineers will use things such as the following.

Infrastructure as code

Infrastructure as code means treating the infrastructure of the IoT solution the same way you treat the solution's source code. In other words, the infrastructure code or scripts are maintained in version control the same as the solution's source code, which will give us lots of benefits, such as faster time to production/faster time to market, improved consistency, less configuration drift, and modern app deployment methods. And finally, it improves the automation of the entire solution deployment.

There are many tools used for infrastructure as code. The most famous infrastructure or cloud-agnostic and open source tool is Hashicorp Terraform.

CI/CD (Continuous Integration / Continuous Delivery) pipelines

A solution or project's CI/CD pipeline tools usually include the following:

• Source code repository or version control: This is where the project or the solution's code artifacts will be stored and managed. Infrastructure code or scripts can also be hosted in this repository. There are so many source code repositories available on the market. The most common and famous repositories are those built in a Git repository, such as GitHub or GitLab.
• Build and test tool: When it comes to the build stage of the CI/CD pipeline, we have so many options and tools available to build the solution code and other solution artifacts, such as Maven, Ant, Docker, Gradle, Packer, and many more tools available on the market.

Usually, unit test scripts and integration scripts run as part of the building stage.

• Continuous Integration tool: This tool is the brain or the orchestrator of the whole CI/CD pipeline. It triggers the pipeline once developers commit code or based on a specific schedule in the Git repository, and then it executes the build and testing scripts. It then deploys the project binary and artifacts generated from the build stage to testing, staging, and finally to production environments if configured to do so, that is, without manual reviews. There are many tools, such as Jenkins, CircleCI, Bamboo, TeamCity, and others available on the market to do that job.
• Artifact repository: This is a tool to store and manage project or solution artifact deliverables. Usually, they are packaged in binary format. Such packages are basically the output of the build stage of the CI/CD pipeline. Examples include Docker images and the binary of the software. There are many tools on the market, such as Artifactory, Nexus, and many others in that domain.

In the next section, we will discuss IoT solution design patterns.

In software coding practices, you should have heard about software design patterns, in particular, those patterns introduced by the famous Gang of Four (GOF) book Design Patterns: Elements of Reusable Object-Oriented Software.

The idea of design patterns, in general in any domain, is to provide a solution that has been tested and proven by different experts to solve specific repeated problems or challenges in the subject domain. For example, in the software domain, you will see a list of design patterns that solve some common coding challenges, such as the Factory pattern, the Singleton pattern, and so many other patterns. In the enterprise integration domain, you will see patterns such as Publish-Subscribe, Event-Driven, Content-Based Router and Message Filter. In the cloud, you will see patterns such as Ambassador, Anti-Corruption Layer, Cache-Aside, and Responsibility Segregation (Command Query Responsibility Segregation (CQRS)).

In the IoT domain, we do have some design patterns and design principles that are commonly used in different IoT solutions. Let's look at some of these.

Telemetry

This is the most famous and common pattern used in IoT solutions. IoT devices sense the physical world and send related data to the IoT Cloud for further processing. Data sent from devices is called data telematics or telemetry.

To send the data to the IoT Cloud, you need connectivity and a communication protocol. Different protocols may be employed, including HTTP(S), WebSocket, and MQTT.

Since we are talking about telemetry, MQTT is the best and most common protocol used in sending IoT device telematics to the IoT Cloud or, to be more specific, to the IoT Cloud Message Broker or Edge Device gateway running the MQTT server.

This telemetry pattern helps many companies to build and offer IoT SaaS solutions or ready-made solutions, where enterprises buy ready-made IoT solutions to have their products connected very quickly and start to gain useful insights from them. The idea is simple: connect the device to an IoT platform and start sending telematics and the IoT platform will provide dashboard, monitoring, alerting, reporting, and analytics features out of the box based on the telematics data collected. Microsoft Azure IoT Central is one of those IoT application platforms that offer such ready-made IoT solutions with no great development skills required.

Command

This pattern is also very common in IoT solutions and usually comes side by side with the telemetry pattern. The command or action pattern means applying or running different commands to a remote IoT device – commands such as reboot, reset, switch on, and switch off device actions, and even upgrading the device firmware, is also considered a command pattern.

It is usually best practice to have control and management of the remote IoT device for monitoring, diagnostics, and security.

Outbound connectivity only

IoT devices are not like traditional web or proxy server devices where you can open some inbound ports such as 80 or 443 for incoming traffic from the internet or from a private network. Opening such inbound ports for traditional powerful devices could be acceptable, as usually there are firewalls, Distributed Denial-of-Service (DDoS) protections, and Web Application Firewall (WAF) solutions in place to protect such proxy web servers or the whole server farm from such attacks.

In the IoT, it is slightly different. IoT endpoint devices usually, or in most cases, do not run an IP stack, meaning there's no IP assigned to devices. They do not run an IP stack as they are low-power, constrained, and low-value devices. Even in the case of powerful IoT endpoint devices running an IP stack, it is recommended to not open its inbound ports to mitigate security attacks. Security breaches in IoT solutions are more dangerous than a breach in e-commerce applications or any other IT solutions as the impact of an IoT security breach will be severe on systems and humans as well.

So, the most common IoT device communication mode is the outbound communication mode (aka device to cloud), where the device will make an outbound call to the external network instead of receiving inbound calls (aka cloud to device) from external networks.

You might wonder how the command IoT design pattern we mentioned above works then? As explained before, a command means you send instructions to an IoT device to do some actions. Hence, this means inbound traffic from your application/system toward an IoT device. So how come we say IoT device connectivity is usually, or recommended to be, outbound?

This is a very good question and the answer is simple. The IoT device makes an outbound call to ask about any actions or instructions targeted for it that need to be executed. As we will learn through the book, IoT devices might be in a deep sleep mode most of the time and when they wake up, they communicate with the IoT Cloud or the IoT Edge; Hey, I am up now. Any jobs for me? Then, the IoT device will subscribe to a specific topic for such jobs and retrieve instructions and execute them.

Refer to the next pattern as this is related to that point as well.

Device twin or device shadow

For sure, connectivity will be dropped or disconnected at some point in time, and you should always consider that fact when designing an IoT solution. IoT devices might be deployed in very far away locations where there is no network coverage at all, where there is weak network coverage, or where intermittent connectivity occurs due to one of many reasons, such as electronic or radio interference from other surrounding devices or even the IoT device being in deep sleep mode to save the battery, meaning it is not connected all the time.

The solution to that intermittent connectivity challenge is to use an intermediate system or buffer to hold and manage the communication between the IoT devices from one end and the IoT application from the other end. In other words, IoT applications should not talk directly to IoT devices and vice versa. Rather, IoT applications should talk to the intermediate system and instruct it on what needs to be done on the IoT devices, and then that intermediate system will talk to the IoT devices if the IoT devices are on – the best-case scenario. Otherwise, if they are off, then that intermediate system will hold the message until the IoT devices come back to life, wake up, or connect again. Then, they will get the message buffered in the intermediate system when they were off and act accordingly.

Each IoT platform implements the above concept of the intermediate system. AWS calls it the Device Shadow service, Microsoft Azure calls it Device Twin, and so on.

Device bootstrapping or device provisioning

When you buy smart consumer devices, there is usually a common step to configure some device settings before the device works, settings such as the device access point or device connectivity, which Wi-Fi the device should use to connect to the internet in the case of Wi-Fi-enabled devices, which Access Point Name (APN) should be used in the case of cellular LTE connectivity, and which Bluetooth peer should be paired with. This process is called device setup, device provisioning, or device bootstrapping.

In industrial IoT (IIoT), provisioning or bootstrapping IoT devices is different and challengeable. In IIoT, we are talking about a massive number of IoT devices, so how can we have a device bootstrap on such a scale?

To give an example, think about a connected product company that produces thousands or even millions of such connected product devices. They sell devices across the globe. Now, you need a way to streamline the bootstrapping process for all of those IoT devices. If you choose cellular connectivity in your connected products, then how will you bootstrap or provision the SIM inside the device in different countries with different mobile network operators? It is a bit tricky and not a straightforward process.

Usually, two topics emerge in the provisioning and bootstrapping process.

Device identity

As a manufacturer or owner of IoT devices, how can I make sure that only my IoT devices – not any other IoT or non-IoT devices – talk to my IoT Cloud or my customer's IoT Cloud? There's a need to have some sort of attestation or credentials that are stored securely in IoT devices in order to connect to the IoT Cloud. The device will send such credentials to the IoT Cloud during the connectivity handshake, which can then be validated and authenticated by the IoT Cloud.

IoT device credentials could be in the following forms:

• A password or token
• An X.509 certificate
• A Trusted Platform Module (TPM)

There are pros and cons of each option, which we will cover in detail later in the book. But for now, and regarding bootstrapping, the question is how those credentials are stored and used by the IoT device.

To answer that question, a myriad of options are available, including the following:

• During the IoT device manufacturing process
• Over the air, that is, pushed to devices after manufacturing
• Just in Time (JIT) provisioning, that is, when the device connects for the first time to the IoT Cloud
• Dependent on a third-party solution, that is, a telecommunication network backbone

We will cover these options later in the book.

Device home endpoints

Where should the IoT device connect to send the data telematics? Will such an endpoint be statically configured in the device or will it be pushed to the device over the air? Is there a global point an IoT device can and must connect to when it connects for the first time, and then that global point will or might direct the IoT device to the endpoint the IoT device should connect to, for example, a specific region or country's IoT hub or IoT message broker?

All those questions should be answered and clarified as part of the device bootstrapping process.

Now that we have covered IoT solution design patterns in detail, it's time to discuss some use cases to broaden our horizons.

Despite this book being generically about designing and building an IoT solution, we will look at a case study to be used in the book's chapters where applicable.

A smart city initiative is not one IoT project; it is, in fact, so many different IoT projects and it usually has the following cases or modules to be covered:

• Waste collection management
• Street lighting management
• Digital building management
• Energy management
• Green space management
• Forest fire detection
• Digital citizenship services
• Smart parking

In this book, we've chosen the smart parking module of the smart city initiative to be used as a reference or case study:

Figure 1.3 – Parking lots (source: https://wordpress.org/openverse/image/d621a8cf-e786-4877-adea- bc5eb0ce7f87)

In the upcoming sections, we will go through the requirements or the business problems at hand and the design thought process of an IoT solution to address those business requirements and deliver the desired business benefits.

Parking space issues

Usually, in large, bustling cities around the world, finding a parking space (aka slot) is challenging and not an easy task at all. People sometimes avoid outings on account of parking issues. Governments and city council administrations usually look for solutions to address parking availability challenges. There are so many factors behind parking space issues, such as ineffective land planning, insufficient parking spaces, traffic congestion, toxic emissions, and others.

Putting ineffective land planning issues aside, as we can't help with that issue, the congested traffic and toxic emissions issues occur essentially because car drivers lack a real-time parking lot availability solution to enable them to efficiently and quickly find available parking lots in the city.

The solution to the parking issue

City administrators started looking into smart parking solution initiatives to gain the following business benefits and solve parking space issues:

• Reduce toxic emissions and help save the environment.
• Reduce traffic congestion.
• Reduce costs with less fuel consumption.
• Reduce the amount of time drivers spend searching for an available parking lot.
• Increase revenue – with smart parking, parking lots will be occupied efficiently by different drivers throughout the day, and a new billing model will be introduced, such as paying for exactly how long you stay.
• With smart parking analytics and ML technologies, city council administrators can undertake proper land planning to increase the number of parking spaces across the city.

Business requirement analysis

As stated earlier, understanding business problems and pain points in full is an important step toward solving such business problems. Sometimes the solution might be a non-technical solution and might not depend on technology at all. The solution might be just enhancing existing business processes or people skills.

In that phase of the project, that is, business requirement clarification, you, as a business or system analyst or solution architect, should put any questions you have to the business stakeholders as answering such questions will have an impact on the solution selected at the end. For example, Is the parking space indoors or outdoors? You might ask, will this matter? And the answer is yes, it will matter, as, based on the answer, you will define which devices, sensors, and connectivity options could be used. For example, if it is indoor parking, then you could have a source of electrical power available in the parking lot or nearby so you might not worry much about low-power, very constrained IoT devices and so on. As regards the sensors, you might not worry much about the external environmental and non-environmental impact on the functionality of the sensors, such as dust and lighting levels. For connectivity, you might choose Wi-Fi and fixed broadband instead of cellular (mobile) connectivity and so on.

The business and system requirement identification process is not an easy task; it would need a book to explain that topic at length. However, here are the general steps used in that process:

• What are the smart parking solution use cases? What are the business drivers for a smart parking solution or what are the goals of the business related to the smart parking solution?
• Who are the stakeholders of the smart parking solution?
• What are the business's smart parking and technical KPIs?
• What are the smart parking solution's Non-Functional Requirements (NFRs), such as security, availability, scalability, disaster recovery, and resiliency?

Let's dive a bit deeper here and discuss the role of various stakeholders in a smart parking solution.

City council administrators

These individuals will need to manage and monitor the smart parking solution, meaning they might require the following:

• A dashboard showing the occupancy level of the different parking spaces in the city
• An alert management solution to alert and notify council administrators of any issues that occur
• Analytics and reporting for smart parking solutions across the city
• A wholesale billing solution to help the council manage and bill different smart parking operators
• Data lakes and ML capabilities to enable council or government data scientists to run different ML predictive models to help with land planning and other logistics

Smart parking operators

Usually, councils do not run smart parking solutions themselves; rather, they make data such as parking space details and other data they can expose through a rich set of APIs available to third-party companies and partners to operate and manage the smart parking solutions.

The operators usually cover the following tasks:

• Setting up and converting parking spaces into smart parking spaces
• Offering vehicle owners different digital engagement channels, such as on web, mobile, or virtual assistant devices such as Alexa to do the following:

a. Search for available parking lots nearby

b. Book, reserve, and pay for an available parking lot

c. Parking lot management, that is, updates, changes, cancelations, and so on

• Monitoring and operating the whole smart parking solution on a production-grade scale
• Exposing or selling smart parking APIs to other third parties and start-ups for the co-creation of different ecosystems for smart parking
• Integrating with internal and external capabilities such as payment gateways, OpenCV (OpenCV is an open source library for computer vision or image processing), and many other features as part of the final smart parking solution

Vehicle drivers

These are the end users and the target users at the end of the new business model or smart parking solution. Drivers will be provided with the features mentioned above by smart parking operators.

Smart parking solution details

Now let's think about how the smart parking operator will address the requirements we just discussed and come up with a solution.

IoT solution field planning

In networking, network engineers usually do a survey where network nodes such as switches and routers will be placed on the site, which kind of cables will be used, and which kind of network topology will be used (that is, star, mesh, ring).

Cables going through specific routes and even walls is not a haphazard task; there are engineering practices and explanations behind all of that setup.

IoT solutions are no different from traditional networking solutions. In fact, the IoT is sometimes classified as a networking engineering topic. It is called the internet of things, so connectivity and networking are a core part of it.

With any IoT solution, there is a physical world that it needs to sense and then act upon that sensing, which means in an IoT solution, there is always a field or playground where you need to deploy and install IoT devices and sensors.

Step number 1 in any IoT solution is to study very well the field or the ground where the IoT devices will be deployed. In our case, the parking space that we need to study is a field.

We need to know the following about the city's parking spaces:

• The number of parking spaces in the city and their location details
• Parking space type(s):
  1. Is it a one-level parking lot or multi-level?
  2. Is it off-street (a kind of closed/private parking space where there is a gate (in and out) controlling the vehicles coming in and out of the parking lot), or is it on-street (an open parking area) where there is no gate to control the vehicles coming in and out of the parking space?
• Parking lot type:
  1. Within the parking lot, how many parking spaces are there? What type of parking spaces are they? That is, are they perpendicular, angled, or double parking spaces?
  2. Any other metadata about the parking lot, for example, its latitude and longitude.

IoT solution devices and sensors

Given the above IoT solution field planning, the next steps will involve choosing the IoT devices and sensors needed to detect the occupancy status of the parking lot.

There are so many ways in which to detect the occupancy status of a parking lot. Here, we'll mention a few:

• You could install one or more – based on the parking space size – surveillance cameras to cover the whole parking space. Then you could use the ready-made, advanced AI Video Analytics technology to detect whether the parking lot has spaces or is occupied.

Previously, you'd have had to build such services from scratch, using technologies such as image processing and similar, but now, with AI and ML's maturity, hyperscale companies such as Amazon, Microsoft, and Google provide so many ready-to-use cognitive services, such as object detection, image classification, or activity detection (video), that you don't need to build an ML model yourself; it is already done for you. You might only need to feed the model with your data, that is, parking lot images or videos to show when they are occupied and when they are empty. I said might, as detecting a parking lot's occupancy status is becoming a standard, popular use case in that domain, so you might even find a third-party company that offers APIs ready to detect that. You would just need to pass to those APIs images of the parking lot you want to check the occupancy status of and you would get the answer: Occupied or Empty.

• You could install in each parking space an IoT device buried underground. That device would be equipped with an infrared sensor to detect vehicle motion and report accordingly whether a space is occupied. This option might be a bit expensive as you would have to install an endpoint IoT device with sensors underneath each parking space. Yes, we could have low-value ($5 or less), low-power (battery-based, lasting 10 years or more) IoT endpoint devices to serve that purpose, but the cost will be linear with the number of parking lots in all parking spaces across the city as a whole.
• You could install – in the case of gate-controlled parking spaces – a sensor on the in and out gate controllers to count the number of incoming vehicles minus the number of outgoing vehicles to detect how many parking spaces are available and how many are occupied. Detecting how many parking spaces are available might be enough in some cases, but in other cases, there might be a need to show the vehicle owner or driver where exactly the available parking space they booked or reserved is. For the latter use case, you need to use a different approach, as explained earlier.

Smart parking in offline mode (or IoT Edge)

You might, as part of smart parking business requirements, need to run some smart parking workloads at the edge, like the example we mentioned before about calculating the number of incoming vehicles versus the outgoing vehicles, or some real-time or near-real-time analytic requirements, and so on.

You must think carefully about such requirements. You need to think about the locations of where you will put the edge computing nodes. Edge units could be as simple as a small Raspberry Pi device or as medium complexity as a small-scale data center, or even as complex as a complete data center hosted at the edge.

In the case of off-street or private parking spaces, edge units could be placed in the parking spaces or nearby, while in the case of on-street parking, it would be a bit challenging to know where you should put the edge units. There are many options for that case, such as renting a nearby facility such as a building or even a room(s) in a shared building. You need, though, to think about the connectivity between the IoT endpoint devices on the field and such edge units, or you could buy managed edge services or hosting facilities from telecommunication companies or public cloud providers who have massive infrastructure footprints to host your units.

We have mentioned telecommunications companies as they have really massive footprint infrastructure coverage for a district or even – with 5G technology – street levels. That is because of their need to host telecommunication radio equipment. Public cloud providers also have edge locations but, for historical reasons, they don't have the level of coverage of telecommunication companies.

IoT solution connectivity

Given the preceding IoT solution field planning and based on the parking space type and details, you can, as a solution architect, define what kind of connectivity is required in the solution.

First, you need to ask yourself, I need to connect what to what? You basically need to connect the endpoint IoT devices to the internet or to the backend servers of the smart parking operators or council. Those backend servers are hosted in what is called the IoT Cloud or IoT backend cloud.

There are two options available:

• Connect endpoint IoT devices directly to the IoT backend cloud.
• Connect endpoint IoT devices to the edge gateway first and then the edge gateway will connect on behalf of those IoT endpoint devices to the IoT backend cloud.

With the first option, that is, directly connecting endpoint IoT devices to the IoT Cloud, you will need the IoT endpoint device to do the following:

• Have a communication module to support WAN connectivity, that is, like the LTE (LTE-M) module in the case of using a telecommunication network (a SIM card-based or Ethernet module in the case of using fixed broadband)
• Have an IP stack running in the device to support IP-based connectivity protocols

Those two conditions make such a connectivity option, that is, connecting to the IoT Cloud directly, not the preferred option due to the following:

• IoT endpoint devices – in the case of underground buried parking lot sensors – will become a problem as the cost will be high, that is, you have to have in each endpoint IoT device a cellular or LTE-M module with a SIM card. Also, in order to run the IP stack, the devices can't be constrained to low-value IoT devices.
• Those IoT endpoint devices will usually be on streets or far away from power supplies, hence they are usually battery-based devices. Running an IP stack on such endpoint IoT devices would impact the battery life of the devices, which usually work for 10 years or more to avoid the disturbance of changing such devices or their batteries.

The second connectivity option – that is, through the gateway – looks good as you could deploy low-value, low-power, and constrained endpoint IoT devices in the parking spaces. Those devices could communicate between each other and gateway devices using low-power local wireless networking such as Zigbee or Bluetooth Low Energy. Such connectivity technology will help in saving device batteries and it is cheap. The gateway will connect to the internet, meaning the gateway device could use a fixed broadband (wired option) if available or use cellular connectivity (wireless option). The gateway device or edge could or should be a powerful device in terms of computing resources.

We could use the following communication protocols:

• IoT endpoint devices could use the Zigbee protocol to communicate with other Zigbee-enabled devices, including the IoT gateway device.
• IoT edge devices or gateway devices – IP-enabled devices communicate with the IoT backend cloud using MQTT or HTTP(S) over the internet.

Smart parking IoT backend cloud

From the requirements, we will need to build (or buy) the following backend components for the smart parking solution:

• An IoT message broker/ IoT device gateway supporting MQTT, HTTP(S)
• A smart parking operational center – a web app for council and smart parking operators' admin users for managing and monitoring the smart parking solution
• Smart parking web and mobile apps – for the vehicle owners or drivers to book, manage, cancel, and pay for a parking space
• A smart parking API hub – an API hub for external third parties and partners looking to use the smart parking solution's data and its available set of APIs in their solutions
• A smart parking data lake – a data lake solution storing all smart parking data from all sources in its original raw format for further analysis by other downstream systems and solutions
• A smart parking analytic solution – an analytical and machine learning solution based on the smart parking data lake solution

Smart parking IoT solution – non-functional requirements

The features or functionality of the smart parking solution might be negotiated with business stakeholders. Usually, the most common statements you will hear at that stage are we can't boil the whole ocean, which feature is a must and which feature is nice to have?, and so on. There are lots of features requested by business stakeholders, but not all such features could be delivered in one release of the IoT project for a myriad of reasons, such as a lack of resources, the pressure of the delivery timeline, or even some features just being fancy features that the solution can work without.

But, when it comes to non-functional requirements, usually there's no negation with the assumption that the business stakeholders agreed with the increasing costs associated with achieving those non-functional requirements. Every business wants its solutions to be highly available (up and running 24x7), highly performant, highly scalable, highly reliable, and highly secure.

As a solution architect, you should consider non-functional requirements from the design stage and provide all the design principles, technical components, and controls required to fulfill such requirements. Also, those design principles should be applied from the device to the cloud, in each layer of the IoT solution.

This section of this chapter is mainly to draw your attention to the philosophy or strategy that we will follow and use throughout this book:

• IoT ecosystems and technologies are so massive, and many technologies, solutions, and vendors are available for each IoT solution layer, from devices, sensors, and the edge to the IoT Cloud. Therefore, in this book, we will explain the concepts, and then we will explain the different options available. Finally, to be practical and pragmatic, we might go into the details of one, and only one, of a specific type of technology, solution, or vendor to show real examples where applicable.
• There are many IoT platforms available on the market, as we will explain in a later chapter. We will use one of those IoT platforms, which is the AWS IoT platform, and other AWS services that are related to building an E2E IoT solution. However, and as explained in the previous principle, the book will also touch upon other platforms if needed. For example, if a specific feature or service is not provided by AWS IoT and is provided by another platform, then we will cover that feature using the other IoT platform that provides the service.
• The book is basically for IoT solution architects and designers to design and build production-grade, large-scale IoT solutions, so we will not be able to go over some of the topics that will be covered in this book, such as connectivity, sensors, and devices, in-depth as they will require a dedicated book(s) in order to be covered in full. Having said that, the book will explain the concepts and some details that an IoT architect or designer should know about and understand when designing a complete E2E production-grade, large-scale IoT solution.

For example, when we discuss the IoT cellular connectivity option, we will not delve deep into how it works in terms of radio access networks, telecommunication core networks, and so on. We will instead explain the concepts to some degree so that you understand at a high level how such types of connectivity work and how you can use them as part of your IoT solution blueprint.

In this chapter, we have learned what the IoT is, why we need the IoT, and what IoT solution architecture looks like at a high level. We covered different IoT solution architecture layers, starting with the IoT devices layer, which hosts IoT endpoint devices, sensors, actuators, microcontrollers, and so on. We also discussed the IoT Edge layer, which hosts IoT Edge computing and platforms, and then the IoT backend cloud, which hosts all IoT applications, platforms, and solutions. We explored the IoT connectivity layer, which is responsible for IoT connectivity across the whole IoT solution, and finally, the IoT security and access management layer, which is responsible for the security controls and access management of the whole IoT solution. We also covered different IoT solution design patterns, including Telemetry, Command, Bootstrapping, Device Twin/Shadow, and IoT device outbound connectivity. At the end of the chapter, we talked about a smart parking case study, which we will use throughout the book's chapters when needed.

In the next chapter, we will start with the anatomy of the word IoT. We will start with the letter I in IoT, which refers to the internet or, in other words, IoT connectivity.