How a Micro‑Frontend Workbench Boosts E‑Commerce Operations Efficiency

Why There Is an Operations Workbench

Background

After more than 20 years of e‑commerce development, the market has entered a fiercely competitive stage. User growth and traffic dividends are shrinking, platforms have grown large, acquisition costs have multiplied, and the industry is moving into a mature, stable phase with limited explosive growth. Business models on the consumer and marketing sides are converging, intensifying competition.

Improving organizational efficiency, reducing collaboration costs, optimizing operational processes, and enhancing R&D efficiency are key to creating a fertile ground for commercial innovation, lowering marginal costs, and achieving fine‑grained operations.

Problems

Internally, as the Taobao‑Tmall ecosystem expanded rapidly, different business and technical teams built many “new” systems on top of legacy ones. These systems are fragmented, duplicated, and have low usability. Historical systems focused on meeting individual business goals without considering unified operational scenarios, leading to disjointed workflows, especially after the recent Taobao‑Tmall integration.

From an operator’s perspective, completing a full operational workflow often requires jumping between four separate systems, each with its own permissions and inconsistent user experience, resulting in high learning costs and low efficiency. Best‑practice knowledge is mostly oral, with little systematic documentation, making onboarding difficult and data‑driven optimization impossible.

From a technical perspective, duplicated functionality incurs extra development and maintenance costs. Front‑end and back‑end implementations differ, leading to high response and iteration costs. Heterogeneous systems are hard to integrate, creating technical and data silos.

Overall, the organization is split across people, goods, venues, and commerce, each focusing on local optimization without a global view, hindering unified operational improvement.

What Is the Operations Workbench

We aim to solve three core issues:

Operational efficiency and experience, and the sedimentation of operational models.

Systemic “chimney” architecture and technical silos, standardizing system capabilities and improving R&D efficiency.

Data‑driven measurement of operational actions and business outcomes to guide optimization and innovation.

The goal is a unified, standardized, data‑driven, and highly usable Operations Workbench that aligns people, goods, venues, and commerce.

We structure the e‑commerce capability matrix, deduplicate vertical system capabilities, and abstract them into the smallest operational unit – the Process Unit (PU). A PU consists of one or more pages with data interfaces that complete a basic operational task. By applying SOP (Standard Operation Procedure) concepts, we standardize operational workflows into reusable SOPs, which are then composed into site‑specific solutions.

The platform provides a foundational development environment for PU creation, SOP orchestration, site configuration, permission management, and data analytics, enabling consistent integration and deployment of operational solutions.

Below is the product diagram of the Operations Workbench, showing the layered architecture: a foundational platform for production‑research and permissions, PU capabilities built on the people‑goods‑venue‑commerce model, SOP construction, and site‑specific solutions.

Operations Workbench Frontend Technology System

Solution based on micro‑frontend architecture

To deliver a consistent experience and SOP‑driven integration of Taobao‑Tmall operational capabilities, we adopted a micro‑frontend architecture. This approach decouples the framework application from business applications, allowing independent development and autonomous deployment while maintaining a seamless SPA experience.

The solution is organized into four layers: production‑research, configuration, runtime, and data monitoring.

Production‑research provides a complete platform for PU creation, offering ProCode, LowCode, and NoCode development modes, and a centralized PU asset hub.

The configuration layer assembles PU (micro‑apps) and PUC (micro‑modules) into SOPs and configures site‑level settings.

The runtime layer handles loading and rendering of sub‑applications via the IceStark framework, integrating permissions, unified tracking, and watermarking.

Data monitoring spans from PU development metrics to runtime stability and platform traffic analytics.

After a PU’s pages are built, the bundle is published to CDN and metadata (bundle URL, version, route) is stored in a database. The PU center registers this information as a sub‑application.

During configuration, SOP orchestration retrieves PU metadata, allows visual drag‑and‑drop composition, and stores the resulting SOP configuration for site deployment.

At runtime, the base application loads the appropriate site and SOP based on routing, renders the main framework, and uses IceStark to load and render the selected PU.

Production‑Research System

PU / Micro‑App Development

To support the workbench and SOP ecosystem, we built a full production‑research system focused on two principles: (1) product/platform solutions capture business requirements and decompose them into standardized PUs; (2) PU‑centric development provides a unified front‑end and back‑end solution, ensuring consistency and quality.

Production‑Research Process

The process involves three roles:

Business PD – proposes requirements.

Platform PD / Ops – reviews PU proposals for product‑level rationality.

Business Developers – implement PU as front‑end/back‑end code.

Four development artifacts are defined:

Front‑end application – publishes a bundle to CDN.

Front‑end page – a route within the application.

PU – a micro‑frontend composed of multiple pages.

SOP – an orchestrated flow of multiple PUs.

Developers can choose ProCode (ICE), LowCode (IceLuna), or NoCode (Orca) modes. After PU creation, a change request registers the PU in the PU center for SOP composition.

PU Change / Production

PU change requests capture:

Basic PU information (name, category, description).

Associated pages.

Parameters for scenario‑specific variables.

Permission points for access control.

PU versions are managed with gray‑release capabilities, allowing targeted rollout to specific sites or SOPs.

PU and page relationships are many‑to‑many, enabling reuse of pages across multiple PUs and vice‑versa.

Site Configuration

SOP / Micro‑App Configuration

Business scenarios compose SOPs visually using PU assets, configure menus, permissions, and then publish sites. Two configuration approaches are provided: SOP composition for PUs and configuration for PUC micro‑modules.

SOP types include:

Weak‑flow SOP – no pre‑node dependencies.

Strong‑flow SOP – includes pre‑node validation.

Sub‑SOP – reusable templates.

Dynamic SOP – node‑level functions that select PUs based on conditions.

We built a visual editor with GGEditor, extending node and edge protocols to support PU models and SOP relationships.

For micro‑module scenarios, we defined configuration protocols, layout, and workflow capabilities, currently used for homepage modularization and intra‑page business flow orchestration.

Site Runtime

PU, SOP Runtime / Main & Sub‑App Solution

The workbench container (base app) renders the framework and loads PU/sub‑apps based on site and SOP configuration. Business capabilities such as SOP parsing, permission checks, and data tracking are decoupled via a plug‑in architecture, enabling flexible extension.

Core layers include:

Base services – common utilities like watermarking and unified tracking.

Middleware – handles site info, SOP processing, and PU routing.

Plugins – encapsulate additional business logic.

Renderer – renders PU and PUC using IceStark.

Consistent Experience

Historically, internal tools prioritized functionality over design, resulting in inconsistent UI/UX. Consistency across structure, visuals, interaction, content, and feedback reduces learning costs, improves efficiency, and strengthens brand perception.

We defined design specifications in three dimensions: platform framework (global navigation, SOP navigation, toolbars, menus), component library, and content guidelines (error pages, prompts). The front‑end team provides a unified theme and standardized material for all business scenarios.

Conclusion

Results & Progress

The Operations Workbench now supports over 500 products and developers, standardizing more than 1,000 PU capabilities, 2,500 SOPs, and 300+ sites, covering core operational flows such as merchants, items, and marketing. It serves over 8,000 operators daily with a consistent SOP‑driven experience.

Outlook & Planning

Upgrade development modes: continue exploring NoCode approaches that expose minimal configuration while driving UI‑driven and data‑model‑driven development.

Standardize platform solutions: abstract the current technical stack into a reusable architecture for other mid‑backend platforms, defining universal standards and best practices.