Skip to main content

BUSINESS SYSTEMS & DATA INTEGRATION

Connect scattered workflows and data into one usable system

From admin portals, APIs, and databases to devices and real-time feeds, I clarify users, workflows, and system boundaries before turning scattered information into an operational, traceable process.

  • Work directly with the planner and developer
  • Define scope before estimating
  • Plan for ownership after launch
INTEGRATION BLUEPRINT01 — 06
  1. Users & roles

    Who needs to view or act on the data

  2. Data sources

    Devices, services, and existing systems

  3. APIs & data flow

    Define exchange, sync, and access

  4. Validation & rules

    Handle formats, states, and exceptions

  5. Operations & monitoring

    Turn data into usable information

  6. Delivery & observability

    Track operation, errors, and maintenance

Connected · Understandable · Traceable

Choose the integration approach around the data sources, workflow, and existing environment

  • Admin Portals
  • REST APIs
  • WebSocket
  • Databases
  • Access Control
  • Cloud Delivery

SELECTED SYSTEMS

See how integration works from incoming data to shared APIs

Four projects across AI detection, live traffic, manufacturing, and environmental devices show how integration changes with the data source and team boundary.

01Production & quality management
ITRI production management system interface

Industrial Technology Research Institute

ITRI Production Management System

Starting problem
Nine production stations needed consistent digital quality control and traceable historical records.
Planning decision
Define station data, validation rules, and process states first, then support analysis through one consistent API and data model.
System shape
Node.js and TypeScript APIs, Prisma ORM, PostgreSQL, Docker, and Swagger documentation.
My responsibility
Built the backend APIs and data layer in collaboration with the partner frontend team, including validation, history, and statistical process control.
  • Node.js
  • PostgreSQL
  • Prisma
  • Zod
  • Docker
02Real-time monitoring & data platform
NCKU real-time energy and air-quality monitoring system

National Cheng Kung University

NCKU Environmental Monitoring

Starting problem
Electricity and air-quality data from different device services needed live visibility, historical analysis, and alerts.
Planning decision
Separate live status, administration, and historical reporting, with role-based access to each area.
System shape
Vue 3 dashboard, admin portal, REST APIs, WebSocket, RBAC, and Excel/CSV export.
My responsibility
Built the frontend architecture and interfaces, connecting device-data APIs and live feeds with localization, permissions, and reporting workflows.
  • Vue 3
  • WebSocket
  • Pinia
  • RBAC
  • XLSX
03AI data & live traffic analytics
Kaohsiung Lighthouse smart traffic LOS analytics system

Linker Vision Co., Ltd.

Kaohsiung Lighthouse Project — Smart Traffic LOS Analytics

Starting problem
AI object detections and camera calibration data had to become live intersection and road-segment indicators for external transportation partners.
Planning decision
Combine detection results with calibration matrices in an inspectable real-time analysis flow, then distribute LOS results through REST APIs and WebSocket.
System shape
Vue 3, TypeScript, Quasar, Socket.io, Konva Canvas, HLS.js, and JWT.
My responsibility
Worked as Front-End Engineer on data integration, real-time calculation, and analysis interfaces that turned AI output into usable traffic data.
  • Vue 3
  • WebSocket
  • Konva Canvas
  • HLS.js
  • JWT
04Cross-device AI data integration
Linker Vision Android TV live AI showcase

Linker Vision Co., Ltd.

Linker Vision Android TV AI Showcase

Starting problem
AI detections, live video, and map context had to appear together on Android TV for a clear on-site demonstration.
Planning decision
Use Android TV as the presentation surface and combine AI APIs, WebSocket, HLS video, and maps into one real-time experience.
System shape
Kotlin Android TV app, AI APIs, WebSocket, HLS, ExoPlayer, and Mapbox.
My responsibility
Owned the Android TV app architecture, interface, and data integration, bringing the partner AI capability into the product.
  • Android TV
  • AI API
  • WebSocket
  • HLS
  • Mapbox

COMMON INTEGRATION NEEDS

Bring data in—and make dependable data available to others

An integration may consume device or partner data, or expose an API to another team. Both need explicit formats, access rules, and failure handling.

01BRING DATA IN

Connect external services and device data

Bring partner APIs, sensors, AI detections, and live feeds into an interface where the team can understand the state and take action.

  • Data source and field inventory
  • API, WebSocket, and access integration
  • Monitoring interfaces and states
  • Errors, reconnection, and exception handling
