Why it Matters

I never met a product manager or engineering leader with too many people or too much time to get things done. There is constant competition for resources and never-ending trade-offs between what to build now and what can wait for the next sprint or release cycle. 

A feature-driven mindset compounds resource-constrained, transformation-driven organizations. That’s because features, by themselves, don’t achieve outcomes. Even connected, automated and integrated features fall short. They are merely pipes and valves in complex value chains - especially in connected product businesses. 

Years ago, Tony Ulwick seeded the “Jobs to be Done” approach to building products. It’s an approach that works backwards from customer and operational desires and outcomes. A feature-centric approach is more of a bottoms-up strategy, albeit requirement driven. Feature-centric mindsets reinforce technology and operational silos that slow organizations down and compound technical debt where simplicity, scale and elegance is what customers need. It’s also operationally burdensome, i.e. expensive.

Workflows deliver outcomes. 

What is a Workflow

A “workflow” is simply the flow of work. This implies a series of steps, decisions and actions that are sequenced, dynamic and intelligent. Features may involve automation, and integration. Workflows are driven by orchestration. Orchestration is the logic, intelligence and decision-making that drives the sequence of tasks and processes that make up the workflow. Orchestration is both the conductor and the score - what do I want to achieve and how do I achieve it?

There is no question that Automation, Integration and Orchestration are tightly linked. Orchestration depends on the ability to execute or automate tasks. Workflows involve multiple things, people, processes, data, applications, systems and networks that must be integrated in order to execute orchestration. But orchestration should be the mindset, and workflows should be the framework for every connected product business leader. 

Examples of Workflows in Connected Product Businesses 

Zero-touch provisioning, Heartbeat monitoring, Software updates, Alerts and Notifications, and Data consumption and storage are examples of automated features in virtually every connected product stack. In a simpler world, features performed the task they were required to do under the umbrella of Device Management. However, requirements evolved significantly as IoT solutions matured, devices became more intelligent and computing more distributed. 

Features can and should evolve into workflows:

Zero-touch Provisioning → Configurable First Connection Workflows
Device State Management → Configurable Device Claiming and Lifecycle Workflows
Monitoring and Alerting → Configurable Service Event Workflows
Software Updates → Configurable Software Validation, Update and Audit Workflows
Data Storage → Configurable Data Consumption, Normalization and Federation Workflows

Double clicking on a single example helps illustrate the difference between a feature and a workflow.

First Connection Workflow

This workflow is initiated by the first connection of a device to a cloud device management service. The device reports its unique ID which is usually pre-registered in the system. In a simple provisioning process, the device would receive specific device and network configuration instructions, perhaps a software update and then begin its normal operations. 

In the First Connection Workflow the device still connects to a cloud service and shares its unique ID. But this can initiate a more complex series of events involving multiple systems and services, including:

↳ Register the device as active in the system of record

↳ Send the most current configuration profile to the device

↳ Check CRM service to determine what local applications must be installed for this specific customer in this specific location
   ↳ schedule application update to device with specified retry management policy
   ↳ monitor for success/fail and take appropriate action
        ↳ log update to system
   ↳ initiate service event workflow if failure

↳ Check firmware version and update if not most current version

↳ Create a resource in AWS IoT Core for the device
     ↳ within the specific customers own AWS account using customer’s account credentials

↳ Download a customer-specific version of AWS Greengrass to the target edge device
     ↳ monitor AWS Greengrass and restart the service if it stops sending messages in a specified interval

↳ Configure local ingestor for specific data protocol
   ↳ send raw data file or normalized JSON to designated local and/or cloud services

↳ Set heartbeat report frequency and payload
   ↳ define connection state parameters for reporting
   ↳ define connection or other states that trigger alerts notifications and…
   ↳ Service event workflows

The Power of Purpose-Built Workflows

There are several examples of general purpose workflow platforms, including Zapier, SnapLogic, Boomi and Node-RED. Many low code and no code software platforms are also workflow-centric, including Quickbase and Appian. The most valuable orchestration platforms are purpose-built for specific domains, market segments and use cases. Obviously EdgeIQ Symphony was designed as a purpose-built orchestration platform for the Connected Product Economy. Industry leaders in other markets have taken a similar approach. The best examples are Servicenow for the customer lifecycle transformation, Rippling for HR, IT and Finance, Tines for IT and Security, Gutsy for security and Kandji for Apple Mobile Device Management and Parabola for Supply Chain and Logistics workflows. 

Almost all workflow platforms take a no-code or low-code approach to data and event driven orchestration. Purpose-built workflow platforms abstract key concepts and elements from specific workflows and the applications they enable. In the case of EdgeIQ Symphony, there is a common model for defining device profiles, users and accounts, a data abstraction and analytics layer, a common security model. Customers can build and orchestrate workflows that integrate their own enterprise and business application layers and incorporate external, third party workflow nodes. Purpose-built orchestration platforms also put guardrails and security measures in place. This empowers the right people with the right permissions under the right circumstances to drive the desired outcomes. 

Another key element of purpose-built orchestration platforms is Observability. With the appropriate tracing, logging and analytics in place, organizations can determine the root cause of workflow failures or performance bottlenecks. This improves diagnostics and remediation but also just helps improve efficiency and reduces downtime. We will double click on Device, Data and Workflow observability in a future post, as well as get more granular on the elements of EdgeIQ Symphony Workflows and how to build them. 

But don't take my word for it yet. In this series of articles I have lined up, I will elaborate on each of the pillars of this manifesto. I will provide details, evidence and anecdotes highlighting the challenges and the path to surviving this existential event. It's an incredibly exciting time for those who seize the opportunity to redefine their business and ultimately dominate their market segment within the connected product economy.

Conclusion

It may seem like semantic hair splitting to distinguish between automation, integration and orchestration. But thinking in terms of workflow orchestration is a clearer, outcome-focused mindset that will drive a better approach to building products and processes in the Connected Product Economy. Understanding the power of purpose-built workflows is equally important.

Want to learn more about how we are helping Connected Product businesses transition from features to workflows, drop us a line.