From Chaotic R&D to Unified Platform: Our Journey to a Scalable Middle‑Platform

Background

The author previously worked for a conglomerate with finance, e‑commerce, insurance and blockchain subsidiaries, where each business line built its own IT system, leading to massive duplication and a fragmented R&D organization of nearly 300 engineers.

Pitfalls

Problem: Siloed ("chimney") Development

Repeated investment across companies and business lines

大量重复投入

Inconsistent team quality resulting in low delivery quality and frequent bugs

交付质量低

Projects lacked reuse, causing long development cycles

交付速度慢

Data and capability sharing across projects was impossible

无法实现跨行业的业务打通

Solution: Build a Public Service Team

Extract duplicated services into a unified public‑service group for centralized maintenance.

Establish a unified technical support system to improve delivery quality.

Evolution: Platform Strategy

With the public‑service group reducing duplication and improving quality, the CTO promoted a platform‑oriented strategy.

Upgrade the public‑service group to a "Platform Service Department".

Encourage each business line to develop its own public services.

Problem: Over‑produced Services, Low Adoption

Although more than 60 services were created, most were used by only a single business line, indicating a "do a lot, use little" issue.

Solution: Middle‑Platform Transformation

Develop reusable middle‑platform services that are close to business needs.

Require each middle‑platform project to have at least two business requirements at inception.

Middle‑platform teams actively participate in business system refactoring and integration.

Evolution: Middle‑Platform Architecture

Business middle‑platform – generic and industry‑specific services.

Data middle‑platform – mining data value and driving business.

Technical middle‑platform – standardizing core tech stack and researching future technologies.

R&D middle‑platform – improving delivery through process, quality management and monitoring.

Problem: Inconsistent Technology Stack

Multiple languages (Java, Node, Scala, PHP).

Diverse middleware versions (Redis, RabbitMQ, etc.).

Different frameworks (Hibernate, MyBatis, Spring Data JPA).

Inconsistent API documentation and styles.

Solution: Adopt Dew Framework

The team mandated new projects to use the Dew Framework (based on Spring Boot 2.x, supporting Spring Cloud and Istio) and gradually migrated legacy projects.

Unified distributed operations (cache, lock, map, leader election) supporting Redis, RabbitMQ, Kafka, Hazelcast, MQTT.

Unified authentication model.

Unified event notification (DingTalk, SMS, email, etc.).

Transparent idempotency handling.

More elegant API support.

Problem: Gaps in Release, Deployment, and Monitoring

Various deployment methods and configuration retrieval mechanisms.

No standard way to integrate automated testing into release pipelines.

Redundant dependent services per project.

Inconsistent monitoring and alerting across projects.

Solution: Dew Microservices System

The Dew Framework was extended into a Dew Microservices System that adds DevOps and containerization support, standardizing the main stages of the development workflow.

Problem: Unstandardized Project Processes

Different projects followed different development methodologies (agile vs. traditional).

No clear standards for deliverable formats.

No unified criteria for project success evaluation.

Solution: PMO and Tailored Agile

A PMO was introduced to govern and assess process compliance. Agile practices were trimmed to reduce overhead, and training was provided.

Problem: No Evaluation Standard for Middle‑Platform

Without a clear metric, it was impossible to judge the quality of middle‑platform initiatives.

Solution: 6S Evaluation Standard

The author introduced a "6S" standard to evaluate middle‑platform construction, providing a measurable framework for progress and outcomes.

Problem: Service Integration and Collaboration

Each service had its own address.

API/SDK styles varied widely.

SLA commitments differed.

Support was fragmented across providers.

No unified service‑quality evaluation.

Solution: Business Informationization Operating System (BIOS)

The "Galaxy" pilot project was upgraded to a BIOS that registers all internal, cloud‑hosted, and on‑premise services, offering a consistent API and governance layer, effectively acting as a service‑integration platform beyond a simple ESB.

Summary

The author systematically addressed technical and managerial challenges encountered during the transition from isolated, duplicated development efforts to a cohesive platform and middle‑platform ecosystem, leveraging a unified micro‑service framework, standardized processes, a 6S evaluation model, and a BIOS integration layer to achieve scalable, business‑aligned engineering outcomes.