Introduction

Purpose

The purpose of this document is to outline the infrastructure and network architecture of the Syniti Platform for the SyWay project. It aims to provide a clear and structured view of the components, data flows, integration mechanisms, and security considerations that support the Syniti platform in its interaction with the Syensqo SAP ecosystem.

Syniti is an unified platform designed to manage, migrate, and govern enterprise data. In the SyWay project, it will remain as the primary platform for managing extraction, transformation, load and validation. Below diagram shows high level activities that can be performed with this platform:


Scope & Objectives

This document defines the architectural scope of the Syniti solution within the SyWay project, focusing on the deployment and integration of Syniti as the central platform for data extraction, transformation, loading (ETL), and validation activities.

The scope includes:

  • The technical architecture of Syniti Platform and its supporting components.
  • The integration architecture between Syniti and SAP systems.
  • The security and connectivity model, including configurations, RFC destinations, and access control mechanisms.
  • The deployment model for the Rest of World (RoW) Landscape.

Out of scope:

  • The data flow architecture, covering how data is extracted from source systems, transformed according to business rules, validated, and loaded into target SAP environments.
  • The detailed functional design of migration objects, business rules, or data cleansing logic, which are addressed in separate deliverables.

  • The list of required and approved tables to be extracted from source system is out of the scope of this document. This will be defined during the Data Stream design phase.
  • It also excludes operational procedures post-migration, such as data governance or ongoing data quality monitoring, unless explicitly tied to the Syniti platform.

  • As of writing this document, there are pending architectural decisions regarding North America & China, and RISE infrastructure. These designs will be added to this document as they are finalized.
  • Security policies in Syniti SKP for application users.

Key Decisions and Requirements


Requirement IdentifierRequirement Description
Single Instance
  • Syniti platform will have a single Production Instance serving the entire Syensqo ROW Landscape. It will connect to the different environments (Dev, QA, Prod) of source and target systems.
Source Systems for Data Extraction
  • Source Systems for data extraction will be SAP ECC Syensqo WP2 and PF2. 
Target Systems for data Load
  • The initial Target Systems for data posting will be SAP RISE S/4HANA systems. However the database of Syniti may also be used as a source of data for other applications until S/4HANA has gone live (e.g. as a source for  Ariba master data ).
One syniti Connector Server per each region
  • Each region (RoW, EU, China) will have its own Connector server that will be used to connect Cloud Syniti SKP with Syensqo SAP systems.
Security
  • Syniti will have no direct access to Source SAP ECC Systems Database due to Data Protection policies. If direct access becomes necessary due to delivery requirements, it will be analyzed separately.


Application Architecture

Architectural Decisions

Syensqo has decide to implement the Synity Hybrid Deployment Model. The Syniti Knowledge Platform (SKP)-Hybrid consists of the cloud-native, multi-tenant application platform with customer-hosted working databases and a series of remote services. The remote services are the platform components that run outside of the Syniti Knowledge Platform application and are designed to run close to the data stores that persist and transact data management activities. Below diagram provided by Syniti company shows an example of Syniti Hybrid Deployment model:



Application Architecture Design

Based on Hybrid Deployment , following Architecture will be implemented for Syensqo:



Application Architecture Components

