Tag Archives: vendor

In IoT ecosystem evolution, constraints = opportunities for IoT innovators

Leave a reply

What are our opportunities for guiding the rapidly evolving IoT ecosystem? The Internet of Things, with its explosive growth, unprecedented variety of device & system types, lack of broadly shared language and conceptual frameworks to discuss and plan, lack of precedence for implementation, and the organizationally complex consumer systems — i.e. cities and institutions — required to implement and manage these IoT systems — all make for a challenging space. It can be difficult to even know where to start. One way to add structure and framework to the conversation is to introduce some constraints — and good news! There are constraints already there! They’re just not broadly seen or talked about yet.

What does a successful IoT system implementation look like ?

A natural source for constraints is from those things that define a successful IoT System implementation in an institution or city. I use two primary components to define IoT System implementation success:

  1. Return on Investment (ROI)
  2. Cyber risk profile

Regarding the first — ROI, does the system do what we thought it would do at the costs/investment that we thought would be incurred? As discussed in a recent post on IoT System costing, determining costs of IoT Systems implementation is different from traditional enterprise systems. Most institutions and cities have little experience at it and are generally not very good at it. Further, other subtleties such as expectations of the data created from deployed IoT systems across a spectrum of populations, demographics, & constituencies directly impact perceptions of system (and investment) success.

Regarding the second — cyber risk profile, did the IoT System implementation make things worse for the institution or city? Cyber risk profile degradation can come from poorly configured devices/endpoints, insufficient management resources (skill, capacity) for endpoints and data aggregators/controllers, inadequate vendor management, and others.

Constraints drive opportunities in the IoT ecosystem

These same two analysis requirements of a city’s or institution’s success, aka constraints, can also be used by innovators and providers of IoT systems. Knowledge of these constraints by IoT systems providers, these requirements for city/institution implementation success, creates opportunity for the IoT systems innovator and provider by identifying where they can help address organizational complexities in the course of pursuing ROI and cyber risk posture/profile objectives.

IoT systems are different

As discussed in other articles and posts, IoT Systems are different. The process of selecting, procuring, implementing, & managing IoT systems is different from doing the same for traditional enterprise systems such as email, calendaring, resource and customer management, etc. At least six aspects of IoT Systems contribute to this difference:

  1. High number and growth rate of IoT devices
  2. High degree of variability of device types & variability of multiple hardware/software components within a device
  3. Lack of language and frameworks to discuss IoT opportunities, risks
  4. IoT Systems span multiple organizations within an institution or city
  5. IoT endpoint/devices tend to be out of sight out of mind
  6. Lack of precedent for successfully implementing these systems, few examples, few patterns to follow

Of these differences, #4 – the organizational spanning aspect of IoT Systems — presents a subtle but substantial challenge. Deploying IoT Systems in a city or institution is not like deploying an enterprise application in a data center or SaaS in the cloud and then providing for end-user training and support. This, of course, does not mean that deploying large enterprise systems is easy by any stretch, but rather that there are more and different organizations required in the technical, operational, and management aspects of the system.  Because of this, new levels of inter-organizational cooperation and collaboration are sought. And, as we all have experienced, collaboration and cooperation is frequently touted but successful collaboration and cooperation is often not achieved — “the discrepancy between the promise of collaboration and the reality of persistent failure” (Koschmann).

Cities and institutions are complex multi-component organizations that offer a complex substrate for IoT System implementation. These complex IoT product and service consuming organizations are not blank slate, clean whiteboard, or powerpoint deck solution organizations. There is little homogeneity here.

IoT Systems innovators and providers that recognize these constraints brought on by these complex consumer systems, that seek to learn the institutional organizational challenges in detail, and get in the dirt at the outset with the city or institution will ultimately be IoT Systems ecosystem drivers.

“I built it in my garage, it works there, it’ll be awesome in your city!”

Because of the seemingly unbounded potential of IoT Systems solutions, there’s also room for undifferentiated, poorly provisioned, and poorly serviced garbage in this space.

