- 9 minutes to read

What is a System?

Take full control of your integration landscape by managing Systems in Nodinite. This page guides you to map dependencies, analyze impact, and streamline system replacement for robust enterprise integration.

✅ Map and visualize all system dependencies for every integration
✅ Instantly analyze the impact of changes or replacements
✅ Streamline documentation and governance with custom metadata and fields
✅ Empower your teams to manage integrations with confidence and agility

Start now: See the Add or Manage System user guide.

Understanding Systems in Your Integration Landscape

A System represents any source or destination entity involved in message exchanges within your integration landscape. In Nodinite, a System is a foundational entity in the Repository Model that identifies who participates in integrations—whether that's an internal application, an external partner organization, a middleware platform, or a third-party service.

Systems serve as either the Source (sender) or Destination (receiver) in message flows. Every Service you define belongs to exactly one System, creating clear ownership and accountability for each integration endpoint. This structure enables precise mapping, impact analysis, and dependency tracking across your entire integration portfolio.

Systems Can Represent Different Concepts

The flexibility of the System entity is one of its greatest strengths. A System can represent:

  • Software Products: BizTalk, SAP, Dynamics 365, MuleSoft, IBM MQ
  • External Organizations: Customer ABC, Supplier XYZ, Partner DEF
  • Internal Applications: HR+, PIM (Product Information Management), MES (Manufacturing Execution System)
  • Cloud Services: Azure Logic Apps, AWS Lambda, Salesforce
  • Legacy Systems: Mainframe applications, on-premises databases, file servers

This flexibility means you can model your integration landscape exactly as your business sees it—not forced into artificial categories.

graph LR A(System A) -->|Interacts| B(System B)

A simplified example shows System A passing information to System B.

Common System Examples

Examples of Systems you might manage in Nodinite include:

  • BizTalk
  • SAP
  • TEIS
  • Dynamics 365
  • Insightly
  • PIM
  • MES
  • Customer ABC
  • HR+
  • Bluegarden
  • Evatic
  • Basware

Systems Connect Through Services

Systems don't interact directly—they connect through Services. This is a critical architectural principle in Nodinite's Repository Model:

  • A System owns one or more Services
  • Each Service has a direction: Send, Receive, Two-way Send, or Two-way Receive
  • Services contain Transport Contracts that define the actual message exchange points
  • An Integration documents the relationship: "System A sends via Service X to System B which receives via Service Y"

This Services-based connection model provides several advantages:

  1. Clear Ownership: Each Service belongs to exactly one System, establishing accountability
  2. Reusability: One Service can participate in multiple Integrations
  3. Impact Analysis: When a System changes, you instantly see affected Services and their Integrations
  4. Direction Clarity: Service direction (Send/Receive) makes message flow explicit

Complex Integration Scenarios

With Nodinite, you manage relationships between Systems using the Integration Landscape feature.

Real-world integrations often involve more than simple A-to-B scenarios. Systems interact in complex patterns with multiple participants, bidirectional flows, and hub-and-spoke architectures:

graph LR A(SAP) --> B(BizTalk) B --> C(MES) B --> D(HR+) D --> B B --> A

A more complex systems integration scenario showing BizTalk acting as a hub connecting SAP, MES, and HR+ Systems with bidirectional flows.

In this example, BizTalk acts as an integration hub (middleware System) routing messages between SAP (ERP System), MES (manufacturing System), and HR+ (HR System). The bidirectional arrows show two-way communication patterns common in enterprise architectures.

How Systems Fit into the Integration CMDB

Systems are a foundational layer in Nodinite's purpose-built integration CMDB (Configuration Management Database). While traditional CMDBs track generic IT assets like servers and applications, Nodinite's Repository Model focuses specifically on integration relationships:

  • Integrations document the "what" (which integration scenarios exist)
  • Systems identify the "who" (which entities participate)
  • Services define the "how" (what endpoints and contracts enable the exchange)
  • Message Types specify the "format" (what message structures are exchanged)
  • Endpoints detail the "where" (which physical transport channels are used)

This Systems-centric view enables powerful capabilities:

✅ Portfolio Management: See all Integrations involving any System
✅ Impact Analysis: Assess replacement or upgrade consequences instantly
✅ Dependency Mapping: Understand upstream and downstream relationships
✅ Operational Context: Link Systems to monitored Resources showing real-time health
✅ Living Documentation: Systems auto-populate from logged events (no manual maintenance)

A System has a unique name within Nodinite and can include any number of custom properties (Custom Metadata). You connect each System with others through Services and, optionally, Contracts. Use the Integrations entity to manage these relationships.

Impact Analysis: Why System Replacement Becomes Manageable

One of the most powerful capabilities Systems provide is instant impact analysis for changes and replacements. When you need to upgrade, migrate, or replace a System, Nodinite shows you exactly what's affected:

Before Nodinite: Replacing a System meant hunting through documentation, spreadsheets, code repositories, and tribal knowledge. Teams spent weeks identifying affected integrations, often discovering hidden dependencies during deployment—causing outages and rollback chaos.

With Nodinite: Click on any System in the Web Client and instantly see:

  • All Integrations where this System participates (as source or destination)
  • All Services owned by this System
  • All Transport Contracts involving this System's Services
  • All Message Types exchanged with this System
  • Recent log activity showing actual usage patterns

This complete impact picture enables confident decision-making:

