Victor Maragioglio

whitepaper.id

whitepaper.id works with SAP integration and interface management, helping teams make complex integration landscapes more transparent, manageable and controlled.

As user interface designer, I worked on the design and development of an SAP integration cockpit, using Svelte and IBM Carbon Design System.

Year
2022
Role
User Interface Designer
Type
Enterprise Software
Discipline
UI Design / Frontend Development
System
  • Svelte
  • IBM Carbon Design System
Location
Hannover

01 Understanding the problem

Companies run many systems. Interfaces connect them, and those connections carry the processes that run across applications. This section explains the problem the interface was designed for.

01

A simple network

A few business systems exchange information through interfaces.

02

A complex network

The problem is not connecting two systems. The problem is understanding hundreds of connections at once.

03

A structured, managed network

The same systems and interfaces, grouped, indexed and classified.

  1. InventoryWhat exists?
  2. DocumentHow is it connected?
  3. MonitorWhat is happening?
  4. GovernHow is it controlled?
  • Transparency
  • Control
  • Quality

whitepaper.id

SAP interfaces · Interface management · Integration excellence

whitepaper.id works with SAP integration and interface management, helping teams make complex integration landscapes more transparent, manageable and controlled.

Integration happens between systems.
Understanding happens through the interface.

Diagram showing a small set of business systems becoming an increasingly complex integration network, then being reorganized through inventory, documentation, monitoring and governance. whitepaper.id works with SAP integration and interface management, helping teams make complex integration landscapes more transparent, manageable and controlled.

02 The integration cockpit

A control center for understanding interfaces, integrations and the systems around them.

If the integration landscape is the system, the Cockpit is the interface through which that system becomes understandable. Complex products do not need more visual invention. They need stronger rules: IBM Carbon provides consistency, hierarchy, predictability and a pattern for every new screen.

Step 01 / 12 · Sign in

Outside the system: a restrained sign-in.

  1. Whole landscape
  2. Inventory
  3. Integration
  4. Component
  5. Runtime signal

Product reconstruction based on historical project context and publicly available WHINT product information. Demo data is fictional. Historical project: Svelte and IBM Carbon Design System. This reconstruction: React and Next.js with @carbon/react.

  1. Sign in: Outside the system: a restrained sign-in.
  2. Overview: Inside the Cockpit. An overview of the whole landscape, before any detail.
  3. Catalog: The catalog: applications, partners, objects and interfaces as one structured inventory.
  4. Integrations: Every integration, with its sender, receiver and transferred object.
  5. Search: Search narrows the inventory.
  6. Integration: One integration. The row opens into its detail: sender, receiver, object.
  7. Components: An integration is not necessarily one line. It can consist of several technical components.
  8. End to end: The same integration as a path: sender, API proxy, queue, integration flow, receiver.
  9. Component: Select a component to see what it does.
  10. Landscape: Zoom out: the integration in its landscape of applications, integration layer, partners and objects.
  11. Reporting: Reporting: the runtime signal of the same integration.
  12. Errors: Errors and stability, for exploring the interface. The numbers are demo data.

03 Seeing the integration

One order. Many systems.

What looks like one purchase to a customer can trigger a chain of systems, interfaces and decisions across an enterprise.

Packet ORDER #10482Demo data

Sender
Customer · web client
Receiver
Commerce · storefront
Object
Order
Event
CheckoutSubmitted
Type
REST API
Environment
PROD
Status
Healthy

01 / 08 · PurchaseA customer buys a product.

