AIoT Product/Solution Design

Abstract

The idea of a more detailed design document may seem old fashioned to someone who is used to working in small, agile development teams. After all, the Agile manifesto itself values working software over comprehensive documentation and emphasizes the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. However, in large-scale, multi-team, multisite projects, a certain amount of documentation is required to ensure that all teams and stakeholders are aligned and working in synch. Working across organizational boundaries will add to the need for more detailed documentation of requirements and design decisions. Finally, some types of procurement contracts will require detailed specifications and SLAs (see Sourcing_and_Procurement). Given that an AIoT-enabled product or solution will contain different building blocks, such as AI, hardware, software, embedded components, etc., it is likely that it will face many of these constraints. Consequently, the Digital Playbook proposes to create and maintain a product/solution architecture that captures key requirements and design decisions in a consistent manner (Fig. 25.1).

The idea of a more detailed design document may seem old fashioned to someone who is used to working in small, agile development teams. After all, the Agile manifesto itself values working software over comprehensive documentation and emphasizes the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. However, in large-scale, multi-team, multisite projects, a certain amount of documentation is required to ensure that all teams and stakeholders are aligned and working in synch. Working across organizational boundaries will add to the need for more detailed documentation of requirements and design decisions. Finally, some types of procurement contracts will require detailed specifications and SLAs (see Sourcing_and_Procurement). Given that an AIoT-enabled product or solution will contain different building blocks, such as AI, hardware, software, embedded components, etc., it is likely that it will face many of these constraints. Consequently, the Digital Playbook proposes to create and maintain a product/solution architecture that captures key requirements and design decisions in a consistent manner (Fig. 22.1).

Fig. 22.1

Product/Solution design

1 AIoT Design Viewpoints and Templates

To provide a consistent and comprehensive design for AIoT-enabled products or solutions, the Digital Playbook proposes a set of design viewpoints, each with a specific set of design templates:

• Business Viewpoint: Builds on the input from the Business Model, adds KPIs and planning details

• UX Viewpoint: Focus on how users are interacting with and experiencing the product or solution

• Data/Functional Viewpoint: Focus on the data and functional components of the AIoT solution

• Implementation Viewpoint: Adds details on the implementation aspects

• AIoT Product Viewpoint: Mapping to the agile product development perspective

It is important to note that the Digital Playbook does not propose an excessive, RUP/waterfall-style level of documentation. The general idea is to provide a comprehensive yet lightweight set of design documents that enable efficient communication between the main stakeholders. The key to success here is to keep the design documentation on a level of detail where it is meaningful but not overly complex. The agile teams must be able to apply their own mechanism to derive requirements for their backlog and provide feedback to the overarching architecture in return. As will be discussed in the following, a central story map can be a powerful tool for keeping the design decision and the individual sprint backlogs in synch.

2 Important Design Considerations

It is important to accept that design documentation can rarely be seen as a stable document. The waterfall approach of fixing requirements and design decisions first will not work in most cases because of the inherent complexity, volatility of requirements and too many external and internal dependencies. The agile V-Model, for example, is specifically designed to support continuous updates of the overall system design. Each v-sprint (1) in the agile v-model must return to the design and match it against the learning from the previous sprint (2). This also means that the design documentation cannot be too detailed, since otherwise it will not be possible to perform a thorough review during each sprint planning session. The design templates provided in the Digital Playbook aim to strike a pragmatic balance between comprehensiveness and manageability. The sprint backlogs for the different teams must be in synch with the overall design (3).

In most AIoT projects there will be certain parts of the project that will require a higher level of stability for the design documentation than others. This is generally true for all areas that require more long-term planning, e.g., because of procurement or manufacturing requirements, or to manage complex dependencies across organizational boundaries. This is a key problem that the solution design team must address. In many cases, this will also require some kind of architectural layering, especially from a data/functional viewpoint. In particular, the design must ensure that no stable system components have any dependencies on more volatile components. Otherwise, the changes to the volatile components will have a ripple effect on those components that are supposed to be stable (4) (Fig. 22.2).

Fig. 22.2

AIoT product/solution design and the agile process

