Forem: Andrii Siryi

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:11:28 +0000

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:07:31 +0000

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

How to build an AI that predicts ERP integration failures.

Andrii Siryi — Tue, 28 Oct 2025 15:01:37 +0000

Everyone who works with integrations has faced situations where integration can break for different reasons, and the system or business analyst can spend hours chasing failures after they happen.

But what if we can predict integration failures before they occur?

Just as NVIDIA does in its NVIDIA Omniverse platform (https://www.linkedin.com/showcase/nvidia-omniverse/), where AI simulates robot collisions and system bottlenecks before real-world deployment, you can try those predictive steps in the ERP integration processes.

So, first of all, you can try to collect integration logs to the CSV file over the past few months. For example, I extracted the following:

ERP type (NetSuite, Sage Intacct, etc.)
API endpoints (/invoices, /payments, /customers, etc)
Payload size
Number of fields
Response time
HTTP status code
Outcome (1 = success, 0 = failure)

These fields gave the model context on what happens under the hood of each request.

I attached the example of the CSV table.

The second step, you train an XGBoost classifier.

Using Google Colab (https://colab.research.google.com/), I trained the model on ~1000 rows of logs.
The model learned patterns like:

Payloads >500 KB + more than 3 custom fields + /invoice = 78% failure risk.

The third step, I tested new requests.

Before hitting the ERP API, I request metadata through the model. If the predicted risk is high, I pause, flag it, or reroute it.

Finally, you will receive:

a) Caught high-risk failures before they happened;
b) Reduced fire-fighting in production;
c) Gave business visibility into fragile integration conditions;
d) Boosted confidence during testing;

Using NVIDIA NeMo Agent Toolkit to improve data sync processes

Andrii Siryi — Tue, 28 Oct 2025 14:59:27 +0000

As a PO/BA/SA managing different integrations, you often deal with complex workflows: syncing various data across systems. Manually tracking these operations can be slow, difficult, and error-prone.

NVIDIA NeMo Agent Toolkit (NAT) helps automate, monitor, and optimize these workflows with minimal coding.

What it does:

NeMo Agent Toolkit allows you to create intelligent agents that call your integration tools — REST/GraphQL APIs, SDK clients — in a structured workflow. Agents can reason about steps, execute actions, log results, and provide insights through dashboards.

How I apply it:

Sync Monitoring Agent

For instance, if you work with ERP integrations, you can build a simple agent to check the status of invoices and payment syncs. It verifies balances, ensures all required fields are updated, and highlights inconsistencies.

Hands-On Without Developer Skills

NAT provides a web UI accessible at http://127.0.0.1:5173 after running.
In this UI, you can type commands like: Sync Agent: Check invoices for Customer ABC.

The agent sequentially calls tools you have configured — e.g., fetching invoices, payments, and calculating balances, and displays results step-by-step. After that, I can see which invoices are synced, which need attention, and suggested actions. And all without writing code.

Connecting to your Connector

Any API or SDK call from your connector can be registered as a tool in NAT. Then, the agent’s workflow uses these tools to perform actions like retrieving any data, applying some logic, and validating sync status. The UI provides real-time logs, so you can see exactly what the agent did, step by step.

Iterative Learning

Start with a small set of scenarios, for instance, such as partially paid invoices or overpayments. Running them through the agent refines its workflow and improves accuracy. Over time, the agent becomes smarter and more reliable.

So, why can it be important for PO/BA/SA?

With NAT, you can manage and optimize syncs efficiently, even without a development background. Agents make processes observable, repeatable, and actionable. The web UI ensures you can interact with the agent, monitor results, and improve workflows.

Here is the link to the documentation - https://developer.nvidia.com/nemo-agent-toolkit

Using Python and AI to Enhance Requirements Elicitation

Andrii Siryi — Tue, 28 Oct 2025 14:53:59 +0000

In my work as a Product Owner and System Analyst, collecting and reviewing requirements and documents is a daily task.

To make this process faster and more efficient, I developed a small assistant using Python and AI.
The assistant monitors comments in Google Docs. When I highlight text and write a question or instruction starting with AI:, the bot analyzes the selected text and provides feedback directly in the document.

This approach helps to:

Quickly check the format and clarity of requirements.
Provide suggestions for improving text without leaving the document.
Save time for System/Business Analysts and Product Owners who frequently review content.

From a technical perspective, the Python script uses several key components:

Google Docs and Drive APIs to read comments and post replies.
OpenAI API to analyze highlighted text and generate feedback.
Logic to ignore old comments at startup and avoid duplicate replies, ensuring the bot only responds to new or repeated comments intentionally.
Temporary tracking of processed comment IDs during each cycle to maintain performance and prevent multiple responses to the same comment.

