A Framework for Developing IoT-related Solution Architecture Blueprints

Smart, Connected Products enable Digital Transformation but Entail Challenges

Smart, connected products (aka the Internet of Things (IoT)) amalgamate hardware assets, sensors, data storage, microprocessors, software and connectivity in various ways. They enable the digital transformation of asset- and product-related business operations and corresponding operational technologies. However, only a few solutions related to smart, connected products (or the IoT) are developed from scratch and have to be integrated into existing business operations and IT landscapes. Therefore, they leverage existing operational technology systems and have to be integrated with existing business applications in order to support end-to-end processes. IoT-related projects and solutions typically contain a lot of interdependencies on business and IT level resulting in complex integration scenarios which in turn lead to sophisticated architectural, testing and monitoring requirements. Furthermore, as IoT is focusing on the digital transformation of business operations, it aims at changing and improving the existing asset-/product-related processes and services, which bares the risk of interrupting them. Thus, more often than not business operations and solutions are developed and changed incrementally across several sprints, increments and/or projects. In order to manage and reduce the risk inherent in the development and change of IoT-related business operations and solutions, any organization should use a strategy and target architecture to plan and align the required business changes and solution components – independently of the chosen development methodology (plan-driven, agile, etc.). Particularly, an IoT-related strategy enables an organization to implement a portfolio of business capability enhancements and plan the implementation of solution components accordingly. Target architectures and architectural solution blueprints are critical enablers of such an IoT-related strategy. The former defines a high-level, medium- to long-term, strategic target state of an IoT solution. The latter refines and guides the incremental development of a target architecture along a set of sprints, increments or projects. Both should be leveraged to manage complexity proactively, support the progressive build-up of skills and knowledge, enable agility and the incremental delivery of business and IT capabilities along the execution of the strategy.

In order to develop target architectures and architectural solutions blueprints, reference architectures should be leveraged to quickly build up the knowledge of the problem domain. In relation to the domain of IoT (or smart, connected products) there are non-proprietary and vendor-specific reference architectures available (please refer my former blog post on non-proprietary reference models and architectures related to smart, connected devices and the Internet of Things). However, the existing non-proprietary reference architectures are quite abstract and don’t consider existing IoT platforms which can be leveraged to implement IoT-related solutions. The existing vendor-specific reference architectures developed by the various IoT platform providers are too generic as they for example don’t distinguish between different IoT domains. They typically focus only on the set of services provided by a single IoT platform provider and therefore don’t sufficiently support the incremental analysis, design and implementation of an overarching IoT solution. Therefore, many organizations grapple with the question of how to incrementally design and implement IoT-related solution architectures based on the services supplied by the IoT platform providers. Particularly, they are challenged by the problem of how to extend and enhance the architectures of existing IoT-related applications (e.g. SCADA, OT applications) and how to leverage and integrate the services of a specific IoT platform provider into existing IT landscapes.

The Idea: A Library of IoT-related Solution Architecture Blueprints

These challenges can be addressed by a library of IoT-related solution architecture blueprints which considers different IoT domains and the incremental delivery of business and IT capabilities required in each phase of an IoT adoption journey. The library is structured by two dimensions: The IoT business domain and maturity stage of the IoT journey. This structure supports the identification and selection of an appropriate set of solution architecture blueprints in line with the specific IoT adoption journey of an individual organization. Each solution architecture blueprint guides the development of a concrete transition or target architecture by defining the fundamental structure and interaction of components, services and interfaces. A blueprint represents an intermediate design model, which is more concrete than a reference architecture but less detailed that a concrete solution architecture. Particularly, it is more detailed than the existing IoT-related non-proprietary reference architectures and more specific that the reference architectures typically supplied by the IoT platform providers.

As the development of such a library of IoT-related solution architectures is a huge effort, the overarching idea of this work is to inspire collaboration and knowledge sharing within the community of architects. Such an approach would distribute the workload and thus speed up the identification, design and documentation of all solution architecture blueprints along the structure of the library. This post is supposed to be a starting point and focuses on the framework which structures the library of solution architecture blueprints.

A Framework to Structure Incremental IoT Solution Architectures for Different Domains

The framework aims at providing a holistic view on the IoT/smart, connected products space. It considers different business domains because they have different characteristics, objectives and value propositions in relation to IoT (see figure 1). Thus, each domain requires different business and IT capabilities. In addition, the framework distinguishes successive maturity stages which represent sets of product functions and capabilities. The different stages support an incremental adoption approach of the IoT and ensure that product functions and capabilities are designed and implemented in a reasoned sequence.

The framework organizes the library of solution architecture blueprints based on a table. The columns represent different capability maturity stages for smart, connected products based on a model by Michael E. Porter and James E. Heppelmann¹⁾. The rows distinguish between different IoT-related business domains. The cells at the intersection of a row and a column demarcate one distinct solution architecture blueprint of the library.

Maturity Model for Smart, Connected Products

