In 2019 I delivered a design to integrate the IoT platform Device Simulator with IoT platform Connection and Analytics Services.
The objective of this design is to improve the customization of simulated device data and by automation of Data Management configurations enabling data to be stored in the DB2 data lake by the Connection Service.
“A LOB engineer running a POC can use out-of-the-box simulated device data and in a minute with no other actions required start exploring simulated entities and apply analytics functions to the simulated entity data”
Design Requirements
The requirements on this design
Device simulator shall by default be Activated
The Device Simulator editor shall provide a setting to “Save device events to the data lake”
The Device Simulator shall automatically generate and activate a physical and logical interface for a simulated device if the “Save device events” property is selected
The Device Simulator editor shall optionally allow a CSV file to be uploaded containing a simulated time series of data.
The Device Simulator shall construct an event payload schema from CSV file column names and data types.
The Device Simulator shall, by rows in the CSV file, send data events with column values as event payload.
The Device Simulator editor shall run (as-is) in the client browser. Closing the browser will terminate simulation and ingest of simulated data
The Device Simulator shall support the export/import of the simulator configuration.
Limitation: A user shall not be allowed to edit the simulated device type and the event payload schema after the physical and logical interface has been defined.
Production Design
The final Device Simulator production design.
Meet Chris is the Application Developer and Devon is the Edge Device Developer.
Chris and Devon are the most frequently used personas in the developer experience design across the platform capabilities.
Simulated Devices Design
The Device Simulator design in Watson IoT Platform enables developers to build and test the IoT applications without deploying physical devices beforehand.
In 2018 I delivered a design on the IoT Edge developer experience in the Watson IoT Platform.
What is IoT Edge?
Edge devices generally live on the edge of the network within an enterprise. They are specific hardware sensors, industrial controllers, or other industrial devices residing on private or potentially proprietary networks at a physical location.
Edge devices are creating quite a challenge for systems integrators since most are generally building cloud-based applications which rely on receiving information from IoT devices to accomplish the business goal.
There are many challenges that exist in developing a path for this information flow, including
Latency vs Time
Quality vs Time
Bandwidth and Cost
Security and Vulnerability
Compliance
Maintenance and operations
Read more about my design research on the IoT Edge experience in the Watson IoT Platform
Design Research on IoT Edge Design research on the IoT Edge experience in the Watson IoT Platform.
Hills
The Hills for IoT Edge may be viewed as a stack of capabilities that deliver value to the Business and the Solution.
“Chris, an IoT application developer, can develop and deploy applications that are transparent to the instrumentation of devices at the edge”
Hill 1 formulates the transparency of IoT Edge to solution development.
“Devon, an IoT Edge developer, can develop workloads for the edge using common cloud programming models, and automate workload distribution, management and updates on Edge Gateways”
Hill 2 expresses the WOW on adopting new Cloud programming models for the IoT Edge and moving away from the constraints of monolithic FW.
“Dave, an IoT Ecosystem Partner, can deliver IoT Gateway products with edge capabilities, managed by the IoT Edge”
Hill 3 that states the value to the partner ecosystem to leverage the IoT Edge as a platform for delivering edge-based services by shipping on or shipping with.
Design Vision
Chris, the IoT Application developer, can develop code to work with state and conditions of manageable assets, without knowledge of individual instrumentation, data workload distribution, or network connection state.
Using IoT Edge, Chris can
Create Edge Gateway types, select IoT Edge capabilities, and register Gateways, using the IoT Platform UI and APIs
Provision IoT Core capabilities to IoT Edge gateways
Distribute Data Management workloads to the edge to Filter Messages and Compute Device Device State and submit State Change Events
Connect devices to the Gateway to Ingest, Store and Forward MQTT messages
Develop and deliver cloud applications, independently of changes made to the edge instrumentation
Devon the IoT Edge developer, can develop workloads for the edge using common cloud programming models, and automatically distribute, manage and update workloads on Edge Gateways.
Using IoT Edge, Devon can
Create, build and upload custom containers to the IoT Edge component registry
Provision, Update and Manage custom containers on IoT Edge Gateways
Use the local MQTT message bus in IoT Core, to integrate messaging across custom containers, devices, and cloud
Create and test Cloud Functions on the cloud and configure as edge followers to run at the edge
Create aggregation of devices into Things
Create Rules and Actions, using Device and Thing state, and distribute as workloads to the edge
UX design
The User Experience of IoT Edge has three major parts
IoT Edge extensions to Watson IoT Platform Gateway Types
IoT Edge extensions to Watson IoT Platform Gateways
New IoT Edge Services
Developers will use existing concepts of IoT Platform Gateway Types. By choosing the option to make a Gateway an IoT Edge Gateway, developers get access to additional capabilities when defining a gateway type. The new capabilities are introduced together with the existing gateway properties or added as new tabs.
When adding a new Edge Gateway Type, a developer will create a gateway type, select the Edge option, and then choose the hardware architecture for gateways of this type. The options are Intelx86, ARM32, ARM64.
The developer can also optionally select Edge Services that will run on gateways of this type. The developer can browse the Edge Service Catalog for a list of services and available versions for gateways of this architecture. The latest version is shown by default. Alternatively, a different version can be viewed and selected.
For developers that want to get an overview of available Edge Services, the Edge Service Catalog is available for browsing and exploring the Docker images that have been configured for a service.
In 2017 I contributed to the design research and design concepts for Device Activity Policy for Risk and Security Management in the Watson IoT Platform.
What is Device Activity
Device Activity is an indicator of device health. In the Design Research on IoT Device Activity, it was proven that Time since the last message is a preferred metric on device activity and health. This new design for the Watson IoT Platform provides a new Risk and Security Management policy that defines the expected messaging activity for devices connected to the IoT platform. The policy monitors whether a device sends a request at least once every defined time period. A threshold for device activity can be defined generally for all devices, and exceptions defined for individual device types. Compliance with the Device Activity policy can be monitored on the dashboard, or reported on using drill-in reports.
Design Vision
The design vision for the new Device Activity policy is to call with the concepts already established for Risk and Security Management policers in the Watson IoT Platform. Learn more about the common design policies in Risk and Security Management Design. The new policy should be available in the Security section in the platform, next to other policies. The policy should have a simple default setting that applies generally across devices on the platform. This policy should set clear a clear threshold on the expended frequency of messages arriving from healthy devices exhibiting an active behavior. The policy should also allow exceptions to be set individually for any device type that differs from a default general policy. As an option, the threshold value may be set indefinitely to disable checking and make any devices of a type compliant.
Using compliance reporting, administrators and operators may identify any devices that exhibit unhealthy behavior. Drill-in reports allow users to view device status and perform diagnostic actions.
Personas
Risk and Security Management is primarily targeting two of the IoT personas
Adam is an IoT Security Operator. He ensures security and compliance by specifying policies that detect abnormalities and prevents devices to be compromised. He reports to audits on compliance with regulations and policy coverage on devices.
Sally is an IoT System Operator. She handles the day-to-day system operations on the LOB and client IoT organization. She makes sure that new device types and devices are registered, are behaving, and are up to date with recent secure firmware. She defines policies, creates and runs actions on policy alerts that act on misbehaving devices.
Hills
“Adam, the security analyst can define a Device Activity policy for devices, to determine whether a device is active or inactive by tracking how frequently a device talks to the platform, activating the policy, and reporting on the coverage of the policy, in under 5 minutes”
Use-Cases
As a security analyst, I can
View the default (disabled) device activity policy configuration
Modify the default device activity and set a messaging interval
Add a custom rule as exception device activity policy configuration for a device type
Preview the predicted compliance of the new policy configuration
Save and enforce the updated device activity policy configuration
UX Design
The UX design of the use-case above.
The UX design of the Device Activity policy.
Final Product Design
Final production design for Device Activity Policy editor.
Final production design for Device Activity Dashboard and Compliance Reporting.
Related Designs
Design Research on IoT Device Activity. Read more about the research on device behavior metrics to use for a Device Activity policy in Watson IoT Platform Risk and Security Management.
Risk and Security Management Design. Read more about the design of the Watson IoT Platform Risk and Security Management policies.
Compliance Reporting Design. Read more about the design for reporting compliance with Watson IoT Platform Risk and Security Management policies.
Watson IoT Platform Risk and Security Management Lab. DevZone Quick Lab at Think 2018 on Risk and Security Management.
Meet Sally the IoT System Operator.
Sally is one of the most frequently used operator personas in the design across the platform capabilities.
Also, meet Adam the IoT Security Operator.
Design Research on IoT Device Activity. Read more about the research on device behavior metrics to use for a Device Activity policy in Watson IoT Platform Risk and Security Management.
Risk and Security Management Design. Read more about the design of the Watson IoT Platform Risk and Security Management policies.
Compliance Reporting Design. Read more about the design for reporting compliance with Watson IoT Platform Risk and Security Management policies.
Watson IoT Platform Risk and Security Management Lab. DevZone Quick Lab at Think 2018 on Risk and Security Management.
In 2017 I delivered design concepts for an improved developer experience using a help hub capability in the Watson IoT Platform.
What is a Help Hub and a Side Panel
When users launch the Watson IoT service and open the IoT Platform web interface they are taken to the IoT platform dashboard. This default behavior is desirable and efficient for existing users of the IoT platform and takes them directly to an overview of the system state. The IoT platform dashboard is a flexible solution that allows users to use default boards, or configure their personal or team boards that present the right IoT system status to every user or team.
However, for new users entering the platform for the first time, this feature may be perceived as confusing. Users are left with the question “Ok, now what? You dropped me here, what do you want me to do?”
To improve the experience for developers exploring the platform we designed a Help Hub that answers just those questions. And, provides a structured journey for developers to quickly get started with the Watson IoT platform.
Design Vision
With the Help Hub design, we want to provide a simple onboarding experience for new users of the platform. The design should create a seamless learning experience within the Watson IoT Platform; gently guiding users toward the key ah-ha moments that allow them to form a mental model of the IoT platform and its resources. This will increase the likelihood that new users achieve their goals, gain satisfaction, continue engaging with key features, and happily refer the service to others.
The design should present a list of actions for the user to take to get started. The tasks should be context-sensitive. That is, actions are presented in a sequence of importance. Once an action is completed, new action(s) are activated and appear to the user. There are conditions that make actions active. For example, if there are no device types created the Help Hub should display a task to create a device type. Or, if there is only one user registered with the IoT platform, the Help Hub should provide an action to add additional team members as users.
Some users may find the pushing of tasks a bit annoying and will turn off such suggestions. Such users will find the Side Panel helpful as a way to, on-demand, see a list of recommended tasks and easy access to documentation.
User Research
In our research, we identified typical situations here the Help Hub and Side Panel are key to user success and satisfaction.
Getting started – Devon is an IoT developer in a new team formed to run a POC using IBM Cloud and Watson IoT Platform to build a demo IoT applications for a line of business in a week. The POC will provide new insights and optimizations for existing products or processes.
Devon, needs to
Solve a business problem through innovation
Build a PoC to secure ongoing funding & support
Anticipating production-level requirements: scale, DevOps, security, etc.
Needs to integrate with existing systems and processes.
Hills
“As a Developer with no prior IoT platform experience, I can within 15 minutes set up a new IoT platform organization and start developing and testing my IoT devices and applications.”
Help Hub Design Concept
The design concept for Help Hub identifies that
Developers will set up their development space in IBM Cloud, add a Watson IoT Platform service and launch the IoT Platform Dashboard
On the dashboard, the developer will see a clear call to action to get started
Enough context and information on the action will be provided directly on the dashboard
More detailed, deeper, information is available in the IBM Cloud documentation
Selecting an action will take the user directly to the right section of the IoT Platform
A pre-step is presented to the user. This describes the context, the resources, and the options and considerations to be taken.
When the action is completed, the user its taken to a post-step that salutes the achievement, and introduces the next action to be taken.
Use-cases
As a developer
I need to connect devices and get data flowing into the IoT Platform
I need to create my first Device Type
I Need to register my first Device
I need to connect my device to the IoT Platform
Or, I need to simulate a device
I need to enable my team members to access the IoT Platform dashboard
I need to add a Member
I need to enable my application to access the IoT Platform APIs
When launching the Watson IoT Platform for the first time, Devin is welcomed to the platform. The dashboard suggests that he registers a device or simulates a device. He is guided by the IoT platform on how to accomplish the action. New actions follow as he adds members and API keys to the platform.
Using the Help Hub
Final UX for Side Panel
When launching the Watson IoT Platform, Chris is presented with actions to connect devices and to register members and API keys. He clicks a button, indicating that he is not interested in any guidance. Later, Chris opens the Side Panel to view suggested actions and product documentation.
Using the Side Panel
Final Product Design
The final production design
Related Designs
IoT Platform Developer Experience Design research on the developer experience in the Watson IoT Platform.
Meet Chris is the Application Developer and Devon is the Edge Device Developer.
Chris and Devon are the most frequently used personas in the developer experience design across the platform capabilities.
IoT Platform Developer Experience Design research on the developer experience in the Watson IoT Platform.
Make and model of products from a single manufacturer include a lot of variability in the underlying components and sensors. When you are building IoT solutions to work with a range of connected THINGS from many suppliers, you start to realize the huge challenge you face managing the interaction with this broad and complex device ecosystem. Wouldn’t it be better if the IoT application developer could just interact with a standard resource model and the underlying IoT platform managed the relationship between the model and the real-world devices? Come and learn more about the latest innovations in the Watson IoT Platform.
This session presents the new Information Management capabilities in the Watson IoT Platform for device abstractions and things aggregation that is the basis for the Digital Twin work for IoT.
In 2017 I delivered design concepts for an improved developer experience using simulated devices in the Watson IoT Platform.
What is a Simulated Device
Devices are smart sensors that instrument equipment at the edge. They connect to the IBM Cloud through the Watson IoT Platform. Devices send messages, using the MQTT messaging protocol, to the IoT platform. The messages contain sensor readings formatted as JSON payloads.
To connect a device to the IoT platform developers need an actual physical device. Most IoT developer has devices ready to connect. But in some cases, a lack of an available device may become a delay in exploring the IoT Platform and start developing IoT applications. The IoT Platform should support developers to get started even without a physical device to connect. This blog describes the design of a new flexible capability to set up simulated devices in the Watson IoT Platform.
Design Vision
With Simulated Devices, we want to improve the getting started experience for device and application developers.
The design vision is to allow users to create simulated virtual devices of a new or an existing device type. Users should be allowed to define the messages that the device should send, set up a schedule for the frequency of messages to be sent, and then turn on the device. Directly in the IoT Platform. As simple as that!
We want to deliver this capability independently of the IoT Platform backend and make the simulator run in the client browser. We also want to be conservative about the number of messages and data volume sent to avoid choking the IoT platform with high volume data or spending the free data plan for trial IoT Platform clients.
User Research
In our research, we identify two developer personas.
Devon, a Device Developer. Devon develops and tests code for a device that integrates sensors and actuators with the OS and CPU board capabilities. He integrates MQTT and device management protocols on the device. He uses SDKs provided by chip manufacturers and applies security by design principles.
Chris, an Application Developer. Chris is developing applications and services in a connected product IoT solution based on a cloud service architecture in IBM Cloud that integrates with the IoT Platform. He develops and tests his components locally and deploys to a team development space in the cloud configured with an IoT Platform using live or simulated device data.
In most cases, Chris may have a device delivered by Devon to use for application development and testing. In other cases, Chris needs a simulator to proceed with exploring the IoT Platform APIs, Data Management interfaces and transformation, State change events, and other aspects of the integration of his IoT Application with devices and data on the IoT Platform.
In this design, we primarily focus on Chris the application developer and his first steps in exploring and getting started with the IoT Platform. We want Chris to quickly get live devices and data. Secondarily we support Devon in his everyday use of the platform to develop new device firmware. Using the simulator, Devon can test and deliver new message schemas to Chris and early validate new firmware specifications with Chris applications running with the IoT Platform.
Hills
We defined the following hill for Chris the application developer
“As a Developer with no prior IoT platform experience, I can within 15 minutes set up a new IoT platform organization and start developing and testing my IoT devices and applications using simulated devices”
“As a Developer creating a new Device Type, I can choose to register a new physical device, or simulate a device of the new type”
Device Simulator Design Concept
The design concept for Simulated Devices identifies that
Simulated devices are a core part of the platform experience
As a developer you opt-in for this capability in IoT platform settings
The simulator is driven by a floating panel easily available from any screen in the IoT platform
Simulated devices act as any other device on the platform; they are of a device type, they have an identity, they send messages to the platform, like any physical device.
Messages from simulated devices act as any message on the platform; they are received on a topic, they are of a message type, they are put into the last message cache, they are passed to applications, like any message from any physical device.
There may be multiple simulated devices of a single device type
There may be simulated devices of multiple device types
There may be both simulated and physical devices of the same device types
Simulated devices may mimic physical devices and send events that are already the last message cache. (So if I once had a device connected that sent a message I have to use a simulator to act as that device and continue to send messages.)
I can set up variability in messages so data randomize between two end-points.
I can set up variability in messages so different simulated devices, of the same type, send different data messages.
The design should also provide shortcuts in other parts of the IoT platform to provide hints to developers to use simulated devices to make progress.
Shortcuts put on IoT platform panels, can set up simulations with one click.
Rather than pulling simulators out in the developer experience and out of context, they are integrated into the development flow
Use-cases
As a developer
I can opt-in and enable simulated devices and get a ‘Simulated” device type added to my organization
I can add (one or more) simulated devices and give them a name (pattern) “MyDevice” or “MyDevice#” and get a default event/payload sent to a topic, alternating over these instances.
I can browse the list of devices on the platform and view real and simulated device and their state (raw data)
I can specify the JSON payload schema for devices
I can specify a data range for simulated element values
I can add (one or more) additional simulated devices by id
I can specify a different JSON payload schema for different devices
UX Designs
The initial UX design explored two major screens in the IoT Platform.
The main simulator page for devices of a selected type. On this page, users can add new simulated devices, or select an existing registered device to be simulated. Users can also turn on/off the simulation.
In the first user journey below, Chris is entering the IoT platform. He enables Simulated devices on the settings page. When opening the simulator he is informed that he needs to create a device type. He switches to the Device Type section and creates a new temperatureSensor type. He then returns to the simulator, modifies the default message to send a temperature value. He creates a device that is given the default name TemperatureSensor-1. The simulator starts to send 20.0 C values. Chris modifies the message schema to send temperature values in a range between 15.0 and 20.0 C.
Configure a new simulated device.
In the second user journey below, Chris is using an existing device type TiSensorTag and an already registered device TiSensorTag-1. The device has previously been connected to the IoT Platform and an event exists in the last event cache. Chris configures the message to match the registered device.
Simulate a registered device.
The configuration of types, events, and devices in IoT Platform Device Simulator simulator can be Exported and Imported across sessions, users, and test cases.
Use the Import/Export tab to manage simulations using a JSON definition of the simulator configuration.
IoT Platform Developer Experience Design research on the developer experience in the Watson IoT Platform.
Getting Started with Simulated Devices DevZone Quick Lab at Think 2018 on Simulated Devices.
“All IoT Platform Design Partners strongly agree with the importance of simulated devices to their organisations and that the design meets their needs.”
Meet Chris is the Application Developer and Devon is the Edge Device Developer.
Chris and Devon are the most frequently used personas in the developer experience design across the platform capabilities.
IoT Platform Developer Experience Design research on the developer experience in the Watson IoT Platform.
Getting Started with Simulated Devices DevZone Quick Lab at Think 2018 on Simulated Devices.
In 2017 I contributed to the design concepts for Compliance Reporting for Risk and Security Management in the Watson IoT Platform.
What is Risk Management?
Businesses with IoT deployments have the challenge of ensuring that the entire IoT landscape operates within acceptable and expected boundaries. The consequences of IoT devices operating outside of defined criteria, or policies, could have a major impact on the security of the overall IoT deployment, the safe operation of connected devices, and business impact.
What is a Risk and Security Risk Management Policy?
The Watson IoT Platform allows the configuration of specific policies in relation to connection security.
Compliance reporting provides dashboard cards and drill-in reports on the policies configured in a Watson IoT Platform organization.
Personas
Risk and Security Management is primarily targeting two of the IoT personas
Sally is an IoT System Operator. She handles the day to day system operations on the LOB and client IoT organization. She makes sure that new device types and devices are registered, are behaving, and are up to date with recent secure firmware. She defines policies, creates and runs actions on policy alerts that act on misbehaving devices.
Adam is an IoT Security Operator. He ensures security and compliance by specifying policies that detect abnormalities and prevents devices to be compromised. He reports to audits on compliance with regulations and policy coverage on devices.
Hills
“A LOB engineer running a POC can use out-of-the-box simulated device data and in a minute with no other actions required start exploring simulated entities and apply analytics functions to the simulated entity data”
Use-Cases
As a systems operator, I need to:
See the high-level security status of the devices so I can quickly identify potential risks.
Drill down from a general view to more specific reports to identify problems
Drill into the current state and history of devices to analyze root-cause
Download, filter, and sort the report
UX Design
View Policy Compliance from Dashboard
The Watson IoT Platform Risk and Security dashboard provides an instant overview of the current security position and provides drilling to find more compliance-related information.
The dashboard has a collection of cards that can be used to monitor security-related KPIs.
Sally sees that the Connection Security policy has the most violation. She drills down to find out more information. She clicks on Connection Security
The compliance report shows overall compliance with the Connection Security policy and the current compliance for each rule. Sally clicks on a custom rule defined for TemperatureSensor device type to drill down to see all the devices that fail the default policy.
The next report presents a list of devices that fail the rule and the causes of failure.
Using the Watson IoT Platform Dashboard to view compliance.
View Policy Compliance from Policies Page
The Policies page in the Security section of the Watson IoT Platform provides an overview of Risk And Security Management policies.
Access the compliance report by clicking the “View Compliance” button.
The compliance report shows overall compliance with the policy and the current compliance for each rule
The next level of drill-down shows all the non-compliant devices that violated the rule. Search/filter/download the report.
Using the Watson IoT Platform Security Policy Editor to view compliance.
Final Production Design
Viewing compliance reports using the Dashboard in the Watson IoT Platform.
Viewing compliance reports using the Risk And Security Policies in the Watson IoT Platform.
Related Designs
Risk and Security Management Design The Watson IoT Platform Risk and Security Management provides an overview of compliance on policies and risks so that security administrators and operations personnel can quickly understand the security posture of their IoT deployment according to policies that they have configured within the Platform.
Watson IoT Platform Risk and Security Management Lab. DevZone Quick Lab at Think 2018 on Risk and Security Management.
Meet Sally the IoT System Operator.
Sally is one of the most frequently used operator personas in the design across the platform capabilities.
Also meet Adam the IoT Security Operator.
Risk and Security Management Design. Read more about the design of the Watson IoT Platform Risk and Security Management policies.
Watson IoT Platform Risk and Security Management Lab. DevZone Quick Lab at Think 2018 on Risk and Security Management.
IoT Security Heartbeat iPad Application demonstrates how existing IBM products in the IoT and Security portfolios are providing better insights and responses to security threats using a Operational Dashboard
In 2017 I delivered the design for an IoT Security Heartbeat iPad Application demonstrating how existing IBM products in the IoT and Security portfolios are providing better insights and responses to security threats.
IoT Security Heartbeat Scenario
The IoT Security Heartbeat demo is designed around a business case scenario
Business Context
ACME Inc is a company producing multiple product lines of IoT white goods devices to two kinds of customer.
Unmanaged: Sell product for B2C with limited support. Firmware upgrades provided
Managed: Sell products B2B. Monitored, managed and upgradeable over the network. Compliance level SLA.
Personas
The CISO, or CSO, is directly responsible for risk, compliance, securing and protecting the assets of the business—including employees, data, IT infrastructure and information, plants and customers B2C and B2B managed and unmanaged IoT devices
Operational Dashboard and Security KPIs
CISO views the Operational Dashboard to confirm the IoT security state
High-level domains description:
Overall Enterprise Security
Connected Plant
Customer Endpoints
Business Alerts
Intelligence
Risk Forecast
Examples of Overall Enterprise Security KPIs
Endpoints Security Score – Fixed and Mobile devices
Application Endpoints Security Score
External Service Security Score
Identity Management
Network Connectivity
Geographies Alert Level
Governance Maturity Score
The Geographies Alert Level is Low based on current state of threats from IBM X Force Exchange
Scene 1 – Production plant IoT security issue
There has been a fire that caused damage to the manufacturing facility at Globex Inc. The fire centered around an exit door. Upon further investigation, it was clear that the source of the fire was an electric motor used to automate the security shutters on the door. Fortunately, nobody was harmed and the fire was contained, but the consequences could have been grave.
There are serious safety concerns in relation to risk to human life, as well as the potential negative impact to the reputation of, Globex Inc;, the manufacturing facility and the reputation of the brand for Oscorp Inc, the OEM company, supplying the faulty electric motor.
The Intelligence domain and Current News KPI becomes Amber indicating a warning on security risks with Supplier Risks Alarm on Oscorp Inc
Scene 2 – FW Version Update Status
The Intelligence domain and Suppliers Software Updates KPI becomes Amber indicating a warning that some of our devices needs to be updated (FW).
Devices need to be updated because we have a new firmware available from the OEM
Our current understanding of the FW update content upgrade => NOT CRITICAL
Upgrade postpone until next standard planned maintenance
Scene 3 – High level of Attacks/Threats on our Oscorp devices
The Connected Plant domain and Incident Management / Attempts KPI exceeds its threshold and becomes Red (Alert) because we are facing massive attack tentative on Oscorp Inc devices.
The debugging code left in the device opened up a security hole allowing the possibility of remote commands to be sent to the device outside of safe operating ranges. The IP addresses had been detected in relation to unauthorized access to other critical computing resources. In some instances devices were ‘cloned’ and malicious connections were attempted from those cloned devices to skew IoT data readings.
Scene 4 – Business Impact Alert on Production
The Business Impact domain and Incident in Production Floor becomes amber because of current attacks on Oscorp. Devices may have a huge impact on our production planning.
Scene 5 Watson Alert / Prescription / Recommended Actions
Watson raises an alert with Production at Risk, Compromised security and High level Physical Safety issue.
Prescription: Upgrade as soon as possible Oscorp Inc. devices with last Firmware update
Show how to enforce near real-time Firmware Upgrade
Show how to “isolate” those devices
Show how to plan countermeasures
Start a business process/workflow
Options are provided for resolving the risk with a Security optimised route, or a Cost Optimised route.
ACME is choosing the Cost Optimisation route and schedules device FW updates based on a need scheduled update cycle. It minimises the impact win business and any demands for production downtime. By choosing this route, relevant people in the ACME organization are notified of the conditions and plan.
Scene 6 – Intelligence and Sentiments Analysis on Social Media
The Operational Dashboard provides intelligence and insights into customer satisfaction related to product security. ACME provides B2C smart products to end consumers and managed products under SLAs for B2B clients.
The Intelligence domain and News Awareness becomes amber because clients satisfaction is dropping and Sentiment Analysis in Social Media is indicating product, security or vulnerability issues. These early indicators may not yet show in corporate support channels.
Scene 7 – Business Alerts
The Business Alerts and Variation in Client Support Requests becomes amber because because the increase in client support requests on product malfunctions. This is impacting the ACME operational cost but also indicating a risk to client operations.
Scene 8 – Customer Endpoints The Customer Endpoints and Policy Compliance Score becomes amber because the Enterprise Assets KPI is dropping. Drilling into the data source of Device Security Policies in the Watson IoT Platform we see that a significant number of devices are failing to authenticate. This suggests that there is an issue.
Scene 8 Watson Alert / Prescription / Recommended Actions
Watson issues an Alert on the condition.
To the left, notifications on Compliance, Customer, and Social Media KPIs. To the right, prescriptions from Watson on the root cause and suggestions on further actions
This concludes the IoT Security Heartbeat demo.
“Ninety-four percent of CxOs believe it is probable their companies will experience a significant cybersecurity incident in the next two years.”
“An effective tactic to combat cybercrime is transparency and collaboration, sharing incident information internally and externally. Improve awareness and drive a more risk-aware culture across the entire organization.”
“The trust on comfort on cybersecurity strategy of their enterprise is well established is widely different. 76% of The trust on comfort on cybersecurity strategy of their enterprise is well established is widely different. 76% of the CIO’s agree – 51% of CEO’s agree .”
In 2006-2008 I developed scenarios for the IBM Rational Global Development and Delivery offering
The GDD scenarios outline the steps for a client that is transforming from a single-site development team to a global delivery organization. This scenario was chosen based on its business importance to our sponsors and to the overall design of the DGG solution.
The design scenario covered the following acts
Setup the Distributed Environment (Unique to GDD)
Develop a new application release (Business Driven Development Green Thread)
Fix a problem in the first release (System in Trouble Green Thread)
Scenario Synopsis
The GDD scenario is a branch of the JK Enterprise scenario developed by the IBM Rational Green Threads team. The scenario is using a financial banking context and a new Account Opening application.
The GDD storyline starts with the delivery of the first release of the Account Opening application. The development team of 11+ has been local to a single site in the US with a Central tool deployment topology. The team is preparing for the second release with a larger team. JKE has acquired a company in the EU of 5 developers that will join the Account Opening team. Also, a team of 10+ developers contracted through GSI in India will take over the support for the first Account Opening application release while the US and EU teams start developing the second release.
The teams need to
Bring up a multisite backbone with the new development sites in the EU and with GSI.
Hand-off the Account Opening first release code to GSI.
Establish a change management process with the JKE and GSI teams for the support of the first release
Establish a requirement management process with the JKE US and EU teams for the second release.
The scenario assesses the gaps and drives the design for improvements in the GDD solution.
The need to quickly deploy the development infrastructure to new teams to make them produce from day one.
The need for WAN tools that can support all key developer use-cases in CC, CQ, and UCM.
The need for centralized builds.
The need for distribution of central builds for local testing.
The need to run change management for a maintenance release and for new development.
The need to ensure asset security and isolation of maintenance new development projects.
The need for secure connections over removed connections.
Scenario Personas
US
Overall Project Manager
Business Analyst
Architect
Developer
Test Engineer
Integration Developer
Build Engineer
Enterprise Architect
IT Administrator
Development Tools Administrator
EU
Business Analyst (for EU market)
Architect / Lead Developer
Test Engineer
Build Engineer
IT Administrator
GSI
Project Manager
Architect / Developer
Test Engineer
Integration Developer
Build Engineer
Enterprise Architect
IT Administrator
Development Tools Administrator
The GDD Scenario As-Is State
The JKE development team is using a single side local topology deployment of the IBM Rational GDD solution
The JKE development team is targeting a centralized hub topology deployment of the IBM Rational GDD solution and WAN access for EU and GSI team members.
Rational Portfolio Manager for project management in the US
ClearCase Web for source code management in EU and GSI
ClearQuest Web for change management in EU and GSI
BuildForge for central software builds in the US
SystemTest for quality management in the US
Client tools for modeling and test execution in the US, EU, and GSI. Test artifacts under SCM control.
In 2006-2008 I performed research, scenario design, and defined the user experience strategy for the IBM Rational Global Development and Delivery offering
What is Global Development and Delivery
Global development profiles organizations with a distributed team dispersed across towns, across the borders, or overseas. Teams may be Onsite, Nearshore, Offshore, or Outsourced. Generally, hybrid structures are used. Onsite and Nearshore and often internal staff. Nearshore and Offshore are often directly owned subsidiaries or joint partnerships. Outsourced covers contracts with the service provider that supplies supplemental resources or assumes responsibility for all or part of the software development lifecycle.
While the user of global resources often lowers the cost of staff, additional pains arise. Mismatched and Misunderstood Processes. Communication Issues. Cultural Issues. Decrease Productivity. Increased Rework. Mistakes in Work-Transfer. Higher Coordination Costs. Political Issues. Security IP Protection. Lack of Project Visibility, Agility, and Control. Unable to Measure Success.
Support for GDD best practices can change the equation. Process, Workflow, and Development challenges can be addressed by improving team efficiency across cultures and geographies by automating the full lifecycle processes and development tools. Communication and Collaboration challenges can be improved by accelerating project success through collaborative team-based development and a workplace environment. Project Management & Portfolio Management challenges can be improved by providing global visibility through accurate project metrics and reporting.
Researching Global Development and Delivery
I researched global organizations in the US, Europe, and India that depend on global development and delivery or deliver outsourcing services to uncover the root causes of the challenges reported above. The following root causes were identified.
Communications issues – time lag, cultural
Requirements not well-defined upfront
The requirements management process does not provide a feedback loop or method for communicating changing / evolving requirements
Requirements well defined, but not well communicated
Organizational issues – lack of motivation
Process (handoff, delivery, change management) not well understood – time spent trying to figure out who does what
Additional project management overhead
Mismatched and unsynchronized configuration management processes and systems – resulting in classic configuration management problems – work to know what files to work on, what is the latest build, why did the build break, etc.
The end product, not the right product (requirements mismatch)
The end product has a high defect density
The offshore testing process not aligned with onsite needs
Requirements changes not reflected in product
Enhancement requests not reflected in product
Poorly defined deliverables
Wrong versions delivered for integration and deployment
Conclusions on User Research
The metrics from the research show that
Productivity may decrease by up to 50%
Typically localized project rework is 20%-30%
Distributed development: 50%-100% rework in initial projects
The research also shows two emerging client topologies
Centralized
Single centralized server hub
Local LAN access – thick clients
Remote WAN access – thin web clients
Distributed/Replicated
Multisite backbone with server hubs
Local LAN access – thick clients
Remote WAN access – thin web clients
Integration with open source SCM tools like Subversion
The research identified new trends impacting our GDD design strategy
The enterprise development model is challenging
Consolidate infrastructure to centralized hubs
Connect global teams with remote access
Connect global teams into supply chains
Be aware of competitive pressure from open source
Needs on GDD called out by our Board of Advisors
Need to launch new projects quickly
Need to provision new global sites quickly
Collaboration between distributed teams are key to success
Formulating a GDD User Experience Strategy
Based on my analysis we formulated a GDD UX strategy
7 Views identifying the key aspects of global delivery
Collaboration
Governance
Access
Administration and Scaleability
Security
Usability
GDD Drivers identifying the stakeholders and their incentives
Portfolio drivers
Project drivers
IT drivers
We also formulated a hill for GDD that ‘Global organizations can grow development capacity and achieve cost savings by providing a centralized the development infrastructure with remote access to global teams’
This UX strategy was driving our
Design scenarios for GDD
Product strategies approved by the GDD Offering Team
Simulated Devices Design
“All IoT Platform Design Partners strongly agree with the importance of simulated devices to their organisations and that the design meets their needs.”
“Ninety-four percent of CxOs believe it is probable their companies will experience a significant cybersecurity incident in the next two years.”
