Product Architecture: Difference between revisions
Line 44: | Line 44: | ||
What is important in most AIoT projects is that there will be certain parts of the project which will require a higher level of stability for the design documentation than others. This is generally true for all areas which require a more long-term planning, e.g. because of procurement or manufacturing requirements, or in order to manage complex dependencies. This is a key problem which the solution design team must address. In many cases, this will also require some kind of architectural layering, especially in the 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 which are supposed to be stable. | What is important in most AIoT projects is that there will be certain parts of the project which will require a higher level of stability for the design documentation than others. This is generally true for all areas which require a more long-term planning, e.g. because of procurement or manufacturing requirements, or in order to manage complex dependencies. This is a key problem which the solution design team must address. In many cases, this will also require some kind of architectural layering, especially in the 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 which are supposed to be stable. | ||
[[File:Agile Design.png|800px|frameless|center|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 ([[Agile_AIoT_Organization|Conway`s law]]). The design will usually include many features which require support from different technical layers. For example the seat-heating-on-demand, which requires a smart phone component, a cloud component, and different components on the vehicle to work together in order to deliver this feature. The AIoT Playbook is proposing to define feature teams which are working across the different technical layers. Being able to derive the setup of these feature teams from the product / solution design will be key to success. | 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 which require support from different technical layers. For example the seat-heating-on-demand, which requires a smart phone component, a cloud component, and different components on the vehicle to work together in order to deliver this feature. The AIoT Playbook is proposing to define feature teams which are working across the different technical layers. Being able to derive the setup of these feature teams from the product / solution design will be key to success. | ||
== Authors and Contributors == | == Authors and Contributors == |
Revision as of 07:25, 8 July 2021
Product / Solution Design
The idea of a more detailed design document might seem old fashioned to somebody 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, 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. 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 AIoT playbook is proposing to create and maintain a product/solution architecture which captures key requirements and design decision in a consistent manner. In order to achieve this, the following viewpoints are proposed:
- 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 notice that the AIoT playbook is not proposing an excessive, RUP/waterfall-style level of documentation. The general idea is to provide a comprehensive yet lightweight set of design documents which 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.
It is important to accept that the 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 in the agile v-model must go back to the design and match it against the learnings from the previous sprint, and any changes to the known requirements. This also means that the design documentation can not be too detailed, since otherwise it will not be possible to do a thorough review during each sprint planning session. The design templates provided in the AIoT Playbook aim to strike a pragmatic balance between comprehensiveness and manageability.
What is important in most AIoT projects is that there will be certain parts of the project which will require a higher level of stability for the design documentation than others. This is generally true for all areas which require a more long-term planning, e.g. because of procurement or manufacturing requirements, or in order to manage complex dependencies. This is a key problem which the solution design team must address. In many cases, this will also require some kind of architectural layering, especially in the 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 which are supposed to be stable.
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 which require support from different technical layers. For example the seat-heating-on-demand, which requires a smart phone component, a cloud component, and different components on the vehicle to work together in order to deliver this feature. The AIoT Playbook is proposing to define feature teams which are working across the different technical layers. Being able to derive the setup of these feature teams from the product / solution design will be key to success.
Authors and Contributors
|