A Framework for Developing IoT-related Solution Architecture Blueprints

© Dr. Stefan Malich 2019© Dr. Stefan Malich 2019
A Framework for Developing
IoT-related Solution Architecture
Blueprints
Version 1.0
1

© Dr. Stefan Malich 2019
1
0
2 3 4
Table of Contents
2
• Views on the solution
architecture blueprints
• Reuse of the ArchiMate®
standard
• Definition of the different
views
• Objectives & structure of
the framework
• Solution architecture
blueprints as intermediate
design models
• Maturity model for smart,
connected products
• IoT-related business
domains
• Development of a library of
IoT-related solution
architecture blueprints
• The Big Picture: A
collaborative development
approach
• Smart, connected products
enable digital transformation
• The risk of operational
disruption
• An incremental approach to
address complexity & risk
• IoT-related strategies &
architectural solution
blueprints as enablers
Digital Transformation &
Challenges related to IoT
Introduction & Motivation
The Idea: A Library of
Architectural Blueprints
A Framework for the
Blueprint Library
Description of Solution
Architecture Blueprints

0
3
• The Slidedoc concept
• Experimenting with the Slidedoc concept
Introduction & Motivation

The Slidedoc Concept
4
"Simply put, Slidedocs communicateon your behalf.“ – Nancy Duarte, Duarte Inc.
Some time ago I discovered the Slidedoc1)
concept developed by Nancy Duarte. A
Slidedoc is a document which was
developed using presentation software and
uses visuals and words to convey well-
structured content without the attendance
of a presenter. It is a medium that can be
read easily and digested more quickly than
either a document or a presentation.
Nancy Duarte described the Slidedoc
concept by using the concept itself: A
Slidedoc in PowerPoint© format.
Duarte, Nancy: Slidedocs - Spread ideas
with effective visual documents
1) Slidedocs™ is a trademark of Duarte Press LLC. All rights reserved.

Experimenting with the Slidedoc Concept
5
As I'm working in the consulting and
professional services business for some
time, I always have a special focus on
effective communication and high-quality,
structured deliverables. Therefore, the
Slidedoc concept particularly resonates
with my professional motives and I wanted
to experiment with it.
The document you're reading right now is
my first Slidedoc. I've developed my own
PowerPoint© template and converted one
of my blog posts into the Slidedoc format.
Although I've enriched this version of the
post by further figures and visuals, the
content is almost the same.
evaluation of the result to you as a reader.
In any case I'd be happy to receive your
feedback. At least I have my own Slidedoc
template now.
Of course creating a Slidedoc requires
additional effort which should be weighed
against the increased value for the
consumer. However, I'd like to leave the

1
6
• Smart, connected products enable digital transformation
• The risk of operational disruption
• An incremental approach to address complexity & risk
• IoT-related strategies & architectural solution blueprints as enablers
Digital Transformation & Challenges related to
the IoT

Smart, Connected Products enable Digital Transformation
7
Smart, connected products
(aka the Internet of Things)
amalgamate hardware assets,
microprocessors, data storage,
sensors, software and
connectivity in various ways.
They enable the digital
transformation of asset- and
product-related business
operations and corresponding
operational technologies.
Smart,
Connected
Products

Integration is Essential to Smart, Connected Products
8
However, only a few solutions related to smart, connected products (or the IoT) are developed from scratch
and have to be integrated into existing business operations and IT landscapes. Therefore, they leverage
existing operational technology systems and have to be integrated with existing business applications in order
to support end-to-endprocesses.
An IoT solution is typically
broken down into three layers
which have to be integrated.
The edge is the layer where
information is digitized and
collected from the environment
by smart, connected products.
The platform ingests, stores
and analyzes the data. It could
integrate with existing SCADA
and operational technologies.
The enterprise layer represents
the business processes,
applications and services.
Edge Platform Enterprise
• End-to-End
Business
Processes
• Existing Business
Applications &
Services
• Data Ingestion
• Data Analytics
• Platform
Management
• Existing SCADA &
Operational
Technologies
• Smart, connected
products including
sensors &
actuators
• Gateways &
Aggregation
Devices

Adoption of Smart, Connected Products is involved with Operational Risk
9
IoT-related projects and
solutions typically contain a lot
of interdependencies on
business and IT level resulting
in complex integration
scenarios which in turn lead to
sophisticated architectural,
testing and monitoring
requirements.
Furthermore, as IoT is focusing
on the digital transformation of
business operations, it aims at
changing and improving the
existing asset-/product-related
processes and services, which
bares the risk of interrupting
them.
Edge Platform Enterprise
• End-to-End
Business
Processes
• Existing Business
Applications &
Services
• Data Ingestion
• Data Analytics
• Platform
Management
• Existing SCADA &
Operational
Technologies
• Smart, connected
products including
sensors &
actuators
• Gateways &
Aggregation
Devices

