Raising Expectations for IoT Systems Vendors

To achieve the rich potential that the Internet of Things brings to higher education, our institutions need to raise expectations for providers of IoT systems. A proposed checklist suggests how to begin.

Raising Expectations for IoT Systems Vendors

Higher education institutions need to raise expectations for providers of Internet of Things (IoT) systems. Because of their diverse activities, services, and city-like aspects, colleges and universities can anticipate continued growth in the numbers and types of IoT systems on campus. They should raise the bar regarding IoT system deliverables. Don't mistake this recommendation for an anti-vendor sentiment — higher education needs clever and thoughtfully applied technology developed and delivered by vendors. Further, vendors can offset support staffing needs for short- or long-term arrangements dealing with IoT issues. As is natural in a market economy, however, vendors optimize engagements for themselves and their particular set of products or services. It's not their job to understand, support, and mitigate risks around our ecosystems. That's our job, and to do it, we have to raise our expectations, articulate them, and communicate them clearly to vendors. Both institutions and their vendors benefit from strong, respectful, well-understood relationships.

IoT Systems Are Different

As discussed in my June 2016 article, "The Internet of Things, IoT Systems, and Higher Education," IoT systems differ from traditional enterprise systems in a number of ways, including the high number of devices and types of devices, the lack of mature language and frameworks to discuss the phenomenon, their organization-spanning aspects, and the out-of-sight, out-of-mind nature of many IoT systems.

Of these system differentiators, two have a particularly strong influence on vendor management. First, IoT systems, with their high counts of networked computing endpoints, can be installed by the hundreds or thousands throughout a single contract with a vendor. These endpoints can be mounted all over a research space, building, campus, or other geographically dispersed area such as a stadium. These hundreds or thousands of networked computing devices (aka the "thing" in Internet of Things) are not installed in a neat rack in a data center — a  networked computer can sit on walls, ceilings, spaces, street lights, labs, and other nontraditional locations.

Second, the multi-organizational aspect of IoT systems demands attention. Many, if not most, of these often complex IoT systems are not acquired by central IT but rather by organizations like facilities management, researchers or end users, housing and food services organizations, and others. There is often no vetting of these IoT systems by traditional IT organizations because these systems arrive on campus from so many different places.

Growing System Complexity

The increase in complexity of our systems, ranging from technical to organizational, also adds to the challenge. At least four factors contribute to growing system complexity:

  1. The complexity of the technology itself
  2. The growing number of systems involved
  3. The growing number of interdependencies between those systems
  4. The energy and resources required to manage multiple interdependent client-to-vendor and vendor-to-vendor relationships

Increasing Technological Complexity

If we look at the device or "thing" itself, three areas provide avenues for increasing complexity. An IoT device computes, is networked, and interacts with the environment in some way. The increasing computational capabilities in these IoT endpoints is one source of growing complexity. Processing power that can enhance networking capabilities, new IoT-targeted cloud services, and the new and evolving protocols of these devices create more options to consider. Finally, from biometric sensors supporting identity management to air particulate sensors in research labs to increasingly complex accelerometers in smart phones, the number of ways in which a device might interact with the environment is large and rapidly growing. The industry for sensor development is accelerating, as is that for actuators.

Growing Number of IoT Systems

The sheer size and growth in the number of IoT devices and systems and the vendors that deliver them also influence the growing complexity that an organization such as a higher education institution must manage (or accept the risk of not managing).

Because colleges and universities can be city-like in providing so many services to their broad array of constituents — students, faculty, staff, the public — they offer a broad arena for IoT systems to land with their potential benefits. Because of this and because of increased service expectations from that same constituent population, the number of IoT systems and their respective supporting vendors will only continue to grow.

Rising Interdependency of Systems

Another factor in increasing complexity is the growing number of interdependencies between technology systems and therefore between the vendors that deliver and support these systems. In the early days of Internet connectivity, most vendor relationships were between the consumer and each individual vendor. Increasingly, though, the consumer not only has those consumer-to-vendor relationships to manage but also relationships between vendors. For example, imagine a smart grid provider that installs and supports energy meters and provides aggregate energy use information to researchers and operational staff via a web-based dashboard. The consumer organization will have a relationship with this provider. That smart grid provider will probably also have a relationship with the institution's network provider in order to obtain IP addresses, install metering equipment, test installations, and provide ongoing support and maintenance. The consumer really needs to manage this relationship, too, or at least have some oversight of it. Otherwise they won't know how a system is installed.

If a higher ed institution looks at the total number of vendor relationships for which it is responsible (and to which it must devote management resources), it will find that the number of relationships to manage grows faster than the rate of growth of the number of vendors. For example, in the scenario described, the consumer has three relationships:

  • Relationship between contracting department and energy management vendor
  • Relationship between contracting department and its network provider
  • Relationship between energy management vendor and the consumer's network provider

Now, say the contracting organization wants to add a security provider. That adds three more relationships to the first three above (a new relationship from the security provider to each existing party), for a total of six relationships to manage. So, in this case, adding only one vendor increased the total number of relationships to manage from three to six! This growth in the number of relationships is even larger as the vendor count increases (figure 1).

Figure 1. Relationships diagram