The  Syniti architecture  is designed to support scalable, secure, and efficient data migration and governance. Breakdown of components:

  • Syniti Knowledge Platform (SKP)
    • It is a cloud-based data management solution hosted on AWS Frankfurt for EU designed to help organizations transform their data into a strategic asset. SKP provides a secure, scalable, and strategic data management environment that supports various data-related activities such as data quality reporting, profiling, metadata scanning, and data migration.
    • It enables communication with systems in an organization's landscape through components called SKP connectors, which support metadata scanning, profiling, and data quality functionalities.
    • The platform uses a connector-based architecture to securely distribute execution outside of the SKP application environment, ensuring that customer master, transactional, and operational data are not persisted within the platform itself. Instead, only metadata and metrics are sent to SKP for storage and processing.
  • Server 1 - Syniti Connector
    • The Syniti Server Connector , is a secure, Linux-based software component that enables communication between Syensqo SAP systems and the Syniti Knowledge Platform (SKP) in the cloud.
    • Purpose:
      • Secure Data Transfer: It securely transmits metadata and data between your enterprise systems and Syniti’s cloud platform using encrypted channels
      • Metadata Scanning: Enables the SKP to scan and analyze metadata from systems like SAP, Oracle, and SQL Server.
      • Data Governance & Migration: Supports Syniti’s tools for data quality, governance, and migration by providing real-time access to source systems.
  • Server 2 - Replicate Server
    • The Syniti Replication Platform runs on a Windows Platform. The Replicate server is responsible for extract data from the source system and create source snapshots for the Migrate component to process.  It also connect to the Target system to extract data for post load data verification. 
  • Server 3 - SQL Server for Working and Constructor Database
    • This SQL Server instance acts as the central repository for all working data during migration or data quality projects. It serves as the primary staging and processing environment for data transformations, validations, and migrations. Its components include:
      • Working Database. The Syniti Migrate Platform will work with several different databases for processing. This database may store Source snapshots (Production copy of source data), Data Transformations (Business Conversion rules), Target Snapshots (Copy of Target for load validation).
      • Construction Database. The Syniti Migrate Platform will use SQL server for Data Construction (User input for bad data or missing data elements) and for Value Mapping Cross Reference Table Values.
    • Architecture considerations.
      • The Working Database can be built on HANA, Oracle, or SQL Server. However, if Oracle or HANA are used, the Construction Database must be hosted on a separate server, which may require an additional license (especially in the case of HANA).Therefore, the requirement from the Product Team was to use SQL Server for both the Working and Construction Databases. 
  • Server 4 - Tooling Server (Administrator Jump Server)
    • It is a secure intermediary VDI server used to access and manage systems that are otherwise isolated or protected within a private network. Securely connect to on-premise components like the Syniti Connector, Replicate, or Working Databases.
    • Only Syniti administrators users will have access to this server so they can perform admin activities like:
      • Connect to Syniti servers
      • System Administration and Operation Tasks
      • Troubleshooting and diagnostic
  • Syensqo VDI TPA (Third Party Access)
    • The Syniti Migrate Platform will require that Syniti developers can develop business rules in the working database. This group of people will require access and development tools that will be installed on the Virtual Desktop Infrastructure being used for Syniti staff.
    • This VDI will contain following software required for developers activities:
      • Microsoft Office Applications
      • SAP GUI
      • Internet access
      • SQL Server Management Studio
  • Source and target systems
    • The Syniti Migrate Platform will extract data from SAP Source Systems using RFC calls. Due to Syensqo security policies no access to Source HANA DB would be granted.
    • Syniti requires READ ONLY access to the PRODUCTION Source systems to get the most up to data for cleansing and conversion.

    • S/4HANA Rise system is the primary target system for Syniti data replication .
      • An important remark is that the Syniti instance will be integrated with multiple environments (Dev, QA , Prod) .
      • For data load in target system the recommended method is use Migration Cockpit tool connected to a Staging HANA schema in S/4HANA as described in following link . The Target system load method must be defined as part of the Data Migration strategy and is beyond the scope of this document . Different access methods will be granted depending on the selected approach. Potential alternatives include Migration Cockpit, BAPIs, Idocs, Custom objects etc...
  • AWS S3 Bucket
    • Created for Syniti administrators users, will be used to download the required software to be installed in Syniti Servers.

Network Architecture


Firewall Rules:

Firewall Rules Implemented can be found in following document: Syniti Architecture (DD-TEC-080) .





Application Security

Authentication

  • Syniti SKP.  Single Sign on integrated with Azure Entra ID (formerly Azure Active Directory) was configured as per following document.
  • Syniti servers: As part of the installation process of the Syniti servers Syensqo IT team created corresponding Admin users for every server at application level. The objective is to have a minimal number of Admin users ( approximately 5 users) who are fully autonomous in executing administration and operational activities across all Syniti servers.
  • Authentication for other Non Syniti applications is out of the scope of this document
  • User management for Syniti developers team is under review and out of the scope of this document.

Authorisation

Data elements inside the SAP Source applications are subject to export controls such as ITAR, EAR, or various UK or European Regulations. In order to integrate Syniti Platform on Syensqo Security Policies following approach is implemented:

  • No direct access to the SAP HANA Source Database, only to the SAP Application layer.
  • Syniti Replication Server will access to Source system data trough RFC Service user . This RFC Service user will have restricted ReadOnly authorization to specific SAP Tables and functions, see list of Service user authorization . (List of required and approved tables to be extracted from source system is out of the scope of this document, that will be decided during the design phase of Data stream.). See list of tables for which will be granted read access to Syniti RFC user.
  • NextLabs tool is used to enable field level encryption in S/4HANA. This will encrypt ITAR-relevant data elements and the encrypted values will be stored in HANA DB. Data will be unencrypted on the fly when it is access by an authorized user. Therefore, Syniti will not be able to extract ITAR data unless the RFC service user is explicitly authorized.
  • Enable at-rest TDE encryption in the SQL Syniti Working DB server for all generated databases.


Communication Security

All data in transit will be encrypted.

  • SSL is used for all web traffic . 
  • SNC is used for all RFC and SAPGUI communications. 
  • SSL is used for all Syniti Server Working DB traffic, ensuring that the database only accepts TLS-encrypted connection requests. 

Other Controls

Below there is a list of required applications and systems to be used by Syniti Team activities and the mechanism to access it:

Application/SystemUsersAccess Method

Syniti SKP