An Incremental Approach is Key to Address Complexity and Risk
10
More often than not business operations and solutions are developed and changed incrementally across several sprints, increments
and/or projects. In order to manage and reduce the risk inherent in the development and change of IoT-related business operations
and solutions, any organization should use a strategy and target architecture to plan and align the required business changes and
solution components – independently of the chosen development methodology (plan-driven, agile or hybrid).
1 2 3
Strategy
Target
Architecture

Target Architectures and Architectural Solution Blueprints are Enablers
11
An IoT-related strategy enables an organization to implement a portfolio of business capability enhancements and plan the
implementation of solution components accordingly. Target architectures and architectural solution blueprints are critical enablers of
such an IoT-related strategy. The former defines a high-level, medium- to long-term, strategic target state of an IoT solution. The latter
refines and guides the incremental development of a target architecture along a set of sprints, increments or projects. Both should be
leveraged to manage complexity proactively, support the progressive build-up of skills and knowledge, enable agility and the
incremental delivery of business and IT capabilities along the execution of the strategy.
1 2 3
Architectural
Solution
Blueprint
Architectural
Solution
Blueprint
Architectural
Solution
Blueprint
1 2 3
Strategy
Target
Architecture

IoT-related Reference Architectures should be leveraged
12
In order to develop target architectures and
architectural solutions blueprints, reference
architectures should be leveraged to
quickly build up the knowledge of the
problem domain.
In relation to the domain of IoT (or smart,
connected products) there are vendor-
specific and non-proprietary reference
architectures available.
Check out my former blog post on non-
proprietary reference models and
architectures related to smart, connected
devices and the Internet of Things.
IoT-related
Reference
Architectures
Non-proprietary
Reference
Architectures
Vendor-specific
Reference
Architectures

Challenges with Existing Reference Architectures
13
However, the existing non-proprietary
reference architectures are quite abstract
and don't consider existing IoT platforms
which can be leveraged to implement IoT-
related solutions.
The existing vendor-specific reference
architectures developed by the various IoT
platform providers are too generic as they
for example don't distinguish between
different IoT domains.
They typically focus only on the set of
services provided by a single IoT platform
provider and therefore don't sufficiently
support the incremental analysis, design
and implementation of an overarching IoT
solution.
Therefore, many organizations grapple
with the question of how to incrementally
design and implement IoT-related solution
architectures based on the services
supplied by the IoT platform providers.
Particularly they are challenged by the
problem of how to extend and enhance the
architectures of existing IoT-related
applications (e.g. SCADA, OT
applications) and how to leverage and
integrate the services of a specific IoT
platform provider into existing IT
landscapes.

2
14
• Development of a library of IoT-related solution architecture blueprints
• The Big Picture: A collaborative development approach
The Idea: A Library of Architectural Blueprints

Development of a Library of IoT-related Solution Architecture Blueprints
15
The challenges can be addressed by a library of IoT-related solution architecture blueprints which considers
different IoT domains and the incremental delivery of business and IT capabilities required in each phase of an
IoT adoption journey.
The library is structured by two
dimensions: The IoT domain and maturity
stage of the IoT journey.
This structure supports the identification
and selection of an appropriate set of
solution architecture blueprints in line with
the specific IoT adoption journey of an
individual organization.
Each solution architecture blueprint guides
the development of a concrete transition or
target architecture by defining the
fundamental structure and interaction of
components, services and interfaces.
A blueprint represents an intermediate
design model, which is more concrete than
a reference architecture but less detailed
that a concrete solution architecture.
Particularly, it is more detailed than the
existing IoT-related non-proprietary
reference architectures and more specific
that the reference architectures typically
supplied by the IoT platform providers.
Maturity Stages
Domains
Solution Architecture
Blueprints

The Big Picture: A Collaborative Development Approach
16
As the development of such a
library of IoT-related solution
architectures is a huge effort,
the overarching idea of this
work is to inspire collaboration
and knowledge sharing within
the community of architects.
Such an approach would
distribute the work load and
thus speed up the identify-
cation, design and document-
tation of all solution architect-
ture blueprints along the
structure of the library.
This Slidedoc and the
corresponding blog post are
supposed to be a starting point
and focus on the framework
which structures the library of
solution architecture blueprints.
Maturity Stages
Domains
Blueprints

