Skip to content

Architecture

The Talisman Platform is an enterprise integration platform deployed directly within customer premises and private cloud environments. Designed for complete operational sovereignty and infrastructure flexibility, the platform operates on customer-managed infrastructure across Kubernetes and Docker runtimes.

Talisman enforces a strict architectural boundary between the Control Plane (authoring, project governance, build orchestration, and deployment coordination) and the Execution Plane (lightweight, immutable integration microservices). This guarantees that runtime workloads execute independently of management tooling, while source code, configuration secrets, and container images remain strictly within the customer's private network perimeter.

The platform follows one principle: build in development and promote immutable images. Each integration is built once into a container image and promoted, unchanged, to Test and Production; only the environment configuration differs. The Development & Deployment Principles describe the three developer workflows built on this architecture.

System Architecture

The following diagram illustrates the core components of the Talisman Platform, spanning developer interfaces, control plane services, shared infrastructure repositories, and runtime execution environments:

flowchart TB
    subgraph Clients ["Developer Tooling Layer"]
        WebUI["Studio Web (Browser)"]
        VSCode["Studio for VS Code"]
    end

    subgraph ControlPlane ["Talisman Server (Control Plane)"]
        WebApp["Control Plane"]
        BuildEngine["Server Build (Dev Only)"]
        MetadataDB[("Platform Database\n(PostgreSQL)")]
        WebApp <--> MetadataDB
        WebApp -->|Trigger Build| BuildEngine
    end

    subgraph SharedInfra ["Enterprise Repositories & Registries"]
        GitRepo[("Git Repository\n(Projects & Manifests)")]
        ImageRegistry[("Container Image Registry\n(Immutable Images)")]
        MavenRepo[("Artifact Repository\n(Maven / Dependencies)")]
    end

    subgraph RuntimePlane ["Execution Plane (Docker | Kubernetes)"]
        direction TB
        subgraph Microservices ["Integration Microservices (Apache Camel)"]
            Service1["Integration Microservice A"]
            Service2["Integration Microservice B"]
            ServiceN["Integration Microservice N"]
        end
    end

    subgraph EnterpriseSystems ["Enterprise Target Systems"]
        DB[(Corporate Databases)]
        SysA["Enterprise Applications / ERP"]
        SysB["Message Brokers / Cloud APIs"]
    end

    %% Developer interactions
    WebUI -->|HTTP / WebSocket| WebApp
    VSCode -->|Push / Pull Code| GitRepo

    %% Control Plane interactions
    WebApp <-->|Sync Code & Manifests| GitRepo
    BuildEngine -->|Pull Source & Specs| GitRepo
    BuildEngine -->|Resolve Dependencies| MavenRepo
    BuildEngine -->|Publish Image| ImageRegistry
    WebApp -->|Deploy Workloads| Microservices

    %% Runtime Plane interactions
    ImageRegistry -.->|Pull Image| Microservices
    Microservices <--> DB
    Microservices <--> SysA
    Microservices <--> SysB

Architecture Layers

Developer Tooling

Developers design integrations in Talisman Studio: Studio Web in the browser, served by the dev Talisman Server, or Studio for VS Code on their own machine. Components describes both.

Control Plane

The Talisman Server manages the integration lifecycle, environment orchestration, and administrative functions:

  • Talisman Server: Deploys, operates and observes the integrations of its environment. On the dev Server it also serves Studio Web. It manages project lifecycles, coordinates with Git repositories, and communicates with the underlying runtime APIs (Kubernetes API or Docker daemon).
  • Platform Database (PostgreSQL): Stores platform metadata, user sessions, workspace configurations, and project indexing caches.
  • Server Build (Dev Server only): A containerized build that transforms integration project definitions and dependencies into standalone container images and, for Kubernetes, baseline deployment manifests. Higher environments (Test, Prod) run no build. With VS Code with CI/CD, your pipeline builds instead.

Infrastructure Services

Talisman connects natively to customer-managed or cloud-hosted infrastructure services:

  • Git Repository: The single source of truth for integration project code, Apache Camel route definitions, deployment manifests, configuration patches, and Docker configurations.
  • Container Image Registry: Stores immutable, OCI-compliant container images produced during the development build phase.
  • Artifact Repository (Maven): Resolves Apache Camel components, enterprise connectors, shared corporate libraries, and project dependencies during container packaging.

Execution Plane

Integrations execute as isolated, containerized microservices powered by the Apache Camel Runtime: pure Apache Camel on Apache Camel Main:

  • Standalone Footprint: No application servers or framework wrappers are required; integrations run on Apache Camel Main as lightweight, fast-booting containers.
  • Decoupled Architecture: Each integration microservice is packaged into its own isolated container, ensuring independent scaling, isolated memory heaps, and zero runtime blast-radius between different integration services.
  • Universal Connectivity: Integrations leverage standard Apache Camel components to orchestrate exchanges with corporate databases, messaging queues, event streams, ERPs, and internal or external REST/SOAP APIs.