02SHARE DATA OUT

Build backend APIs and data services

Turn operational rules and data into validated, permissioned, documented services for internal products or partner teams.

  • Data models and validation rules
  • API contracts and documentation
  • Permissions, history, and audit records
  • Deployment, monitoring, and handoff

PLANNING BLUEPRINT

Before listing features, answer six system questions

A feature list says what to build. A complete plan also defines who uses it, how data moves, what happens when things fail, and how completion will be accepted.

  1. Users & roles

    Question to clarify

    Who needs to complete which work? Who can view, edit, or approve?

    Specification produced

    Role map · Permission matrix

  2. Scenarios & workflow

    Question to clarify

    How is work done today? Where does it stall? What are the normal and exception paths?

    Specification produced

    User flow · State diagram

  3. Information & interface

    Question to clarify

    What must people see, enter, or decide at each step?

    Specification produced

    Information architecture · Wireframe

  4. Data & rules

    Question to clarify

    Where does data come from? How is it validated, related, stored, and traced?

    Specification produced

    Data model · Validation rules

  5. Systems & integrations

    Question to clarify

    What services must connect? How are access, sync, and failures handled?

    Specification produced

    System architecture · API contract

  6. Delivery & operations

    Question to clarify

    What means done? How will the system deploy, monitor, back up, and improve?

    Specification produced

    Acceptance criteria · Launch plan

WHAT YOU CAN REVIEW

Planning is not one meeting. It is a set of decisions everyone can review.

The right level of documentation gives owners, users, and developers one shared understanding of the system.

  1. Requirements & scope

    Goals, success criteria, feature boundaries, priorities, and what this phase intentionally leaves out.

  2. Workflow & architecture

    Role journeys, modules, data movement, service integrations, and major technical decisions.

  3. Rules & acceptance

    Permission matrices, validation, exception handling, and testable definitions of done.

  4. Phases & risks

    Delivery order, dependencies, estimates, and unknowns that should be validated first.

DELIVERY PROCESS

Every phase leaves a decision you can review

Reduce the cost of a wrong direction before increasing engineering investment. You see working evidence well before the end of the project.

  1. Discovery

    Interview key roles and map today’s process, goals, data sources, and hard constraints.

    Align on the problem, outcome, and priorities
  2. System blueprint

    Define workflows, scope, access, data, and architecture, then shape a realistic first release.

    Approve system boundaries and acceptance
  3. Incremental delivery

    Use working frontend and backend slices to validate risky workflows and integrations early.

    Demo, test, and adjust each increment
  4. Launch & operations

    Prepare deployment, data, and handoff, then improve the system based on real use.

    Confirm launch, monitoring, and ownership

WAYS TO START

Wherever the project is today, find a practical next step

The first conversation assesses the current state and risks without assuming everything needs to be rebuilt.

  • Build from zero

    Turn an early idea into an executable first-release scope.

  • Take over an existing system

    Audit code, architecture, deployment, and issues before sequencing the handoff.

  • Extend features & integrations

    Add modules, third-party services, or new data flows to an existing operation.

  • Technical planning & guidance

    Help the team clarify architecture, requirements, and delivery decisions.

FAQ

Questions you may have before getting started

Can we talk if I only have an early idea and no requirements document?

Yes. We can start from how work happens today, what you want to improve, who uses the system, and known constraints. No technical specification is required before the first conversation.

How are budget and timeline estimated?

First, we clarify outcomes, scope, integrations, and major risks. The work is then divided into reviewable delivery phases. When uncertainty is high, a focused validation phase avoids pricing a large build around vague assumptions.

Can you take over an existing system?

Yes. I first review the code, database, third-party services, deployment environment, account access, and current issues, then outline handoff risks and an incremental improvement order.

Can the engagement include UI, backend, deployment, and maintenance?

Yes. The scope can cover interfaces, frontend, APIs, databases, deployment, and maintenance, or integrate with your existing design and engineering partners. Responsibilities are made explicit in the proposal and specification.

Do we need to choose a technology stack first?

No. Technology follows the users, constraints, current resources, integrations, maintenance capacity, and budget. We define the problem first, then choose a solution the organization can sustain.

START WITH THE PROBLEM

Bring the current situation. Leave with a clearer next step.

You do not need a finished specification. We can review the workflow, problem, and constraints, then identify the most sensible place to begin.