3
17
• Objectives & structure of the framework
• Solution architecture blueprints as intermediate design models
• Maturity model for smart, connected products
• IoT-related business domains
Framework to Structure the Blueprint Library

Objectives of the Framework
18
The framework aims at providing a holistic view on the IoT/smart, connected products space.
It considers different business domains
because they have different objectives,
characteristics and value propositions in
relation to IoT. Thus, each domain requires
different business and IT capabilities.
In addition, the framework distinguishes
successive maturity stages which
represent sets of product functions and
capabilities.
The different stages support an
incremental adoption approach of the IoT
and ensure that product functions and
capabilities are designed and implemented
in a reasoned sequence.
Maturity Stages
Domains
Blueprints

Structure of the Framework
19
The framework organizes the library of
solution architecture blueprints based on a
table.
The columns represent different capability
maturity stages for smart, connected
products based on a model by Michael E.
Porter and James E. Heppelmann.
Porter, M.E.; Heppelmann, J.E.: How
Smart, Connected Products Are
Transforming Competition. In: Harvard
Business Review, November 2014.
The rows distinguish between different
IoT-related business domains.
The cells at the intersection of a row and a
column demarcate one distinct solution
architecture blueprint of the library.Maturity Stages
Domains
Blueprints

Maturity Model for Smart, Connected Products
20
The maturity model groups product
capabilities into four areas which represent
the following maturity stages: Monitoring,
Control, Optimization and Autonomy.
Each stage is valuable in its own right and
represents the foundation for the next
stage. A smart, connected product could
be developed towards the highest stage.
However, an organization has to
individually assess the target maturity
stage for a specific smart, connected
product based on the customer value
delivered and the competitive advantage
realized.
In other words not every product has to
achieve the highest stage of Autonomy but
each stage builds on the preceding one by
leveraging the corresponding product
functions and capabilities of the previous
stage.
Autonomy
Optimization
Control
Monitoring

Monitoring Stage
21
In the initial Monitoring stage the smart,
connected product is able to observe it’s
condition, operation and external
environment based on sensors and
external data sources. The generated data
can be used to analyze how the product
operates and how it is actually used.
Monitoring data is the foundation for
triggering alerts such as deviations in
performance and enables fact-based
feedback loops into e.g. the product design
and the after-sales service domain.
Autonomy
Optimization
Control
Monitoring

Control Stage
22
The Control stage is characterized by
additional control functions that are either
realized as remote commands or
algorithms that are executed as part of the
product or in a back-end system.
Algorithms are rules that steer the product
to respond to specified changes in its
condition or environment. The control
function enables customization and
personalization of the product.
Autonomy
Optimization
Control
Monitoring

Optimization Stage
23
The Optimization stage leverages the
Monitoring and Control capabilities to
realize enhanced algorithms and analytics
that optimize the product performance and
usage.
Real-time, historical and/or additional data
are combined to improve output, utilization
and efficiency of the products.
Those enhanced algorithms and analytics
enable use cases like preventative
maintenance, yield optimization and asset-
as-a-service models.
Autonomy
Optimization
Control
Monitoring

Autonomy Stage
24
The Autonomy stage builds on top of the
Monitoring, Control and Optimization
capabilities to enable the products to learn
about their environment, self-diagnose
their own service needs, and adapt to
users’ preferences. This allows smart,
connected products to achieve a
previously unattainable level of autonomy
and reduces the need for human
operators.
In the Autonomy stage the responsibilities
for a human operator shifts from managing
the individual products to managing a
complete product/asset portfolio or a
system as a whole.
Smart, connected products in the
Autonomy stage are also enabled to
collaborate with other products and
systems. Thus, those products implement
algorithms that leverage data about their
own performance and external
environment which encompass the
operation and behaviour of other products
in a broader system.
Autonomy
Optimization
Control
Monitoring

Different Domains related to the IoT
25
The IoT-related domains are Consumer,
Industrial and Smart City.
Each domain has different characteristics,
objectives and value propositions and
therefore, requires different business and
IT capabilities.
Domains
IndustrialConsumer Smart City