DevelopersWeb
Business usersWeb
AdministratorsWeb
Syniti Connector ServerAdministratorsSSH (from Syniti Jump server)
Syniti Tooling/Jump ServerAdministratorsWindows RDP (from Syniti Jump server)
Syniti Replicate ServerAdministratorsWindows RDP (from Syniti Jump server)
Syniti Working DBAdministratorsWindows RDP (from Syniti Jump server)
*DevelopersSyensqo TPA VDI (SQLServer Management Studio) 

SAP Syensqo Source Systems

DevelopersSAP GUI
Business usersSAP GUI
AdministratorsSAP GUI

SAP RISE Syensqo Target Systems

DevelopersSAP GUI and Web
Business usersWeb
AdministratorsSAP GUI and Web

Shared Folder

Developerstbc
Administratorstbc
AWS S3 BucketAdministratorsWeb


*Syniti Developers require to execute actions on SQL Databases available on Syniti Working DB, for that SQLServer Management Studio have been installed in TPA VDI Syniti Company so they can execute required actions.



System Landscape

Production Environment

Due to the nature of the use of the Syniti platform , it will have one single Production Instance for the whole Syensqo SAP Landscape. The table below describes the the corresponding servers deployed on AWS:


VM NameInstance NameInstance IdIPHostnameFQDNAZ
Connectorsco-ec2-ew1-syni-p-con-01i-06aae6a28c8f5ca47172.18.212.4ASEW1PSYNICON01ASEW1PSYNICON01.prd.aws.cloud.syensqo.comeu-west-1a
Replicatesco-ec2-ew1-syni-p-rep-01i-04bd1953eaea64b3f172.18.212.8ASEW1PSYNIREP01ASEW1PSYNIREP01.prd.aws.cloud.syensqo.comeu-west-1a
Tooling (Jump Server)sco-ec2-ew1-syni-p-rdp-01i-02c65796baaa4503b172.18.212.14ASEW1PSYNIRDP01ASEW1PSYNIRDP01.prd.aws.cloud.syensqo.comeu-west-1a
Working DBsco-ec2-ew1-syni-p-sql-01i-0fc0cbe6dfe839f25172.18.212.23ASEW1PSYNISQL01ASEW1PSYNISQL01.prd.aws.cloud.syensqo.comeu-west-1a


Servers deployment was done by Syensqo IT teams under JIRA AWSCLOUD-75 . Detailed information regarding servers infrastructure can be found in following link: Syniti Servers





Operation Architecture

Roles and Responsibilities

RACI for Mobilize phase:


SYNITI

Syensqo


Tasks

Cloud Ops

Delivery Partner

Platform Architect

Tech Lead

Project Coordinator

Network

Infra

ERP

Project Lead

Cloud Tenant

R



A






Network Connectivity

C


C

I


A, R

I



Onboard Syniti Team


C

C






A, R

Infrastructure



C

I


I

A, R

I

I

Data Access


C

C

C


C

I

A, R

C

Tech Setup


C

A

R


I

I

I

C

Project Setup


R

C

R





A


<Roles and responsibilities matrix for delivery phase is under review, will be added to the document once validated>

Backup/Restore

  • <Place holder>To confirm BackUp requirements from Syniti Development team for Working DB

Backup Policies implemented can be found in following link . As per Syensqo policies have been implemented Daily, Weekly and Monthly Backup in Syniti Servers.


Syniti recommend following Backup Policy in its own documentation:

  • Syniti Connector OS —Daily snapshot
  • Syniti Replicate OS —Daily snapshot
  • Syniti Working Databases—Daily OS snapshot
    • SRC / TGT Databases—Daily SIMPLE backup
    • WRK Databases—Daily FULL backup (if possible), otherwise SIMPLE
    • MIGRATE Database—Daily FULL backup
    • REPORT Database(s)—Daily SIMPLE backup
  • Syniti Construction Database(s)—Daily FULL backup
  • Syniti Replicate Metadata Database—Daily SIMPLE backup


Maintenance Plan

  • Syniti servers updates (OS patching) will be performed by Syensqo IT Team: For production environment Monthly on 3rd Sunday 00-03 UTC.
  • Syniti software updates will be performed monthly by Syniti team on demand.


Service Introduction

Application Category

Provide the details of application category based on application classification. Application category is defined based on RPO, RTO requirements

Support Team

Provide the details of support team that may be required to support the application

Skill required

Provide the details of skills that are required to support this application

Checklist

Provide the checklist for support organization to support the application


Exceptions

This section covers any exceptions to the reference architecture. Some Applications may have limitations and may not meet the Enterprise Architecture, Reference Architecture and IT Policy guidelines. All exceptions should be included in this section.


See also

Provide links or references to relevant documents for further context on this architecture decision and its impact. Listing related architectural decisions here can clarify dependencies.


Change log