Product / Solution Design: Difference between revisions

Line 60: Line 60:


= AIoT System Design =
= AIoT System Design =
Some agile software projects will mainly rely on story maps and user stories, without an explicit system design. However, especially more complex project usually 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 which helps aligning all the different stakeholders and sub-systems. The AIoT Playbook proposes a set of design viewpoints, which are introduced in the following.
== AIoT Design Viewpoints ==
== AIoT Design Viewpoints ==
The AIoT Playbook proposes 4 viewpoints to help creating a consistent system design which covers all relevant aspects: Business Viewpoint, UX Viewpoint, the Data / Functional Viewpoint and Implementation Viewpoint. The intial 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. Technical contraints as well as skills and organization will again heavily influence the implementation viewpoint. And 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 smart phones to hail rides and interact with the system. So as an enabling technology they have both enabled new business models, created a new UX, heavily influenced the system functionality, and finally the implementation.


[[File:Design Intro v01.png|800px|frameless|center|Product / Solution Design - Overview]]
[[File:Design Intro v01.png|800px|frameless|center|Product / Solution Design - Overview]]

Revision as of 21:17, 9 August 2021

More...More...More...More...More...More...More...0.2-Design.png


Requirements & Design

What is the next step after agreeing on the first iteration of the business model and securing funding for execution? In the traditional waterfall world, the answer is relatively clear: Documentation of requirements with a high level of detail and accuracy, 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 are focusing 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 (sprint backlog - created for each sprint; typical sprint duration is 3-4 weeks). This way, the agile approach ensures that no waste is created by investing in detailed, long-term requirements which 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 pure agile approach.

Nevertheless, a good starting point will be the agile best practices in this area, which we will discuss first. Next, a short look at more traditional requirements will be taken, before looking 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.

The Agile Approach

The agile pendant 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, as will be discussed in the following. 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

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. For the purpose of simplicity, the AIoT Playbook is focusing 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. Epics often are 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). Features 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 by which the elements are worked on.

Story Map Overview

Example: AIoT Story Map & User Stories

The following example shows a more detailed structure of a story map. The top level contains epics. Coming back to the smart kitchen appliance as an AIoT example from earlier on, epics on this level could including "cooking", "baking", and "recipe recommendations". On the level below, features are shown. A feature for the smart kitchen appliance could be "pre-defined 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 be also grouped in releases.

Story Map details

Non-Functional Requirements

Story maps including epics, features and user stories usually focus on the functional aspects of the system. In addition to these, most AIoT solutions or products will usually also have some non-functional 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 has to be noted that non-functional 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 as well as output

AIoT System Design

Some agile software projects will mainly rely on story maps and user stories, without an explicit system design. However, especially more complex project usually 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 which helps aligning all the different stakeholders and sub-systems. The AIoT Playbook proposes a set of design viewpoints, which are introduced in the following.

AIoT Design Viewpoints

The AIoT Playbook proposes 4 viewpoints to help creating a consistent system design which covers all relevant aspects: Business Viewpoint, UX Viewpoint, the Data / Functional Viewpoint and Implementation Viewpoint. The intial 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. Technical contraints as well as skills and organization will again heavily influence the implementation viewpoint. And 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 smart phones to hail rides and interact with the system. So as an enabling technology they have both enabled new business models, created a new UX, heavily influenced the system functionality, and finally the implementation.

Product / Solution Design - Overview

AIoT Viewpoint Details

Click HERE for more details on AIoT product / solution design viewpoints.

AIoT Design Viewpoints - Overview

From requirements and design to implementation and validation

From design to implementation and validation

Design vs co-creation & sourcing

Story Map vs Sourcing Perspective