Consumer Domain
26
The Consumer domain is characterized by
the fact that after the sales and delivery
phase the customer possesses the
physical product and usually the producer
has no physical access anymore. Thus, a
remote device management is required to
support ongoing usage and operation of
the product including e.g. security updates,
provisioning of new and enhanced
functionality, customer support etc.
The objectives within the Consumer
domain are typically related to delivering
value to an end user, responding to
customer-specific requirements and
providing sophisticated customer user
experience and usability.
Value propositions are focused on fighting
against commoditization by making
products smart (i.e. differentiating products
and services) and transforming the
customer engagement from a one-time buy
transaction to an ongoing service
relationship.
ConsumerProducer
Remote Device
Management &
Customer Support
Customer Experience &
Personalization

Industrial Domain
27
Within the Industrial Domain a customer
can either possess or lease a physical
product. If a service contract is
established, the customer grants the
product producer service-related physical
assess to the product after the sales and
delivery phase. Usually the physical
products are already managed by existing
SCADA/OT systems that are deployed at
the customer's site and implement a
peripheral asset management capability.
The products in the Industrial domain are
embedded into the core business
processes (e.g. manufacturing, supply
chain, etc.) and therefore, require close
integration with the existing back-end
systems of an organization. The core
business processes within the Industrial
domain typically imply demanding non-
functional requirements (e.g. performance,
The value propositions focus on improving
output, utilization and efficiency of the
products and increasing the efficiency and
effectiveness of industrial business
processes within and beyond a single
organization.
security and reliability) which apply to the
smart, connected products too. The
objectives within the Industrial domain are
centered around optimizing the product
usage and value chain, enabling the
collaboration with partners and sharing of
product data.
ConsumerProducer
Customer Support &
Maintenance
SCADA/OT Systems &
Integration with Core
Business Processes

Producer
Producer
Smart City Domain
28
The Smart City domain is characterized by
close collaboration and integration of
citizens, municipalities, providers of public
services and IT service providers.
Typically, multiple providers have to be
integrated because they are commissioned
and responsible for different parts of a
large system. There is a strong focus on
openness and interoperability in order to
increase the flexibility and reuse of data,
functions and features across all
participants of the system.
The products, in the context of the Smart
City domain, could be either existing
resources of municipalities and providers
of public services or newly deployed
devices and sensors which provide data of
the external environment. The latter could
require a remote device management to
register and
The Smart City domain aims at increasing
the value for the citizen and optimizing the
usage of municipal resources. This can be
achieved by different use cases which are
based on the collaboration and data
sharing of all involved parties in a smart
city context.
manage products and/or sensors along
their life cycle.
Depending on the use case there are
specific requirements related to privacy,
safety and reliability in the Smart City
domain.
Service Provider CitizenMunicipality
Asset & Data
Management, Data
Access
Solution Development
& Operations
Service Consumption
& Data Provisioning

Complete Framework
29
The cells of the table represent one unique solution architecture blueprint. A blueprint describes an
intermediate design model which is more detailed than the existing IoT-related non-proprietary reference
architectures and more specific that the reference architectures typically supplied by the IoT platform
providers.
AutonomyOptimizationControlMonitoring
ConsumerIndustrialSmartCity
Blueprint C1
Blueprint C2
Blueprint C3
Blueprint C3
Blueprint I1
Blueprint I2
Blueprint I3
Blueprint I4
Blueprint S1
Blueprint S2
Blueprint S3
Blueprint S4
Maturity Stages
Domains

4
30
• Views on the solution architecture blueprints
• Reuse of the ArchiMate® standard
• Definition of the different views
Description of Solution Architecture
Blueprints

Views on the Solution Architectural Blueprints
31
Each blueprint is described by the
following views which adress different
concerns: Quality attributes, business,
application, technology, development &
operations and cost.
Views on each
Blueprint
Quality
Attributes
Business
Application
Technology
Development
& Operations
Cost
Solution
Architecture
Blueprint

The ArchiMate Framework1)
Reuse of the ArchiMate® Standard
32
In relation to the perspectives on the
business, application and technology, I'm
currently considering to reuse at least the
metamodel of the corresponding layer of
ArchiMate standard.
The Open Group: ArchiMate® 3.0.1
Specification. Open Group Standard,
August 2017.
Although ArchiMate is a modeling
language for enterprise architecture, it fits
well to define an encompassing, high-level
solution architecture.
Views on the
Solution
Architecture
Blueprint
Quality
Attributes
Business
Application
Technology
Development
& Operations
Cost
1) Source: The Open Group: ArchiMate® 3.0.1 Specification. Open Group Standard, August 2017.