Finally, it is important to keep in mind that product/solution design and organizational structure must be closely aligned (Conway's law). The design will usually include many features that require support from different technical layers. For example, seat-heating-on-demand, which requires a smartphone component, a cloud component, and different components on the vehicle to work together to deliver this feature. The Digital Playbook is proposing to define feature teams that are working across the different technical layers. Properly deriving the setup of these feature teams from the product/solution design will be key to success (5).

3 ACME:Vac Example

The design section of the Digital Playbook is based on the fictitious ACME:Vac example, which is used to illustrate the different viewpoints and design templates. Robotic vacuum cleaners — or short robovacs — have become quite popular in the last decade and represent a multibillion dollar market, with a number of different players offering a variety of different models. Many of the advanced models today utilize AI to optimize robovac operations, including automatic detection of room layouts, navigation and cleaning path optimization. As such, they are a very good example of a smart, connected product provided by a Digital OEM. Differences between the design requirements of an AIoT-enabled product (Digital OEM perspective) and a solution (Digital Equipment Operator perspective) are highlighted in each section.

4 Business Viewpoint (Fig. 22.3)

Fig. 22.3

AIoT business viewpoint

The Business Viewpoint of the AIoT Product/Solution Design builds on the different artifacts created for the Business Model. As part of the design process, the business model can be refined, e.g., through additional market research. In particular, the detailed design should include KPIs, quantitative planning, and a milestone-based timeline.

4.1 Business Model

The business model is usually the starting point of the product/solution design. The business model should describe the rationale of how the organization creates, delivers, and captures value by utilizing AIoT. The business model design section provides a good description of how to identify, document and validate AIoT-enabled business models. A number of different templates are provided, of which the business model canvas is the most important. The business model canvas should include a summary of the AIoT-enabled value proposition, the key customer segments to be addressed, how customer relationships are built, and the channels through which customers are serviced. Furthermore, it should provide a summary of the key activities, resources and partners required to deliver on the value proposition. Finally, a high-level summary of the business case should be provided, including cost and revenue structure (Fig. 22.4).

Fig. 22.4

ACME:Vac business model canvas

The fictitious ACME:Vac business model assumes that AI and IoT are used to enable a high-end vacuum cleaning robot, which will be offered as a premium product (not an easy decision - some argue that the mid-range position in this market is more attractive). AI will be used not only for robot control and automation but also for product performance analysis, as well as analysis of customer behaviour. This intelligence will be used to optimize the customer experience, create customer loyalty, and identify up-selling opportunities.

4.2 Key Performance Indicators

Many organizations use Key Performance Indicators (KPIs) to measure how effectively a company is achieving its key business objectives. KPIs are often used on multiple levels, from high-level business objectives to lower-level process or product-related KPIs. In our context, the KPIs would either be related to an AIoT-enabled product or solution.

A Digital OEM that takes a smart, connected product to market usually has KPIs that cover business performance, user experience and customer satisfaction, product quality, and the effectiveness and efficiency of the product development process.

A Digital Equipment Operator who is launching a smart, connected solution to manage a particular process or a fleet of assets would usually have solution KPIs that cover the impact of the AIoT-enabled solution on the business process that it is supporting. Alternatively, business-related KPIs could measure the performance of the fleet of assets and the impact of the solution on that performance. Another typical operator KPI could be coverage of the solution. For example, in a large, heterogeneous fleet of assets, it could measure the number of assets that have been retrofitted successfully. UX and customer satisfaction-related KPIs would only become involved if the solution actually has a direct customer impact. Solution quality and the solution development process would certainly be another group of important KPIs (Fig. 22.5).

Fig. 22.5

Vacuum robot - product KPIs

The figure with KPIs shown here provides a set of example KPIs for the ACME:Vac product. The business performance-related KPIs cover the number of robovacs sold, the direct sales revenue, recurring revenue from digital add-on features, and finally the gross margin.

The UX/customer satisfaction KPIs would include some general KPIs, such as Net Promoter Score (results of a survey asking respondents to rate the likelihood that they would recommend the ACME:Vac product), System Usability Scale (assessment of perceived usability), and Product Usage (e.g., users per specific feature). The Task Success Rate KPIs may include how successful and satisfied customers are with the installation and setup of the robovac. Another important KPI in this group would measure how successful customers are actually using the robovac for its main purpose, namely, cleaning. The Time on Task KPIs could measure how long the robovac is taking for different tasks in different modes.

Product Quality KPIs need to cover a wide range of process- and product-related topics. An important KPI is test coverage. This is a very important KPI for AIoT-enabled products, since testing physical products in combination with digital features can be quite complex and expensive but a critical success factor. Incident metrics such as MTBF (mean time before failure) and MTTR (mean time to recovery, repair, respond, or resolve) need to look at the local robovac installations, as well as the shared cloud back end. Finally, the number of support calls per day can be another important indicator of product quality. Functional product quality KPIs for ACME:Vac would include cleaning speed, cleaning efficiency, and recharging speed.

Finally, the Product Development KPIs must cover all of the different development and production pipelines, including hardwire development, product manufacturing, software development, and AI development.

4.3 Quantitative Planning

Quantitative planning is an important input for the rest of the design exercise. For the Digital OEM, this would usually include information related to the number of products sold, as well as product usage planning data. For example, it can be important to understand how many users are likely to use a certain key feature in which frequency to be able to design the feature and its implementation and deployment accordingly.

The quantitative model for the ACME:Vac product could include, for example, some overall data related to the number of units sold. Another interesting bit of information is the expected number of support calls per year because this gives an indication for how this process must be set up. Other information of relevance for the design team includes the expected average number of rooms serviced per vacuum robot, the number of active users, the number of vacuum cleaning runs per day, and the number of vacuum cleaner bags used by the average customer per year (Fig.22.6).

Fig. 22.6

Quantitative plan

For a Digital Equipment Operator, the planning data must at its core include information about the number of assets to be supported. However, it can also be important to understand certain usage patterns and their quantification. For example, a predictive maintenance solution used to monitor thousands of escalators and elevators for a railroad operator should be based on a quantitative planning model that includes some basic assumptions, not only about the number of assets to be monitored, but also about the current average failure rates. This information will be important for properly designing the predictive maintenance solution, e.g., from a scalability point of view.

4.4 Milestones/Timeline

Another key element of the business viewpoint is the milestone-based timeline. For the Digital OEM, this will be a high-level plan for designing, implementing and manufacturing, launching, supporting, and continuously enhancing the product.

The timeline for the ACME:Vac product differentiates between the physical product and the AIoT part (including embedded hardware and software, AI, and cloud). If custom embedded hardware is to be designed and manufactured, this could also be subsumed under the physical product workstream, depending on the organizational setup. The physical product workstream includes a product design and manufacturing engineering phase until the Start of Production (SOP). After the SOP, this workstream focuses on manufacturing. A new workstream for the next physical product generation starting after the SOP is omitted in this example. The AIoT workstream generally assumes that an AIoT DevOps model is applied consistently through all phases.

Key milestones for both the physical product and the AIoT part include the initial product design and architecture (result of sprint 0), the setup of the test lab for testing the physical product, the first end-to-end prototype combining the physical product with the AIoT-enabled digital features, the final prototype/Minimum Viable Product, and finally the SOP.

The following figure also highlights the V-Sprints, which in this example applies to both physical product development and the AIoT development. While physical product development is unlikely to deliver potentially shippable product increments at the end of each V-Sprint, it still assumes the same sprint cadence.

Because sourcing is typically such a decisive factor, the timeline includes milestones for the key sourcing contracts that must be secured. Details regarding the procurement process are omitted on this level (Fig. 22.7).

Fig. 22.7

Example milestone plan

For a Digital Equipment Operator, this plan would focus less on the development and manufacturing of the physical product. Instead, it would most likely include a dedicated workstream for managing the retrofit of the solution to the existing physical assets.

5 Usage Viewpoint (Fig. 22.8)

Fig. 22.8

AIoT usage viewpoint

The goal of the UX (User Experience) viewpoint is to provide a holistic view of how the product or solution will be utilized by the user and other stakeholders. Good UX practice usually includes extensive product validation, including usability testing, user feedback, pilot user tests, and so on. A good starting point is usually customer surveys or interviews. In the case of an AIoT-enabled product or solution it can also make sense to include site surveys to better understand the environment of the physical products or assets.

To ensure realistic and consistent use cases across the design, a set of personas should be defined, representing the typical users of the product or solution. Revisiting the User Journey from the initial business design helps clarify many details. Finally, HMI (Human-Machine Interaction) design, early prototypes and wire frames are also essential elements of the UX viewpoint.

5.1 Site Surveys and Stakeholder Interviews

To capture and validate requirements, it is common practice for IT projects to perform stakeholder interviews. This should also be done in case of an AIoT product/project.

However, an AIoT project is different in that it also involves physical assets and potentially also very specific sites, e.g., a factory. Requirements can heavily depend on the type of environment in which assets are deployed. Additionally, usage patterns might vastly differ, depending on the environment. Consequently, it is highly recommended for the team responsible for the product design to spend time on-site and investigate different usage scenarios in different environments.

While many AIoT solutions might be deployed at a dedicated site, this might not be true for AIoT-enabled products. Take, for example, a smart kitchen appliance, which will be sold to private households. In this particular case, it can make sense to actually build a real kitchen as a test lab to test the usage of the product in a realistic environment. Alternatively, in the case of our Vacuum Robot, different scenarios for testing the robot must be made available, including different room types and different floor surfaces (wood panels, carpets, etc.).

5.2 Personas

Personas are archetypical users of the product or solution. Often, personas represent fictitious people who are based on your knowledge of real users. The UX Viewpoint should define a comprehensive set of personas that help model the product features in a way that takes the perspective of different product users into consideration. By personifying personas, the product team will ideally even develop an emotional bond to key personas, since they will accompany them through an intense development process. A persona does not necessarily need a sophisticated fictitious background story, but at least it should have a real-world first name and individual icon, as shown in Fig. 22.9.

Fig. 22.9

AIoT personas

5.3 User Journeys

The initial User Journeys from the Business Model design phase can be used as a starting point. Often, it can be a good idea in this phase of the product design to create individual journey maps for different scenarios, adding more detail to the original, high-level journey.

The example user journey for ACME:Vac shown here is not that different from most user journey designs found for normal software projects. The main difference is that the user journey here is created along the life cycle of the product from the customer’s point of view. This includes important phases such as Asset Activation, Asset Usage and Service Incidents (Fig. 22.10).

Fig. 22.10

Customer journey for vacuum robot

From the point of view of a Digital Equipment Operator, the user journey most likely focuses less on an end customer but more on the different enterprise stakeholders and how they are experiencing the introduction and operations of the solution. Important phases in the journey here would be the solution retrofit, standard operations, and what actually happens in case of an incident monitored or triggered by the solution. For example, for a predictive maintenance solution, it is important not only to understand the deep algorithmic side of it but also how it integrates with an existing organization and its established processes.

5.4 UX/HMI Strategy

The UX/HMI strategy will have a huge impact on usability. Another important factor is the question of how much the supplier will be able to learn about how the user is interacting with the product. This is important, for example, for product improvements but also potentially for upselling and digital add-on services (Fig. 22.11).

Fig. 22.11

UX/HMI for vacuum robot

The HMI strategy for ACME:Vac seems relatively straightforward at first sight: HMI features on the robovac are reduced to a minimum, including only some status LEDs and a reset button. Instead, almost all of the user interaction is done via the smartphone app. In addition, some basic commands such as starting an ad hoc cleaning run are supported via smart home integration.

It is important that the decision for the HMI strategy will have a huge impact not only on usability and customer experience but also on many other aspects, such as product evolvability (a physical HMI cannot be easily updated, while an app-based HMI can), customer intimacy (easier to learn how a customer is using the product via digital platforms), as well as the entire design and development process, including manufacturing (none needed for app-based HMI).

However, the risk of completely removing the HMI from the physical product should also not be underestimated. For example, in the case of bad connectivity or unavailability of a required cloud backend, the entire physical product might become entirely unusable.

5.5 Mockups/Wireframes/Prototypes

To ensure a good user experience, it is vital to try out and validate different design proposals as early as possible. For purely software-based HMI, UI mockups or wireframes are a powerful way of communicating the interactive parts of the product design, e.g., web interfaces and apps for smartphones or tablets. They should initially be kept on the conceptual level. Tools such as Balsamiq offer a comic-style way of creating mockups, ensuring that they are not mistaken for detailed UI implementation designs. The figure shown here provides a mockup for the ACME:Vac floor map management feature on the ACME:Vac app based on this style (Fig. 22.12).

Fig. 22.12

Example wireframe for vacuum robot smart phone app

It should be noted that the validation of the UX for physical HMI can require the actual creation of a physical prototype. Again, this should be done as early as possible in the design and development phase, because any UX issued identified in the early stages will help save money and effort further downstream. For example, while the HMI on board the ACME:Vac robot is kept to a minimum, there are still interesting aspects to be tested, including docking with the charging station and replacement of the garbage bag.

6 Data/Functional Viewpoint (Fig. 22.13)

Fig. 22.13

AIoT Data/Functional viewpoint

The Data and Functional Viewpoint provides design details that focus on the overall functionality of the product or solution, as well as the underlying data architecture. The starting point can be a refinement of the AIoT Solution Sketch. A better understanding of the data architecture can be achieved with a basic data domain model. The component and API landscape is the initial functional decomposition, and will have a huge impact on the implementation. The optional Digital Twin landscape helps understand how Digital Twin as a concept fit into the overall design. Finally, AI Feature Mapping helps identify which features are best suited to an implementation with AI.

6.1 AIoT Solution Sketch

The AIoT Solution Sketch from the Business Model can be refined in this perspective, adding more layers of detail, in a slightly more structured process of presentation. The solution sketch should include the physical asset or project (the robovac in our example), as well as other key assets (e.g., the robovac charging station) and key users. Since interactions between the physical assets and the back end are key, they should be listed explicitly. The sketch should also include an overview of key UIs, the key business processes supported, the key AI and analytics-related elements, the main data domains, and external databases or applications (Fig. 22.14).

Fig. 22.14

Solution sketch for vacuum robot

6.2 Data Domain Model

The Data Domain Model should provide a high-level overview of the key entities of the product design, including their relationships to external systems. The Domain Model should include approximately a dozen key entities. It does not aim to provide the same level of detail as a thorough data schema or object model. Instead, it should serve as the foundation for discussing data requirements between stakeholders, across multiple stakeholder groups in the product team (Fig. 22.15).

Fig. 22.15

Data domain model for vacuum robot

For example, the main data domains that have been identified for the ACME:Vac product are the customer, the robovac itself, floor maps and cleaning data. Each of these domains is described by listing the 5–10 key entities within. This is typically a good level of detail: sufficiently meaningful for planning discussions, without getting lost in detail.

The design team must make a decision on whether the required data from an AI perspective should already be included here. This can make sense if AI-related data also play an important role in other, non AI-based parts of the system. In this case, potential dependencies can be identified and discussed here. If the AI has dedicated input sources (e.g., specific sensors that are only used by the AI), then it is most likely more interesting at this point what kind of data or information is provided by the AI as an output.

6.3 Component and API Landscape

To manage the complexity of an AIoT-enabled product or solution, the well-established approach of functional decomposition and componentization should be applied. The results should be captured in a high-level component landscape, which helps visualize and communicate the key functional components.

Functional Decomposition and Componentization

Functional decomposition is a method of analysis that breaks a complex body of work down into smaller, more easily manageable units. This “Divide & Conquer” strategy is essential for managing complexity. Especially if the body of work cannot be implemented by a single team, splitting the work in a way that it can be assigned to different teams in a meaningful way becomes very important. Since a system’s architectural structure tends to be a mirror image of the organizational structure, it is important that team building follows the functional decomposition process. The idea of “feature teams” to support this is discussed in the AIoT Product Viewpoint.

Another key point of functional decomposition is functional scale: without effective functional decomposition and management of functional dependencies, it will be difficult to build a functionally rich application. It does not stop at building the initial release. Most modern software-based systems are built on the agile philosophy of continuous evolution. While an AIoT-enabled product or solution does not only consist of software — it also includes AI and hardware — enabling evolvability is usually a key requirement. Functional decomposition and componentization will enable the encapsulation of changes and thus support efficient system evolution.

The logical construct for encapsulating key data and functionality in an AIoT system should be the component. From a functional viewpoint, components are logical constructs, independent of a particular technology. Later in the implementation viewpoint, they can be mapped to specific programming languages, AI platforms, or even specific functionality implemented in hardware. Additionally, component frameworks such as microservices can be added where applicable (Fig. 22.16).

Fig. 22.16

Functional decomposition and componentization

The functional decomposition process should go hand in hand with the development of the agile story map (see AIoT Product Viewpoint) since the story map will contain the official definition of the body of work, broken down into epics and features.

The first iteration of the component landscape can actually be very close to the story map, since it should truly only focus on the functional decomposition. In a second iteration, the logical AIoT components must be mapped to a distributed component architecture. This perspective is actually somewhat between the functional and implementation viewpoints. The mapping to the distributed component architecture must take a number of different aspects into consideration, including business/functional requirements, cost constraints, technical constraints and architectural constraints.

A key functional requirement simply is availability. In a distributed system, remote access to a component always has a higher risk of the component not being available, e.g., due to connectivity issues. Other business-driven aspects are organizational constraints (especially if different parts of the distributed system are developed by different organizational units), physical control and legal aspects (deploying critical data or functionality in the field or in certain countries can be difficult). This is also closely related to data ownership and data sharing requirements.

Achim Nonnenmacher, expert for Software-defined Vehicle at Bosch comments: Because of the availability issues related to distributed applications, many leading services are using a capability-based architecture. For example, many smart phones have two versions of their key services - one which works with the data and capabilities available on the phone, and one which works only with cloud connectivity. For example, you can say “Hey, bring me home”, and the offline phone will still be able to provide rudimentary voice recognition and navigation services using the AI and map data on the phone. Only if the phone is online will it be able to make full use of better cloud-based AI and data. We still have to learn in many ways how to apply this to the vehicle-based applications of the future, but this will be important.

Another key distribution aspect is cost constraints. For example, many manufacturers of physical products have to ensure that the unit costs are kept to a minimum. This can be an argument for deploying computationally intensive functions not on the physical product but rather on a cloud back end, which can better distribute loads coming from a large number of connected products. Similar arguments apply to communication costs and data storage costs.

Furthermore, the distributed architecture will be greatly influenced by technical constraints, such as latency (the minimum amount of time for a single bit of data to travel across the network), bandwidth (data transfer capacity of the network), performance (e.g., edge vs. cloud compute performance), time sensitivity (related to latency), and security.

Finally, a number of general aspects should be considered from the architectural perspective. For example, the technical target platform (e.g., software vs. AI) will play a role. Another factor is the different speed of development: a single component should not combine functionalities that will evolve at significantly different speeds. Similarly, one should avoid combining functionality, which only requires standard Quality Management with functionality, which must be treated as functional safety relevant to a single component. In this case, the QM functionality must also be treated as functional safety relevant, making it costliest to test, maintain and update.

While some of these constraints and considerations are of a more technical nature, they need to be combined with more business or functional considerations when designing the distributed component architecture.

Component Landscape

The result of the functional decomposition process should be a component landscape, which focuses on functional aspects but already includes a high-level distribution perspective.

The example shown in Fig. 22.17 is the high-level component landscape for the ACME:Vac product. This component landscape has three swimlanes: one for the robovac (i.e., the edge platform), one for the main cloud service, and one for the smartphone running the ACME:Vac mobile app. The components of the robot include basic robot control and sensor access, as well as the route/trajectory calculation. These components would most likely be based on an embedded platform, but this level of detail is omitted from a functional viewpoint. In addition, the robot will have a configuration component, as well as a component offering remote services that can be accessed from the robot control component in the cloud. In addition, the cloud contains components for robot configuration, user configuration management, map data, and the management of the system status and usage history. Finally, the mobile app has a component to manage the main app screen, map management, and remote robot configuration.

Fig. 22.17

Example: initial component architecture

API Management

In his famous “API Mandate”, Jeff Bezos — CEO of Amazon at the time — declared that “All teams will henceforth expose their data and functionality through service interfaces.” at Amazon. If the CEO of a major companies gets involved on this level, you can tell how important this topic is.

APIs (Application Programming Interfaces) are how components make data and functionality available to other components. Today, a common approach is so-called RESTful APIs, which utilize the popular HTTP internet protocol. However, there are many different types of APIs. In AIoT, another important category of APIs is between the software and the hardware layer. These APIs are often provided as low-level c APIs (of course, any c API can again be wrapped in a REST API and exposed to remote clients). Most APIs support a basic request/response pattern to enable interactions between components. Some applications require a more message-oriented, de-coupled way of interaction. This requires a special kind of API.

Regardless of the technical nature of the API, it is good practice to document APIs via an API contract. This contract defines the input and output arguments, as well as the expected behavior. “Interface first” is an important design approach which mandates that before implementing a new application component, one should first define the APIs, including the API contract. This approach ensures de-coupling between component users and component implementers, which in turn reduces dependencies and helps managing complexity. Because APIs are such an important part of modern, distributed system development, they should be managed and documented as key artefacts, e.g. using modern API management tools which support API documentation standards like OpenAPI.

From the system design point of view, the component landscape introduced earlier should be augmented with information about the key APIs supported by the different components. For example, the component landscape documentation can support links to the detailed API documentations in different repositories. This way, the component landscape provides a high level description not only of how data and functionality is clustered in the system, but also how it can be accessed.

6.4 Digital Twin Landscape

As introduced in the Digital Twin 101 section, using the Digital Twins concept can be useful, especially when dealing with complex physical assets. In this case, a Digital Twin Landscape should be included with the Data/Functional Viewpoint. The Digital Twin Landscape should provide an overview of the key logical Digital Twin models and their relationships. Relationships between Digital Twin model elements can be manifold. They should be used to help define the so-called ““knowledge graph”“across different, often heterogeneous data sources used to construct the Digital Twin model.

In some cases, the implementation of the Digital Twin will rely on specific standards and Digital Twin platforms. The Digital Twin Landscape should keep this in mind and only use modeling techniques that will be supported later by the implementation environment. For example, the Digital Twins Definition Language (DTDL) is an open standard supported by Microsoft, specifically designed to support modeling of Digital Twins. Some of the rich features of DTDL include Digital Twin interfaces and components, different kinds of relationships, as well as persistent properties and transient telemetry events.

In the example shown in Fig. 22.18, these modeling features are used to create a visual Digital Twin Landscape for the ACME:Vac example. The example differentiates between two types of Digital Twin model elements: system (green) and environment (blue). The system elements relate to the physical components of the robovac system. Environment elements relate to the environment in which a robovac system is actually deployed.

Fig. 22.18

Digital twin landscape

This differentiation is important for a number of reasons. First, the Digital Twin system elements are known in advance, while the Digital Twin environment elements actually need to be created from sensor data (see the discussion on Digital Twin reconstruction).

Second, while the Digital Twin model is supposed to provide a high level of abstraction, it cannot be seen completely in isolation of all the different constraints discussed in the previous section. For example, not all telemetry events used on the robot will be directly visible in the cloud. Otherwise, too much traffic between the robots and the cloud will be created.

This is why the Digital Twin landscape in this example assigns different types of model elements to different components. In this way, the distributed nature of the component landscape is taken into consideration, allowing for the creation of realistic mapping to a technical implementation later on.

6.5 AI Feature Mapping

The final element in the Data/Functional Viewpoint should be an assessment of the key features with respect to suitability for implementation with AI. As stated in the introduction, a key decision for product managers in the context of AIoT will be whether a new feature should be implemented using AI, Software, or Hardware. To ensure that the potential for the use of AI in the system is neither neglected nor overstated, a structured process should be applied to evaluate each key feature in this respect.

Fig. 22.19

AI feature mapping

In the example shown in Fig. 22.19, the features from the agile story map (see AIoT Product Viewpoint) are used as the starting point. For each feature, the expected outcome is examined. Furthermore, from an AI point of view, it needs to be understood which live data can be made available to potentially AI-enabled components, as well as which training data. Depending on this information, an initial recommendation regarding the suitability of a given feature for implementation with AI can be derived. This information can be mapped back to the overall component landscape, as indicted by Fig. 22.20. Note also that a new component for cloud-based model training is added to this version of the component landscape. Not that this level of detail does not describe, for example, details of the algorithms used, e.g. Simultaneous Localization and Mapping (SLAM), etc.

Fig. 22.20

Identifying AI-enabled components

7 Implementation Viewpoint (Fig. 22.21)

Fig. 22.21

AIoT implementation viewpoint

The Implementation Viewpoint must provide sufficient detail to have meaningful technical discussions between the different technical stakeholders of the product team. However, most design artifacts in this viewpoint will still be on a level of abstraction which will hide many of the different details required by the implementation teams. Nevertheless, it is important to find a common language and understanding between the different stakeholders, including a realistic mapping to the Data/Functional Viewpoint.

The AIoT Implementation Viewpoint should at least include an End-to-End Architecture, details on the planned integration with the physical asset (either following a line-fit or retrofit approach), as well as high-level hardware, software and AI architectures.

7.1 End-to-End Architecture

The End-to-End Architecture should include the integration of physical assets, as well as the integration of existing enterprise applications in the back end. In between, an AIoT system will usually have edge and cloud or on-premises back end components. These should also be described with some level of detail, including technical platforms, middleware, AI and Digital Twin components, and finally the business logic itself (Fig. 22.22).

Fig. 22.22

IoT architecture

7.2 Asset Integration

The Asset Integration perspective should provide an overview of the physical parts of the product, including sensors, antennas, battery/power supply, HMI, and onboard computers. The focus is on how these different elements are integrated with the asset itself. For example, where exactly on the asset would the antenna be located, where to position key elements such as main board, battery, sensors, etc. Finally, an important question will concern wiring for power supply, as well as access to local bus systems (Fig. 22.23).

Fig. 22.23

Asset integration

7.3 Hardware Architecture

Depending on the requirements of the AIoT system, custom hardware development can be an important success factor. The complexity of custom hardware design and development should not be underestimated. From the hardware design point of view, a key artefact is usually the schematic design of the required PCBs (Printed Circuit Boards).

The ACME:Vac example shown in Fig. 22.24 includes the main control unit, HMI, power management, sensors, wireless connectivity, signal conditioning, and finally the control of the different motors.

Fig. 22.24

Robovac hardware architecture

7.4 Software Architecture

The technical software architecture should have a logical layering, showing key software components and their main dependencies. For the ACME:Vac example, the software architecture would include two main perspectives: the software architecture on the robovac (Fig. 22.25) and the backend architecture (not shown).

Fig. 22.25

Example: Robovac SW architecture

Depending on the type of organization, software architecture will be ad hoc or follow standards such as the OpenGroup’s [1] framework. TOGAF, for example, provides the concept of Architecture and Solution Building Blocks (ABB and SBB, respectively), which can be useful in more complex AIoT projects.

The example shown here is generic (like an ABB in TOGAF terms). Not shown here is a mapping of the software architecture to concrete products and standards (like a TOGAF SBB), which would usually be the case in any project. However, the Digital Playbook does not want to favor any particular vendor and is consequently leaving this exercise to the reader.

7.5 AI Pipeline Architecture

The AI Pipeline Architecture should explain, on a technical level, how data preparation, model training and deployment of AI models are supported. For each of these phases, it must be understood which AI-specific frameworks are being used, which additional middleware, which DBMS or other data storage technology, and which hardware and OS.

Finally, the AI Pipeline Architecture must show how the deployment of trained models to cloud and edge nodes is supported. For distributed edge nodes in particular, the support for OTA (over-the-air) updates should be explained. Furthermore, in the case of AI on distributed edge nodes, the architecture must explain how model monitoring data are captured and consolidated back in the cloud (Fig. 22.26).

Fig. 22.26

AI architecture

7.6 Putting It All Together

The Data/Functional Viewpoint has introduced the concept of functional decompositioning, including the documentation of the distributed component architecture. The Implementation Viewpoint has added different technical perspectives. The different functional components must be mapped to technology-specific pipelines. For this, feature teams must be defined that combine the required technical skills/access to the required technical pipelines for a specific feature (see the AIoT Product Viewpoint for a more detailed discussion on feature teams and how they are assigned) (Fig. 22.27).

Fig. 22.27

Architectural decomposition and system integration

The results from the different technical pipelines are individual technical components that must be integrated via different types of interfaces. For example, smartphone, cloud and edge components can be integrated via REST interfaces. On the edge, embedded components are often integrated via C interfaces. The integration between embedded software and hardware is done via different types of Hardware/Software Interfaces (HSI). Finally, any AIoT hardware components must be physically integrated with the actual physical product. During the development/testing phase, this will usually be a manual process, while later it will be either a standardized retrofit or line-fit process.

All of this will be required to integrate the different components required for a specific feature across the different technical pipelines. Multiple features will be integrated to form the entire system (or system-of-systems, depending on the complexity or our product or solution).

8 Product Viewpoint (Fig. 22.28)

Fig. 22.28

AIoT product viewpoint

The Product Viewpoint must map the other elements of the Product Architecture to the key elements of an agile product organization. The main artefact here is the agile story map, which is the highest level structural description of the entire body of work. Feature team mapping supports the mapping of the work described in the story map to the teams needed to implement the different product features. Finally, for each team and each sprint an individual sprint backlog must be created based on the story map and the results of the feature team mappings.

8.1 Story Map

It is best practice in the agile community to breakdown a larger body of work into specific work items using a hierarchical approach. Depending on the method applied, this hierarchy could include themes, epics, features, and user stories.

A story map organizes user stories in a logical way to present the big picture of the product. Story maps help ensure that user stories are well balanced, covering all important aspects of the planned solution at a similar level of detail. Story maps provide a two-dimensional graphical visualization of the Product Backlog. Many modern development support tools (such as Jira) support automatic visualization of the product backlog as a story map.

The AIoT Framework assumes the following hierarchy:

• Epic: A high-level work description, usually outlining a particular usage scenario from the perspective of one of multiple personas

• Feature: A specific feature to support an epic

• User Story: short requirements written from the perspective of an end user

Depending on the complexity of the project and the agile method chosen, this may need to be adapted, e.g. by further adding themes as a way of bundling epics.

When starting to break down the body of work, one should first agree on a set of top-level epics, and ensure that they are consistent, do not overlap, and cover everything that is needed. For each epic, a small number of features should be defined. These features should functionally be independent (see the discussion on functional decomposition). Finally, features can further be broken down into user stories. User stories are short and concise descriptions of the desired functionality told from the perspective of the user.

The example shown in Fig. 22.29 is the story map for the ACME:Vac product. It has six epics, including HMI, Cleaning, Maps, Navigation/Sensing, Configuration and Status/History. Each epic is broken down into a small number of key features supporting the epic. User stories are not shown on this level. Note that this story map does not include the entire mechatronic part of the system, including chassis, motor, locomotion (climbing over obstacles, etc.), home base, etc. Also, functional safety is not included here, which would be another real-world requirement.

Fig. 22.29

Example: initial story map

8.2 Feature Team Mapping

One of the main challenges in almost all product organizations is the creation of efficient mapping between the organizational structure and the product structure (the same applies to projects and solutions). The problem here is that organizations are often more structured around skills (UX, frontend, back end, testing, etc.), while product features usually require a mixture of these skills.

Consequently, the Digital Playbook recommends an approach based on feature teams, which are assigned on demand to match the requirements of a specific feature. See Agile AIoT Organization for a more detailed discussion. Feature teams can exist for longer periods of time, spanning multiple sprints, if the complexity of the feature requires this.

In the example shown in Fig. 22.30, the user story “Change cleaning mode” (part of the cleaning mode configuration feature) is analyzed. The results of the analysis show that a number of components on the robovac, the cloud and mobile app must be created or extended to support this user story. A similar analysis must be done for all other user stories of the overarching feature before a proposal for the supporting feature team can be made. In this case, the feature team must include a domain expert, an embedded developer, a cloud developer, a mobile app developer, and an integration/test expert. To support the scrum approach, who in the feature team plays the role of product (or feature) owner, as well as the scrum master, must be agreed upon.

Fig. 22.30

Mapping user story to components and feature team

8.3 Sprint Backlogs

In preparation for each sprint, an individual sprint backlog must be created for each team, which is specific to the upcoming sprint. The sprint backlog is derived from the story map (essentially the product backlog). The sprint backlog contains only those items that are scheduled for implementation during that sprint. The sprint backlog can contain user stories to support features but also bug fixes or nonfunctional requirements.

In larger organizations with multiple feature teams, the Chief Product Owner is responsible for the overarching story map, which serves as the product backlog. He prioritizes product backlog items based on risk, business value, dependencies, size, and date needed and assigns them to the individual teams. The teams will usually refine them and create their own sprint backlogs, in alignment with the Chief Product Owner and the product/feature owners of the individual teams.