Because of the newness of IoT Systems, often there are many technologies and many vendors without particularly long track records. There are some big names in the game of course — Cisco, Microsoft, Intel, Siemens for example. But there are many providers in that long tail, both proven and unproven, and some of them will offer great innovation and value. Some of them will not. The challenge for institutions and cities is to work to separate the wheat from the chaff as they select, procure, implement, and manage IoT Systems.

Going by name brand alone is not sufficient because there will be many new innovators and providers that do indeed offer promising and solid solutions that give a reasonable likelihood of ROI and an approach that does not degrade the existing cyber risk profile of the institution. Further, sometimes large companies can be problematic because they are used to throwing their weight around, possibly invested heavily in particular approaches, and may not be open to new or alternative approaches. This may or may not be with whom a city or institution wants to work.

Eyes off the bling for a moment

So how can a city or institution begin to separate the wheat from the chaff in choosing IoT systems? An initial step can be to take one’s eyes off of the ‘bling’ for a moment. The bling is all of the feature sets and bells and whistles that most think of when they think of IoT systems. So, a three step process would be:

  1. Take eyes off of the bling (feature sets, bells & whistles) for a moment
  2. Review implementation challenges internal to the institution
    • organizational spanning complexity
    • calculating IoT system support costs across all organizations
    • analyzing internally available skill sets and capacity
    • consider what criteria different demographics will use to assess success or failure
    • seek input in estimating cyber risk to which an  institution or city is already exposed to provide an estimated baseline
  3. Seek and prioritize IoT Systems innovators/providers that help address some of these internal organizational challenges and shortcomings

insideoutoutsidein

Cities and institutions look inside out — Some of their internal challenges include:

  • organizational complexity (spanning)
  • IoT system support staffing capacity
  • appropriate skill sets
  • IoT system support tools availability & experience
  • what ROI will a particular provider’s IoT system bring?
  • will implementing this IoT system make my cyber risk picture worse? how do I know?

IoT innovators & providers can look outside in —  and use these constraints to create market differentiators for their organizations, such as:

  • can I help city/institution address internal challenges?
  • can I provide tools to help them manage their system?
  • can I help them reach the ROI they were expecting?
  • can I help them mitigate their cyber risk from this implementation?

Not just one IoT System

We’ve been talking about just one prototypical IoT System for an institution or city. In practice, institutions and cities will have many IoT Systems. Many of these  IoT Systems will:

  • use shared technical resources of the city or institution, eg network and supporting systems
  • have interdependency with other systems
    • at device level
    • at data level
    • to include co-existing with legacy systems & new systems
  • dip into the same limited pool of skill sets and capacity for systems support

This further deepens the IoT Systems management challenge within the city or institution. Implementation challenges for these complex city and institutional consumers will only continue to grow. They won’t diminish.

IoT Systems innovators and providers that recognize and speak to this additional level of complexity — this ecosystem with multiple providers and vendors within an institution —  and provide options, services, and support to help cities and institutions manage this complexity will set themselves apart from the competition and develop longer lasting relationships.

In this seemingly open-ended space of IoT systems possibilities, identifying and developing solutions for organic complex consumer constraints and challenges can be a differentiator for IoT product innovators and service providers.

Creating IoT Systems Manageability – A Risk-Managed Set of Networked Things

1 Reply

To achieve IoT Systems ROI and to ensure non-degradation of an institution’s existing cyber-risk profile, IoT Systems must be manageable. In turn, in order to build IoT Systems manageability, institutions will need to manage their IoT Systems risk with non- traditional approaches that includes assigning IoT endpoints (the ‘things’ in IoT) to risk categories that can be independent of the underlying technologies and vendors.

