CBA Lab’s IoT reference architecture stands out through product neutrality and reusability

The Cross-Business-Architecture Lab has developed a reference architecture (RA) for IoT solutions. Unlike most RAs in the commercial IoT environment, the reference architecture created by the companies that participated in CBA Lab’s IoT Patterns and Architecture workstream was designed from the beginning to be product-neutral, and its individual elements were designed to be reusable.

By Dr. Verena Schmidtmann*

The RA is designed to help CBA Lab members develop their own IoT solutions and also support them when they evaluate commercial solutions. In other words, the reference architecture is both a guide for a company’s own developments and a checklist / evaluation tool for IoT solutions from external providers. The workstream also concluded that because a provider always has an origin and a focus, companies need to have a neutral RA geared toward the needs of users in order to be able to evaluate commercial solutions in terms of their structure and functionality.

The workstream participants had already gained extensive and varied experience with IoT solutions and platforms. They therefore used this experience as a basis to define five principles for their new reference architecture:

  • Cross-business design for ecosystems – IoT solutions must extend across company boundaries. For this reason, the RA includes API management, integration, and connectivity features that enable it to function effectively in different ecosystem roles.
  • Connection to enterprise IT – IoT solutions do not operate in an environment detached from “traditional” enterprise IT. IoT RA must reflect this connection and interaction. It was therefore of the utmost importance to the workstream participants that the further development of traditional IT in the ongoing digitalization process be taken into account in the RA. It is not possible, or desirable, to implement and manage digital business models solely via IoT solutions. Instead, enterprise IT needs to be involved as well, which means enterprise IT also needs to adapt to the new requirements. That’s why traditional IT architecture is also developing further, whereby the objective is for this type of architecture to contain elements of the IoT architecture in the future.
  • Incremental implementation of the RA – the participants wanted to create a reference architecture that contained both the elements needed for pilot projects and elements that play a role in company-wide IoT projects.
  • Lean design – the RA should only contain elements that are actually needed for an IoT solution. RA developers need to exclude from the very beginning things that are simply “nice to have.”
  • Reusability – the architecture created on the basis of the RA should contain reusable elements that allow it to support the largest possible number of IoT applications on the company roadmap.

The workstream participants used these five principles to formulate the following requirements relating to practical work with the reference architecture:





In order to ensure the greatest possible degree of reusability, both the Edge tier and the Integration tier should contain as little business logic or vendor-specific technology as possible.

If no defined business logic is included, devices and their data near the physical level, and the associated sensors and actuators, can be used for a variety of applications. Conversely, if the pattern recognition system in an ATM only recognizes euros, for example, then only euros can be issued by the machine. 



Reusability must be given a very high priority in the areas of monitoring and infrastructure.

Monitoring and network systems are IoT service agnostic and should therefore work with all services.


As few edge device and gateway variants as possible should be permitted, whereby this should not eliminate the ability to effectively utilize new devices and gateways.

The greater the (unnecessary) variety, the more complex interface management, operation, and monitoring will be.


Stream processing should take precedence over batch processing.

A very large number of IoT use cases require the rapid transport and analysis of data. Near-realtime analysis is therefore ideal, and stream processing allows for this.


A cloud-first strategy should apply in all solution areas.

This improves scalability, security, modularity, interoperability, integrability, and resilience. 


Always use standards where possible and appropriate.

Standards generally make systems less complex and also tend to ensure greater independence from individual suppliers.


Open APIs should be given preference over predefined and specialized platforms.

Specialized platforms facilitate vendor lock-ins; APIs do not. Professional API management makes it possible to get additional complexity under control.


Vendor lock-ins are to be avoided.

Companies that use applications and have sufficient in-house expertise and capabilities should avoid excessive dependence on specific providers, as this can significantly impede their ability to use new technologies and implement new IoT use cases.


Data should be viewed as an asset and a valuable raw material.

Data is a source material for all IoT-based business models. It should therefore be managed like any other valuable raw material.


Bandwidth must be used in an optimal manner.

Connectivity is the key in the IoT world. High-availability bandwidth means fast processing speeds. This isn’t always necessary, however, as other requirements are often more important. In terms of costs, for example, it is crucial to know exactly when specific services need bandwidth, and how much of it.


Security by design must be the order of the day.

The highest security standards are used in the IoT world – the world that brings together the physical and virtual realms. Nevertheless, the level of security in the physical realm in particular needs to be improved. The associated weak points can only be reduced if security is taken into account from the very beginning. The RA allows for the use of a variety of important functions here.


Software is more important than hardware.

This actually goes without saying in the era of the cloud, DevOps, and no-code development. However, keeping it in mind can help when prioritizing investment decisions.

Three pillars of architecture

The Architecture stands on three vertical pillars known as the Edge, Integration, and Enterprise tiers. Mounted across these pillars, so to speak, are the overarching levels of infrastructure management, monitoring, and engineering. There are also layers for security, API management, third-party ecosystems, and networks (see the chart below).

The Edge tier contains all physical things that have been digitally enhanced (e.g. with sensors and actuators), plus the systems for monitoring them, the infrastructure management aspects that relate to them, and the connectivity features that link edge devices with the Integration tier.

The Integration tier collects, consolidates, and analyzes the data generated in the Edge tier. Digital twin depictions of real objects can be stored here, as can AI applications. The Integration tier is also used to process control commands from the Enterprise tier and then pass these on to the Edge tier. Management tasks for devices and data can be completed here as well. One of the key tasks of the Integration tier itself involves the decoupling of the Enterprise and Edge tiers in order to ensure provider independence and device interchangeability, among other things.

