IoT service design life cycle
Many IoT service owners make the mistake of believing that the IoT service description and the technical components are sufficient for defining an IoT service. However, for a sustainable, profitable service, the commercial, operational, and technical layer specifications must be defined and recursively addressed as the business evolves.
The first step in creating an IoT service is to define an issue/challenge or business opportunity that can be solved by the service. The next step is to clearly specify the service so it can be understood internally by the service organization and externally by customers and collaborators.
Commercial : Defines the service and specifies how it will be sold, detailing profits, forecasting volumes, and contractual terms and conditions (T&C)
Technical : Specifies the technical implementation of each component and their interlocking interfaces with sufficient detail for life cycle management
Operational : Specifies how the service will be operated and maintained according to the forecasts from the commercial layer and technical layer
IoT service specification
As stated previously, the focus for the design of many IoT services is on technology, but this is incorrect. The first step is to define the service from a non-technical perspective. Customers may be experts in their industry vertical or come from a non-technical (IoT) background, so the service must be explained in their terms. The service description from the commercial layer should be a mandatory input for the technical layer as it describes the “what.” The technical layer contains the solution documents describing “how” the service is implemented. When the technical description is available, the operational layer can be defined outlining the service delivery organization, with associated processes and tools required to operate the service. You cannot define how a service will be operated (operational layer) until you understand the components that should be operated (technical layer) and the budget available (commercial layer).
A Service Approach
The complexities of how the service is implemented should not be of concern to the customer. This puts more risk on the service provider compared to traditional product sales, but it also creates new opportunities. One advantage is that if the customers aren’t aware of what internal components are used in the service, the components can be changed without requiring the customers’ consent, and this simplifies life cycle management.
For example, IoT meter reading services are becoming widespread, offering the collection of meter reading data to energy providers. The core business of the energy provider is not meter reading data; it is producing energy. Receiving meter data is the issue they want to have solved. Contracting the IoT service means they no longer need to be concerned with the complexities of how data reaches their billing systems, just that it arrives on time. The service approach means the IoT provider can replace IT components, such as the databases, to reduce costs without consulting the energy company. Operation centers (that perform the daily activities required to maintain the service) can be consolidated or moved to lower-cost locations without impacting the service or consulting with the customer.
Commercial Layer: Service Definition
A commercial service is defined by the contractual documents signed between the service provider and the customer. In this section, I will outline the documents that are essential for a clear, contractually binding IoT service.
I will not discuss the sales material, which is part of the commercial layer, as this is service-specific. The majority of IoT services solve a problem that improves the top-line, reduces opex, or improves customer experience. These benefits must be explained clearly in the sales material. Often there can be a tendency to over-complicate the material, but my message is to keep it simple.
Service Description
The service description for IoT offerings is a contractual document that specifies service features, the boundaries of the service and how it is accessed. The service owner should approve the document and ensure it is maintained to reflect the introduction of new features and remains consistent for all customers. A careful balance must be drawn between making the service documents too detailed or too general without enough content. Too much content will increase the sales cycle, resulting in service owners getting bogged down with implementation details. Not enough will result in dissatisfied customers because of contractual misunderstandings.
IoT offers the possibility of collaboration between industries that would not normally interact. Therefore, it is critical that the service description is written using terminology associated with the industry vertical that will be understood by all stakeholders. Another frequent error is to write a service description as a feature description, but a true service model will make references to the delivery and operations of the service.
Description of Services
Section | Description |
|---|---|
Features | This section contains a high-level description of the features and functionality currently available. There can be a tendency to include technical implementation details in a service description, but this should be avoided. If necessary, the service components can be described in a generic fashion, but product names must be avoided. If the names of products that are used to implement the service features are included, it limits the flexibility of service providers to replace products during life cycle management. All attempts should be made to provide enough detail to instill the customer with confidence in the service while at the same time hiding the complexity. Note: If a product is well-respected in the industry (such as IBM Watson), it can be beneficial to state it is being used but do not include the name in contractual documents. |
Initial Setup | This section contains the detailed steps required for the customer to get connected to the service for the first time. It can be as basic as registering a user, or more complex such as setting up a leased line for a secure VPN. The level of detail should provide no more than an outline of the activities required by all contributors. The customer must have a clear understanding of their activities and commit to executing these in an agreed timeline. Delays in execution of the initial setup can be critical as revenue is not generated until sign-off has been received from the customer. |
Service Access | This section contains a high-level description of how the service is accessed after the acceptance criteria has been met and the service goes live. It is important that this description has enough detail to enable new users to access the contracted features without requiring support. If the material does not have enough detail, it can result in operations being required to fill in the gaps and increases costs. For example, a clear specification of service reports and how they are accessed must be made available. |
Service Boundaries | This section describes the service demarcation points. In other words, it specifies the technical limits of the key performance indicators (KPIs). For example, if the service is accessed over the Internet, the demarcation point could be defined as the router permitting access to service nodes. If there is an Internet failure but the router is active, it would be considered a failure outside the demarcation point of the service. |
Service Security | This section describes the security measures implemented (without implementation details) providing a clear definition of responsibilities regarding security. |
Optional Services | It is advisable to include a section offering add-on services and customizations. The implementation of these should be considered on a case-by-case basis and can become a useful additional revenue stream. |
Service Level Agreement
The service performance is measured by the KPIs defined in the service level agreement (SLA) . The key question for the service owner is, “What measurements will make the business successful?” Care needs to be taken that only KPIs that are important for the customer will be defined in the SLA. Other KPIs may be defined for internal use and never exposed externally. Where possible, the measurements and resulting KPIs should be collected and generated automatically. Manual generation can be costly and prone to error. These points are illustrated by the example of a meter reading service. Normally, KPIs are defined as how many readings (or percentage of readings) are available for processing at the end of each calendar month. If the SLA requires that 90 percent of readings be available the 1st of each month, the service provider should only report the performance at the end of each month. Measurements can be taken weekly to monitor progress and take corrective action (if the process is automated), but these are for internal use and not customer reporting. It may be interesting to measure daily performance to increase efficiency, but it should not be a KPI specified in the SLA. Other measurements such as how many readings are failing should be monitored, but again these are only for internal use. It is advisable to keep the KPIs defined in the SLA as high level and generic as possible. If they have a detailed specification, it can present additional challenges in terms of controlling how they are calculated to ensure compliance.
Another aspect to consider is to only define performance indicators that you can calculate, measure, and control. If the cellular network goes down, that will be outside the control of most IoT service providers. Therefore, you do not want performance measurements to reflect this.
Appendix B has an example SLA that can be used as a template.
Reporting Service Performance
Where possible, performance reporting should be available on a dashboard, and the production of the reports should be automated. If measurements and reporting cannot be automated, it can prove too expensive as the service scales in terms of resources and cost. A dashboard should be available to provide KPI measurements to reduce the quantity of reports and presentations toward the customer. As customers will always have access to the material, they can consolidate the reporting in the format they require and present it to their stakeholders. This is a method of pushing service operational activities towards the customer to reduce operational costs.
Customized reporting can be an important add-on service and is often given away for free. It is important that the service description has enough clarity to ensure the customer cannot request customized reporting free of charge. Sample reports with the reported KPIs should always be an appendix to the SLA.
Fees and Payment
One of the main advantages of the AaS model is that it provides a steady revenue stream rather than the peaks and troughs that can occur with product sales. This simplifies the financial control process that is linked to the sales forecasts.
The main issue new IoT services face is to ensure a constant positive cash flow. Therefore, the customer payment terms should be linked to the payment terms of externally contracted services. For example, if the IoT service uses a cloud infrastructure service where payment is expected within 90 days, then the customer contract should have a payment period of less than 90 days.
It is always best to incorporate an initial startup fee, but this should not be a one-off payment due when the acceptance criteria has been fulfilled. It is better to define checkpoints that result in payments as the service installation progresses rather than waiting until final acceptance.
Another consideration for fees and payment terms is that IoT AaS business models imply a partnership with the customer. If the customer device volumes grow, their business is growing, and more revenue is being generated for the service provider. Therefore, the initial fees and payment terms should be agreed on with an approach to promoting growth, volume discounts, and so on. (See Chapter 4 for more information on commercial management.)
Acceptance Criteria
Acceptance Criteria
Criteria | Description |
|---|---|
Technical acceptance | A series of technical test cases to ensure all technical components are configured correctly. |
Organization acceptance | A checklist to verify the service owner and customer operations understand how they should interact. It checks governance and working practices between the organizations are clearly defined and understood (may include training and certification). |
Checklist | A final checklist to confirm all business, operational, technical, and training activities has been completed, with all service-relevant documentation released to the customer. |
I was hosting a workshop with a multinational company in Germany, and they asked if they could review our acceptance criteria to check it met with their standards. They needed to ensure the service would be tested sufficiently before exposing it to their end customers. They were surprised to find the acceptance criteria included an audit and certification of their organization. They expected I would give access immediately as this was when we could start generating revenue. However, I explained an AaS business model has additional challenges. I wanted to ensure that they understood the service, how to get maximum benefit from it, and how to operate it successfully. Revenue is generated when the service goes live, but that is also when operational costs kick in. Customers who don’t understand the service can cause additional tasks for operations because of an increase in the volume of questions, erroneous requests, or fault reporting due to misunderstandings. Each request results in an additional cost for operations and therefore will affect service profitability. Initially, this customer was quite taken aback by my approach, but it turned out to be a positive development as it increased their confidence in the service.
Business Strategy
The business strategy defines how to generate profits and is often the first point of failure for IoT services. Business strategies often include a market analysis, a marketing plan, a GTM strategy, deal types, and so on. This can be a never-ending library of analysis documents, most of which will add little value in making the business a success. Startups should keep their business strategy simple. Define the revenue streams and calculate the expected revenue by forecasting the growth plan. They should understand the cost drivers and forecast their evolution by maintaining (or increasing margins) as the service evolves. The service owner should review what is required for an effective business strategy and produce only what is necessary. As the service scales, the strategy will become more complex, but the fundamentals won’t change.
All IoT business strategies should include a definition of the service revenue streams and the cost drivers, both of which are aligned with the sales forecast.
Service Revenue Streams
Revenue streams will be service-specific but should center on the core offering of the IoT service. What is solved by the IoT service? That is the principle revenue stream that is linked to the devices (or the data generated by the devices). This will be linked to the forecast and enables calculations to be made on the available income. It is input for other components in the business strategy that define how the service should grow in terms of features, devices, and customers. See Chapter 4 for further details on revenue streams.
Cost Drivers
There can be many cost drivers depending on the type service, but there are common trends in IoT services. The major costs are a service road map, operations, device manufacturing, service deployment, and cost of sales.
Cost drivers: service evolution
- Drop 1: A new data center will be deployed because of new regulations or latency issues.
This results in a major new cost because of a requirement to implement a new site. The cost driver is not only the expense of implementing a new site; it should include the recurring costs due to the operational support required, field services, and so on.
There is an operational cost reduction between Drop 1 and Drop 2 because of automation.
- Drop 2: New features will impact operations.
The increase in operational activities is because of an expected growth in the volume of trouble tickets. Additional manual monitoring is required, as automated monitoring is not currently available for the new features.
Drop 3: New features will be implemented, and operations estimate there will be no increase in operational costs apart from deployment costs (not every new feature should result in an increase in operational costs).
Service Road Map
These are usually R&D costs, but in an AaS model it is a little more complex. The service road map will have two main drivers (customer requirements and the market conditions) resulting in feature proposals that require careful management. The evaluation process must be streamlined. It can be time-consuming in terms of costs and resources because of the analysis before acceptance/rejection (see Chapter 4 for more on requirements management).
A frequent error in estimating the cost of new features is to consider the implementation costs without considering the implications to operations. The cost of operating new features will be recurring and consequently can have a considerable impact on the business model. Another error in cost calculations is to omit the expected reuse of the features by multiple customers. Each new customer feature should become a central asset that can be resold to other customers. There may be no business case for developing a feature for one customer, but a forecast should be made of the expected reuse, and the development costs can be split across multiple customers.
Operations
The major transition many companies undergo while implementing IoT services is the deployment of an AaS business model. This requires that they transform an existing operations organization (or implement a new one), which can result in higher operational costs than those associated with a product/capex model.
Cost drivers—operations
Operations is a major cost for IoT service models, but its calculation should not be related directly to the number of devices or even the number of customers. The operational cost will be related to the number of activities the operations team is required to perform because of internal requests, customer requests, support activities, internal maintenance, and so on.
Device Manufacturing
The majority of IoT service companies will have the production of devices outsourced, so this becomes a numbers game. As the volumes ordered increase, the manufacturer should reduce costs per unit, enabling an increase in margins. The value of the device increases with the value of the data; therefore, the business plan should show an increase in profits per device as the service scales.
Service Deployment
Industry trends for Internet services have evolved to the stage where the consumer is expected to install the device (sometimes with remote support). This is facilitated by reducing the complexity required for deployment and providing sufficient assistance via a service desk to offer support in case of issues. The aim of the service provider should be to reduce costs by outsourcing deployment activities to customers. The downside can be that revenue is not generated when devices are ordered or delivered. Usually payment is received when devices are active in the service central database, and (in this scenario) that depends on the customer. The upside is that it can often improve customer satisfaction. Customers feel the relationship is more of a partnership if they have control of the deployment process. Rather than feeling like a seller-vendor relationship, the customer becomes an active participant and contributor to the service.
Cost of Sales
Including cost of sales here may be a surprise to some readers. Many IoT startups will have a sales organization consisting of one person possibly performing multiple tasks. However, the planning of the sales budget should not consist solely of staff costs. There will be a travel budget, production of sales material, and most importantly service discounts. The service discounts are introduced by many IoT startup services to capture new customers and promote device growth. They can take the form of reducing revenue share percentages or the cost per device. It is usually more attractive in IoT AaS models as the revenue can be recovered over the full period of the contract. Commercial management should consider this in all calculations, balancing the short-term goals of increasing the customer base with the long-term goals of recurring revenue.
Technical Layer : Service Implementation
In this section, I will outline the technical documents required for IoT services. These documents should be mandatory, as they enable service life cycle management and differentiate a proof of concept (POC) from a commercial service. They must always reflect the current implementation and be of sufficient quality and detail for product managers, solution architects, and engineers to reference during the deployment and commercial life of the service for each customer.
Solution Description
The solution description is written by the solution architects (usually) from the research and development (R&D) and the DevOps organizations. It describes how the service functions are designed according to the specification in the service description. The solution description details the technical components, their interfaces, and a high-level specification of their configuration. Normally, it will be reviewed by product management and the operations organization to agree on cost, implementation, and deployment methods. It will then be used by product management during the new requirements evaluation process and by operations during the implementation of new features and troubleshooting.
Level 0, 1, and 2 architecture descriptions
Physical architecture
Functional components
Interfaces and messaging flow diagrams
It can be shown to customers or partners but should be restricted to show only external interfaces and integration points.
Design Documents
The design of each IoT module may consist of high- and low-level design documents. High-level design documents can be omitted if there is sufficient detail in the solution description. High-level design documents will consist of interfaces and flow specifications, whereas the low-level design will consist of implementation details such as parameter settings, and so on. Operations will use low-level design documents to perform troubleshooting activities and check that parameters are set according to specification.
It should be noted that many functional components will be implemented across several modules. For example, there should be design documents for the security solution, which is implemented in all layers of the architecture and usually impacts all modules.
Operations Layer : Service Delivery and Operations
In the section I will describe the documents required to specify clearly the service delivery and operations organization including how it interacts with customers. For more details, see the IoT operational framework in Appendix C and the RASCI in Appendix D that can be used as templates for the documents described here.
Operational Model
The operational model described in this section gives an overview of how the stakeholders, organizations, and key players should interact by defining workflows and working practices. An AaS model is not a typical vendor/customer relationship, it requires that all stakeholders contribute to the success of the service by efficient cooperation. This implies that the operational model becomes more critical for the success of the business.
The operational model may not be necessary for startups but will become key for services as they scale in terms of customers and geographical location. The operational model used in many IoT services consists of a service management function and an operations function managing multiple customers following an ITIL/managed service model. The operations organization includes first-level and second-level support, as well as emergency management that follows strict guidelines and processes for managing operations. The purpose is to serve multiple customers using the same processes that become automated, creating an economy of scale.
Service management: Governance on a management level including contract management, service scope management, and service performance reporting
Service assurance: Defining how the organizations and processes are implemented to ensure the service is delivered according to the SLA
Demand management: Detailing the operational flow for the organizations that implement internal or customer requests
To create maximum efficiency, the customer must understand the operational setup and the scope of the service. In a vendor-customer relationship, the customer will try to maximize service received from the vendor. However, an AaS model should be considered more like a partnership where a balance must be reached to provide a service where both parties maximize the benefit and the service provider is not punished by handling requests outside the scope of service.
Responsibility Matrix
If written well, the responsibility matrix can be a useful tool for service organizations, but too often that is not the case. It is a difficult balance to strike between making the RASCI too high level and too detailed. I advocate “less is more.” It is best to have less detail and allocate high-level responsibilities than spend time discussing trivial minor activities. Too often one can encounter RASCI documents with hundreds of entries, and once approved, they are filed away never to be used again. The other extreme is equally bad: if the service organization is constantly referring to a RASCI document to understand roles and responsibilities, then it is quite likely that there are other organizational issues that need to be solved.
A good test for the quality of a RASCI is to review it several weeks apart. You might be surprised to find that your own interpretation of each entry in the first review is radically different from the second review. If that is the case, imagine how others will interpret it. You need a rethink!
Procedures Manual
The procedures manual is a structured template containing the practical details of how the customer and the service provider organizations will interact daily to facilitate smooth delivery of the service. During the customer initiation phase, this document will be completed to define the customer contact details. It will also detail the agreed governance procedures between the customer and service owner, including escalation procedures and reporting, and so on.
The process defining how the delivery organization will operate must remain consistent for each customer to facilitate scaling. However, the specific contact details of delivery managers, and so on, will vary from customer to customer.