Planning your PhixFlow System

This section provides background information and guidance on the software and hardware environment required for supporting installations of PhixFlow.

The diagram above illustrates a typical process of gathering requirements, and drawing from this:

the choice of platform software (operating system, database)
network topology
server sizing.

One important aspect of assessing your requirements is to avoid over specifying the resources needed to run PhixFlow, as much as to ensure that sufficient resources are provided. In most virtualised environments, which the vast majority of PhixFlow installations will run in, altering CPU and memory are straightforward. We have provided guide sizing in this section, but it is possible to set resources at a starting level, and increase or decrease in response to the observed performance of the system. In this way, you can control costs in balance with meeting the needs of your solution.

Planning outcome	Description	Main input requirements
Platform software choice	On the whole, there is little difference operating PhixFlow on any combination of valid platform software - that is the combination of operating system and database. This is true for both performance, and general maintenance. This decision is generally driven by what in-house skills you already have in place, corporate software licensing (and therefore the cost of the deployment, and the support options in place), and corporate standards governing systems like PhixFlow.	Current infrastructure Corporate software licensing
Physical location/ cloud provider	In terms of management of PhixFlow from an administration point of view, and performance on back office tasks, the choice of physical deployment makes little difference. However, if you have a choice over where PhixFlow is deployed, the size, physical distribution and circumstances of your user base may be worth consideration. If your user base is large, globally distributed, and in some cases working with variable and unpredictable internet connections (e.g. you have a lot of home workers), working with a public cloud is more likely to allow you to support fast connections to the service, wherever it is situated in the world.	Physical location of users
Network topology	In most cases, the strongest influence on network topology is balancing access for PhixFlow users against security considerations. Does your PhixFlow solution need to be available on the public internet? Or can you confine it to a corporate network (including allowing remote access via VPN)? If you need to make PhixFlow available via the public internet, can you list the allowed source IP addresses? What is an acceptable level of risk: Does the solution handle sensitive data? Personally identifiable information (PII) Extra sensitive data about individuals as defined by applicable legislation Financial data Commercially sensitive data Common network topologies are discussed here: Network topology, but as long as you meet the Minimum system requirements, you can adopt any topology you wish.	Security considerations Physical location of users
Server specifications	It may be useful to specify some targets, or at an early stage, reasonable expectations, for performance of the system, in particular to human interaction - e.g. on the application that will be built in PhixFlow, how long should certain key actions take when a button is pressed? Target times for key processes and operations Tolerance to variance against these targets Server specifications are discussed here: Server Specification	Performance requirements Data volumes Processing volumes
Backups	Establishing your resilience to system and data loss, and specifying these with the Recovery Point Objective (RPO) and Recovery Time Objective (RTO), are useful at an early stage to help determine the backup strategy. Typically, at an early stage of the process, a high level description of the backup strategy is enough, and it is not necessary to determine the precise details of the process - this is usually done at the infrastructure planning stage (see Backup). However, in some cases, if it is known that a particular backup solution is required, this may have an impact on the storage and performance of the servers (Server Specification)	Recovery (RPO, RTO)