Product Architecture: Difference between revisions

No edit summary
(Editorial Changes)
 
(38 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<imagemap>
<imagemap>
Image:2.2-ProductArchitecture.png|frameless|1000px|Ignite AIoT - Product Architecture
Image:2.2-ProductArchitecture.png|frameless|1000px|Product/Solution Design


rect 0 0 642 133 [[AIoT_Execution_and_Delivery|Agile AIoT Grid]]
rect 4 0 651 133 [[AIoT_Framework|More...]]
rect 642 0 1492 133 [[Product_Organization|Leadership and Organization]]
rect 970 0 1298 133 [[AIoT_Data_Strategy|More...]]
rect 1497 0 1900 133 [[Sourcing_and_Procurement|Sourcing]]
rect 651 0 970 133 [[Artificial_Intelligence|More...]]
rect 1904 0 2547 133 [[Service_Operations|Service Operations]]
rect 1298 0 1767 133 [[Digital_Twin_Execution|More...]]
rect 2768 128 3539 257 [[Artificial_Intelligence|AI Implementation]]
rect 1767 0 2095 133 [[Internet_of_Things|More...]]
rect 2768 257 3539 385 [[Product_Architecture|Architecture]]
rect 2095 0 2542 133 [[Hardware.exe|Hardware.exe]]
rect 2768 385 3539 518 [[AIoT_DevOps_and_Infrastructure|DevOps]]
 
rect 2768 518 3539 651 [[Trust_and_Security|Trust & Security]]
rect 2764 128 3539 257 [[Product_Architecture|More...]]
rect 2768 647 3539 784 [[Reliability_and_Resilience|Reliability & Resilience]]
rect 2764 257 3539 390 [[Agile AIoT|More...]]
rect 2768 779 3539 917 [[Verification_and_Validation|Verification & Validation]]
rect 2764 385 3539 518 [[AIoT_DevOps_and_Infrastructure|More...]]
rect 2764 518 3539 651 [[Trust_and_Security|More...]]
rect 2764 651 3539 784 [[Reliability_and_Resilience|More...]]
rect 2764 779 3539 917 [[Verification_and_Validation|More...]]
 
rect 1005 199 1878 412 [[AIoT_Business_Viewpoint|Business Viewpoint]]
rect 1005 465 1878 717 [[AIoT_Usage_Viewpoint|Usage Viewpoint]]
rect 1005 757 1878 1005 [[AIoT_Data_and_Functional_Viewpoint|Data and Functional Viewpoint]]
rect 1005 1041 1878 1311 [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]
rect 1962 199 2671 1315 [[AIoT_Product_Viewpoint|Product Viewpoint]]


desc none
desc none
</imagemap>
</imagemap>


__NOTOC__
<s data-category="AIoTFramework"></s>
 
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 [https://agilemanifesto.org/ 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.
__TOC__


== AIoT Framework: Product Architecture ==
= AIoT Design Viewpoints and Templates =
The idea of a product architecture might seem old fashioned to somebody who is used to working in small, agile development teams. After all, the [https://agilemanifesto.org/ 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, multi-site projects, a certain amount of documentation is required in order to ensure that all teams and stakeholders are aligned and working in synch. Many AIoT projects will have this problem. Consequently, Ignite AIoT proposes to create and maintain an AIoT Solution Architecture which captures key requirements and design decision in a consistent manner. In order to achieve this, the following viewpoints are proposed:
To provide a consistent and comprehensive design for AIoT-enabled products or solutions, the ''AIoT Playbook'' proposes a set of design viewpoints, each with a specific set of design templates:
* [[AIoT_Business_Viewpoint|AIoT Business Viewpoint]]: Builds on the input from the Business Model, adds the capability perspective
* [[AIoT_Business_Viewpoint|Business Viewpoint]]: Builds on the input from the Business Model, adds KPIs and planning details
* [[AIoT_Usage_Viewpoint|AIoT Usage Viewpoint]]: Focus on how users, assets and other system elements are using the AIoT solution
* [[AIoT_Usage_Viewpoint|UX Viewpoint]]: Focus on how users are interacting with and experiencing the product or solution
* [[AIoT_Data_and_Functional_Viewpoint|AIoT Functional Viewpoint]]: Focus on the data and functional components of the AIoT solution
* [[AIoT_Data_and_Functional_Viewpoint|Data/Functional Viewpoint]]: Focus on the data and functional components of the AIoT solution
* [[AIoT_Implementation_Viewpoint|AIoT Implementation Viewpoint]]: Focus on the implementation aspects
* [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]: Adds details on the implementation aspects
* [[AIoT_Product_Viewpoint|AIoT Product Viewpoint]]: Mapping to the agile product development perspective
* [[AIoT_Product_Viewpoint|AIoT Product Viewpoint]]: Mapping to the agile product development perspective


It is important to notice that Ignite AIoT is not proposing an excessive, RUP/waterfall-style model depth, as can be seen when looking at the individual templates. The general idea of collaboration between the different project stakeholders in the architecture management process is shown in the figure below.
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.
 
= 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|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).
 
[[File:Agile Design.png|1000px|frameless|center|link=|AIoT product/solution design and the agile process]]


[[File:2.2.x-SolutionArchitectureProcess.png|700px|frameless|center|AIoT Solution Architecture Process]]
Finally, it is important to keep in mind that product/solution design and organizational structure must be closely aligned ([[Agile_AIoT_Organization|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).


The key to success here is to keep the AIoT Solution Architecture on a level of detail where it is meaningful but not overly complex. The agile teams must be able to apply their own mechanism (e.g. demand-driven design spikes) to derive requirements for their backlog and provide feedback to the overarching architecture in return.
= 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.


== Authors and Contributors ==
= Authors and Contributors =


{|{{Borderstyle-author}}
{|{{Borderstyle-author}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
|}
|}

Latest revision as of 22:53, 5 July 2022

More...More...More...More...More...Hardware.exeMore...More...More...More...More...More...Business ViewpointUsage ViewpointData and Functional ViewpointImplementation ViewpointProduct ViewpointProduct/Solution Design

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.

AIoT Design Viewpoints and Templates

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

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.

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).

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).

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.

Authors and Contributors

Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

AUTHOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.