(AIA). The intention is that the PD
practice should be used to conduct
project self-assessments, compare
different IoT options, and select the
solution architecture and technologies to be used in a project. The AIA
practice is then used to identify the
devices, gateways, and services, and
their responsibilities for an enterprise solution. Ignite provides a set
of technology patterns (such as machine-to-machine connectivity, and
sensor networks, among other).
The benefit of Ignite is that it is
based on real-world experience, capturing this experience and best practice in
a well-thought-out and comprehensive methodology. Naturally, the first
thought of the authors of the methodology was not so much about the modularity of the practices described but
about the completeness and relevance
of the method as a whole.
The IoT Methodology. In comparison, the IoT Methodology2 is a lightweight method highly inspired by lean
startup12 and design thinking.
1 It involves the following iterative steps:
1. Co-create. Communicate with end
users and stakeholders to identify pain
problem areas in a nontechnical way.
2. Ideate. Simplify discussions to communicate requirements to designers,
implementers, and project managers.
3. Question and answer.
Translate soft concepts into hard requirements, analyze solutions, and brainstorm options.
4. Map Io T OSI (Open Systems Interconnection). Map requirements to
a valid architecture, infrastructure,
and business frameworks, similar to
the layered approach used in the ISO/
5. Prototype. Use standardized tool-kits to build prototypes and iterate toward minimal viable products.
6. Deploy continuously to close the
feedback loop and improve the products.
Like Ignite, this seems to be a very
generic method at the high level.
What’s so special about Io T Method-
ology is its use of an Io T Canvas and
an IoT OSI reference architecture.
The IoT Canvas is an adaptation of
the business model/lean canvas used
in brainstorming sessions to validate
minimal viable product requirements
for IoT projects. The IoT OSI refer-
ence model is an adaptation of the
the high-performance, highly reliable,
highly governed, secure, resilient, scal-
able systems needed to process, ana-
lyze, and respond to the vast amounts
of data they produce, and everything
in between. Not only that, the rate of
change and the need for innovation
will never have been higher.
The Io T Needs Everything
The IoT does not lack methods. Researching the space shows clearly,
and not surprisingly, that there is
not a one-size-fits-all approach. Instead, methods for waterfall and Agile, methods for small applications
(apps) and for complex systems of
systems, and methods for systems
engineering (that is, for systems with
hardware and software integrated)
are all still needed. What is really
new is that a larger vendor needs all
this at the same time and with compressed time scales, which increases
complexity significantly. Thus, for
larger vendors a multitude of methods are needed. A smaller vendor
needs a more specific and focused
approach, but one that can grow as
new products evolve and new problems emerge. Thus, methods such as
Rational Unified Process (RUP) and
SAFe, and practices such as Scrum,
user stories, and use cases are all being applied. As always with any new
trend, new branded methods are
born. Literature regarding methods
for the Io T is extremely sparse at the
time of this writing. We have found
two methods within the domain: Ignite13 and the Io T Methodology.
The Ignite IoT Methodology.
Ignite is an enterprise methodology for
a major player in the Io T. It is a “big
method” covering all aspects of developing for the Io T. It has two major
practice areas. (In this article, practice
is defined as a repeatable approach
to doing something with a specific
purpose in mind.
9 Practices are the
things that practitioners actually do.)
These areas are strategy execution and
solution delivery. Strategy execution is
about agreeing what to build (that is,
the solution) and involves the practices of opportunity identification,
opportunity management, and initiation. Solution delivery is about delivering the solution to users, and it has
a life cycle consisting of planning,
building, and running (that is, operating the solution). Planning involves
project initiation, whereas building
and running are carried out through
parallel project workstreams.
Project initiation is a set of practices that results in a number of different artifacts, including solution
sketches, a milestone plan, user interface mockups, and software architecture. Project workstreams consist of a
complementary set of practices (called
workstreams): project management,
cross-cutting, solution infrastructure
and operations, back-end services,
communication services, on-asset
components, and asset preparation.
At a high level, these might seem to
all be very general practices, but embedded within are two domain-specific practices: project dimensions (PD)
and asset-integration architecture
Figure 1. An abundance of practices.
PSP Process Essentials QA Essentials Agile Modeling Team Essentials