Figure 1. Relationships to manage grow as the number of vendors grows.

Managing Multiple Vendors of Interdependent Systems

As mentioned in the EDUCAUSE Review article in June, managing these relationships takes energy and resources. When the number of relationships grows quickly, the complexity of managing that large set of relationships grows as well. Unfortunately, we often don't see this growth in complexity for what it is or where it comes from. Things just seem to get harder.

An Initial IoT Systems Vendor Checklist

Below is a possible starting point for a checklist or procedure for working with IoT systems vendors. While checklists deserve to be maligned when applied independently of a larger context, they are appropriate when applied thoughtfully within a larger system or process. When I am flying as a passenger on a plane, I want the pilot to be able to think out-of-the-box when the situation calls for it. Checklists applied in other phases of the flight can help free up the cognitive headroom for that out-of-the-box thinking by making common procedures methodical and rote. The same applies here; a checklist can be very helpful in knocking out some standard things that occur in many IoT systems vendor engagements. But a checklist is only useful when it supports a comprehensive process.

An IoT systems vendor checklist can be used during RFI, RFP, contract negotiation, contract review, contract re-negotiation, and other planning activities.

IoT Systems Vendor Checklist

  • Internal
    • What organizations/departments will be involved?
    • Who will oversee the whole system?
    • Do supporting organizations understand their roles and responsibilities in support of the system?
    • Who will manage the vendor contract and vendor performance?
  • Vendor-facing
    • Does the IoT vendor need data feeds/data sharing from your organization?
      • Consuming data? Exporting data?
      • Are the data feeds well defined? Reasonably defined? Written down?
      • Do the data feeds exist already?
      • If not, who will create and support these data feeds?
      • Are there privacy considerations?
    • How many endpoint devices will be installed?
    • Is there a patch plan?
      • Do you do the patching?
      • Who manages the plan, you or the vendor?
      • What are the projected costs associated with patching (this might be large)
    • Does this vendor's system have dependencies on other systems?
    • How many IoT systems are you already managing?
    • How many endpoints do you already have?
    • Are you anticipating or planning more in the next 18 months?
    • Is there a commissioning plan? Or have IoT vendor deliverable expectations otherwise been stated (contract, memorandum of understanding, letter, other?)
    • Is there a Design Guide or similar?
    • What is the vendor's plan/approach to changing default logins and passwords?
      • Has the password schema been shared with you?
    • Are non-required ports and services closed on all your deployed IoT endpoints?
      • How does the vendor demonstrate this?
      • Has the vendor port scanned (or similar) all deployed IoT endpoints after installation?
    • Is there a plan (for you or vendor) to periodically spot-check configuration of endpoint devices?
      • Or a plan for accepting the risk of not doing this?
    • Has the installed system been documented?
      • Is there (at least) a simple architecture diagram?
      • Is the server configuration documented?
      • Are endpoint IP addresses and ports indicated?
    • Who pays for the vendor's system requirements (such as hardware, supporting software, networking?)
    • Does local support (staffing/FTE) exist to support the installation? Is it available? Will it remain available?
    • If supporting IoT servers are hosted in a data center, who pays those costs?
      • Startup and ongoing costs?
    • Same for the cloud — if hosted in the cloud, who pays those costs?
      • Startup and ongoing costs?
    • What is the total operational cost after installation?
      • Licensing costs
      • Support contract costs
      • Hosting requirements costs
      • Business resiliency requirements costs
        • □ Redundancy, recovery, etc. for operating systems, databases, apps
    • How can the vendor demonstrate contract performance?
      • It's okay to ask vendor to help you figure this out.
    • Can the vendor maintenance contract offset local IT support shortages?
      • If not, then this might not be the deal you want.
    • For remote support, how does the vendor safeguard login and account information?
    • Does the vendor have a company policy or standard operating procedure that they can share with you?
    • Is a risk-sharing agreement in place between you and the vendor?
      • When things go awry, who is liable for what?

Please feel free to add additional considerations to this list via the comments section for this article.

Plans versus Planning

In an address to the National Education Association in April 1957, Dwight Eisenhower made the statement, "Plans are worthless, but planning is everything." No doubt his D-Day Omaha Beach experience — landing craft swamped or pushed off course, useless maps because soldiers landed in unplanned areas, artillery support unavailable because of radios lost on the swamped landing craft, and new beach obstacles from wreckage due to slipped timetables — contributed to that sentiment. The extensive D-Day planning created a breadth of knowledge that allowed for rapid adaptation to unforeseen events, a flexibility that otherwise would not have been possible.

As we plan for IoT systems in our colleges and universities and all the potential value these systems bring to our institutions, it is important to keep in mind that plans are just that — plans, not the reality we will face. Our plans, checklists, and procedures are not predictors of the future. Rather they are tools that help us familiarize ourselves with new terrain and influencing factors and help us talk about them with other leaders so that we too can rapidly adapt when things don't go as planned.


Chuck Benson is chair of the Internet2 IoT Systems Risk Management Task Force, chair of the university of Washington IT Service Management Board, and assistant director for IT, Facilities Services, at the University of Washington.

© 2016 Chuck Benson. This EDUCAUSE Review article is licensed under Creative Commons BY-NC-ND 4.0 International.