seven-layer ISO/OSI reference model
for use with IoT solutions. This IoT
OSI reference model consists of five
layers, with endpoints at the bottom,
connectivity, middleware, IoT services, and, finally, applications at the
top. Stakeholders and developers use
the Io T Canvas and Io T OSI reference
model to co-create and co-evolve a solution definition before prototyping.
The IoT Methodology has taken agile thinking as a starting point but is
also a monolithic method.
New Practices Are Needed
It is clear from these methods, and
our own experience handling emerging technologies, that new domain-specific practices will be needed to
handle the very nature of the Io T—
particularly practices to handle
˲ Distributed. These systems are
typically far more distributed than
most other software systems. Experience from the development of telecommunication systems will come into
play: new failure modes (due to communications), reliability engineering,
redundant systems development, and
˲ Mobile. Again telecommunication vendors have practices to develop
mobile systems, which are applicable.
For example, these systems have to
degrade gracefully, security is critical,
and they must be robust.
˲ Human out-of-the-loop. The whole
idea of the Io T is to sense/analyze/acti-vate without a human in the loop—for
example, self-driving cars, automated trading systems, and population
health integration systems. There may
be practices to be designed here,
around reliability, failure manage-ment/failover, and exception condition management.
What isn’t needed are new management practices.
Both Ignite and IoT Methodology
are monolithic methods that reuse
many existing generic practices, combining these with new innovative practices specifically for the Io T—sadly, in
a way that makes the new practices
difficult to reuse and share. This issue
can be easily fixed, however, by taking
them to the next level by
essentializing them and freeing their practices.
This means capturing the essence
of a practice, which consists of the
things to work with, things to do, and
competencies and patterns to provide
minimal explicit guidance to apply
the practice effectively. This does not
just make the practices more acces-
sible, but it also makes them easier to
learn, change, and use for teams that
adopt them. Later, we look at how one
of them—the Ignite Methodology—
could be essentialized.
The Io T Needs Essence
As discussed previously, the IoT requires many methods and practices,
some of them specific to the domain
and others that are generally accepted
good software development practices.
For example, they need to deal with
specific problems of distribution and
mobility, yet at the same time they
must be grounded in sound architecture practices.
Essence and practices. The software development world has already
identified and described hundreds
of different practices, some of which
are shown in Figure 1. Those shaded
in green are selected for an Io T team.
In an ideal world teams would be able
to select the set of practices they need
to address their current situation and
easily assemble them into a method.
For example, a team building software
for the Io T with a high level of engineering complexity and a high rate
of change may choose to base their
method on the practices highlighted
in green using Use Case and Architectural Essentials to provide the required engineering rigor, and Scrum
and Agile Modeling to cope with the
high rates of change.
The problem is these practices
come from different sources and do
not share the common ground needed
to allow them to be readily composed
into an effective method. This isn’t a
problem unique to the Io T; it is a problem that has been plaguing the software industry since its inception and
one that gets worse with every advance
How can teams be empowered to
own and control their methods while
providing them with the guidance
they need to be successful, and reflecting the owning organization’s need
for governance and compliance? How
can teams benefit from the growing
practices and then
into many methods.