The Enterprise tier contains domain-specific applications and services that control the physical level via the Integration tier. The Enterprise tier also includes systems that support decision making and interfaces for users and operations specialists. The Enterprise tier thus connects the IoT world to the business operations at a company.

Basically a simple matrix structure

The tiers are linked by various connectivity components such as the proximity network, which connects Edge devices with the Integration tier, as well as other networks that also establish connections with cloud services. The third-party ecosystem is also important, as this system connects third-party services (i.e. from other providers or data and infrastructure suppliers) while also enabling data and services to be offered to such providers and suppliers. The three tiers are “crossed” by the levels (areas of activity) for engineering, monitoring, and infrastructure management, whereby the two lower levels need to be made as independent as possible from the respective services and business models. The emphasis here is on reusability. The engineering level, on the other hand, is service and business model-specific. Even here, however, the goal should be to depict as many IoT use cases as possible and ensure company-wide utilization of IoT applications.

“The reference architecture is basically a simple matrix structure – but as always the devil is in the details,” says Karsten Schweichhart, Member of the Board of CBA Lab. Schweichhart also stresses the importance of remaining independent of manufacturers. “All workstream participants believe it’s important to understand that implementing an IoT platform from one manufacturer is not enough,” Schweichhart explains. “Each tier is related in some way to the others. The Enterprise tier also changes as a result of the requirements it has to meet when new IoT business models are used.” For example, if a washing machine manufacturer designs its products in a way that enables them to automatically order detergent, the ERP system that processes these orders and handles the invoices must be able to manage a very large number of small order volumes in an economically viable manner. “While it’s possible to create a temporary workaround in such a situation, the IoT business model used isn’t the only model or concept that’s been implemented, which means you need to create an architecture that’s able to deal with all the different requirements,” says Schweichhart.

Digital twins show just how close the relationships are between the tiers. For example, while the Edge tier contains the physical objects and their sensors and actuators, the Integration tier contains digital twin depictions of these objects, whereby the digital twins also receive physical-object control commands from the Enterprise tier. The following predictive maintenance case illustrates the interconnections and makes them understandable: The sensor in a milling machine reports an unusually high milling head rotation speed. The reported speed is analyzed in the Integration tier by programming it into the digital twin and then examining the twin’s behavior. This analysis produces a wear value for the milling head, which is then sent to the Enterprise tier. The Enterprise tier uses this information to predict the remaining service life for the milling head, and to set a date to replace it. In order to ensure that the milling head will definitely last until the replacement date, the digital twin is instructed to reduce the milling head’s processing speed. Within the framework of the synchronization between the physical device and the digital twin, the milling head receives the new operating information.

The starting point for the implementation of any IoT solution is the business model that is to be supported. Another issue involves the question as to whether a company will be implementing the solution end to end or whether the company itself is part of a larger ecosystem seeking to achieve or enable a system-wide solution. IoT solutions are often used in both contexts – i.e. as internal and cross-business solutions. For example, the operator of a parking guidance system generally has two options: It can either equip parking spaces with sensors itself and have these sensors send occupancy information to a self-developed app that it operates and which is used by customers looking for a parking space, or it can implement only part of the solution by merely making the sensor data available. Because these business models are very individualized in ecosystem settings in particular, they can be referenced in an RA as the starting point of an IoT solution, but they cannot be simulated for such settings. The RA must therefore be able to take many different business models into account.

The role determines the complexity

Business models should also include the role that a company wishes to play in terms of an IoT solution within an ecosystem – i.e. that of a consumer, a partial service provider, or a full service provider. The choice made here has clear implications for the required architecture. For example, a company that wishes to act solely as a consumer needs to have a more or less complex interface/API in order to be able to process data with its own solutions. However, if a company is looking to establish a service, a large part of the RA will need to be used in the tiers and the various levels. Things become even more complex if the company itself plans to create the entire IoT service, make it available to others, and charge them for it. The choice of role may sound like a trivial matter at first, but “it is very difficult to make additional resources and funds available in an ongoing process if those responsible do not consider from the very beginning what type of capacities and capabilities they will need to have in order to be able to act effectively as a service provider,” Schweichhart explains..


Lessons learned

  • When choosing an IoT solution, it is important to consider the entire lifecycle of the IoT solution – i.e. development, monitoring, and operation. A significantly high degree of reusability of the IoT solution can be achieved across various use cases with regard to operation and monitoring in particular.
  • The IoT platform must be kept lean! It is important to keep this component of the IoT solution lean if you wish to ensure that the core IoT platform capabilities (e.g. for analytics and machine learning) will be reusable. Here, one should not allow themselves to be influenced too much by the wide range of individual solutions from providers and the extent to which one might be an exact fit for a specific IoT application. Instead, it is important to keep in mind the range of one’s own potential use cases.
  • The IoT solution not only needs to be connected to the existing traditional IT world; the latter will also transform itself in order to facilitate the implementation of IoT scenarios. This fact must therefore also be taken into account when selecting and building IoT solutions.
  • API management and the necessary development of technical and business operation standards – and standards for everything in between – are essential for ensuring effective cooperation in cross-business ecosystems.

*Dr. Verena Schmidtmann managed the Cross-Business-Architecture Lab’s IoT Patterns and Architecture workstream, in which a reference architecture was created. Dr. Schmidtmann is a partner in Detecon – an IT and corporate consulting firm.

Dr. Verena Schmidtmann, Workstream Coordinator

Companies need to have a neutral reference architecture geared toward the needs of users in order to be able to evaluate commercial solutions in terms of their structure and functionality.