Sizing a Multi-Environment Deployment Before the First Install
A financial services firm is standing up Blue Prism for the first time. The programme covers 40 attended users across three regions and 25 unattended digital workers that will run 24/7 with peak concurrency of 18 simultaneous sessions during overnight batch windows. The infrastructure team has proposed a single application server with 8 vCPU and 16 GB RAM, one database server with 4 vCPU and 16 GB RAM, and a shared file share for the runtime resources. The security team requires that the database never accept connections from the application tier over an unencrypted channel, and that the runtime resource machines be treated as a separate trust zone. The project manager wants a go-live in six weeks and has budget for only one additional server. The DBA has flagged that the proposed database server has no maintenance window and is on the same physical host as the application server.
1. Assess the proposed topology against the stated concurrency and security requirements. What must change before installation, and what is the minimum viable revision given a single additional server?
Read the worked answer
The proposal collapses three tiers onto two hosts and violates the trust-zone requirement.
Application tier. 18 concurrent unattended sessions plus 40 attended users is not a single 8 vCPU/16 GB node workload. Each running process consumes memory in the application server's session host, and attended users connect through the same service. The practical revision is to separate the interactive/attended role from the unattended runtime role, or at minimum add the second server as a dedicated application node so the two workloads do not contend. With only one extra server, prioritise separating the database from the application host first - co-location is the hard failure, not the CPU count.
Database tier. 4 vCPU/16 GB with no maintenance window is undersized and operationally unsafe. The database holds session state, queue items and audit data; index maintenance and backups need headroom. Move it to its own host and negotiate a maintenance window before go-live, not after.
Security. Enforce encrypted connections at the database listener and in the connection string, and place runtime resources in their own network segment with explicit firewall rules to the application tier only. The file share must not be a general-purpose share reachable from user desktops.
Sequencing. Re-plan the six-week date: procurement and firewall changes usually dominate, not the install itself.
2. The project manager asks whether the six-week go-live is realistic. What dependencies determine the answer, and how would you present the risk?
Read the worked answer
The install itself is days, not weeks. The critical path is everything around it:
- Server build and OS hardening - the additional host must be provisioned, patched and joined to the domain before any Blue Prism component is installed.
- Database provisioning - the DBA needs to create the instance, set recovery model, size the data and log files, and grant the service account rights. This is often a two-week queue item.
- Firewall and certificate changes - encrypted database connections and the runtime trust zone require change-board approval, which is the most common schedule slip.
- Service accounts and permissions - domain accounts for the application service and runtime resources, with the correct logon rights, must exist before configuration.
- Acceptance testing - a pilot process must run end to end under realistic concurrency before sign-off.
Present it as a dependency chart with owners and dates, not a single date. State plainly that the topology revision is mandatory for security sign-off, so compressing the schedule by skipping it converts a delay into a failed audit. Offer a phased go-live: attended users first on the corrected topology, unattended scale-out after the trust-zone rules are proven.