Smart Power Plant Operations & Production Admin

What it was

Fold operations, maintenance, and planning documents into an admin system—without rebuilding shop-floor control.

What was stuck

Operations, maintenance, and planning each reconcile from their own sheets and chat logs. The floor already has a control system. A second control layer will not be used; if who starts, approves, and reconciles is not drawable first, documents stay in spreadsheets.

What I did

• Use the platform frame for shared capabilities (permissions, process, master data); express plant or discipline differences as configuration.
• Process before feature lists: the path must be drawable before screens and APIs are split.

Desensitized flow

Uses only confirmed framing: recent SOE smart-plant work on platform frame and process design for operations and production admin. Internal architecture dumps, system lists, and machine specs are not invented.

1. 1

   Roles and path

   Name operations, maintenance, and planning roles; draw start—approve—execute—write-back.

2. 2

   Master data and documents

   Keep asset/org/permission master data apart from work-order documents so one sheet is not both archive and process.

3. 3

   Configurable process

   Pack nodes, I/O, and permissions into adjustable process—not a hard-coded UI per plant.

4. 4

   Integrate site systems

   The admin layer consumes or writes back to existing production/ops domains; it does not replace site control.

Outcomes

The path of who starts, approves, and executes is drawable, and admin does not take over unit control. Public names and numbers still to be added.

• A narratable boundary: smart-plant admin and production back office as frame + process + integration—not a feature pile. Public legal names and quantified results still to be added.

How I talk with engineering

Talking architecture here is the same pattern as auto config/change platforms: domains before services. The plant already has production-control systems; the admin layer is coordination and documents—not a second DCS.

How I saw it: Admin should not replace the shop floor

Appendix

Own the platform frame and process design for operations and production admin: bound domains and roles, define master data and documents, and lift configurable workflows out of one-off offline coordination. Legal entity names, internal system dumps, and unpublished metrics are omitted.

What I owned

• Admin for plant operations and production: roles, permissions, process nodes, master data and documents, and the integration boundary with existing production/ops domains.
• Platform frame: which capabilities are reusable modules (org/permissions, process, master data) versus plant-scenario configuration.

What I did not own

• Unit control, protection, and real-time shop-floor control (production-control systems—not rewritten in the admin back office).
• Unpublished legal names, credential-level integration detail, and sensitive operating metrics.

Collaboration

• Business: with operations, maintenance, and planning, turn how work actually happens into configurable process.
• Engineering: align domain bounds, master data, and integration. Product states NFRs (permissions, audit, volume magnitude); engineering owns stack and sizing.

How we split the layers (no stack picks)

• Access: admin portal with role-based menus and permissions—not one UI for every role.
• Application: modules by domain (master data, process, rules, documents)—bound the domains before splitting services.
• Data: master data separate from operational documents, plus audit/logs for traceability.
• Integration: connect to existing ERP / MES / production or commerce systems—do not rewrite shop-floor control or core ledgers.

How to size a separately deployed module

When a module ships as its own deployable, product gives order-of-magnitude needs with the method below—no core/RAM numbers until confirmed.

• Stateless apps: size instances by admin-seat count and peak concurrency; scale out. Ask “who is on at once” before asking for a machine SKU.
• Database: document volume and whether reporting contends with writes decide read replicas or a separate reporting store.
• Files and logs: attachments, exports, and audit trails should not live only in the OLTP database.
• A separately deployed mid-size admin module is usually app instances + database + needed middleware. Spine vs edge modules differ by a tier. Core/RAM are an engineering load-test call; product states availability, permissions, audit, and order-of-magnitude volume.