Throughout the previous chapters in this book, we’ve focused primarily on the technical aspects of designing and deploying a Microsoft Azure-based IoT architecture solution. But we also touched on business aspects as we described some of the potential use cases. By now, you might still be wondering how to determine where IoT will be most beneficial in your organization and how to build support for such projects.
Defining and gaining sponsorship for these projects often incorporate “design thinking,” a methodology that evolved since the early 1990s to become widely adopted in innovative technology projects like IoT initiatives. In 1992, Richard Buchanan connected design thinking to innovation in a work titled “Wicked Problems in Design Thinking.” David M. Kelly founded the design consultancy named IDEO at about the same time and based its processes on design thinking concepts. Today, many major universities teach design thinking in curriculum focused on techniques used to drive innovation.
In this chapter, we’ll cover identifying the right initiatives and dig deeper into techniques used to prioritize projects and maintain an agile approach to problem-solving, prototype creation, and testing. We also cover building support for the project as you move from prototype creation and testing to full-scale implementation.
Identifying the right initiatives
Moving from prototypes to implementation
Some final thoughts
As we cover identifying the right initiatives, we’ll describe how the design thinking approach can help you during this stage in your project.
Tip
If design thinking is a new approach to you, we hope that you’ll gain a basic understanding of the approach by reading this chapter. Design thinking is widely used today in a variety of technology projects, especially in innovative software development and deployment. In addition to IoT projects, you’ll likely find it practiced in the development of artificial intelligence applications and blockchain-based solutions. You might consider taking online or in-person courses to augment your own understanding given the popularity of design thinking as an approach in many technology areas.
Identifying the Right Initiatives
Observation and research
Problem definition
Ideation
Prototype creation
Testing
Implementation
Identifying the right initiatives and solutions to build usually consists of the first five of these steps, beginning with observation and research. This first step seeks to gain an empathetic understanding as to how work is performed and the challenges that are present. It is a prelude to identifying problems and potential opportunities to do this work better in new and different ways. Workers are interviewed or observed, and sometimes developers who will be assigned to the project are also immersed into the experience.
Other research can be initiated that gathers information on internal corporate goals and initiatives, similar initiatives that are in progress at competing companies, and emerging trends in the industry at large. Some sources of places to gather this intelligence include financial earnings statements, presentations provided by companies to investors, trends and case studies described in industry trade journals, and presentations made by experts and insiders at industry trade conferences.
The problems that exist are then defined and framed. We consider the points of view of various potential stakeholders regarding the nature and scope of these problems. Our previous findings can help us create a list of compelling needs and problems that will fuel our brainstorming attempts to identify potentially innovative solutions.
During the ideate phase, we might use a variety of techniques to identify potential solutions and evaluate them. We seek a wide diversity of ideas in problem-solving. We also begin to prioritize which ideas are worthy of prototype development.
The creation of prototypes makes solutions tangible for stakeholders. The development of storyboards, other visuals, or physical builds using technology components are pursued. Multiple solutions to the same problem might be tested, explored, compared, and refined. An important goal is to succeed or fail inexpensively and quickly during the prototype and testing phases.
When testing occurs, stakeholders (including users of the solution) evaluate prototypes and provide their feedback. Problems become better framed, and the most likely viable solutions become better understood. If testing proves successful, we might then move forward with a full-scale implementation.
Implementation of a production-ready solution occurs once we’ve determined that we are ready to put the proposed solution into full-scale operation. The implementation phase requires additional planning and designs for reliability, availability, serviceability, and security. Often, a pilot or operational prototype is developed at smaller scale with these requirements in mind to get a better picture as to the true cost of the final solution. A pilot can also help validate technical feasibility. A roadmap to full implementation might be required with identification of proposed costs and estimated value of the solution at various steps along the way in order to gain budget approval.
Next, we’ll take a deeper dive into each of these phases with practical guidance on how to execute each phase.
Observe and Research
We begin to determine the problems that need to be solved by observing top-of-mind challenges within the lines of business and opportunities for success. We also explore emerging threats external to our company or organization. At this first stage, we are looking for potential stakeholders for projects who possess visions of what the future might look like.
To get our arms around the state of business processes, we document the current environment and interactions that take place. As we do this, we seek to identify opportunities to improve efficiencies, quality of goods, quality of services, quality of production, and/or safety. We also analyze any tools and technologies used in these processes and document how workers use information and respond. We begin to understand the importance of such tools and technologies in successfully executing necessary business processes and uncover any vested interest or reluctance to change that the users might have.
A description of normal activities and situations that users encounter
A description of abnormal activities and situations that the users encounter including the frequency of abnormalities and the impact on the business
A description of feedback from systems in response to normal situations
A description of feedback from systems in response to abnormal situations
A description of how users know what appropriate actions to take during abnormal situations
Critiques about the amount and level of detail in information that is provided
Critiques about the complexity of response required in abnormal situations
Suggestions for process and system improvement
In addition to interviewing individuals, we might simply watch their actions in normal and abnormal situations, including their interactions with co-workers and systems. We might also capture these interactions through video recordings that then can be used for further study and to augment the written record of our observations.
When we document the problem solution process, including current activities and outcomes, we can present the process in the form of a journey model. A typical model that might lead to an IoT project begins with a description of how workers are informed of the status of a specific process and the problems and abnormal situations that might impact that process. Workers then decide what appropriate action is necessary if a problem is confirmed, perform some sort of action to fix the problem, and see a response confirming that the remediation action has occurred.
If the focus is only on improving existing internal processes and/or meeting current needs, we might lose sight of innovations that are happening elsewhere. Interviews with line of business leadership are often a great place to gain a better understanding as to what competitors are up to since having a current understanding of innovative initiatives in their industry is usually part of their day job.
To gain a more complete understanding of external influencing factors, a PESTEL analysis might be performed. Such an analysis weighs political, economic, social, technological, environmental, and legal factors. These factors can drive increased momentum toward more automated IoT solutions.
Relevant political factors helping to provide momentum might include tax incentives for modernization. Economic factors in play could include consideration of increased labor costs and the need to maintain or grow margins. Social factors might be driving the workforce to gain technical skills that rely on IoT-based solutions. Technological advancements could be driving a need for faster innovation to stay competitive. Environmental factors could include demands for sustainability and the need to reduce waste in processes. Legal factors might include the introduction of new regulations and laws related to safety and products.
You might determine that some independent research is in order, especially as competitors begin to enter new business areas and PESTEL-related factors influence the need for IoT solutions. Where can you find such information?
Start with quarterly financial statements and presentations to investors. Pay attention to IoT-related vision statements by leading executives and how they respond to business analysts’ questions on earnings calls that could lead to such projects. Be on the lookout for statements regarding the impact of competition and PESTEL-related drivers that are discussed during these calls.
You should also research industry and government sources of information that can provide insight into additional drivers. Pay special attention to conferences where other similar companies and organizations are speaking about their IoT initiatives and attend those conferences. Though technology vendors sometimes present compelling use cases, presentations of initiatives by business stakeholders within similar companies and organizations to your own can provide you with a great deal more insight into challenges in implementation and the true nature of the business drivers and benefits obtained. Attending such industry and technical conferences can help you determine where you should focus your own initiatives.
Problem Definition
In the previous phase, we began to uncover problems that could be worth solving and that could drive IoT initiatives. In this phase, we better define these problems and look at them through various points of view. We’ll also begin to understand what each group sees as benefits in solving these problems. And we begin to prioritize the importance of solving the defined problems.
For each targeted group, we should fully understand their business goals and any tasks and solutions in place to achieve those goals today. As we gain that understanding, we should document limitations and inefficiencies that are present. We will also want to gain an understanding of each group’s desire for change and any alternative solutions currently under consideration.
In some situations, we might uncover problems that are exacerbated by inadequate skills or extraordinary physical effort required to overcome current solution shortcomings. Though training might overcome some of these problems, we should also be on the lookout for unusual worker turnover where additional training has not solved problems.
For each group, the perceived value and range of benefits in solving a problem could differ. For example, some might see a problem as one of efficiency, while others might see the same problem as a quality improvement problem. This could lead to a divergence on the vision of what ideal solutions might look like. So, the input from each targeted group might include not only broad benefits from improvement in business processes that solve a specific problem but also benefits that will be personal to each target.
Potential return on investment (ROI)
Time to return on investment/solution
Importance to C-level business leaders
Regulatory requirements
Cost
Risk of deployment in deploying a new solution
Risk of not deploying a new solution
Skills needed/lacking
Culture alignment of potential solution
Device sophistication and availability of needed quality data
You might think that in most organizations only consideration of potential return on investment drives the selection of the most important problems to focus on. However, this is frequently not the case. The time that it takes to get to a viable solution and a positive return on investment can be the determining factor when the window of opportunity for solving the business problem is short, there is a very limited budget, management is exerting pressure to solve the problem, and/or the problem is seen as an extremely dangerous competitive threat.
Sometimes, problems must be solved regardless of the ROI. For example, C-level executives might have issued forward-looking statements to investors that promise delivery of a business solution built upon IoT. Regulatory requirements might also drive the need for creation of an IoT solution to address mandates present in some industries.
Several of these factors might cause us to deprioritize certain initiatives. A project might be viewed as too costly or risky, regardless of the ROI that might be obtained. Skills could be lacking to implement or use the proposed solution, and the culture in the organization might not be ready for adoption of the technology or the solution. There could be issues regarding availability of quality data due to a lack of devices, sensors, or other infrastructure.
In many companies and organizations, multiple considerations in combination impact the determination of priorities in project funding decisions. Identifying that mix of prioritization considerations during this phase will be critical in helping you to determine which problems to focus on solving.
Capturing and prioritization of initiatives
Initiative | Stakeholder(s) | Metrics Required | Data Status | Business Impact | Priority |
---|---|---|---|---|---|
Minimize downtime | VP Manufacturing | Uptime, line rate, operating conditions | Need additional sensors on lines | On-time delivery, increased revenue | 1 |
Minimize rework | VP manufacturing, VP quality | Accepted/rejected products | Need additional sensors, data quality issues | Decrease cost of goods sold by optimizing manufacturing process | 2 |
Minimize warranty claims | VP quality | Production line, rate of return | Gather production lines and worker data | Decrease set-asides covering warranty expense | 3 |
In this example, the company is prioritizing efforts that will increase revenue. Cost containment might also be important but is of secondary concern. So, minimizing downtime on the production lines is listed as the top priority, though we’ll likely need to add sensors to the lines or purchase new equipment to gather the metrics that we’ll require.
Ideation
Ideation is the start of solving the identified problem or problems in the initiatives. In IoT initiatives, a goal of this phase is to gather many solution ideas and determine a solution worthy of developing a prototype that will then be tested for validity in front of stakeholders and interested parties.
A variety of techniques are commonly used during the ideation phase. Often, the ideas are generated through facilitated discussions. Brainstorming techniques can be used to bring about a free expression of ideas. The focus is on gathering a large quantity of diverse ideas. No criticism of an idea or idea ownership is allowed. Group members in the exercise are ideally a heterogeneous mix of individuals (not just experts). Everything is written down and captured.
The facilitator has the important role of guiding the discussion. They might occasionally solicit different points of view intended to drive consideration of new and diverse ideas. A best facilitation practice is to ask open-ended questions. The session might begin with the question, “How might we solve the defined problem?” A question sometimes asked to spur insightful discussions is, “How might our toughest competitor solve the same problem?”
Using our earlier prioritized initiatives from our manufacturer example, we would begin by soliciting input on how we might minimize downtime on our production line. During brainstorming, ideas on how to solve this problem can be written by team members on Post-it Notes of different colors, or they might use software-based applications featuring the equivalent of Post-it Notes to share their ideas. Each team member has a uniquely colored notepad so that we can determine where the ideas are coming from (to encourage broad participation) and so that team members can track their ideas as solutions areas are defined.
A sample of some of the ideas that might be gathered in our example scenario includes video training of workers, rotation to different lines during shifts to prevent boredom, automated gathering of assembly line speed statistics, measurement of increased vibrations or abnormal variations in speed caused by equipment problems, and better understanding of bill of materials including quantities on-hand for goods production.
The content on the boards containing the sticky Post-it Notes is usually captured by taking pictures of the results with a mobile phone camera (if an electronic whiteboard application that can capture these results wasn’t used instead).
Note
The application software used for ideation that features the equivalent of Post-it Notes has several advantages. Participants can be in remote locations. Visibility into the notes being written occurs much faster, and deduplication of identical ideas is easier. Such applications can also enable faster classification of ideas and voting among participants.
Brainstorming solutions to minimizing production downtime
Solution Themes | Post-it Note Ideas | Solution Votes |
---|---|---|
Personnel training | Video training, certification, mentoring by supervisor sessions | |
Staffing model changes | Line rotation during shifts, more breaks, more overlap during shift change | |
Automated output metrics measurement | Line rate, uptime, line stoppage reason, total products produced | |
Production line warnings | Vibration levels, speed variation, temperature variation | |
Supply chain shortage warnings | Bill of materials/production planning, supplies on-hand, supplies backordered |
Some of these ideas and solution themes shown here will not lead us toward pursuing an IoT project. That’s ok as the primary goal is to solve the problem at hand, not force fit a technology solution. A vote is taken among the participants regarding the most important solution themes, and that will guide us regarding the next steps to pursue. If IoT projects don’t make the cut, we’ve just determined that funding for developing and putting an IoT solution into production later could be unlikely to occur anyways.
This brainstorming technique used during ideation is also used during other phases when design thinking techniques are used in an agile sprint. We discuss the agile sprint later in the chapter.
Tip
Should all votes count the same? Should everyone vote? At this stage in ideation, usually every vote does count the same and everyone votes. If these alternatives are reconsidered later, you might then give more weight to key stakeholders who can fund the project and the potential users. Prior to this later vote or discussion, you might decide it beneficial to create an influence map that shows which individuals are supporters, neutral parties, and against solving the problem. You’ll also want to note whether they are responsible, accountable, consulted, or simply informed when it comes to solving the problem. Those who are responsible or accountable have the most skin in the game, and their views are particularly important when you determine where to narrow the focus.
Further evaluation of these solution themes generally occurs before the type and scope of a prototype are determined. Proposed solutions are typically broken down into their process steps. Variants in how those processes will be executed are explored. We also document the necessary resources that are available and the resources that we must add for the project to be viable (or indicate work-arounds that might also prove to be adequate).
Let’s assume that “Automated Output Metrics Measurement” received the most votes among the team. Upon further exploration, we see that the way in which needed information is gathered today is through manual input of data into spreadsheets by production line managers. The total products produced is gathered from a counter at the end of each shift. Data regarding uptime and line stoppage reasons is manually input and subject to error based on the skills and attentiveness of the production line manager.
We’ve theorized that a more automated approach to gathering this data will help us increase production since we will be able to fix problems that are occurring much faster. We’ll also eliminate some of the waste that currently occurs because we throw away many of the products produced during production line problems.
As we evaluate the technical capabilities needed, we might decide that additional sensors can help us better measure what is really happening. Alternatively, or additionally, we might also determine that there is an opportunity to introduce cameras and use image recognition on the production line to monitor the line and trigger more immediate actions when needed.
Automated Output Metrics Measurement alternatives
Solution Resources | Pros | Cons |
---|---|---|
Automatic counter, manual entry (current) | No additional infrastructure, training | Inaccurate stoppage times and reasons |
Add only sensors to production line | Gathers actual stoppage time and reasons more accurately | Cost of equipment retrofit, software development |
Add only image recognition to production line | More accurate than manual observations over time, potentially more immediate reaction to production problems | Cost of cameras and software. Need negotiation with union? |
Add combination of sensors and image recognition | Potentially the most accurate, also key to enabling production line warnings | Cost of equipment retrofit, cameras, and software. Need negotiation with union? |
As documented here, the pros and cons of a solution idea for solving a problem is being evaluated for technical feasibility, user desirability, and business viability. Other factors such as adaptability, sustainability, and scalability might also be evaluated.
We might also decide to evaluate each alternative by using more perspectives than simply pros and cons. One way to do this is by evaluating the strengths, weaknesses, opportunities, and threats associated with each alternative in what is often referred to as a SWOT analysis.
SWOT for adding sensors alone in Automated Output Metrics Measurement alternative
Strengths • Gather actual stoppage time • Automated gathering of reasons for stoppage through sensors (more accurate) • A good first step toward improving production | Weaknesses • Cost of equipment retrofit over status quo • Cost of software development over status quo • Still heavily dependent on manual inspection |
Threats • Skills needed to build and maintain • Lots of old equipment present • Competitors are updating their plants with modern equipment | Opportunities • Develop new skills • Replace old equipment with modern equipment • Begin to set the stage of proactive management of line |
You can see that we’ve called out reasons why we might want to go forward with this alternative in the “Strengths” quadrant describing positive immediate outcomes from successful deployment and the “Opportunities” quadrant describing positive longer-term impacts to the company. But we’ve also called out reasons we might not want to go forward with this alternative in the “Weaknesses” quadrant by documenting the perceived shortcomings of the approach and in the “Threats” quadrant documenting the challenges that could impede the project and limit its success.
SWOT for adding sensors and image recognition in Automated Output Metrics Measurement alternative
Strengths • Gather actual stoppage time • Automated gathering of reasons through combination of sensors and images (most accurate alternative) | Weaknesses • Cost of equipment retrofit over status quo • Cost of hardened cameras over status quo • Cost and complexity of software development over status quo |
Threats • Skills needed to build and maintain • Lots of old equipment • Possible union challenge regarding cameras on line | Opportunities • Develop new skills • Replace old equipment with modern • Strongest alternative that sets the stage of proactive management of production line |
We now can compare the relative strengths, weaknesses, opportunities, and threats in the two alternatives. But how do we determine which alternative is the best one for our situation?
Strategic importance
Competitive importance
Feasibility
Return on investment
Time to working prototype and testing
Time to production and return on investment
Scoring of Automated Output Metrics Measurement alternatives
Alternative | Strategic Value | Compete Value | Feasible | ROI | Time to Test | Time to ROI | Total |
---|---|---|---|---|---|---|---|
Adding sensors alone | 3 | 4 | 4 | 4 | 4 | 4 | 23 |
Adding sensors and image recognition | 5 | 5 | 4 | 4 | 3 | 4 | 25 |
The better understanding that one has of the trade-offs, the more likely one is to pick the right prototype creation strategy. Based on the scoring recorded in this table in which we see that one of the alternatives received a higher score, we would likely choose to proceed with the option that both adds sensors and image recognition to the production line.
Prototype Creation
The purpose of prototype creation is to enable testing of the validity of ideas gathered in the previous phase. At this point, we have hypotheses about our potential solution(s) to the problem that we identified. Prototypes can come in a variety of types and sophistication, with the cost and sophistication of prototype creation generally aligned to the degree of commitment to solving the identified problem.
Innovators use prototypes to experiment as they formulate solutions. They expect failures but continually learn through prototyping in the most cost-effective manner possible. They see solution development as an evolutionary process but are not afraid to throw away efforts that early-on prove to be extremely difficult to implement or are impractical in other ways.
Prototype creation sometimes goes through a series of stages. An initial stage might be the creation of a storyboard describing how and what the solution to the identified problem will deliver. How the solution will change business processes might be defined. Needed functional components in the solution are identified.
Mock-ups of the functional components can be created once there is agreement regarding the definitions in the storyboards. These might include versions of the visual interfaces that will be provided. Some of the available technical components might also be used for functional illustration.
A next step could be a technical proof of concept. In this step, we further identify data and integration challenges as well as skills gaps. Up to this prototype development phase, throwing away portions of previous efforts might have had little consequence in the overall cost of creating the solution. At this point, we begin to make a more significant technical investment with the notion that we’ll continue to evolve this prototype over time.
Our technical prototype can be used to demonstrate what the final solution could look like from a functional standpoint. Some also use this effort to determine the operational impact and other potential gaps in the proposed solution.
Testing
During each stage in prototype development, testing is used to solicit feedback from stakeholders and other key parties, especially the frontline users of the proposed solution. We use testing to validate our hypotheses about the value that our solution will deliver. Going into testing, we should have criteria established that define the outcomes that we are expecting to see if our hypotheses are correct.
In early stages of prototype development, stakeholders and key parties view storyboards and mock-ups. They are then interviewed and/or share their observations in discussions or surveys. To get broader feedback, focus groups are sometimes created. When there is a lack of consensus, votes might be taken on components and the overall solutions to assure that choices are made that will have the broadest support.
Testing can help identify the must-have components of the solution since the lack of any such components would be pointed out in the feedback received. Satisfaction that the solution requirements are being met will influence the participants’ views on quality of the effort made by the team and of the solution itself. Features added that go beyond the basic requirements might improve perception of the solution or might have little impact (other than adding cost). It is important to document all of this in the feedback and capture suggestions for improvements.
Ease of use of the prototype
Clarity of messages and indicators provided
Clarity of directions on how operators should respond
Timeliness of messages that appear and quality of automated actions
The response provided by the prototype if the operator makes errors in fixing problems
The prototype’s potential to teach new operators how to more effectively do their jobs
Technical feasibility of the prototype including apparent reliability, availability, and serviceability
Overall satisfaction of operators/workers with the prototype
During the prototype development phase, organizations will sometimes have multiple teams creating prototypes in competition with each other. This can provide a means to get to a more comprehensive solution faster. In our earlier example, one team might be adding sensors alone to a production line and building out that prototype. A second team could be adding sensors and image recognition to a second production line.
Testing and evaluation of competing prototypes provide us with comparisons of the solutions but also enable us to judge the quality of work by each team. One prototype might be chosen over another if it meets all key requirements and is perceived to be the best solution or is more cost-effective. Sometimes, the best features or components from each prototype are determined and then merged into a single solution.
The Agile Sprint Approach
Agile sprints have become a popular technique used in early prototyping and testing of potential software and applications improvements. The sprints generally take place over short periods of time (2 to 4 weeks) with requirements driven and prototypes reviewed by a small group of stakeholders and interested parties. Each iteration of the entire process previously described in this chapter is compressed into this short time frame.
In preparation for the sprint, the facilitator does research into potential problems that might be addressed, observes current solution practices, and determines who the likely stakeholders and interested parties will be. The sprint begins with the facilitator leading this group of participants through the initial problem definition and ideation phases. A diverse group of six to ten people takes part.
Just as in longer engagements, the facilitator briefs the group on the openness of the process and reminds them not to feel limited by constraints and to set aside any critiques. Both the problem definition and ideation phases often utilize the same brainstorming techniques. These phases commonly take place on back-to-back days. The same group of participants is usually present for both.
At this point, a prototype is started and developed, usually over no more than a 2-week or 3-week period. The prototype is then “tested” in front of the participants to validate whether it might provide the solution that the participants were looking for. This discussion can drive further iterations of this process or lead to a decision to move forward with an implementation.
During observation and research, the scope of our effort widens. As we define potential problems to solve, we eventually narrow the scope, often to a single problem. As we gather ideas about solving that problem, our scope widens again. In the prototype creation and then testing, our scope is narrowed, eventually to a single solution as we move toward a production implementation.
Regardless of whether the agile sprint drives prototype creation and testing, or design thinking drives it at a slower rate, funding for a full implementation and operationalizing the solution will require additional considerations. We discuss these in the next section of this chapter.
Moving from Prototypes to Implementation
At this point, our prototypes have been tested, and we have been listening to our constituents. We have aligned our prototype functionality with desired business goals and made modifications where needed.
Is there measurable return on investment or significant business value from the solution when we operationalize it, and when will we see it?
Can we operationalize the solution in a reliable, manageable, serviceable, and secure manner?
Who should implement the production version, and how should it be implemented?
What sort of roadmap will assure sponsors and stakeholders such that the project receives adequate funding needed to deliver the production version?
Let’s explore how we might answer these questions.
Measurable Return on Investment
We noted earlier in this chapter that return on investment is just one of the considerations used in determining which projects move forward. That said, once projects move beyond the testing and prototype phase, ROI analysis frequently becomes necessary to justify making the investment in an operational version of the solution. This is particularly true where the CFO has a role in approving these projects.
ROI = (Business Value – TCO) / TCO
Azure subscription costs of relevant backend components
Development and deployment of IoT Edge, IoT Hub, data management, and analytics/machine learning software solutions
Integration of IoT components
Integration to legacy components (where required)
Internal staffing supporting the Azure deployment
IoT device and networking purchase costs (including upgrading of legacy equipment where required) and installation costs
Ongoing IoT device and networking support and maintenance costs
Training of internal technical staff
Training of IoT solution operators of equipment
Increased revenue from existing and new products and business services
Optimization of limited resources, facilities, and/or supply chain
Improved quality of products and services
Savings from reduced unwanted and unplanned equipment downtime
Elimination of risk, regulatory penalties, and need to set aside monies for other related expenses
Improved safety resulting in savings from minimized lost worker time, reduced workman’s compensation, and reduced healthcare expenses
The potential business value from an IoT solution might initially be viewed by some in an organization as speculative prior to the deployment of the operational system. Such estimates of business value are most believable when coming from responsible business leadership. Often, a range of estimates is provided that can be described as conservative, pragmatic, and aggressive with pragmatic being considered the most likely scenario based on business judgement.
In Figure 8-7, positive ROI occurs just after the start of Year 2 in the project. TCO is growing at a diminished rate, while business value growth continues to increase.
Note
The value of money changes over time. Hence, costs and business value are sometimes computed using “net present value” (NPV) formulae to provide more realistic views of ROI during a project lifetime.
Operational Considerations
In Azure-based backend cloud deployment servicing IoT solutions, operational aspects are greatly simplified compared to earlier on-premises deployment of these resources. Given that most companies were adopting a Platform as a Solutions (PaaS) strategy for IoT solutions when this book was written, let’s look further at key tasks and roles of key players aligned to such a strategy.
Identifying the key tasks and roles needed prior to deploying a production version of your IoT solution is important for a variety of reasons. As we estimate costs associated with full deployment, personnel costs need to be identified. In addition, understanding the skills that need to be developed will impact cost, time to solution, and hiring that must take place.
Key tasks that must be executed when full deployment occurs include managing day-to-day operations – monitoring the infrastructure, performing change management, application release management, and performance tuning – and assuring the protection of data. Operationalizing the architecture is frequently represented by a RACI diagram.
Example RACI diagram for an IoT cloud backend deployment
Activity/Task | Stakeholder/LOB | Analyst/Data Scientist | Azure Admin. | Data Admin. | Developer | IT Manager |
---|---|---|---|---|---|---|
Day to day Operations | I | R | A | |||
Monitoring | I | R | A | |||
Change management | I | I | R | R | R | A |
Application release management | C | R | I | I | R | I |
Performance tuning | C | C | R | R | R/I | I |
Data protection | I | R/I | R | A |
Example RACI diagram for an IoT edge deployment
Activity/Task | Stakeholder/LOB | Analyst/Data Scientist | Developer | Device Admin. | Network Admin. | Facility Manager |
---|---|---|---|---|---|---|
Day to day Operations | I | R | R | A | ||
Monitoring | I | R | R | A | ||
Change management | I | I | R | R | R | A |
Application release management | C | R | R | I | I | |
Performance tuning | C | C | R/I | R | R | I |
Data protection | I | R/I | R/I | R/I | A |
Implementation Strategy
The earlier stages of the design thinking approach we described previously in this chapter should have convinced key stakeholders that there is business value in the proposed IoT solution. We should now have a good idea as to what our IoT solution will deliver. The financial and operational considerations we described in this section of the chapter will also help us in developing our implementation strategy. Even so, many risks could remain when we approach operationalizing our project, especially if this is our first IoT solution. Our implementation strategy will help us mitigate those risks.
For example, the design complexity and cost of our IoT solution could raise concerns about the potential outcome. Developing a phased approach that clearly lays out the scope of deployment within the project phases, deliverables at the end of each phase, and likely cost and business value of each phase can help to alleviate those concerns.
Within the project phases, developer and deployment skills might be required that are not widely present within the organization. Such concerns can be addressed by providing an education and hiring plan or identifying technology partners that will assist in the development and deployment during these phases.
In a highly competitive environment, competitors could be developing similar IoT solutions that match or exceed the capabilities that you have planned. Monitoring these developments and having flexibility in making some adjustments in response within the project phases could be well received by key stakeholders of the project.
Deployment of our proposed solution could also have significant impact on existing business processes. Having well-thought-out change management plans is critical to mitigating concerns about this impact. Such plans often include activities that are designed to gain support for the new processes among workers and alleviate the concern of sponsors. Training can provide education on how day jobs will be impacted and generate enthusiasm for the changes.
Preparing an Implementation Roadmap
To gain needed funding for the IoT project, you might need to sell the value and viability of the project to senior management by providing an implementation roadmap. The roadmap should contain an easily understandable message about the problem to be solved, its potential business value, and the expected time to solution that will demonstrate its value.
An explanation as to the process used in determining which business problem(s) merited solution consideration and why this problem was given higher priority and selected for an IoT implementation
An overview of how this IoT solution will solve the identified business problem(s)
A timeline showing project phases, costs, and business benefits
An overview of the current state technical architecture and how the architecture will change in its future state
An overview of project risks and risk mitigation steps
A description of immediate next steps upon project approval including funding needed, staffing required, planned acquisition of IoT devices and their installation, planned acquisition of additional cloud resources, and immediate training and change management activities
Multiple roadmaps are often developed to address the concerns of different audiences in different levels of detail. Business and technical roadmaps each focus on answering the questions relevant to those audiences. An executive roadmap presentation presents the information we just noted at a very high level, conveying just enough information such that the executive(s) can make an informed decision.
Some Final Thoughts
We hope that you now have gained enough knowledge to define IoT solution architectures that rely upon Microsoft Azure for providing key components. You probably realized that there is a lot to consider even before you read this book. You have many options in how you might justify such projects and in the details of the architecture that you define.
Modern IoT architecture patterns
Azure IoT solutions overview
IoT devices and Azure
Landing data in Azure
Applying analytics, machine learning, and cognitive services in Azure
Deploying solution accelerators and managed solutions
Integration with legacy infrastructure
Developing a plan for success
IoT continues to evolve. Microsoft and its partners are at the forefront in driving this evolution and are enabling new and innovative business solutions. New IoT-related standards also continue to appear while previous standards evolve, addressing areas that formerly were less well-defined or understood. That said, IoT has matured a great deal in the past few years. And waiting for the next generation solutions and standards to emerge is not an option for most organizations.
You likely read this book because you have heard so much about IoT and wanted to learn more. But you might have also read the book because you are feeling pressure from your business leadership to solve problems that would benefit by deployment of an IoT-based solution. Getting started today will help you build and develop the skills you need and start you down the road of designing and deploying solutions that can make immediate impact on the business. This book is just the beginning of gaining an understanding on how to do that.
We wish you success regardless of where you are on this journey. Microsoft IoT and the Azure platform enable the intelligent edge and the intelligent cloud required in the delivery of these valued business solutions. Successful deployment of these solutions is assuring that talented individuals skilled in designing and deploying the architecture covered in this book will be in demand for years to come.