IoT Systems are increasingly complex to implement, manage, and to establish system ownership in institutions, whether cities, Higher Education institutions, or corporate campuses. In turn, an institution’s IoT Systems Portfolio – a systems of systems – rapidly deepens the complexity. We will need to tackle the problems and challenges in new ways and with new organizational concepts if we are to have an opportunity for well-managed and reasonably risk-mitigated systems. This includes thoughtful inter-organizational planning, partnerships, and development of a more common language between central IT, distributed operational organizations and departments, and vendors. Further, this will be required to establish system ownership and management plans between organizations such as facilities organizations, central IT, research groups, vendors, and others. One step toward this objective is identifying things to be managed independently of the technologies and vendors implementing them — a Risk-Managed Set of Networked Things.

Central IT won’t own all of the IoT Systems

Traditional enterprise network and system management tools, staffing models, and even language are ill-equipped to address this rapidly changing technology. Historically, network and system management tools have all been within the purview of central IT. Central IT will not be able to keep up with the accelerating growth of IoT Systems across an institution. Just like central IT organizations cannot manage every user/academic/business application on their networks (or even many of them), central IT will not be able to support all of the IoT Systems either. Business owners — operational (academic in the Higher Ed case) and administrative — will have to share that load. That’s better for them too — they are closer to the problem and have a truer understanding of desired outcomes from the system. Implementing this coordination across two or more organizations in the institution is new work though. There are not great precedents for this. Institutions, particularly Higher Education institutions, are known for their bureaucracies within bureaucracies, entrenched ways, and “cylinders of excellence..” (aka silos) .

system of system of systems ...

system of system of systems …

In a similar fashion facilities management organizations have substantial skill sets in building in and integrating equipment into built environments whether they are buildings or spaces. However, facilities management organizations don’t have network design, implementation, network management, and traditional server management skill sets. Finally, while operational departments, whether acting independently or in collective partnerships with other operational departments, know what they want systems to do and comment on performance, they do not have the required skill sets that facilities management and central IT groups bring to the table.

This organizational-spanning nature of IoT Systems in institutions make establishing ownership and a post-implementation management plan particularly challenging.

Designing for & building IoT System manageability

The growth in institutional system count, system complexity, and system interdependency makes for rapidly evolving systems management and owner environments for Higher Ed institutions. We have to take definitive steps to make things more manageable. That is, we have to design for system manageability. Applying historical and traditional tools and organizational approaches to this rapidly changing environment will no longer be sufficient.

A core component of any framework to facilitate manageability is a language, or at least shared concepts, that support it. In turn, a substantial objective of that shared language development (shared, for example, between central IT, facilities, and operational users) is to develop structures that make the systems more manageable. This sounds obvious, but in our complex environments and with our dwindling availability of time and cognitive bandwidth, it is easy to lose sight of this objective.

Agreeing on what is being managed

Before different organizations within an institution can establish those manageability- facilitating-structures and figure out how to partner, establish ownership, and mitigate risk to institutional systems, they have to be able to mutually identify and agree upon what is being managed. What is the set of things — devices, systems, spaces, buildings, infrastructure, etc — that we care about managing, from both operational and risk mitigation standpoints?

In days of relatively simpler systems, sets of networked things/devices to be managed were often defined by the network itself and/or systems on the network and/or the particular brand of technology supporting the network. Further, these networked things/devices were typically run by central IT organizations and these organizations were comfortable with using locally understood network terminology and concepts to define that set of things. Examples include — devices/things on a particular subnet or set of subnets, devices/things behind a particular firewall, on a particular VLAN or VRF, etc.

These examples above don’t mean much to potential system owners that are business organizations and/or academic organizations. The terms used are way too abstract, jargon-y, and/or colloquial. The cross-organizational planning and coordination needed for IoT Systems implementations and subsequent management cannot occur if participating groups can’t mutually identify what is to be managed.

Also problematic in trying to apply these old approaches of identifying things and systems to be owned, operationally managed, and risk-managed is that it is easy to slip into the high-granularity/high-entropy of technical details when the initial conversation is simply identifying and agreeing upon what is to be managed. Because these new and rapidly evolving technologies are increasingly complex, requiring increasingly deep technical skill sets, conversations in technical detail can be challenging even for technical professionals and effectively useless for potential academic and business partners and systems owners.

