Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Business Viewpoint

Business Viewpoint

The Business Viewpoint of the AIoT Product Architecture is building on the different artifacts created for the Business Model. In order to refine and validate this information, site surveys and stakeholder interviews should be performed. The definition of personas helps ensuring all key stakeholder perspectives are taken into consideration. The high-level vision and requirements are then captured as epics. From there, a story map is created to capture all high-level requirements. This is the main interface between the Business Viewpoint and the Product Viewpoint.

Business Model


Site Surveys and Stakeholder Interviews

In order to capture and validate requirements, it is common practice for IT projects to perform stakeholder interviews. This should also be done in case of an AIoT product/project.

However, an AIoT project is different in that it also involves physical assets and potentially also very specific sites, e.g. a factory. Requirements can heavily depend on the type of environment the assets are deployed in. Also, usage pattern might vastly differ, depending on the environment. Consequently, it is highly recommended for the team responsible for the product design to spend time on-site and investigate different usage scenarios in different environments.

While many AIoT solutions might be deployed at a dedicated site, this might not be true for AIoT-enabled products. Take, for example, a smart kitchen appliance, which will be sold to private households. In this particular case it can make sense to actually build a real kitchen as a test lab, to test usage of the product in a realistic environment. Or, in the case of our Vacuum Robot, different scenarios for testing the robot must be made available, including different room types, different floor surfaces (wood panel, carpet, etc), and so on.

Personas

Personas are archetypical users of the product or solution. Often, personas represent fictitious people which are based on your knowledge of real users.

The Business Viewpoint should define a comprehensive set of personas which help with modeling the product features in way that takes the perspective of different product users into consideration. By personifying personas, the product team will ideally even develop an emotional bond to key personas, since they will accompany them through an intense development process. A persona does not necessarily need a sophisticated fictitious background story, but at least it should have a real-world first name and individual icon, as shown in the example below.

AIoT Personas

Epics

It is best practice in the agile community to break down a larger body of work into specific work items by using a hierarchical approach. Depending on the method applied, this hierarchy can include themes, epics, features and user stories.

The AIoT Framework is assuming the following hierarchy:

  • Epic: A high-level work description, usually outlining a particular usage scenario from the perspective of one of multiple personas
  • Feature: A specific feature to support an epic, which is further broken down into user stories
  • User Story: short requirements written from the perspective of an end user

Depending on the complexity of the project and the agile method chosen, this might have to be adapted, e.g. by further adding themes as a way of bundling epics.

When starting to break down the body of work, one should first agree on a set of top-level epics, and ensure that they are consistent, not overlapping, and covering everything that is needed.

Story Map

Example: Initial Story Map