TotalAgility: The Clarity Series • 5 min read

The TotalAgility Architecture Blueprint: 5 Deployment Levels for Scalable Systems

How should you design a Tungsten TotalAgility deployment architecture? A scalable Tungsten TotalAgility (TTA)—formerly Kofax TotalAgility (KTA)—architecture evolves across five deployment levels based on user concurrency, page volume, and uptime requirements: starting with a combined All-in-One sandbox (Level 1), splitting Web and Application tiers (Level 2), isolating CPU-heavy Transformation and Reporting servers (Level 3), adding load-balanced Web and App nodes (Level 4), and deploying a multi-node High Availability (HA) cluster across data centers (Level 5).

A deployment topology that runs smoothly for a Friday afternoon proof of concept will quickly lock up once real operators, heavy PDF batches, and ERP integrations hit production. Here is how to find the right architectural level for your workload—and how to scale without flying blind. Need a hands-on review of your current server topology? Explore our Tungsten TotalAgility consulting and architecture services.

Level 1: The "All-in-One" Sandbox

• The Setup: Web, Application, Transformation Server (OCR), Core Worker, and SQL Database all sit on a single physical or virtual server.

  
  

• The Symptom It Fixes: You have minimal hardware budget and need a working environment stood up by Friday.

  
  

• The Advantage: Lowest infrastructure cost, zero cross-server firewall rules to configure, and the fastest setup time.

  
  

• Who It Fits: Developers, Proofs of Concept (POCs), training sandboxes, and very low-volume internal testing.

  
  

The Architect’s Warning: Do not let a successful POC accidentally become your production architecture. In an all-in-one setup, every component fights for the same CPU and RAM. The moment a large batch of multi-page PDFs arrives, Transformation OCR will spike CPU usage to 100%—instantly freezing the Workspace UI for your human operators.

Level 2: The "UI Defender" (Split Web & Application Tiers)

• The Setup: The Web Server is isolated on its own host (often inside a DMZ), while the Application Server stays behind the internal firewall to run Core Worker, Message Connector, Transformation, and export services.

  
  

• The Symptom It Fixes: "The UI Freeze." Operators complain that loading a single validation form takes 10 seconds whenever background imports or workflow jobs run.

  
  

• The Advantage: Protects the human user experience. Heavy background processing can max out the Application Server without slowing down operators clicking through the browser UI on the Web Server.

  
  

• Who It Fits: Small-to-midsize production deployments with dedicated validation teams and baseline network security rules.

  
  

Level 3: The "Heavy Lifter" (Dedicated Transformation & Reporting Nodes)

• The Setup: Web, Application, Transformation Server (TS), and Reporting Server each get their own isolated machines.

  
  

• The Symptom It Fixes: The Workspace UI feels snappy, but document classification, OCR, and data extraction queues keep backing up—causing downstream ERP export delays.

  
  

• The Advantage: Document transformation is a massive CPU and memory consumer. Isolating the Transformation Server (which Tungsten recommends as a core best practice) lets you allocate high-compute hardware strictly to OCR and AI extraction—and scale horizontally by adding a second or third Transformation Server node—without overpaying for Web-tier hardware.

  
  

• Who It Fits: High-volume processing centers handling complex, unstructured documents (such as environments processing 50,000+ pages per day, depending on document complexity and extraction depth).

  
  

Level 4: The "Traffic Master" (Load-Balanced Horizontal Scaling)

• The Setup: Multiple Web Server nodes and multiple Application Server nodes sitting behind an enterprise load balancer (such as F5 or Azure Application Gateway).

  
  

• The Symptom It Fixes: "The 8:00 AM Shift-Change Crash." When hundreds of global operators log in at the same time, a single IIS Web Server hits connection limits and drops user sessions.

  
  

• The Advantage: True horizontal scaling and daytime maintenance. You can drain a Web node from the load balancer pool, apply Windows security patches in the middle of the business day, and put it back into rotation without kicking operators offline.

  
  

• Who It Fits: Large enterprises and BPOs with hundreds of concurrent Workspace users and high API traffic.

  
  

Level 5: The "Fortress" (True High-Availability Architecture)

• The Setup: Fully redundant across every tier: dual DMZ Web Gateways routing to active-active Network Load Balanced (NLB) Web farms, multi-instance Transformation pools, clustered Application Server services using Windows Server Failover Clustering (WSFC), and clustered/replicated SQL Server nodes across data centers or availability zones.

  
  

