Previous topic

Project Phases

Next topic

Sales Model

Design

The design process aims at analyzing the application integration needs, designing the information architecture (IA), and creating comprehensive requirements for the development phase.

Purposes

The design process involves the product manager and solution architect roles. On completion of the design steps, they create documents required in the development process:

  • Sales model

  • Resource model

  • User scenarios

  • Information architecture

  • Wireframes of all UI screens

Prerequisites

Leverage the effect of this document by complying with the following prerequisites:

Input

Will, as the product manager, starts with gathering a description of the cloud application that he is going to integrate with the OSS/BSS platform. Key points:

  • Which services and sub-services are you going to provide and sell?

  • Which services does the application provide per customer and per user?

  • Which configuration sets can the providers offer to parameterize resources acquired by customers?

  • Does the application need services from other applications? For example, domain registration or anti-virus.

  • Are there other applications your application can integrate with?

Sales Model

A sales model usually contains the following minimal set:

  • Services for sale - offers

  • Included resources and add-ons

  • Resource types and service templates

  • Service plans

Get more details about this step in the Sales Model document.

APS Resource Model

Build Resource Model

A resource model must be closely related with the sales model. The model design process is described in the APS Resource Model section.

APS Documents

The documents that help understand and build the application resource model:

Outcome

  • A resource model diagram as demonstrated in the APS Resource Model document.

  • A detailed description of each service including properties and operations to be implemented.

  • A corrected sales model as demonstrated in the APS Resource Model document for various resource models and represented by:

    • A service template with application resources

    • A service plan with resource rates

More Details

Get more details about this step in the APS Resource Model document.

Requirements for the Solution Architect

Will formulates design requirements for his colleague Roger, the solution architect of the project. The requirements are contained in the following documents designed at the previous step:

  • A description of the application services to be delivered to customers

  • A sales model presented by the service template and service plan with respective descriptions

  • A resource model with a description

The designed sales model and resource model allow Roger to proceed with the following steps:

Design activity

Outcome

Identify customer personas that are consumers of the application services
- List of a administrative personnel and service use employees
- Detailed description of each persona

Identify integration points of the application on the OSS/BSS platform

Persona-based list of touchpoints with a brief description of the communication area where these touchpoints are used

Design user scenarios
Approved User scenarios, separately for each persona:
- Scenarios for Samantha in CCP
- Scenario for Emily

Design the information architecture

Tables and diagrams presenting details of UI screens and APS types

Design UI wireframes

Approved UI wireframes with interaction calls of backend and frontend methods

Personas

The platform must have a simplified customer team that will manage and consume application services as described in the Customer Personas document:

  • Samantha: the SOHO owner and simultaneously the administrative staff

  • Emily: the SOHO employee that is the typical consumer (service user) of an application resource

Get more details about this step in the Customer Personas document.

Integration Points

In the considered OSS/BSS platform, there is a predefined set of integration points that Roger can use in his project. Analyzing the sales model, resource model, and the list of available integration points, Roger defines the set of integration points his application needs to implement.

User Scenarios

The User scenarios must be oriented towards the personas defined earlier. Roger gets familiar with the typical Customer Scenarios to develop user scenarios for his application. The scenarios must walk the respective users through the integration points defined at the previous step.

Get more details about this step in the Customer Scenarios document.

Information Architecture

In this step, Roger compiles the data gathered and built at the previous steps in the format suitable for developers as described in the Information Architecture document. Preferably, it should be a set of tables and diagrams with detailed description of all APS types involved into development.

Get more details about this step in the Information Architecture document.

Wireframes

Roger analyzes scenarios and designs a wireframe for each step. Refer to the Frontend documentation and primarily to User Interface to get description of the controls Roger can use in the custom UI.

For more detailed descriptions, refer to:

Requirements for the Integration Developer

Roger sends the following documents designed in this phase to Kevin, the project developer, who will start the development process.