The appeal of this is immediately apparent: the more
connected devices a business has, the more opportu-
nities to improve visibility and make better decisions
on how to operate.
Large enterprises, especially those that are distrib-
uted, with many locations and assets to monitor, are
struggling with the surging need to connect, main-
ta in and effectively manage all the devices. At the
same time, as enterprises begin to realize the disrup-
tive potential of IoT, they are struggling with how to
rapidly meet the changing needs of the business
while building solutions and infrastructure that will
scale securely and cost-effectively.
The Lean Startup Philosophy
Four years ago, when my last startup was incubating
a new automated IoT logistics solution, we decided to
build it as a cloud-based service running on AWS. At
the time, this was an obvious choice. We were firm
believers in the Lean Startup, a popular book by Eric
Ries, in which “failing fast,” “minimum viable product
(MVP),” and “DevOps principles” were the order of the
day. Building on top of AWS quickly provided us with
global reach at reasonable cost while we developed
the initial MVP, secured our initial customers and
scaled the company. We leveraged a variety of the
then-available AWS services, such as compute, stor-
age and database, but by and large we had to develop
most of the core services ourselves using open source
technologies and our own homegrown analytical
models.
Fast forward a few years. If we were starting today,
our design and architectural approach would be very
different. In the fast-moving world of startups — and
of today’s most innovative enterprises as well — time-
to-market is absolutely critical to any initiative’s
chance of success. In the case of a startup, it also can
mean the very survival of the company.
Therefore, today there would be a low-to-zero per-
cent chance that we would build a platform from the
ground up. Rather, we would develop our solution on
top of someone else’s cloud-based IoT platform. But
which one would we choose? As we say in the con-
sulting world: “It depends...” Indeed, the answer
would very much depend on which industries, solu-
tions, geographies and markets our products were
seeking to serve.
Lock-In Concerns
We often hear concerns from our clients regarding
“cloud-lock,” where clients seek to “maintain option-
ality,” and then make design decisions that rely heav-
ily on generic, open source products and tools. How-
ever, they make this compromise of perceived code
portability at the expense of leveraging native, highly
optimized, cloud vendor-provided services and fea-
tures that can dramatically increase solution
performance.
The exact same argument can be made against “plat-
form-lock,” where choosing the wrong vendor may
limit future integration or deployment capabilities.
While there may, in fact, be a trade-off in terms of
absolute, long-term flexibility when making a plat-
form decision, in many cases the benefits gained in
capability, consistency and time-to-market far out-
weigh the risks of lingering platform-lock concerns.
While every client has its own set of technical and
business challenges, as consultants we often observe
patterns across clients as we deliver solutions. Our
clients value the experience, frameworks and reus-
able assets we bring to the table, which in turn allow
us to implement best practices quickly and achieve
the shortest possible time-to-value.
One of the most effective ways we achieve this is by
focusing on, and building competency in, what we
believe to be the best-of-breed IoT platforms that are
quick to deploy from an infrastructure perspective,
and that subsequently allow us to build and deploy
robust business applications and solutions on top.
In other words, there are a lot of factors tied up in
helping our clients choose the right platform for their
needs, and ensuring that it is quickly adopted by the
business, its employees, partners and customers.
Choosing the right platform can unlock tremendous
value and set our clients on the path to success.
Choosing the wrong one may lead to project delays
and missed opportunities.
WINTER 2018 | THE DOPPLER | 51