• The Symptom It Fixes: "The Single Point of Failure." A hardware fault, hung Windows service, or network switch outage halts operations and costs the business tens of thousands of dollars per hour in missed SLAs.

  
  

• The Advantage: Eliminates single points of failure across Web, Application, Transformation, and Database layers with defined failover and disaster recovery (RTO/RPO) continuity.

  
  

• Who It Fits: Mission-critical 24/7 operations in Banking, Insurance, Healthcare, Defense, and Shared Services.

  
  

Architect’s Note on App Server Clustering: While TotalAgility Web servers run active-active behind a load balancer, TotalAgility Application Server Windows services (such as Core Worker and Streaming) use Windows Server Failover Clustering (WSFC) where one node is active per cluster group—or multiple WSFC groups are partitioned for scale. Always align your failover design with the exact clustering model of your TotalAgility version.

The Final Boss at Scale: "Distributed Blindness"

As your environment matures from Level 2 to Level 5, a new operational problem appears: Distributed Blindness.

On a single Level 1 server, troubleshooting is easy—you open Windows Task Manager, see CPU pinned at 95%, and know immediately what is wrong. In a 15-server Level 5 cluster with three Web nodes, two App clusters, four Transformation servers, and an HA database, you cannot RDP into 15 machines one by one when an SLA breaches.

The Architect’s Fix — Scale Your Visibility Alongside Your Servers: When you scale out your infrastructure, you must move from manual server checks to centralized platform intelligence:

• Automated Architecture & Config Auditing: Use TA Audit to automatically scan your entire cluster for thread-pool mismatches, database index fragmentation, security gaps, and configuration drift across nodes.

  
  

• Process-Level Bottleneck & SLA Prediction: Deploy TA Process Miner to see exactly which workflow activity, Transformation queue, or integration step is causing wait-time spikes—and predict SLA breaches before they happen.

  
  

• Cluster-Wide License Tracking: Pair your environment with TA License to monitor concurrent session spikes and page-volume burn across every process and department.

  
  

The Bottom Line: Scale the Layer That Is Actually the Bottleneck

Never over-engineer a day-one rollout into a 15-server fortress if your initial volume doesn't need it—but never trap your business in an all-in-one setup that cannot scale when document volumes double.

Start with evidence: if user screens lag, separate Web and App (Level 2). If extraction queues grow, isolate and scale Transformation Servers (Level 3). If peak logins or patching hurt uptime, add load balancing and HA clustering (Levels 4 & 5).

Planning a new deployment, scaling a slow cluster, or preparing for an upgrade? Speak with our Certified Master Developers via our Tungsten TotalAgility consulting services or explore our TotalAgility support and performance tuning services.

TotalAgility Architecture FAQ

Can Tungsten TotalAgility run on a single server in production?

While an all-in-one single-server TotalAgility installation is supported for development, demos, and proofs of concept, it is not recommended for production. Heavy OCR and Transformation jobs will consume CPU resources and freeze the Workspace UI for active users.

When should you separate the TotalAgility Transformation Server?

Tungsten recommends installing the Transformation Server on a dedicated machine whenever classification, OCR, and data extraction workloads are significant. Separating Transformation prevents CPU-intensive capture tasks from slowing down Web and Application servers, and allows you to add multiple Transformation Server nodes horizontally.

How does load balancing and clustering work in TotalAgility?

In a distributed TotalAgility architecture, multiple Web Servers run active-active behind a network load balancer (NLB) to distribute user and API traffic, while Application Server Windows services use Windows Server Failover Clustering (WSFC) alongside clustered SQL Server databases to eliminate single points of failure.

How do I know which TotalAgility server layer needs to be scaled?

Scale the specific layer causing the bottleneck: add Web Servers for high concurrent user logins, scale Transformation Servers when OCR/extraction queues back up, tune Application / Core Worker nodes when background workflow tasks lag, and use TA Process Miner to pinpoint exact activity wait times.

How can I audit an existing TotalAgility architecture before scaling or upgrading?

Run an automated environment assessment using TA Audit or engage Flexinta for a TotalAgility architecture health check to evaluate server sizing, Core Worker thread pools, database health, and high-availability readiness.