An Architect's vision

No, Robotic automation extends and complements BPMS and SOA initiatives which are attacking the automation challenge from a different, top down, IT driven angle. Robotic automation is aimed at small-to-mid size automation initiatives. Where speed and size and agility are major factors, then robotic automation is often the fastest and most efficient approach. When larger initiatives are required with a fuller “Business Process” character then BPMS may be better suited. This difference in scale is illustrated with the so called Long Tail of Automation Requirements. This says that core IT deals with the high volume bulk processing requirements an organisation may have. Typically, these are core ERP systems, mainframe accounting and core data bases. As we move towards the middle of the graph requirements become more specialist and diverse. This is where an organisation often differentiates its product and service offerings. Typical technologies here are workflow, desktop integration, BPM

BPMS is principally aimed at improving IT architecture to allow greater flexibility in automation and process management capability. Most often its aim is to support agent productivity through desktop acceleration, application connectivity, workflow management. As such BPMS is part of the core IT tool set, to which adjustments outside of configurable parameters to a solution normally require a traditional IT change-program. Most often connectivity between applications, and design work on how applications should be integrated against business requirements is a key skill that is required to operate BPMS effectively. Robotic Automation is principally aimed at clerical staff replacement as opposed to clerical staff acceleration as with BMPS. The philosophy of the approach is therefore to target routine, repetitive, rules-based tasks (procedures as sub-tasks within a larger business processes). Such tasks can often tie clerical staff down for long stretches of time. Very often such task

If you have established a second AWS Direct Connect connection, traffic will failover to the second link automatically.  We recommend enabling Bidirectional Forwarding Detection (BFD) when configuring your connections to ensure fast detection and failover. If you have configured a back-up IPsec VPN connection instead, all VPC traffic will failover to the VPN connection automatically. Traffic to/from public resources such as Amazon S3 will be routed over the Internet. If you do not have a backup AWS Direct Connect link or a IPsec VPN link, then Amazon VPC traffic will be dropped in the event of a failure. Traffic to/from public resources will be routed over the Internet. 

Multiple VPN channels are required to communicate to multiple VPCs even within single region in AWS whereas a single AWS Direct connect can be connected to multiple VPCs within a single region. Multiple VPN channels are required for multiple AWS accounts in a single region whereas a single AWS Direct connect can be connected to multiple AWS accounts within a single region. You can get lower network latency in AWS Direct connect that in VPN.  AWS direct connect is a dedicated line provisioning which handles the subnet traffic from your on prem site and then in to your VPC. VPN would be a good backup solution in case your ISP had an outage.