What is the next step after agreeing on the first iteration of the business model and securing funding for execution? With the traditional waterfall approach, the answer is relatively clear: documentation of requirements with a high level of detail and accuracy, serving as the stable foundation for planning, design and execution. However, in the software world, we have learned that getting stable, long-term requirements is often difficult. Consequently, traditional requirements management often has a bad name in the agile community. Instead, agile best practices focus on the backlog as the central means of managing requirements and work items. The goal is to capture the high-level, long-term vision on a more abstract level (e.g., via so-called epics and themes) and then provide a detailed and precise work definition only for the next upcoming sprint (via the sprint backlog - created for each sprint; typical sprint duration is 3-4 weeks). In this way, the agile approach ensures that no waste is created by investing in detailed, long-term requirements that are likely to change over time anyway.
Most AIoT projects or product developments will need to combine both perspectives. For the standard software part -- and probably also the AI part -- agile planning will work well. For those parts involving hardware and telecommunications infrastructure -- as well as any part with complex dependencies -- a more planning-centric approach will most likely be required. Enterprise sourcing processes will add their part to limit a purely agile approach.
Nevertheless, a good starting point will be the agile best practices in this area, which we will discuss first. Next, we will look at how to derive an AIoT system design from all of this. This will be completed by a discussion of the entire cycle from requirements and design to implementation and validation. Finally, we will discuss the dependencies between AIoT system design and co-creation/sourcing.
From Business Model to Implementation
The AIoT Playbook proposes an approach that combines the business model design patterns outlined in Part III with Agile Story Maps, as well as an AIoT-specific approach for product/solution design. This is shown in the figure following. The starting point are the elements of the business model design, which can be adapted over time based on market feedback. The product/solution design provides a lightweight yet holistic view of the system design, from the business view down to the implementation view. Finally, the Agile Story Map provides the high-level breakdown of all work items. For each sprint, a dedicated sprint backlog is derived from the story map, containing the prioritized and agreed-upon work items for the upcoming sprint.
The Agile Approach
The agile equivalent to requirements management is the backlog. The product backlog is a list of all the work items required to build and improve the product. It represents the single source of work definitions accepted by the scrum teams. For each upcoming sprint and each sprint team, a sprint backlog is created, which defines the work to be done by the team in the next sprint. Product backlog items can have different granularities. Sprint backlog items must be implementable in a single sprint. Story maps often serve as the visualization of the product backlog, as will be described in the following.
Story maps are a useful tool to manage the high-level requirements and structure of a product. Depending on the school of thought, they are either described as a visualization of a product backlog or as a customer journey-centric way of structuring the body of work on the highest level. Especially in the early stages of product creation, story mapping is used as a technique for product discovery, helping to outline the structure of a new product (or a complex, new feature for an existing product). To achieve a higher level of abstraction and orientation than a linear backlog, story maps typically arrange lower-level features in higher-level, functional groups.
Typical units of work in story maps include so-called themes, epics, features and user stories. The number of levels in the hierarchy of the body of work depends on the complexity of the product/solution. For the purpose of simplicity, the Digital Playbook focuses on epics, features and user stories:
- Epics are a high-level body of work, typically representing 2-6 months in duration. An epic can span multiple releases and more than one team. They are often aligned with senior management. Epics contain features.
- Features describe a specific functionality of the product. They are smaller than epics and typically contained within a specific release and assigned to a specific team (see => feature team). They are typically managed by product owners. Features contain user stories.
- User stories are the smallest definition of an increment, usually less than a week. They are bound to a specific sprint.
Depending on the layout used, the story map can imply a certain order at the top level, either in terms of the logical sequence in the customer journey or the order on which the elements are worked.
Example: AIoT Story Map & User Stories
The following example shows a more detailed structure of a story map. The top level contains epics. Returning to the smart kitchen appliance as an AIoT example from earlier, epics at this level could include "cooking", "baking", and "recipe recommendations". On the level below, features are shown. A feature of the smart kitchen appliance could be a "predefined baking program". Below this, user stories are shown. Use stories usually follow a specific pattern, as shown in the figure below ("As a..."). User stories should also include acceptance criteria. Depending on the layout of the story map chosen, use stories can also be grouped into releases.
Story maps, including epics, features and user stories often focus on the functional aspects of the system. In addition, most AIoT solutions or products will usually also have some nonfunctional requirements (NFRs). NFRs usually define attributes such as availability, performance, reliability, scalability, security, maintainability, and usability. For a distributed, AIoT-enabled system, NFRs might have to be broken down to specific areas, e.g., edge vs. cloud or specific functional areas. For example, an autonomous robot might have different NFRs for functional safety-relevant vs. non-relevant areas. This is important to keep costs and effort down to a realistic level, since functional safety development is usually much more expensive.
Finally, it should be noted that nonfunctional requirements for AI-enabled components are often different than those of traditional, software-enabled components. NFRs for AI components can include, for example:
- Algorithm accuracy and reliability: comparing AI output to reality
- Algorithm performance: for both online and training
- Transparency: making results explainable
- Fairness: ensuring results are fair and non-biased
- Testability: ensuring that the AI can be properly tested
- Security and privacy: related both to input and output
AIoT System Design
Some agile software projects will mainly rely on story maps and user stories, without an explicit system design. However, a more complex project may also require a certain amount of system design. Sometimes this is done in a "Sprint 0", which then focuses on creating both the high-level story map as well as a corresponding system design.
Given the typical complexity of an AIoT initiative, a system design is required that helps align all stakeholders and subsystems. The Digital Playbook proposes a set of design viewpoints, which are introduced in the following.
AIoT Design Viewpoints
The Digital Playbook proposes four viewpoints to help create a consistent system design which covers all relevant aspects: business Viewpoint, UX Viewpoint, the Data/Functional Viewpoint, and Implementation Viewpoint. The initial Business Model will have a huge impact on the Business Viewpoint. The UX Viewpoint will be heavily influenced by the customer journey. Policies and regulations will have a huge impact on both the Data/Functional Viewpoint as well as the Implementation Viewpoint. Again, technical constraints as well as skills and organization will heavily influence the implementation viewpoint. Finally, AIoT and enabling technologies will have an impact on all viewpoints. For example, car sharing, as we know it today, would not be possible without smartphones to hail rides and interact with the system. As an enabling technology, they have both enabled new business models, created a new UX, heavily influenced the system functionality, and finally the implementation.
AIoT Viewpoint Details
The Digital Playbook provides a set of templates for each of the four viewpoints. They are discussed in detail in the technology execution section on product/solution design. The Business Viewpoint starts with input from the Business Model, and then adds key KPIs, quantitative planning and a milestone-oriented timeline. The UX viewpoint is based on customer and/or site surveys and focuses on personas, Human/Machine Interaction and mockups for key user interfaces. Of course, the Data/Functional Viewpoint includes a high-level overview of the main data domains and the component and API landscape. If the project makes use of Digital Twins as an additional structural element, this is included here as well. Finally, the AI feature map helps ensure that AI is utilized to the fullest potential. The Implementation Viewpoint provides a high-level end-to-end architecture, an asset integration architecture, a hardware architecture, and software and AI architecture. Adjacent to all of this, the Product Viewpoint includes the Story Map, the mappings to feature teams, and the sprint backlogs.
It is important that the level of detail in the different viewpoints be kept on such a level where it is useful as a high-level documentation to enable cross-team alignment and efficient stakeholder communication, without drifting into the habits of waterfall-centric, RUP-like detail models. Detailed design models should only be created on-demand and where specifically needed. Again, this is also likely to differ for the software vs. hardware parts of the system.
From Requirements and Design to Implementation and Validation
Business models, story maps and product/solution designs capture key requirements and high-level design decisions. The teams in the DevOps organization are responsible for the implementation, testing and continuous delivery of the product increments. However, in AIoT, we cannot always assume a fully agile approach due to the aforementioned constraints. This is why we introduce the Agile V-Model, which proposes to execute individual sprints as small V-Model iterations, which take the high-level design plus the current sprint backlog as input, and then perform a miniaturized V-Model iteration, including Verification and Validation at the end of the sprint against the initial requirements. Finally, customer and user feedback as well as product performance data need to be incorporated back into the requirements and design perspective. This way, continuous improvement can be ensured.
Design vs. co-creation & sourcing
Finally, a key question that remains is who should actually do the requirements capturing and design work. This will heavily depend on the make/buy/co-creation strategy chosen. If the AIoT system is mainly developed in-house, both requirements and design will have to be created and maintained by the in-house team.
If the company decides to acquire significant parts of the system from outside suppliers or partners, high-level requirements/designs such as epics and feature definitions are likely to remain in-house. For the user stories, this could go either way, depending on the sourcing model chosen. Finally, in the case of a turnkey solution, one might even go to the extreme of only retaining the high-level requirements management in-house, and relying on external suppliers/partners for the rest.
Especially for AIoT systems with their more complex supply chains including hardware, software and AI, it is important to carefully balance this out.