One order. Many systems. What looks like one purchase to a customer can trigger a chain of systems, interfaces and decisions across an enterprise. An isometric world: a home, a commerce storefront, a payment service, an ERP, a warehouse with a worker, a loading dock and logistics, a notification service, and, apart from the business world, a control room where an integration manager observes. One order token travels between them. The simulation has its own controls: previous, play or pause, next, the eight steps, Story or Debug, zoom, and, once the journey has been seen, a failure to simulate.
  1. Step 01, Customer → Commerce: A customer buys a product. The token reads ORDER #10482. Debug reading: Customer · web client sends Order (CheckoutSubmitted, REST API) to Commerce · storefront, PROD, Healthy.
  2. Step 02, Commerce → Payment: The payment is requested. The token reads PAYMENT #10482. Debug reading: Commerce · storefront sends Payment (PaymentAuthorizationRequested, REST API) to Payment service · PSP, PROD, Healthy.
  3. Step 03, Payment → Commerce: The payment is processed. The token reads PAYMENT #10482. Debug reading: Payment service · PSP sends Payment (PaymentAuthorized, REST API) to Commerce · storefront, PROD, Healthy.
  4. Step 04, Commerce → ERP: The order enters the business system. The token reads SALES ORDER #10482. Debug reading: Commerce · storefront sends SalesOrder (OrderCreated, Integration Flow) to ERP Central, PROD, Healthy.
  5. Step 05, ERP → Warehouse: The warehouse receives work. The item is picked. The token reads PICK REQUEST #10482. Debug reading: ERP Central sends PickRequest (PickRequested, Integration Flow) to Warehouse · WMS, PROD, Healthy.
  6. Step 06, Warehouse → Loading dock → Logistics: Shipping starts. The token reads SHIPMENT #10482. Debug reading: Warehouse · WMS sends Shipment (ShipmentBooked, REST API) to Carrier API, PROD, Healthy.
  7. Step 07, Logistics → Notification → Customer: The customer is notified. The token reads NOTIFICATION #10482. Debug reading: Carrier API sends Shipment (ShipmentDispatched, Event) to Notification service, PROD, Healthy. Debug reading: Notification service sends Notification (CustomerNotified, Notification) to Customer · web client, PROD, Healthy.
  8. Step 08, The complete flow: The business sees one purchase. The integration landscape sees a chain of events. Debug reading: Notification service sends Notification (CustomerNotified, Notification) to Customer · web client, PROD, Healthy.
Same process. Different reading. Story mode shows what the business experiences; Debug mode shows the same world with the systems, interfaces, events and a packet card. Each business action is an exchange between systems: a sender, a receiver, an object, an event.Failure. Purchase successful, Payment successful, ERP receives the order. Then the pick request stalls between the ERP and the warehouse: the order is delayed, the worker stays idle, the shelf stays full and the warehouse status turns to warning. Something stopped. The warehouse never received the work. Now we can see where. The ERP → Warehouse integration failed after three retries. The debug layer shows the ERP Central to Warehouse · WMS interface (PickRequest, PickRequested, Integration Flow, PROD) with status error, error timeout, retry 3 of 3, dependency Warehouse WMS API. The observer in the control room receives a warning. See the whole journey. Inspect what is underneath.8 interfaces in this demo. All values are fictional demo data.

Two readings

What looks like one purchase to a customer can trigger a chain of systems, interfaces and decisions across an enterprise.

The same process can be read twice. Story shows what the business experiences. Debug shows what the integration landscape is doing underneath. The world does not change; only the reading does.

Concept study using fictional process data to explore how enterprise integrations can be made more legible. System names and technical values are demo data, not WHINT architecture and not an existing product feature.

04 From one to thousands

One process can be followed by eye. A large integration landscape cannot.

Business process view

Order #10482

One business process. It can be followed by eye.

  1. 01 Customer → Commerce
  2. 02 Commerce → Payment
  3. 03 Payment → Commerce
  4. 04 Commerce → ERP
  5. 05 ERP → Warehouse
  6. 06 Warehouse → Loading dock → Logistics
  7. 07 Logistics → Notification → Customer

Order #10482: one business process across 7 steps.

Representation

Visualization can narrow the landscape from thousands of relationships to one explainable process.

One process
show the world.
One hundred flows
show the topology.
One thousand integrations
show the structure.

Then filter until the detail becomes human again. The same data supports every view; only the representation changes with the question. No AI is involved: filters, structure and semantic zoom do the narrowing.

Domains, systems, flows and counts in this section are fictional sample data for a portfolio study. They are not WHINT customer architecture or product figures.

Filtering works when you know what to look for.
What happens when you do not?

05 Does this need AI?

Reflection

Working at whitepaper.id introduced me to a class of software where the interface has to make highly technical systems understandable without oversimplifying them. That problem has stayed interesting to me: how information architecture, visualization and motion can help people reason about infrastructure they cannot see directly.

whitepaper.id · User Interface Designer · 2022 · Svelte, IBM Carbon Design System