how an Io T application architecture is
described. The way teams work on an
Io T architecture is similar to the way
they work on other kinds of architectures. Thus, they do not introduce a
new Architecture alpha but reuse the
Architecture alpha and description
from the generic architecture practice. There are specific considerations
peculiar to Io T applications, however.
Hence, each of these domain-specific
practices introduces a pattern for describing an IoT application. A pattern
stereotypes to model the IoT application. In Unified Modeling Language
(UML) speak, this corresponds to a
4 UML profiles are a common approach to describe domain-specific architectures, and IoT is one
such domain. The AIA practice introduces an AIA pattern for the architecture description, whereas the IoT OSI
practice introduces an Io T OSI pattern.
At the very top is a technology-specific
architecture practice for EPC/REST-based Io T applications. This contains a
specific pattern for EPC/REST.
The layering of practices helps
practitioners understand what is
truly different when working with
IoT-based applications, as opposed
to a more general application. Under-
standing this difference helps practi-
tioners quickly pinpoint the specifics
they need to be aware of and, hence,
learn a domain quickly. This practice
separation is in contrast to monolithic
methods where salient aspects of such
methods often drown in the sea of ge-
neric information. It also helps prac-
titioners differentiate methods—for
example, Ignite and IoT Methodol-
ogy—from the way they work with ar-
chitecture and to understand if they
are truly different. Practice separation
also helps practitioners pick the best
parts from different methods, pro-
vided they have been decomposed,
as shown in Figure 4. This mix-and-
match approach helps teams become
innovative with methods, as well as
the solutions they produce.
Thus, architecture is one area that
needs special attention when building
IoT applications. Security and privacy
also need special consideration. The
Io T opens the world to new ideas and
use cases, and, as such, product idea
generation and formulation also need
special considerations. Each of these
areas require generic practices and
Welcome to the Future
The IoT promises a new dawn for all
sorts of industries, fundamentally
changing the basics of everyday life.
Let’s make sure our software-engi-
neering practices do not get left be-
hind. Let’s stop producing inflexible,
monolithic methods that are not easy
to adopt. Instead, the focus should be
on essentialized practices that provide
an incremental and safe path for teams
and organizations to evolve and grow
their ways of working.
By using Essence as the foundation
for a new practice library, we can liberate the practices and provide development teams with the guidance they
need to innovate, improvise, and excel.
We can avoid the traps of the past and
enable software-engineering methods
to evolve at Internet speeds while building on established, proven practices.
1. Brown, T. Design thinking. Harvard Business Review
86, 6 (2008), 84.
2. Collins, T. A methodology for building the Internet of
3. Evans, P.C., Annunziata, M. Industrial Internet:
Pushing the boundaries of minds and machines.
GE, 2012; www.ge.com/docs/chapters/Industrial_
4. Fontoura, M., Pree, W., Rumpe, B. The UML Profile for
Framework Architectures. Addison-Wesley Longman
5. Guinard, D., Mueller, M., Pasquier-Rocha, J. Giving
RFID a REST: Building a Web-enabled EPCIS.
Internet of Things. IEEE, 2010, 1–8.
6. Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I.,
Lidman, S. The Essence of software engineering: The
SEMAT kernel. Commun. ACM 55, 12 (Dec. 2012);
and acmqueue 10, 10; http://queue.acm.org/detail.
7. Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I.,
Lidman, S. The Essence of Software Engineering:
Applying the SEMAT Kernel. Addison-Wesley, 2013.
8. Jacobson, I., Ng, P.-W., Spence, I. The Essential
Unified Process. Dr. Dobb’s Journal (Aug. 2006); http://
9. Object Management Group. Essence—Kernel and
language for software engineering methods, 2014;
10. Page, V., Stimson, R. Essentializing the DSDM Agile
Project Framework. Agile Methods Conference,
London, 2016. Ivar Jacobson International; https://
11. Perkens-Golomb, B., Folkjaer, P., Rauch, F., Spence,
I. Ending method wars: The successful utilization of
Essence at Munich Re. Ivar Jacobson International,
12. Ries, E. The Lean Startup: How Today’s Entrepreneurs
Use Continuous Innovation to Create Radically
Successful Businesses. Random House, 2011.
13. Slama, D., Puhlmann, F., Morrish, J., Bhatnagar, R.
Enterprise Io T: Strategies and Best Practices for
Connected Products and Services. O’Reilly, 2015.
Ivar Jacobson, chair of Ivar Jacobson International, is
a father of components and component architecture, use
cases, the Unified Modeling Language, and the Rational
Unified Process. He has contributed to modern business
modeling and aspect-oriented software development.
Ian Spence is CTO at Ivar Jacobson International and
the team leader for the development of the SEMAT kernel.
An experienced coach, he has introduced hundreds of
projects to iterative and agile practices.
Pan-Wei Ng coaches large-scale systems development
involving many millions of lines of code and hundreds
of people per release, helping them transition to a lean
and agile way of working, not forgetting to improve their
code and architecture and to test through use cases
Copyright held by ownes/authors.
Publication rights licensed to ACM. $15.00.
Figure 4. Architecture practices in Ignite and Io T Methodology.
(Io T) Domain
Specific Practices EPC/REST
Io T OSI
(extends) (extends) (extends)
(extends) (extends) (extends)
Io T OSI
Layer Practices Alphas