Ignite AIoT: Product Organization
The product organization is ultimately responsible for delivering your smart, connected products. Given the complexity of a typical AIoT product, as well as the different cultures which have to be brought together, building an efficient and effective AIoT product organization is not an easy task. This section of the Ignite AIoT framework is discussing key challenges and proposing a specific setup which can be easily adapted to fit your individual needs.
- 1 Ignite AIoT: Product Organization
- 2 AIoT Products
- 3 AIoT & Agile
- 4 AIoT Product Organization
- 4.1 AIoT Product Manager / Chief Product Owner
- 4.2 AIoT Product Engineering Lead
- 4.3 AIoT Product Architect
- 4.4 AIoT Product Coordinator
- 5 References
- 6 Authors and Contributors
Before we start discussing the setup of the AIoT product organisation, we first need to have a short look at what actually constitutes an AIoT product. There is often some confusion regarding concepts such as products, solutions and platforms. The figure below attempts to put these key concepts in context:
- At the core, we have smart, connected products - enabled by AI and IoT, and delivering specific features to the customers
- Sometimes, it can make sense to extend the product perspective to the solution level. While there is no clear delineation, a solution is typically understood to add the business process perspective (including operations-related processes), and providing value to customers (as opposed to product features)
- For many companies, the holy grail are still platforms - typically in the form of multi-sided business platforms, which open the offering beyond the own products, to include partners into the ecosystem (e.g. via APIs or app stores)
Smart, connected products are often part of complex ecosystems and organizations. As indicated by the example in the figure below, they can exist within larger product families, and will have to be subject to long-term, multi-generation product planning. In some cases, only the newest product generations will utilize IoT, AI, or even AIoT.
In order to successfully manage evolution in such an environment it is important to understand the product lifecycle of the individual products, as well as how this fits into a platform or product line context.
AIoT Product Lifecycle
Especially at the beginning of the new product journey it is important to take a step back and look at the complete product lifecycle, in order to be prepared for the road ahead. The lifecycle of most products can be described as follows:
- Exploration: During this phase, the initial product is developed (MVP) and the market reception validated, initial customers are acquired, etc.
- Growth: The growth phase aims to expand reach, scale sales and continue to develop the product to stay competitive
- Maturity: In this phase, the focus is on customer retention and to sustain market share
- Decline: Finally, a strategic decision regarding strategic pivoting or phasing out has to be made
Traditional Project Organizations
In many incumbent enterprises, the development of a new product often starts as a project, because from a controlling and administration point of view, setting up a project is more lightweight than establishing a new organizational unit. Since in the early stages it is often not known whether the product idea will be successful, this is quite understandable. If the initial MVP is promising, the project might be transferred to an internal accelerator. If the product is showing the potential to scale from a sales point of view, a new line of business might be created eventually.
In principle, there is nothing wrong with this approach - however, in practice it can cause severe problems. Let`s first quickly summarize the key differences between project and product. The table below provides a high-level comparison.
|Project||Product / Solution|
|Timeline||Discrete, with well defined start and end dates||Continuous, long term - potentially with multiple product generations|
|Funding||Project budget, e.g. from innovation fund||Funding from operations budget|
|Metrics/KPIs||Development and go-to-market milestones, budget (cost)||Revenue, profitability, market share, customer satisfaction|
Towards the AIoT Product Organisation
In practice, there are a number of common problems associated with starting a new product with a project mindset and setup. First, a product should be developed from the beginning with product KPIs as the central measurement of success - customer satisfaction and customer adoption should be key KPI from the very beginning. Typical project-centric KPIs like development and go-to-market milestones as well as cost should be secondary.
Second, a typical project has a fixed start and end date, while a product needs to take a longer-term perspective. Especially in manufacturing-centric organizations, it is still a common assumption that at the end of the initial development project the product is "ready" and can be handed over to a maintenance and operations team, eliminating the costs for expert developers. Such a transition will obviously cripple any long-term oriented, continuous advancement of the product.
Even if the product is initiated as a project in the early stages, it is therefore key to observe the following:
- Use product-oriented KPIs from the beginning
- Implement a sustainable team setup with a 4-5 year perspective; this will will continually evolve the product beyond MVP
- View the project only as an administrative vehicle for initiating the product organization, but follow a product-oriented approach from the beginning
AIoT & Agile
With the emergence of Internet- and Cloud-based development, Agile software development has risen to become the de-factor standard for many organizations - even though there are still many (sometimes religious) debates about how to do Agile right. Software projects are usually plagued by very high levels of complexity and highly volatile requirements. Agile development is addressing this by combining collaborative efforts of self-organizing and cross-functional teams with a strong sense of customer-centricity and focus on value creation. Agile promotes continuous exploration, continuous integration and continuous deployment. Scrum - as probably the most prominent Agile method - is based on an Adaptive planning approach, which combines higher-level epics with a more detailed requirements backlog. Detailed requirements ("user stories") are typically only created for the next 1-2 sprints ahead. Successful Scrum organizations are very thorough and consequential in their Scrum rigor, while still supporting adaptive and flexible planning.
Unfortunately, in most AIoT projects, there are some inhibitors to a fully Agile approach, including:
- Cultural differences between Cloud-native developers and product/manufacturing type of engineers
- Scalability across multiple, often distributed teams (e.g. AI development, cloud and edge/embedded software development, hardware and network engineering)
- Hardware and embedded software engineering, which play by different rules than cloud-based software development
- The need for more detailed end-to-end specifications as the foundation for fixed-price sourcing of hardware and software
The following will look at each of these inhibitors in detail, followed by a recommendation for how to address them in an AIoT product organization.
Inhibitor 1: Cultural Differences
The first inhibitor for the adoption of a pure agile approach in an AIoT project are the cultural differences typically found in the heterogeneous teams which need to work together. Developers who are used to working frequent, Cloud-enabled updates have a very different to managing projects compared to manufacturing-centric engineers who know that after the SOP (Start-of-Production) any change to a physical asset after it has left the factory involves a costly and painful recall procedure. As shown in the figure below, different types of organizations typically have different types of cultures - even within the same company. Applying a one-size-fits all methods to such a cultural mix will be difficult.
Depending on the culture found in the organizational units involved in the development of the AIoT product, a matching agile approach must be chosen. Approaches like Scrum of Scrums (SoS) or Large Scale Scrum (LeSS) could be a good fit for an entrepreneurial culture which permits a "pure" agile approach. The Scaled Agile Framework (SAFe) could be a good fit for organizations which are more coming from a "Command & Control" background, often combined with elements of a more matrix-like organization.
Inhibitor 2: Scalability
The second inhibitor is scalability: Most "pure" Agile methods like Scrum are working best for single, co-located teams. Chances are that an AIoT project will be larger, involving multiple teams which are dealing with the AI development, on-asset components (Edge software, embedded, hardware), the IoT network, the backend business logic (cloud or on-premise), as well as the integration of existing enterprise systems. Given the diversity of these tasks, it also seems likely that the teams and team members will be distributed across multiple locations.
Consequently, most AIoT projects will require an Agile method that can be scaled beyond a single team and potentially a single location. In the discussion above, different approaches for scaled Agile development were introduced, including Scrum of Scrums (SoS), Large Scale Scrum (LeSS) and the Scaled Agile Framework (SAFe). We will discuss later how they can be adapted to also overcome some of the other limitations of AIoT development.
Inhibitor 3: Hardware & Embedded
Most AIoT projects require a combination of traditional (backend) software development with some form of edge or embedded software development. In many cases, custom hardware development and manufacturing will also be a requirement.
If the edge platform is a powerful, server-like system, e.g. running Linux and C++ or even high level languages, the difference to an Internet or enterprise software project might not be as high. However, in many cases AIoT projects also require custom embedded software and hardware, which is a different animal all together, and many Agile principles can not be directly applied. Embedded software is typically very technical, e.g. focusing on hardware-specific drivers or controllers, running on specialized real-time operating systems. And hardware development is following its own rules. Some differences include:
- Software in general is easier to change than hardware designs
- It is not possible to change hardware after it has been manufactured
- Higher-level hardware designs must often incorporate existing, standardized lower-level parts
- The lead times, acquisition times and feedback loops for hardware components are much longer
- Time to first full integration test with custom hardware usually significantly longer than with software
All of the above does not mean than an Agile mindset can not be applied to embedded hardware/software development. However, an Agile embedded approach will have to take these specifics into consideration and adapt the methodology accordingly.
Inhibitor 4: AI
While AI is quickly becoming a popular element of modern product development, there are currently no well established methodologies for AI development. Some teams are applying methods like CRISP-DM, KDD, or CPMAI to AI projects. However, there is not yet a well documented and established method out there which explains how to combine agile and AI. Which is not to say that it can`t be done, but the lack of proven agile methods for AI development is certainly an inhibitor for AIoT & Agile.
Inhibitor 5: Sourcing
Most AIoT products require sourcing of development resources with often very specialized skills, as well as a variety of technologies including hardware (boards, gateways, sensors, actuators, antennas, communication modules), software (AI, embedded, cloud, enterprise, EAI), networks (LAN and WAN), security technology and others. Sourcing can already be a complex topic in normal software projects. With the added complexities of an AIoT project, any form of Agile organization will have to be closely aligned with the sourcing process.
In some organizations, the Agile teams will have a high level of autonomy over the sourcing process. In a matrix-type of organization as described above, a central sourcing team will have a high level of influence and potentially little experience with this type of project. If the AIoT product is a large-scale, strategic product, it is very likely that procurement will dominate the first one or even two years of the development. In addition, lead times for hardware acquisition can be much longer than those of software components.
Probably the biggest challenge from an Agile perspective is that most sourcing projects require extensive documentation of requirements or even solution designs. Many procurement organizations still see fixed-price offers as the preferred way of sourcing complex solutions. The level of documentation detail needed for most fixed-price contracts runs directly diametral to the low-documentation mantra of the Agile world.
Consequently, the product team and the procurement team will have to find ways to satisfy both their needs, e.g. through creative solutions like "fixed-price agile contracts" (e.g. a time-and-material contract with a performance-based compensation component based on individual sprint performance).
Finally, another big issue are SLAs (Service Level Agreements) and warranties. The buyer typically wants this fixed as early in the development cycle as possible (ideally as part of the contract), while the supplier will have a hard time agreeing to any SLA or warranty if the requirements are not fixed.
AIoT Product Organization
The Ignite AIoT framework recommends to use an Agile approach as the blueprint for the product organization, and combine it with elements needed to address the AIoT-specific inhibitors described above. Ignite AIoT does not make a specific recommendation for any of the Scaled Agile Frameworks (SoS, LeSS, SAFe, etc.), but describes some AIoT-specific elements which can be combined with most of the existing Scaled Agile frameworks.
As shown in the figure above, Ignite AIoT recommends that four key roles be created to manage the AIoT product:
- Product Manager / Chief Product Owner
- Product Engineering Manager, e.g. Release Train Engineer (RTE) if SAFe is used
- Product Architect, using the Ignite Product Architecture approach
- Coordinator, the administrative backoffice
Each of these four roles will be described in more detail below. In addition, Ignite AIoT is assuming that the following types of teams should exist:
- Asset prepration: Prepares the asset for the AIoT solution elements (asset design and manufacturing setup, in case of a line-fit approach)
- IoT on-asset components: hardware, firmware, software and AI-driven logic ('asset intelligence') which needs to be deployed on the assets
- IoT communication services: IoT WAN and LAN, including matching service conditions, set-up and management.
- IoT backend services: provides interfaces to the on-asset services, any IoT-specific data processing and management in the back-end (potentially building a digital twin), IoT-specific application logic, AI-driven logic ('swarm intelligence'), and integration with existing enterprise applications
- IoT DevOps & infrastructure: provides the required cloud infrastructure and development environments, and also integrates the on-asset platforms - potentially providing infrastructure for OTA (over-the-air) updates, etc.
- 'IoT cross-cutting': end-to-end security, integration testing, etc.
The positioning of the AI team will depend on the project specifics: Is the AI functionality dominating the product? Then it should be a top-level team. If not, it can either be part of the on-asset or backend organization, depending on the project. If AI is distributed accross backend and asset, then it can either be part of cross-functional or toplevel.
The following will look at each of the 4 key roles defined above in more detail, and how they interact with the different teams defined above.
AIoT Product Manager / Chief Product Owner
Product Management is a well established discipline, especially for tech companies. We will first look at good practices, before then addressing the AI/AIoT specifics.
Product Management Good Practices
Product Management for smart, connected product can build on existing good practices, which are summarized in the figure below.
Product Management and AI/AIoT
Since smart, connected products often rely heavily on Artificial Intelligence and other advanced technologies, a key task for the product manager is to build multi-disciplinary teams which can work on identifying the best possible match between AI / AIoT capabilities on the one hand, and the business needs on the other. For this purpose, AI and technology experts need to work closely with domain experts.
AIoT Product Engineering Lead
The Product Engineering Lead is effectively responsible for ensuring that the different AIoT product teams together are continuously delivering integrated product increments. Depending on the chosen setup - loosely coupled teams or a more hierarchical organization - he will directly or indirectly coordinate and orchestrate the delivery of the product increments.
Some of the key tasks include:
- Management of end-to-end product engineering roadmap
- Alignment of product vision with product roadmap and backlogs
- Facilitation of cross-team planning events
- Oversee continuous delivery pipeline and efficient DevOps
- Coordination / support of technology and resource acquisition
- Escalation and tracking of road-blockers
- Ensure UX principles are followed
- Ensure establishment of Quality Management
- Creation and tracking of key engineering metrics
- Coaching and guiding the engineering staff
- Collaborate with product coordinator on dependency management, risk management, cost management
Aligning Product Organization and Product Architecture
The right set-up of the project organization (or, in fact, the product organization) is another key success factor. As we will see in the following, this needs to take a number of different aspects into consideration.
According to Conway`s Law, every software system ends up with an architecture "shaped like" the organizational structure it is developed in ("Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure", Melvin Conway, 1967).
Simply put: If you assign 3 teams to develop a two-tier architecture, you are still likely to end up with a 3-tier architecture - regardless of what the architecture definition says. This extremely important truth should guide every project manager in the setup of his project organization.
Ignite AIoT proposes to create a project engineering organization which is closely mirroring the intended target architecture of the AIoT solution. In particular, it is recommended that the toplevel solution architecture elements are mirrored as toplevel workstreams in the project organization (the term 'workstream' is chosen to indicate that especially in the early project phase, not all deliverables within each workstream might be 100% defined, and that each workstream presents ongoing work; this is closer to the agile mindset than the traditional Work Breakdown Structure (WBS) approach).
The following describes how the top-level workstreams should be defined with the key elements of the AIoT architecture in mind. For example, a common element in any AIoT architecture are the assets, onto which certain parts of the AIoT solution need to be deployed. Often, the design and manufacturing of the asset itself is not directly in scope of the AIoT project. However, in order for asset and AIoT solution to play together, the asset needs to be prepared to fulfill the requirements of the AIoT solution (e.g. provide a mounting for special hardware, power supply, cable routing, a space for the antenna, etc.). Consequently, the project org chart should include a sub-project of workstream 'asset preparation'.
The next workstream could be 'IoT on-asset components', which includes any hardware, firmware, software and AI-driven logic ('asset intelligence') which needs to be deployed on the assets.
Following this, the next workstream could be 'IoT communication services', which link the assets to the back-end. This workstream will have to deal with sourcing of potentially global communication services, including matching service conditions, set-up and management.
The 'IoT back-end services' workstream must deal with providing interfaces to the on-asset services, any IoT-specific data processing and management in the back-end (potentially building a digital twin), IoT-specific application logic, AI-driven logic ('swarm intelligence'), and integration with existing enterprise applications.
The 'IoT DevOps & infrastructure' workstream must not only provide the required cloud infrastructure and development environments, but also integrate the on-asset platforms - potentially providing infrastructure for OTA (over-the-air) updates, etc.
Finally, the 'IoT cross-cutting' workstream must - as the name indicates - deal with cross-cutting tasks like end-to-end security, integration testing, etc.
Product Schedule Management
Traditional project schedule management and agile development might seem like conflicting approaches. However, even if the general development setup is agile (or, in our case, most likely a form of scaled agile), it will be necessary to augment the agile approach with a more traditional project schedule management approach. The project schedule will have to address:
- Alignment between the agile development schedule and external stakeholders, e.g. if external services are to be used via APIs or own services are to be used from external consumers
- Alignment between the agile development schedule and the different sourcing activities of the project, e.g. sourcing of development resources, application development environments, cloud infrastructure, and so on
- Alignment with senior management and other 'internal customers' by providing at least a high level project road-map including project and release milestones
AIoT Product Architect
The AIoT Product Architect must define and maintain the end-to-end architecture for the product. He must work closely with the different AIoT development teams and other key stakeholders. He must focus only on architectural decisions which are of relevance from a cross-team perspective. Architectural decisions which have no impact outside of an individual team should be made by the team itself.
In order to support the AIoT Product Architect, Ignite AIoT supports a number of different viewpoints - each supported by a set of reusable templates:
- AIoT Business Viewpoint: Builds on the input from the Business Model, adds the capability perspective
- AIoT Usage Viewpoint: Focus on how users, assets and other system elements are using the AIoT solution
- AIoT Functional Viewpoint: Focus on the data and functional components of the AIoT solution
- AIoT Implementation Viewpoint: Focus on the implementation aspects
- 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.
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.
AIoT Product Coordinator
In order to support the Product Manager, Engineering Lead and Product Architect in their work, Inite AIoT recommends to install an overall Product Coordinator in a backoffice management type of role. The key tasks of this coordinator are summarized in the figure below.
Product Scope & Dependency Management
Successfully managing the product scope and external dependencies is a critical tasks, and the Product Coordinator can play a key support role here. Scope creep refers to continuous and uncontrolled growth in a product's scope. Scope creeps occurs when the scope of a product is not properly defined and controlled. Because agile methods are designed to deal with constant change (change is expected and accepted throughout the life of an agile project), scope does not 'creep' in agile projects - at least in theory. However, even in agile projects it is important to manage scope on the top level, especially to manage expectations of senior management, which typically expects a commitment to a scope definition defined early in the project. Using a diagram like the one below can help with this.
In addition to the product scope, there are dependencies. Experienced project managers typically try to avoid external dependencies as much as possible, because from their point of view they present an uncontrolled risk. However, in some cases external dependencies are unavoidable. The product coordinator is typically not making the decisions in these cases, but ensures that all external dependencies are clearly identified, documented and managed.
The successful acquisition and management of resources is a key prerequisite for successful products. Product resources typically include money (budget), people (internal or external), consumables and materials (finished goods, raw materials), capital assets (space and accommodation, tools, equipment, plants, and machinery) or intangible assets (methods, skills, software).
Internal resources are coming from within the own organization and require some for of allocation or negotiation to be accessed. External resources are usually acquired via a procurement process, as discussed in the next section.
Regardless of whether resources are internal or external, a key question is usually capacity:
- How many developers with a certain skill do you need? For how long?
- How much bandwidth for communication between assets and the back-end?
- How many antennas? With certifications for which countries?
Consequently, capacity planning is an important task. For many resources like hardware and software, external sourcing will be required, which is discussed in detail HERE. For people (developers, engineers, etc.), capacity planning is usually required before the question re internal vs external sourcing can be answered. Agile methods are very good at fine-grained capacity planning (e.g. using velocity as a measure of how much work can be completed in each sprint). However, such a fine-grained, bottom-up approach will usually not work for planning the required capacities for a large-scale, multi-workstream project. Instead, it makes sense to apply a top-down approach, which initially will focus on teams and team capacities. This approach relies on the experience of project managers, and often results in a 'design to budget' type of approach - which again the agile method is ideally suited to support.
AIoT products usually require a variety of resources and technologies, including development resources, software and cloud infrastructure, engineering services and potentially manufacturing capacities, telecommunication services, etc. Defining and implementing a suitable sourcing strategy will be key to the project success. Aligning the sourcing strategy and timelines with the development schedule will be challenging. Because this topic is so important, Ignite AIoT is devoting a dedicated section to it, which can be found HERE.
Cost management is a key function of the product coordinator, usually consisting of cost estimating, cost budgeting and cost control. From an AIoT point of view, cost estimation is the most AIoT-specific part. AIoT cost estimation must combine back-end software (custom or COTS) cost estimation, embedded hardware and software cost estimation, IoT network cost estimation and last but not least an estimation of the costs for AI development.
Unfortunately, there is very little research available which would help here. A report from Business Insider is suggesting a cost breakdown for average IoT projects. If you combine this a rough estimate for costs attributed to AI development and the rule-of-thumb assumption that the initial project cost will usually be 20-25% of a 5 year Total-Cost-of-Ownership, then an AIoT cost breakdown might look as in the figure above (deliberately shown without percent numbers).
AIoT Risk Management must identify and assess risks and mitigate potential threats. In order to better understand an AIoT-specific approach, a dedicated section on AIoT Risk Management can be found HERE.
Quality Management (QM) helps ensuring that the product meets the quality standards expected by customers, as well as any regulatory requirements. The QM process can usually be broken down to
- Quality Assurance: the process of monitoring the software engineering processes and methods to ensure proper quality of the software
- Quality Planning: defines the quality attributes the project output, and how those attributes should be assessed
- Quality Control: examines, analyzes and reports the project's progress and conformance with the quality requirements
The focus of the Ignite AIoT framework is currently on Verification and Validation, which supports Quality Control. Since this is a complex and important topic in the context of AIoT, it has its own dedicated section which can be found HERE.
Communications & Stakeholder Management
AIoT products often have very complex networks of stakeholders. Internally, many different parts of the organization have different stakes in the project, including senior management, the affected business units, legal, purchasing, etc. Externally, AIoT projects often have to deal with complex partner networks, which can be a strengths but also a challenge. Best practices in this space include:
- Stakeholder identification, e.g. using stakeholder network analysis tools
- Stakeholder classification, e.g. using a power/interest grid
- Define stakeholder management strategy to increase the support and minimize negative impacts of stakeholders
- Plan and execute stakeholder communications
Overall Product Coordination
And finally, all the above tasks must be coordinated across the entire product organization:
- Develop Project Charter: Lays out the goals of the project as well as the business case - should be closely matching the AIoT business model
- Develop Project Management Plan: Defines the how the project will be managed - should cover all of elements defined HERE
- Direct and Manage Project Work: Must be closely aligned with the agile process
- Manage Project Knowledge: Could be a Wiki structured along the Ignite AIoT templates
- Monitor and Control Project Work: Must include general-purpose project management as well as the agile development organization
- Perform Integrated Change Control: Should focus on those areas which require changes to the setup of the agile development organization
Authors and Contributors
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.
RALPH NELIUS, DEUTSCHE POST AG
Ralph Nelius loves to build great products in agile teams. After various stints as a software engineer, consultant and enterprise architect, he now works as a product owner at Deutsche Post on AI topics.