The maturity model groups product capabilities into four areas which represent the following maturity stages: Monitoring, Control, Optimization and Autonomy (see figure 2). Each stage is valuable in its own right and represents the foundation for the next stage. A smart, connected product could be developed towards the highest stage. However, an organization has to individually assess the target maturity stage for a specific smart, connected product based on the customer value delivered and the competitive advantage realized. In other words not every product has to achieve the highest stage of Autonomy but each stage builds on the preceding one by leveraging the corresponding product functions and capabilities of the previous stage.

In the initial Monitoring stage the smart, connected product is able to observe it’s condition, operation and external environment based on sensors and external data sources. The generated data can be used to analyze how the product operates and how it is actually used. Monitoring data is the foundation for triggering alerts such as deviations in performance and enables fact-based feedback loops into e.g. the product design and the after-sales service domain.

The Control stage is characterized by additional control functions that are either realized as remote commands or algorithms that are executed as part of the product or in a back-end system. Algorithms are rules that steer the product to respond to specified changes in its condition or environment. The control function enables customization and personalization of the product.

The Optimization stage leverages the Monitoring and Control capabilities to realize enhanced algorithms and analytics that optimize the product performance and usage. Real-time, historical and/or additional data are combined to improve output, utilization and efficiency of the products. Those enhanced algorithms and analytics enable use cases like preventative maintenance, yield optimization and asset-as-a-service models.

The Autonomy stage builds on top of the Monitoring, Control and Optimization capabilities to enable the products to learn about their environment, self-diagnose their own service needs, and adapt to users’ preferences. This allows smart, connected products to achieve a previously unattainable level of autonomy and reduces the need for human operators. Smart, connected products in the Autonomy stage are also enabled to collaborate with other products and systems. Thus, those products implement algorithms that leverage data about their own performance and external environment which encompass the operation and behaviour of other products in a broader system. In the Autonomy stage the responsibilities for a human operator shifts from managing the individual products to managing a complete product/asset portfolio or a system as a whole.

Different Domains related to the IoT

The IoT-related domains are Consumer, Industrial and Smart City (see figure 3). Each domain has different characteristics, objectives and value propositions and therefore, requires different business and IT capabilities.

The Consumer domain is characterized by the fact that after the sales and delivery phase, the customer possesses the physical product and usually the producer has no physical access anymore. Thus, a remote device management is required to support ongoing usage and operation of the product including e.g. security updates, provisioning of new and enhanced functionality, customer support etc. The objectives within the Consumer domain are typically related to delivering value to an end user, responding to customer-specific requirements and providing sophisticated customer user experience and usability. Value propositions are focused on fighting against commoditization by making products smart (i.e. differentiating products and services) and transforming the customer engagement from a one-time buy transaction to an ongoing service relationship.

Within the Industrial Domain a customer can either possess or lease a physical product. If a service contract is established, the customer grants the product producer service-related physical assess to the product after the sales and delivery phase. Usually the physical products are already managed by existing SCADA/OT systems that are deployed at the customer’s site and implement a peripheral asset management capability. The products in the Industrial domain are embedded into the core business processes (e.g. manufacturing, supply chain, etc.) and therefore, require close integration with the existing back-end systems of an organization. The core business processes within the Industrial domain typically imply demanding non-functional requirements (e.g. performance, security and reliability) which apply to the smart, connected products too. The objectives within the Industrial domain are centered around optimizing the product usage and value chain, enabling the collaboration with partners and sharing of product data. The value propositions focus on improving output, utilization and efficiency of the products and increasing the efficiency and effectiveness of industrial business processes within and beyond a single organization.

The Smart City domain is characterized by close collaboration and integration of citizens, municipalities, providers of public services and IT service providers. Typically, multiple providers have to be integrated because they are commissioned and responsible for different parts of a large system. There is a strong focus on openness and interoperability in order to increase the flexibility and reuse of data, functions and features across all participants of the system. The products, in the context of the Smart City domain, could be either existing resources of municipalities and providers of public services or newly deployed devices and sensors which provide data of the external environment. The latter could require a remote device management to register and manage products and/or sensors along their life cycle. Depending on the use case there are specific requirements related to privacy, safety and reliability in the Smart City domain. The Smart City domain aims at increasing the value for the citizen and optimizing the usage of municipal resources. This can be achieved by different use cases which are based on the collaboration and data sharing of all involved parties in a Smart City context.

Description of the Solution Architecture Blueprints

The cells of the table represent one unique solution architecture blueprint (see figure 4). A blueprint describes an intermediate design model which is more specific than a reference architecture but more general that a concrete solution architecture. Particularly, it is more detailed than the existing IoT-related non-proprietary reference architectures and more specific that the reference architectures typically supplied by the IoT platform providers.

Each blueprint is described by the following views which address different concerns: Quality attributes, business, application, technology, development & operations and cost (see figure 5).