By combining Python and AI, this tool automates part of the review process, letting me focus on higher-level analysis and decision-making instead of manual text checks.

I attached straightforward examples of how it looks:

Safe and Smart Project Discovery. How NVIDIA Nemotron Beats Cloud AI for Integration Projects

Andrii Siryi — Tue, 28 Oct 2025 14:52:27 +0000

When you start an integration project, the discovery phase is a very important part to understand the application, APIs, and processes. It can take a lot of time if done manually.
Unlike cloud AI tools, which can raise concerns about data privacy, NVIDIA Nemotron works locally. This means your project data stays safe while Nemotron helps you analyze it.
Nvidia Nemotron it is a thinking brain that can predict a lot of steps ahead.
The model reads documentation, understands patterns, and can even suggest next steps, helping the team move faster and avoid mistakes.

Why Nvidia Nemotron works well for discovery:

Security: Your sensitive data never leaves your environment.
Smart analysis: Nemotron can process technical documents and find important details quickly.
Guided steps: It can suggest what to check next, making discovery more structured.

Practical example:
As an example, I used Nvidia Nemotron to review API documentation. It helped identify key API endpoints, authentication methods, potential error scenarios, potential documents behaviour depends of their statuses.
Within a few hours, I had a structured discovery project report and clear next steps for testing.
Thus, within a few hours, I can quickly assess how the integration with this system might look and whether it is generally compatible, based on the requirements of the system that will receive the integrated data.

Compared to using ChatGPT or other OpenAI tools, I didn’t expose sensetive data. Nemotron’s local, thinking approach made the discovery phase faster, safer, and more predictable.

Explore NVIDIA Nemotron here:https://www.nvidia.com/en-us/ai-data-science/foundation-models/nemotron/

Lessons from Volvo and BMW: How Car Companies Really Integrate Their Systems

Andrii Siryi — Tue, 28 Oct 2025 14:49:30 +0000

Integrating systems in the automotive industry is much more complex than just data mapping between standard business systems like ERP or CRM. A good real-world example is the collaboration between Volvo and BMW in Vehicle-to-Everything (V2X) and telematics services, where cloud platforms, ECUs, telematics units, and ADAS systems all need to work together. These projects require attention not only to data structures but also to protocols, security, and real-time operation.

https://www.energy-storage.news/bmw-volvo-step-up-interest-in-bi-directional-charging-and-vehicle-to-x-use-cases/

Key Differences in Automotive System Integration

Looking at Volvo and BMW, we can see several things that make car system integration different from standard data integration:

Variety of systems -> ECUs, telematics, multimedia, ADAS, each using different protocols (CAN, LIN, Ethernet).

Real-time data -> sensors and control systems need instant responses; batch updates alone are not sufficient.

Security and standards –> ISO 26262, AUTOSAR, certified protocols, and encryption are required.

Complex data –> binary packets, telemetry, and multiple parameters with interdependencies.

Version compatibility –> ECUs and software may have different versions, so integration should ensure compatibility.

Approaches for the Discovery Phase

For systems analysts planning integration in automotive projects, the following methods are especially useful during the discovery phase:

Integration Context Mapping –> visual maps showing how systems and modules interact, including data flows.
Interface Analysis –> detailed study of interfaces, protocols, message formats, and security requirements.
Data & Protocol Mapping –> matching parameters and formats between systems, including unit conversions and range checks.
Sequence Modeling –> diagrams showing the order of messages and system reactions in real time.
Gap Analysis & Compatibility Assessment -> identifying version mismatches, protocol differences, and standards gaps.
Proof of Concept (PoC) –> pilot testing integration points to verify data flow and timing.

Conclusion

The discovery phase in automotive system integration goes beyond simple data mapping. System Analysts should understand technical system features, protocols, security, and version compatibility.
Using structured analysis methods and visual models helps plan integrations correctly and reduces risks when connecting complex automotive systems.

YAML-Based Story Mapping

Andrii Siryi — Mon, 27 Oct 2025 07:26:58 +0000

System Analysts who work with integration processes should formulate user stories in a way that diverges from the traditional structure. This is primarily due to the need for a more technical and structured description, which allows for the inclusion of integration-specific details.

The user story might need to specify exactly what kind of data should be retrieved via an API, from which system, using what HTTP method, and so on.
Additionally, such user stories can incorporate validation requirements.
For instance, before sending the data to an external system through an API, certain transformations or formatting might be required.

As a result, the structure of a user story in this context tends to differ significantly.

Here’s an example of how a story might look:

story_map:
epic: "Invoice Integration"

user_stories:

