Your target architecture starts with real sources and responsibilities.
In a technical discussion, we review data sources, interfaces, architecture, security and the potential implementation approach.
Enterprise Travel Architecture
Plan and assess your travel data architecture.
Assess data provenance, field scope, delivery and operational responsibilities. The Architecture Center connects the four platform components with a planning example and specific questions for your architecture review.
Reference architecture
Four building blocks. Clear data contracts and responsibilities.
Each building block can be assessed separately from a functional, technical and operating perspective.
From sources to a usable data view
Connected sources
TMCs, GDSs, OBTs and available enterprise data
TD pool
Receive, map, check and consolidate
Travel Data Suite · data foundation
Shared journey records and enterprise context
Purpose-specific views from the shared data foundation
Applications & business processes
TD care · travel security, TD doc · communication, TD chart · analysis, TD go · approvals
For authorised teams and travellers in each process
TD hub
Prepare consolidated data for each recipient and distribute it through the available delivery method.
Connected Finance, BI, Security and other enterprise systems
Example: travel data for Finance
TD pool brings bookings from a TMC and cost centres from an enterprise system together in the shared travel data foundation within the Travel Data Suite. TD hub provides the data view required by Finance or BI.
- Data scope: which fields does the recipient need, such as booking reference, travel dates and cost centre?
- Updates: how often is data delivered, and how does the recipient identify its freshness?
- Changes: how are cancellations, corrections and late-arriving data handled?
- Operations: who resolves missing mappings or failed deliveries?
Planning example: field scope, updates, access and responsibilities are defined for each connection.
Assessment questions
A dependable target architecture answers more than a product list.
Which systems are sources of truth?
How are origin, freshness and conflicts made visible?
Which rules remain enterprise-owned?
How are portability and exit readiness retained?
Which personal data does each process require?
Which operating and escalation paths are defined?
FAQ
Frequently asked questions about the NP4 architecture.
Why would an organisation need another layer between its TMC and enterprise systems?
Because an international travel programme often consists of several data sources, providers and enterprise systems. An independent functional layer can prevent every downstream process from having to couple directly to the technical logic of an individual travel provider.
Does NP4 replace our TMC, OBT, expense system or BI platform?
No. NP4 connects existing systems and makes travel data usable for your business processes. Which systems can be connected depends on your landscape and technical access.
How are data sources connected?
The connection method depends on the technical capabilities of the respective source and the agreed project scope. Different interface or file-based methods may be used depending on the source. Public architecture information deliberately does not disclose customer-specific technical endpoints.
Does NP4 use a shared data model?
Yes. Data from different sources is mapped into shared functional structures so downstream processes can work with consistent meanings. The complete internal data model is not public; the parts relevant to your implementation are discussed within the project.
What happens when a provider changes?
Source connectivity and functional data views are separated wherever possible. This allows a new source to be integrated without automatically adapting every downstream process to the technical structure of the new provider.
How is inconsistent or conflicting data handled?
Functional quality and processing rules are defined for connected sources. Which source is authoritative for a particular data point and which checks apply depends on the relevant data flow and use case.
How does data reach Finance, BI, Security or other downstream systems?
TD hub prepares travel data for each recipient and supplies it through an agreed delivery method. The data scope, format and access rights follow the target system and intended purpose.
Where can we find information about security, privacy and due diligence?
Public architecture information deliberately remains at an appropriate functional level. Information about privacy, information security and available due-diligence material is provided in the Trust area. Customer-specific operational details are not published publicly.