In relation to the views on the business, application and technology, I’m currently considering to reuse at least the metamodel of the corresponding layer of ArchiMate standard²⁾. Although ArchiMate is a modeling language for enterprise architecture, it fits well to define an encompassing, high-level solution architecture. However, the application and technology views require an additional logical design layer which further refines the architecture for a single IoT platform provider. This additional layer refers to the specific reference architecture of an IoT platform provider and considers the provider-specific IT services and terms. It substantiates the reference architecture by focusing only on the mandatory structure and interaction of components, services and interfaces which are required at a certain maturity stage in a specific domain.

The view on the quality attributes (or non-functional requirements) elaborates on quality-attribute-scenarios, trade-offs and architectural tactics (see ³⁾) which are specific to the unique solution architecture blueprint.

The business perspective elaborates on the structure and interaction between the organization, functions business processes and information needs. It uses elements like e.g. business process, business function and business event to describe a high-level business architecture supporting the corresponding maturity stage and domain.

The application view describes the information systems architecture including the application architecture that is to say the structure and interaction of applications. Particularly it models how an IoT solution has to be integrated with existing systems/applications like SCADA, OT, customer relationship management, billing & invoicing etc. It leverages the ArchiMate elements like e.g. application component, function, interaction & service to illustrate how an IoT solution works and how it is collaborating with other applications in an encompassing landscape.

The view on the technology represents the structure and interaction of the platform services, logical and physical technology components. It contains ArchiMate elements like device, system software, technology interface and communication network to model the structural and behavioral elements of the technology architecture. Those elements can be used to describe various hosting and cloud delivery models including the IoT-related cloud services of the various IoT platform providers (see also ⁴⁾). Particularly the specialization relationship of ArchiMate can be used to introduce an additional logical design layer and incorporate the provider-specific IT services and terms.

The development and operations view elaborates on special aspects which should be considered during the development and operation phase of an IoT solution. In relation to the development phase, for example, it is crucial to identify the parts of the solution which could be developed using agile methods and which parts should be developed using plan-driven methods (see also ⁵⁾). Furthermore, this view details IoT-specific aspects of testing, monitoring and automation. IoT solutions are usually difficult to test and simulate due to the fact that they are integration-heavy and could contain singular assets, products or devices. Those could be linked with size, cost and complexity constrains which prevent them from being integrated into an IoT lab or the testing concept and process. One example of the Industrial domain are expensive manufacturing facilities: Usually it doesn’t make sense from a financial perspective to purchase and set up another unit of the facility just for testing. The end-to-end monitoring of an IoT solution could be another challenge. Generally existing monitoring tools should be leveraged and for each of the components of an IoT solution and it should be clarified how it will be monitored. The operation of an IoT solution could be complex due to the distributed and integration-heavy nature of the domain. In order to address this challenge the concepts and tools for automation should be leveraged intensively. Thus, a solution architecture blueprint is proactively considering the automation requirements, pattern and services of the IoT providers.

The view on cost focuses initially on the operating costs of the IoT solution. The idea is to use the required cloud services and the corresponding cost calculation tools of the IoT platform providers to develop a high-level formula for calculating the cost based on API calls, messages, data volumes, user, etc. Of course, this isn’t a complete and precise cost model, but I think it greatly supports the understanding of the various cost elements, drivers and influencers.

Summary and Conclusion

Smart, connected products enable digital transformation but also entail challenges related to complexity, operational disruption, etc. An incremental approach guided by an IoT-related strategy and target architecture is key to address these challenges. Particularly target architectures and architectural solution blueprints should be leveraged to manage complexity proactively, support the progressive build-up of skills and knowledge, enable agility and the incremental delivery of business and IT capabilities along the execution of the strategy. The proposed library of IoT-related solution architecture blueprints – which considers different IoT domains and the incremental delivery of business and IT capabilities – can be used to guide the development of target architectures, transition architectures and corresponding architectural roadmaps (see figure 6).

However, as the development of such a library of IoT-related solution architectures is a time-consuming effort, this post also aims at inspiring collaboration and knowledge sharing within the community of architects. The distribution of workload would speed up the identification, design and documentation of all solution architecture blueprints along the structure of the library. The usage of common architectural concepts like quality-attribute-scenarios and open standards like ArchiMate greatly support this collaborative approach.

The framework described in this post is considered only as a starting point. It provides a holistic view on the IoT (or smart, connected products) space and structures the set of solution architecture blueprint based on a maturity model for smart, connected products and different IoT-related domains. The next logical step of this work is to elaborate, prototype and document the first solution architectural blueprint. The documentation approach and format should be then established as a template for documenting the other blueprints.

References

1) Michael E. Porter and James E. Heppelmann: How Smart, Connected Products Are Transforming Competition. In: Harvard Business Review, November 2014.
2) The Open Group: ArchiMate 3.0 Specification. Technical Standard, June 2016.
3) Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 3rd Edition, Addison-Wesley, Boston et al. 2012.
4) Edwards, Charles: Hosting and Cloud Software Delivery modelled in Archimate. Blog post on https://www.agileea.com. April 19th, 2017.
5) Boehm, B.; Turner, R.: Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, Boston et al. 2003.