id: US001
title: "Obtain AR invoice"
as_a: "Application X"
i_want: "obtain AR invoices from ERP {{X}} via API"
so_that: "I can handle this invoice and send to the client"
source_system: "ERP {{X}}"
target_system: "Application X"
direction: "pull"
api_call:
method: "GET"
endpoint: "/api/invoices"
auth_required: true
id: US002
title: "Validate data"
as_a: "Application X"
i_want: "validate the fields of the received invoice"
so_that: "I don't sync the invoice with errors"
validation:
invoice_number: "required"
invoice_id: "required"
invoice_total_amount: "should be > 0"
invoice_status: "should be 'posted'"
id: US003
title: "Push invoice payment"
as_a: "Application X"
i_want: "push the invoice payment created in Application X to the ERP"
so_that: "the payment is approved in the ERP and synchronized back"
source_system: "Application X"
target_system: "ERP {{X}}"
direction: "push"
api_call:
method: "POST"
endpoint: "/api/payments"
auth_required: true

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Mon, 27 Oct 2025 07:26:26 +0000

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Recommendations on how to properly troubleshoot integration issues in support.

Andrii Siryi — Mon, 27 Oct 2025 07:25:51 +0000

When a client reports that certain data hasn’t synced correctly, it’s important to follow a structured, step-by-step troubleshooting process to identify and resolve the root cause.

I added some recommendations that can help quickly to identify the root cause:

Start with the integration logs.

a) You need to Identify the relevant API request/response in logs.
b) Check timeouts, unexpected responses, or missing data in the response, and check the consistency of the API call.

Check the connector transformation logs.
Here you can identify if any errors occurred while parsing, mapping, or converting the data.
Inspect the upload database.
a) Compare the data received by the connector via API with what's stored in the Database.
b) Ensure that all required fields are present and valid.
c) This helps determine whether the issue occurred before or after the upload stage.
Check sync rules and configuration.
Ensure the sync configuration matches the data:
a) Is the object type enabled for syncing?
b) Are the filters or date ranges correctly set?
c) Are the fields mapping misconfiguring?
Try to reproduce the issue (if needed).
If the problem persists, try to replicate the issue in a test environment or sandbox with similar data.
This helps confirm if the root cause is data-specific, configuration-based, or system-wide.
Communication with the client.
Keep the client informed at each stage:
a) What was checked
b) What was found
c) What actions will be taken (manual resync, fix deployment, etc.)

Think Twice: Customizations That Break Your Integration

Andrii Siryi — Mon, 27 Oct 2025 07:24:26 +0000

When you build data integrations between applications, small details are very important. If you miss them, you might need to rebuild parts of the integration later, which costs time and money.

One common case is when a team asks the client to make custom changes in their system to help sync the data. This might work in the short term, but it can also bring risks if you don’t think it through.

Before you suggest or require such changes, ask yourself:

Will this work for all clients, or just a few?
Does it require an extra license?
Can the client do it themselves, or will they need outside help (for example, a vendor)?
Is it supported in every version of the app?
Could this setting be removed or changed later in the app?

Why this matters:

Scalability –> integrations should work for many clients, not only special cases.
Maintainability –> customizations can break after upgrades and create extra work.
Risk reduction –> planning early helps avoid broken syncs and unhappy clients.

By asking these questions up front, you can save a lot of rework and keep integrations stable in the long run.

Stop Pulling Your Hair Out Over Integrations: Simple Tips

Andrii Siryi — Mon, 27 Oct 2025 07:22:47 +0000

Using your app to integrate data from an ERP system requires some essential tips and things that you need to keep in mind to avoid problems later.

Understand What Data You Need to Integrate
Before setting up the integration, you should understand which ERP data your app will use and how it should be mapped inside your app. This helps prevent mistakes later.
Choose the Right Integration Approach
Your app can get data in different ways. Sometimes a simple API call is enough, sometimes you need more complex workflows to reduce the complexity and minimize API calls. Pick the approach that works for the data you need and the ERP system you’re integrating with.
Make Sure the Data is Accurate
Always check that the data coming from ERP is clean. Remove duplicates, verify references, and make sure everything matches your app’s requirements. Clean data makes the integration reliable.
Think Carefully About Customizations
ERP systems often need small tweaks to work perfectly with your app. But customizations can be risky, costly, and hard to maintain. Only ask clients for changes if it’s really necessary, and plan for long-term support.
Plan for Scale and Maintenance
Make sure your integration works for multiple clients and multiple ERP versions. Use automation in your app to handle repetitive tasks and make updates easier. This keeps everything stable as your client base grows.
Consider Non-Functional Requirements
It’s important to understand how much data the client plans to integrate and how often. This helps you estimate the system load, predict performance impact, and plan for stress testing. Thinking about this upfront prevents surprises and ensures the integration runs smoothly under real conditions.