Introducing the RoboFlow reference application

Overview

RoboFlow is a B2B eCommerce company specializing in robotics and robotic parts. Initially, the company operated a simple online store serving business customers with standard product orders. Over time, RoboFlow has outgrown their legacy monoliths and is struggling with scaling, inconsistent customer experiences, and an inability to integrate emerging AI capabilities. As the business expanded, so did the variety of users, use cases and operational processes, requiring the platform to support internal and external activities in a consistent and scalable way.

Our reference implementation showcases RoboFlow's modernization initiative to address these pain points and deliver a scalable, future-proof B2B eCommerce and CRM platform using IBM DevOps Solution Workbench.

Your journey with the Workbench

In this reference implementation, you will follow the steps RoboFlow took to design and modernize their architecture using the Workbench. You will explore how to collaboratively design systems, model capabilities, and break them down into deployable microservices. From capturing key architectural decisions and modeling domain concepts to integrating into CI/CD pipelines, the journey reflects how your team can go from idea to running software within a single tool.

Getting started: Goals, Domains, and Boundaries

To begin a modernization effort like this, you typically start by capturing the key business goals and technical requirements. This helps uncover the domain and identify bounded contexts, often through collaborative techniques like Event Storming (see CRM Project for an example).

In the Workbench, these early insights are captured and refined using our System Architecture Design tool. This helps teams define business capabilities and context boundaries early in the process, laying the groundwork for consistent, scalable design.

In the case of RoboFlow, at first, we need to understand their ambition for a modern B2B platform and the core capabilities the solution needs to support. With IBM DevOps Solution Workbench, these requirements are then translated into architectural models using the light-weight C4 framework, starting with a Level 1 system context view.

Let's take a look at RoboFlow's objectives, ambitions, and the specific requirements they set out to fulfill.

Objectives

RoboFlow platform shall consist of two primary subsystems: the eCommerce Platform and the CRM System, interconnected through APIs and event-driven workflows. Below is a high-level view of the ambitions in their modernization journey for these two systems.

RoboFlow's ambition

Modern B2B eCommerce Platform

The customer-facing eCommerce system for browsing, configuring, and purchasing robots and robot parts. It supports dynamic pricing, inventory integration from third-party suppliers, and seamless checkout with external payment and shipping providers. As RoboFlow evolved, the system also began serving internal functions such as order placement by sales engineers or support agents.

Enhanced CRM System

The internal system used by customer support and sales teams to manage interactions, resolve issues, and track relationships throughout the customer lifecycle.

Platform expectations

To support these systems, RoboFlow's platform must:

1. Handle interactions from multiple types of users, including customers, store managers, support agents, and third-party suppliers.
2. Integrate with external services such as payment gateways, shipping providers (DHL, DPD), and email providers for transactional messaging.
3. Enable synchronization of customer interactions across systems for a consistent experience.

🎯Context

For more details on the CRM system, you can visit the reference implementation of the CRM Project.

Visualizing the system landscape

Capturing these ambitions at a high-level in C4 leads to a Level 1 diagram similar to the one below.

This Level 1 view is typically our first modeling step in the Workbench, helping align stakeholders on the overall system landscape and identifying the actors, internal systems, and key activities - it's the type of diagram you could show to non-technical people.

Recognize our systems, some internal and external actors? Awesome, then let's move on.

Requirements

Now that the high-level system landscape is clear, RoboFlow's next step in the Workbench is to break the system down into deployable units - using the Level 2 diagram of the C4 framework. This is where functional and non-functional requirements begin to shape the structure of your architecture.

Let's look at how the RoboFlow team did this for their B2B webshop.

🎯Info

These requirements and design considerations can serve as inspiration for your own modeling.

Functional Requirements Driving Design

RoboFlow's team identified the following key capabilities the new B2B webshop must support:

1. User sign-in
2. List product items with product details (image, name, category, tags, and price).
3. Manage shopping cart (add, remove, delete items).
4. Checkout process including payment and shipping.
5. Personalized product recommendations based on previous purchases of the signed-in user (RAG component).
6. Email notification to inform customers of order and shipment updates.

These features led to the decomposition of the system into dedicated services, including:

1. Webshop Frontend and a backend-for-frontend (BFF) to present the UI and orchestrate backend interactions
2. Product Catalog, Basket, and Checkout services to support core shopping flows
3. Supporting services like Payment, Shipping, Order Management, and Notification

You can start modeling your own containers by analyzing your key features in the same way: What are the core user flows? What backend capabilities do they depend on? What boundaries emerge naturally from those responsibilities?

💡tip

You don't have to start from scratch. You can reuse and tailor model elements in Workbench by duplicating existing examples like RoboFlow and adapting them to your needs.

Non-Functional Requirements Influencing Architecture

RoboFlow's team also made sure non-functional requirements were reflected in the architecture from the start:

1. High availability: Services are loosely coupled and independently scalable.
2. Performance: Separation of concerns ensures fast response times for critical interactions like search, checkout, and payment.
3. Continuous Integration/Delivery (CI/CD): Each container can be built, tested, and deployed independently.
4. Maintainability: Clear service boundaries allow teams to own and evolve specific capabilities.
5. Extensibility: Future integrations (e.g., new payment or shipping providers) can be added with minimal disruption.

These qualities are not just theoretical goals, they are automatically reflected in the services generated by IBM DevOps Solution Workbench. These services follow proven patterns that address these architectural concerns out-of-the-box, helping teams deliver production-grade microservices from day one.

By tying containers back to user-facing requirements and architectural qualities, Workbench's Level 2 model gives teams a shared, implementation-ready understanding of the platform.

Want to see how these requirements translate into a complete, modeled architecture? In the next section, we walk through RoboFlow's system structure using C4, from systems and containers to detailed runtime diagrams and architectural decisions.

Use it as a walkthrough or as a foundation for your own architecture.