Environment Topology

In enterprise production deployments, Talisman is deployed across dedicated environments: Development (Dev), Test, and Production (Prod).

To maintain strict network boundaries and audit controls, build tools are confined to the Development phase, while higher environments operate strictly as deployment runtimes. The diagram shows the Studio Web on Server and VS Code with Server Build options; with VS Code with CI/CD, your pipeline takes the build and promotion role of the Dev Server:

flowchart LR
    subgraph DevEnv ["Development Environment"]
        DevServer["Talisman Server (Dev)\n- Studio Web\n- Server Build\n- Promotion\n- Control Plane"]
        DevRuntime["Dev Runtime\n(Docker / K8s)"]
        DevServer -->|Deploy| DevRuntime
    end

    subgraph CentralInfra ["Enterprise Infrastructure"]
        Git[("Git Repository\n(Code & Resources)")]
        Registry[("Container Registry\n(Immutable Images)")]
    end

    subgraph TestEnv ["Test Environment"]
        TestServer["Talisman Server (Test)\n- Control Plane"]
        TestRuntime["Test Runtime\n(Docker / K8s)"]
        TestServer -->|Deploy| TestRuntime
    end

    subgraph ProdEnv ["Production Environment"]
        ProdServer["Talisman Server (Prod)\n- Control Plane"]
        ProdRuntime["Prod Runtime\n(Docker / K8s)"]
        ProdServer -->|Deploy| ProdRuntime
    end

    %% Flows
    DevServer -->|Commit Code & Resources| Git
    DevServer -->|Publish Immutable Image| Registry

    Git -.->|Fetch Resources| TestServer
    Git -.->|Fetch Resources| ProdServer

    Registry -.->|Pull Image| TestRuntime
    Registry -.->|Pull Image| ProdRuntime
  • Dev Environment: Hosts authoring tools and the build subsystem. Integrations are designed, container images are built and pushed to the registry, and baseline deployment definitions are generated and committed to Git. Promotion also runs here: the deployment definition verified on Dev is paired with the Test or Prod configuration and committed to Git.
  • Test Environment: Pulls promoted deployment resources from Git and executes the immutable container image against the Test runtime. No compilation or image building occurs here.
  • Production Environment: Pulls promoted deployment resources from Git and runs the verified image pulled directly from the registry. Production environments remain completely isolated from development toolchains.

Runtime Model

Talisman provides first-class support for both Kubernetes and Docker execution platforms, ensuring compatibility across lightweight single-node deployments and large-scale, multi-cluster architectures.

Dimension Kubernetes Docker
Execution Unit Pods / Deployments Standalone Containers
Configuration Model Baseline manifest + environment configuration patch Environment-specific Docker configuration
Promotion Mechanism Same baseline manifest, paired with the target environment's patch Same image, with the target environment's Docker configuration
Orchestration API Kubernetes API (kube-apiserver) Docker Engine API / Socket
Scaling & HA Horizontal Pod Autoscaler (HPA), replicas Restart policies, external load balancers
Target Footprint Enterprise clusters (OpenShift, EKS, AKS) Edge nodes, isolated VMs, Docker hosts

Development Workflows

The same architecture supports three developer workflows. They differ in where integrations are designed and where the build and promotion run:

  • Studio Web on Server: Developers design in Studio Web on the Dev Server, on the main branch. The Dev Server builds, publishes the image, and promotes; each Server deploys to its own environment from Git.
  • VS Code with Server Build: Developers design in Studio for VS Code on Git branches. After a merge to main, the Dev Server synchronizes, builds, and promotes as above.
  • VS Code with CI/CD: Developers design in Studio for VS Code on Git branches; no Server Build runs. Talisman's pipeline templates for GitHub Actions and Azure Pipelines build and deploy to Dev on Kubernetes; Docker targets and promotion to Test and Prod belong to your own pipelines and GitOps tooling.

Security & Sovereignty

  • Private Perimeter Security: The platform operates with zero required outbound connectivity to public clouds. All dependencies can be serviced by internal Git servers, internal Maven proxies, and local image registries.
  • Immutable Artifact Verification: Building once in Development ensures that byte-for-byte identical images are deployed to Test and Production. Higher environments are strictly read-only execution zones where compilers, build daemons, and package managers are never executed.
  • Decoupled Secret Management: Environment configurations (passwords, connection strings, credentials) are injected exclusively at runtime via Kubernetes configuration patches (paired with Secrets or ConfigMaps) or Docker environment configurations. Sensitive infrastructure data is never stored in source code or baked into container images.
  • Role-Based Access Control: In the VS Code with CI/CD option, direct deployment rights to production infrastructure are restricted to automated pipeline service accounts, eliminating developer access requirements on production clusters.