Integrating the Reference Architectures of IoT Platform Providers
33
The application and technology views
require an additional logical design layer
which further refines the architecture for a
single IoT platform provider. This
additional layer refers to the specific
reference architecture of an IoT platform
provider and considers the provider-
specific IT services and terms. It
substantiates the reference architecture by
focusing only on the mandatory structure
and interaction of components, services
and interfaces which are required at a
certain maturity stage in a specific domain.
Views on the
Blueprint
Quality
Attributes
Business
Application
Technology
Development
& Operations
Cost
Generic
Application View
Provider-specific
Application View
Generic
Technology View
Provider-specific
Technology View

Parts of a Quality Attribute Scenario
View on the Quality Attributes
34
A quality attribute is a testable property of
a system that is used to indicate how well
the system satisfies the needs of its
stakeholders1). The view on the quality
attributes focuses on the properties which
are significant to the unique solution
architecture blueprint. It elaborates on
general quality attribute scenarios which
are a means to describe quality attribute
requirements on a system-independent
level and constitute the basis for specifying
concrete quality attribute scenarios in an
individual project. Furthermore, the view
considers the architectural tactics and
pattern which are typically leveraged by
the IoT platform providers and therefore
have an impact on the design of the
solution architecture blueprint.
1) See: Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 3rd Edition, Addison-Wesley, Boston et al. 2012.
Artifact
Source of
Stimulus
Response
Measure
Environment
Stimulus Response
Example: General Availability Scenario
Artifact:
IoT Hub
Source of
Stimulus:
End Device,
Edge Device
Response
Measure:
Repair Time,
Failover Time
Environment:
Normal,
Region Failure
Stimulus:
Data Event,
Control Event
Response:
Process &
Store,
Buffer,
Re-Route

View on the Business
35
The business perspective elaborates on
the structure and interaction between the
organization, functions business processes
and information needs.
It uses elements like e.g. business service,
business interface and business event to
describe a high-level business architecture
supporting the corresponding maturity
stage and domain.
The ArchiMate® Business Layer Metamodel1)

The ArchiMate® Application Layer Metamodel1)
View on the Application
36
The application view describes the
information systems architecture including
the application architecture that is to say
the structure and interaction of
applications. Particularly, it models how an
IoT solution has to be integrated with
existing systems/applications like SCADA,
OT, customer relationship management,
billing & invoicing etc.
It leverages the elements of the ArchiMate
application layer metamodel (e.g.
application component, function,
interaction & service) to illustrate how an
IoT solution works and how it is
collaborating with other applications in an
encompassing landscape.

View on the Technology
37
The view on the technology represents the
structure and interaction of the platform
services, logical and physical technology
components. It contains ArchiMate
elements like device, system software,
technology interface and communication
network to model the structural and
behavioral elements of the technology
architecture.
Edwards, Charles: Hosting and Cloud
Software Delivery modelled in Archimate.
Blog post on www.agileea.com, April 19,
2017.
Particularly, the specialization relationship
of ArchiMate can be used to introduce an
additional logical design layer and
incorporate the provider-specific IT
services and terms.
Those elements can be used to describe
various hosting and cloud delivery models
including the IoT-related cloud services of
the various IoT platform providers.
1) Source: The Open Group: ArchiMate® 3.0.1 Specification. Open Group Standard, August 2017
The ArchiMate® Technology Layer Metamodel1)

View on the Development & Operations
38
The development and operations view elaborates on special aspects which should be considered during the
development and operation phase of an IoT solution.
In relation to the development phase, for
example, it is crucial to identify the parts of
the solution which could be developed
using agile methods and which parts
should be developed using plan-driven
methods.
Boehm, B.; Turner, R.: Balancing Agility
and Discipline: A Guide for the Perplexed.
Addison-Wesley, Boston et al. 2003.
Furthermore, this view details IoT-specific
aspects of testing, monitoring and
automation. IoT solutions are usually
difficult to test and simulate due to the fact
that they are integration-heavy and could
contain singular assets, products or
devices. Those could be linked with size,
cost and complexity constrains which
prevent them from being integrated into an
IoT lab or the testing concept and process.
One example of the Industrial domain are
expensive manufacturing facilities: Usually
it doesn't make sense from a financial
perspective to purchase and set up
another unit of the facility just for testing.
The end-to-end monitoring of an IoT
solution could be another challenge.
Generally existing monitoring tools should
be leveraged and for each of the
components of an IoT solution and it
should be clarified how it will be monitored.
The operation of an IoT solution could be
complex due to the distributed and
integration-heavy nature of the domain. In
order to address this challenge the
concepts and tools for automation should
be leveraged intensively. Thus, a solution
architecture blueprint is proactively
considering the automation requirements,
pattern and services of the IoT providers.
IoT-specific
Testing,
Monitoring &
Automation
Requirements
Development &
Operations Cycle
Existing
Concepts,
Pattern &
Tools