Finally, sets of things/devices to be managed might involve multiple technologies — eg maybe partially wired, partially wireless/near-field, on a VRF, behind a firewall, etc. So using a technology as a defining mechanism is further unhelpful. While a particular technology or network might happen to align well with a business need for defining a group of assets to be managed, we don’t want to start with that assumption.

IoT System Manageability Groups – A Risk-Managed Set of Networked Things

To address these shortcomings, we can consider a Risk-Managed Set of Networked Things (RMSONT). In this approach, we work to establish sets of networked things based on what best enhances manageability of the system. This is independent of underlying implementing technologies, particular vendors, and existing organizational charts.

What constitutes IoT System manageability?

A managed IoT System will have at least these attributes:

  • the IoT System was selected methodically and with purpose
  • the IoT System is named & known
    • the system has a common name that is known, shared, & published to participating parties (eg central IT, facilities management, operational departments, etc)
  • devices/things of the IoT System are enumerable
  • that is, via network process the device can be known and named
  • IoT System owners identified
  • IoT System component owners identified
  • satisfactory system performance is defined
  • system performance is measured
  • system performance is reviewed by business owners and systems support providers
  • estimates of total costs are established and shared — includes IT and Operational Technology (OT) costs
  • other

What are the qualities/attributes of a thing/device?

Things/devices in IoT Systems have at least these qualities or attributes —

  • a location
  • a function (what is it supposed to do)
  • an IP address; a MAC address
  • a power requirement
  • an associated data aggregator or controller
  • supports a user, users, or population (department, organization, constituency, etc)
  • rate of failure (estimated or known)
  • other

Creating a Risk-Managed Set of Networked Things

The #1 goal is to build and enhance IoT Systems manageability. A risk-managed set of networked things is established to create a manageable group. This could be a group managed by the business consumer or an institutional service organization such as facilities management or central IT — whatever best facilitates system ownership and management.

Multiple sets of risk-managed things can be created to facilitate overall system manageability. One example of a set of risk-managed sets might be:

  • law enforcement/security office owns and manages a set of networked video cameras (possibly with support from central IT, facilities management, local IT, vendor, etc)
  • in an academic setting, a researcher that uses a specialized HVAC IoT System with sensors, actuators, and data aggregation to provide tight environmental control of their research environment might be a logical choice to own that system
  • a metering system might best be managed by the institution’s energy management office
  • a building manager might have a risk-managed set of networked things local to their particular building, but of different types of things— surveillance cameras, energy management system, etc

In general, getting those most familiar with the IoT System’s performance expectations and actual performance into a system management role is probably a good idea.

As we talk about sets of things, and particular kinds of sets of things, we can borrow lightly from the mathematical idea of groups.

As I understand it, mathematical groups are:

  1. Sets of things
  2. These things abide by or participate in some set of rules
mathematicalgroup

A selected set of things abiding by a certain set of conditions & operations …

Similarly, a Risk-Managed Set of Networked Things, can be:

1. A set of networked and computing things/devices (that interact with the environment)

2. These things/devices participate in or are governed by some sort of network management processes and human management processes — eg automated network device enumeration/inventory, device health/responsiveness, etc

iotsystemsgroupimage

RMSONT – A Risk-Managed Set of Networked Things

 

You gotta keep ‘em separated (or not)

To borrow from Offspring’s social commentary (and popular song) on gang membership, colors, and violence in Come Out and Play, the theme of IoT Systems and network segmentation seems to be, “you gotta keep ‘em separated.” The problem is that that is not as easy as it seems.

offspringlive

tie your own rope, tie your own rope, tie your own rope (hey!)