✅ Plan Migrations: Know exactly which integrations need updating before you start
✅ Estimate Effort: Count affected Services and Integrations for accurate resource planning
✅ Prioritize Work: See which Integrations are actively used vs dormant
✅ Communicate Changes: Share System relationship diagrams with stakeholders
✅ Reduce Risk: Test all affected integrations systematically—no surprises

Relations
The Relations view shows all Integrations where this System participates, providing instant impact analysis.

Example: Replacing SAP with SAP S/4HANA

Imagine your organization is migrating from SAP ECC to SAP S/4HANA. In Nodinite:

  1. Open the "SAP ECC" System
  2. View all Integrations involving SAP ECC (might be 50+ integrations)
  3. Review which Services belong to SAP ECC
  4. Create new "SAP S/4HANA" System
  5. Clone Services from SAP ECC to SAP S/4HANA (adjusting endpoints as needed)
  6. Update Integrations one by one, testing thoroughly
  7. Monitor both Systems during parallel run
  8. Retire SAP ECC System when migration complete

The Integration Landscape visualizes this entire process, showing the before and after architecture clearly.

Systems in the Interactive Integration Landscape

The Integration Landscape is Nodinite's truly unique visual exploration feature—and Systems are a primary navigation point. No competing product offers this capability:

  • Visual Design: Drag Systems onto the canvas to design integrations before building them
  • Auto-Population: Systems appear automatically from logged events (living documentation)
  • Click-Through Navigation: Click a System to see its Services, Integrations, and recent log activity
  • Relationship Discovery: Hover over connections to see which Services link Systems together
  • Filter and Focus: Hide/show Systems by Application, Category, or custom criteria

The landscape makes Systems tangible and explorable—not just database records. Business analysts, architects, and operations teams can all understand your integration portfolio visually.

Systems in Operational Monitoring and Alerting

Systems aren't just documentation—they're embedded in Nodinite's operational features:

In Logging

When you view log events in the Web Client, System information provides critical context:

  • Filter log events by System (show me all messages from SAP)
  • Search across all messages involving a specific System
  • Correlate events across integrations by System participation
  • Identify which System generated errors in multi-hop scenarios

In Monitoring

Link Systems to monitored Resources to show operational health:

  • A "SAP Production" System can link to CPU, memory, and disk Resources monitoring the SAP server
  • When viewing the System in the Integration Landscape, see real-time health indicators
  • Alerts can include System context: "Integration Order-to-Cash failed—System SAP is experiencing high CPU"

In Alerts

Email and webhook alerts automatically include System information:

  • "Message from System Dynamics 365 to System BizTalk failed"
  • Custom Metadata attached to Systems (owner, support contact, SLA) appears in alert body
  • Recipients immediately know which systems are involved without checking documentation

This operational integration means Systems serve double duty: design-time documentation AND runtime context.

Custom Metadata

As with all entities in the Nodinite Repository Model, you assign any number of Custom Metadata fields to a System. This approach supports flexible documentation and governance, so you capture all relevant system-specific information.

Common System Custom Metadata examples:

  • Owner: Department or team responsible for the System (IT, Finance, HR)
  • Vendor: Software vendor or partner organization
  • SLA Level: Gold, Silver, Bronze for support prioritization
  • Environment: Production, Test, Development
  • Technical Contact: Primary support contact for System issues
  • Business Contact: Business stakeholder for System changes
  • Compliance Tags: GDPR, HIPAA, PCI-DSS if System handles regulated data
  • Lifecycle Stage: Active, Deprecated, Decommission Planned

These metadata fields appear throughout Nodinite—in the Integration Landscape, in log views, and in monitoring alerts—providing consistent context wherever you encounter a System.

Custom Fields

Similarly, you assign any number of Custom Fields to a System, enabling tailored information management for your integration landscape. This flexibility ensures your documentation and tracking always align with your business needs.

Tip

Prefer Custom Metadata over Custom Fields for new implementations. Custom Metadata offers richer features including mandatory fields, filtering, and better governance.

Who Uses Systems?

Different roles interact with Systems for different purposes:

Integration Architects: Design integration portfolios by defining Systems and their relationships. Use Systems to establish clear boundaries and ownership in SOA architectures.

Solution Designers: Map Integrations between Systems in the Integration Landscape. Identify which Systems need to communicate and design the Services that connect them.

Developers: Associate Services and Transport Contracts with the correct System. Ensure logging Context Options populate System information for automatic landscape building.

Operations Teams: Monitor Integrations filtered by System. When a System experiences issues (high CPU, connectivity problems), quickly identify all affected integrations.

Business Analysts: Understand which systems participate in business processes. Use the Integration Landscape to show stakeholders how Systems interact in Order-to-Cash, Procure-to-Pay, or other workflows.

Compliance Officers: Verify which Systems exchange regulated data. Use Custom Metadata on Systems to track GDPR, HIPAA, or industry-specific compliance requirements.

Next Step

System Overview
Add or manage System
Learn about Services (Systems connect through Services)
Explore Integrations (document System-to-System relationships)
Integration Landscape (visualize your Systems and their connections)

Understanding Repository Model Entities

Repository Model (complete integration CMDB overview)
Integrations (root object documenting System-to-System relationships)
Services (Systems own Services that enable message exchange)
Endpoints (physical transport channels used by Services)
Message Types (message formats exchanged between Systems)

Managing Systems

Custom Metadata (add business context to Systems)
Custom Fields (legacy metadata approach)
Resources (link operational monitoring to Systems)

Operational Features

Log Views (filter log events by System)
Monitor Views (operational monitoring with System context)
Alarm Plugins (alerts include System information)