View on Cost
39
The view on cost focuses initially on the operating costs of the IoT solution.
The idea is to use the required services
and the corresponding cost calculation
tools of the IoT platform providers1) to
develop a high-level cost model for
calculating the cost based on a sizing
model which includes API calls, messages,
data volumes, number of users, etc.
1) Examples: Microsoft Azure Price Calculator, AWS Pricing Calculator, GCP Pricing Calculator
Solution
Architecture
Blueprint List of Required
IoT-related
Services
Sizing Model Cost Model
Of course this isn't a complete and precise
cost model, but I think it greatly supports
the understanding of the various cost
elements, drivers and influencers.
Cost Calculation
Tools of the IoT
Platform Providers

Summary & Conclusion
41
Smart, connected products enable digital
transformation but also entail challenges
related to complexity, operational
disruption, security, etc.
An incremental approach guided
by an IoT-related strategy and
target architecture is key to
address these challenges.
Particularly, target architectures and
architectural solution blueprints should be
leveraged to manage complexity pro-
actively, support the progressive build-up
of skills and knowledge, enable agility and
the incremental delivery of business and IT
capabilities along the execution of the
strategy.
The framework described in this Slidedoc
is considered only as a starting point. It
provides a holistic view on the IoT (or
smart, connected products) space and
structures the set of solution architecture
blueprint based on a maturity model for
smart, connected products and different
IoT-related domains.
The next logical step of this work is
to elaborate, prototype and
document the first solution
architectural blueprint.
The documentation approach and format
should be then established as a template
for documenting the other blueprint.
The proposed library of IoT-related
solution architecture blueprints can
be used to guide the development
of target architectures and
architectural roadmaps.
However, as the development of such a
library of IoT-related solution architectures
is a huge effort, this Slidedoc also aims at
inspiring collaboration and knowledge
sharing within the community of architects.
The distribution of work load would speed
up the identification, design and
documentation of all solution architecture
blueprints along the structure of the library.
The usage of common architectural
concepts like quality attribute scenarios
and open standards like ArchiMate greatly
support this collaborative approach.

Thank You
42

Contact me
43
stefanmalich.com hello@stefanmalich.com Dr. Stefan Malich @stefan_malich
@

Engage me, I’d love to help!
44
Software
Architectures
Whether you pursue to
design a new architec-
ture or your existing
architecture requires a
review, I can support
you along the complete
architectural lifecycle.
I'm proficient in the
structured design and
evaluation of software
architectures based on
proven concepts and
methods, and indepen-
dent of the chosen de-
velopment methodology
(plan-driven, agile or
hybrid).
Presentations &
Talks
I love to speak about
architectural change
management. Topics
can include architecture-
related methods and
processes, the compre-
hensive adoption of
technologies, the appli-
cation of innovative
architectural patterns
and designs and much
more. Of course, focus
and contents of the
presentations can be
tailored to your indivi-
dual needs.
Architectural
Scaling of Start-Ups
I've gathered extensive
practical experience
related to the implemen-
tation and roll-out of
products and services
from an end-to-end
perspective. It doesn't
matter whether your are
a self-contained or intra-
corporate start-up, I can
assist you scaling your
business from an archi-
tectural, overarching
perspective ‒ including
your IT systems, gover-
nance, organization and
processes.
Adoption of
Technologies
If you would like to
assess the potential of
technologies like cloud,
IoT or AI in your corpor-
ate context, I can facili-
tate a structured evalua-
tion and adoption pro-
cess. I'm experienced in
the evaluation and intro-
duction of new tech-
nologies on corporate-
level including the im-
plementation of the re-
quired changes to your
governance, organiza-
tion, processes and skill
sets.
Coaching &
Trainings
From my perspective
coaching and training
are essential parts of an
encompassing, architec-
tural change journey.
However, I also offer
dedicated, custom
coaching and training
sessions on executive,
team and individual
level.

A Framework for Developing IoT-related Solution Architecture Blueprints

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to A Framework for Developing IoT-related Solution Architecture Blueprints

Similar to A Framework for Developing IoT-related Solution Architecture Blueprints (20)

Recently uploaded

Recently uploaded (20)

A Framework for Developing IoT-related Solution Architecture Blueprints