Network segmentation has been all the rage as an answer to IoT Security and risk mitigation. However, as we’ve seen, network segmentation alone is not sufficient. Risk-managed sets of things need to be thoughtfully chosen, the rules and operations supporting that set of things needs to be thorough, and systems owners thoughtfully coupled with systems in order to achieve manageability.

We can manage IoT Systems within our institutions. And we can manage portfolios of IoT Systems within our institutions. However, we need to acknowledge that these are different kinds of systems and that our existing traditional IT systems operational and risk management approaches are likely insufficient. From that point we can sculpt and evolve new management approaches that facilitate successful, well-managed IoT Systems portfolios.

Developing an IoT vendor strategy

Leave a reply

The vendor count for IoT systems that a company or organization manages will only increase in the coming months and years and it will possibly increase substantially. Some of this will be from traditional systems like HVAC that have been in the space longer than most and are maturing and extending their IoT development and deployment.  New growth in an organizations’s vendor count will be from vendors with brand new products and service lines made possible by IoT innovation and expansion.  Many of the benefits of IoT will be from products and services from different vendors that interact and exchange information with each other such as an IoT implementation leveraging the cloud.   Regardless of the source, the number of IoT vendors that an organization has will grow.

This increased IoT system vendor count is not a bad thing in its own right. However, a somewhat insidious effect is that the number of relationships to be managed (or not managed) will grow even faster than the increasing vendor count itself.

number of relationships grows increasingly faster than the number of nodes

number of relationships grows increasingly faster than the number of nodes

Relationships have friction

Every relationship has friction or loss from an idealized state. Nature has plenty of examples —  pressure loss in a pipe, channel capacity in information theory, marriage, and heat engine efficiency established nearly 200 years ago by Sadi Carnot. Carl Von Clausewitz famously established the concept of friction in war in his book On War in which he sometimes evokes the image of two wrestlers in a relationship.

Relationships between business customer and their vendors have friction too — from day-to-day relationship management overhead such as communication planning and contract management to more challenging aspects such as expectation alignment/misalignment and resource allocation problems.

heatengine

there’s a limit to how much work can get done between any two points

Friction in a business customer-vendor relationship (unavoidable to some degree) means less information gets communicated than expected, similar to Shannon’s observations on information exchange. And similar to limits expressed with Carnot’s engine efficiency, less work gets done in practice than in the idealized state. Particularly for the former, a reduction in expected information exchange, by definition, increases uncertainty. Further, friction in a network of relationships can manifest itself in yet even more uncertainty.  Less work gets done than is expected and the state of things is unclear.

With a growing network of nodes (IoT vendors in this case), the even faster growing number of relationships, and the friction that naturally exists between them, our business environments are becoming increasingly complex and accompanied with increased uncertainty. Vendor management and its associated risk, in the traditional sense, have left the building.

Sans organizational IoT strategy, IoT vendors will naturally optimize for themselves

While a strategy around IoT deployment and IoT vendor management can be difficult to devise and establish given the complexity and relative newness of the phenomenon, we have to acknowledge that vendors/providers will naturally optimize for themselves if we don’t have an IoT implementation strategy for our organizations.

This is not an easy thing. We really don’t know what is going to happen next in IoT innovation, so how do we establish strategy? Also, the strategy might cost something in terms of technical framework and staffing — and that is particularly hard to sell internally. However, without some form of an IoT system implementation strategy, each individual provider will offer a product or service line implementation that’s best for them. They won’t be managing the greater good of our organization. This is not evil, it’s natural in our market economy — but we as business consumers need to be aware of this.

