Leveraging good architecture to drive progress
Architects are big fans of patterns and standards. Doing something in a similar and proven way is common in just about every type of job or industry, especially those that produce physical or tangible results. The size or strength of the material can determine much about how to build something, and it helps to define the time and cost that goes into the build. We can translate this directly into building something less tangible, such as software. With Industry 4.0, we have the best of both worlds, hardware, and software, allowing us to use traditional engineering techniques and hopefully rigid hardware and software engineering processes.
In software, we often call them best practices, but it is not always everyone’s best practice. Sometimes what works for one company or team may not work for another. Or similarly, differences occur across industries or environments. With this in mind, our goal is not to prescribe exactly how things work but rather to provide a set of strawman models based on generally accepted industry best practices that can be adapted to your situation or solution.
Throughout this book, we will share approaches and patterns that can be adopted but don’t be afraid to go your own way (within reason). In addition, technology changes over time. What might be the best practice today may not be the same tomorrow as new approaches evolve for achieving your goals.
Observability
We have mentioned the idea of observability in this chapter, but let’s review it in more detail. Observability is not quite the same as monitoring, but there are a lot of different opinions on what the difference is. The name is not that important, but conceptually you should understand the difference. Our best definition to build upon monitoring techniques with an observational approach is as follows.
Monitoring involves collecting data from sensors, logs, and production or machine metrics. This allows you to understand the current state of a system, whether that be a machine or even the components within your IoT application. Monitoring enables you to know whether something is working and when a system or piece of equipment is down.
Observation takes it a bit further and allows you to better know why something is down or not working at the optimum level. Observation requires monitoring and possibly additional instrumentation at multiple levels. Consider the following possibilities:
- To see how systems work together: In IT, it is often possible that one system or process affects another, but clearing away the potential issues to get to the root of the problem can be challenging. For example, a web page is loading slowly, but the problem is that the database is overloaded or that the query is more complex and takes additional time to complete.
- To gain a deeper understanding of an internal systems operation: In the previous example about the database, only through deeper instrumentation, such as bytecode injection in the code world, could we gain insight into what is happening. That instrumentation level also allows us to see how components work together and understand how one depends upon another in the process flow.
To summarize, we can distinctly define the difference between monitoring and observation:
- Instrumentation supports monitoring, which tells you that something is wrong
- Monitoring supports observability, which tells you why something is wrong
As I mentioned, there are different interpretations (I have seen examples where this is reversed), but this seems to make the most sense. In reality, the end goal is something we all want to achieve. We want complete visibility into our systems and processes so we can handle problems and improve the outcome.
Repeatability lowers cost
As you move forward toward advanced digitalization, there will be a lot of moving parts. Both hardware and software will need to constantly adapt as the solution evolves. For large implementations where there is a lot of equipment, or the environment is widely distributed, it may take a lot of help to deploy and manage equipment. Items to consider, include the following:
- What type of equipment are you using, and can it be deployed or configured to handle multiple uses or types of equipment?
- What is the best purpose-fit type of sensor monitoring equipment (single-purpose or multi-purpose equipment)?
- How does sensor monitoring equipment stand up in terms of cost, training, installation, and maintenance?
- How much field training will be needed? Simple plug and place, or complex configuration and management training and runbooks?
- How will software need to be adapted as sensors and monitors are deployed?
As your solutions evolve, consider these guidelines and how you can streamline the deployment and management of the solution, ensuring that as much repeatability as possible is followed. If sensors and data collectors need to be configured, do the software and cloud need custom work? Think about things such as custom tags. At scale, how much work will it be to collect and store data from hundreds of pieces of equipment and thousands of tags?