Similar to the concept of building a socket in the last post, in establishing a policy or framework for IoT vendor relationships, some IoT vendor considerations might include:

  • Are there standard frameworks that can be deployed to support requirements from multiple different IoT vendors? For example, does every vendor need their own dedicated, staffed, and managed database? If individual vendors demand dedicated support frameworks/infrastructure, are they willing to pay for it or otherwise subsidize it?
  • Does your vendor offer a VM (virtual machine) image that works in your data center or with your cloud provider? Do they offer a service that helps integrate their VM image into your data center or cloud environment?
  • Are there protocols that can be leveraged across multiple different vendors? Does the vendor in consideration participate in open-source protocols? For example, for managing trust, Trusted Computing Group has extended some of their efforts in an open source trust platform to the IoT space.
  • Does the vendor provide a mechanism to help you manage them for performance?  If so, the vendor acknowledges the additional complexity that managing many IoT systems brings and offers to help you review and manage performance.

While an IoT framework or policy at this stage is almost guaranteed to be imperfect, incomplete, and ephemeral, the cost of not having one puts your organization at every IoT system provider’s whim.  And that cost is probably much higher.

Systems in the seam — shortcomings in IoT system implementation

2 Replies
Jose Abreu

Coming apart at the seams

One of the greatest areas of risk related to the Internet of Things (IoT) in an organization, corporation, or institution comes not necessarily from the IoT systems themselves, but rather the implementation of the IoT systems. A seam forms between the delivery of the system by the vendor/provider and the use of that system by the customer.  Seams, in themselves, are not bad. In fact, they’re essential for complex systems. They connect and integrate different parts of a system to work towards a cohesive whole.  However, how we choose to approach and manage these seams makes a difference.

Managing the seam

Seams are where interesting things happen. College baseball changed its ball seams this year to flat instead of raised to drive more hits and home runs and, sure enough, balls are traveling an average of 20 feet further.  There are seam routes in football where the receiver tries to exploit the gap between defenders. And anyone that’s ever sat in the window seat by the wing of an airplane can attest that there are many more seams than they would probably care to see. Finally, of course, seams can also be where things come apart.

More seams than I would care to be aware of

More seams than we would probably care to acknowledge

Vendor relationships and vendor management have always been important for firms and institutions. However, the invasive nature of IoT systems makes vendor management particularly important to successful IoT system implementation and subsequent operation. However, the work and staffing required to manage those customer-vendor relationships and to provide the oversight needed to operate safe and effective systems often gets obfuscated by the promises and shininess of the new technology.

IoT systems are different from traditional deployments of workstations, laptops, and servers. By their very nature, IoT systems have the ability to sense, record, transmit, and/or interact with the environments in which we live and work. Further complicating the IoT systems deployments and support, these systems may well be invisible to us and organizational IT might not even know the systems exist much less be able to provide central IT support.

Firms and institutions purchase IoT devices and systems en masse to address some need in their operation. These IoT systems might be related to environmental control and energy efficiency, safety of staff and the public (fire, security, other), biometric authentication systems, surveillance systems and others. Because of this, IoT devices can be brought into an organization’s physical and cyber space by the hundreds or thousands or more. When such systems and devices are partially or improperly configured, there can be significant consequences to the organization. Similarly, a lack of planning of long-term support, whether local or via maintenance contract with the vendor or both, can also have significant implications.

Cost of building a socket

In most organizations, implementing a third-party solution, whether hardware, software, SaaS, or hybrid, requires a supporting infrastructure for that solution. I call this supporting structure a socket. The customer organization must create a socket that allows the new vendor solution to interface with appropriate parts of the customer’s existing infrastructure. Taking the time and resources to plan, build, and maintain this socket is integral to the operational success of the new system. It also provides the opportunity to manage some of the risk that the new system introduces to the organization.

VendorSocket

Building a socket to support vendor IoT systems

Know yourself

One of the worst case scenarios for an organization is believing that an IoT system is managed when it is actually not managed. At this point in the evolution of IoT deployments, I suspect that this scenario is more of the rule than the exception. Given the scale and speed of IoT innovation and growth and the lack of precedence for managing this sort of risk, the famed Sun Tzu guidance to know yourself can be elusive.  The IoT phenomena will change how we seek to know and characterize our organizations as a part of the risk management process.  A good place to start knowing ourselves is planning, building, and managing that seam where the interesting things happen.