Update recommendations.md

Moved paragraph 1 of context spedcific things.

docs/recommendations.md

@@ -71,7 +71,7 @@ Developing computing infrastructure depends on a number of considerations, many
 
   **Who has access:** This encompasses identity and access management, and includes how users are authenticated and authorised to access data. This can be managed by associating users with organisations, projects, and roles. Common defined roles include end users and those with elevated permissions to assist with administration and support.
 
-
+It should however be noted that many implementations are motivated by institutionally-specific factors outside of these five considerations. Not infrequently an organization will for instance have to decide if they will set up an entirely new infrastructure to handle their needs, or if a pre-existing infrastructure will be used. There might be strong incentives or even rules that dictate that pre-existing solutions should be used. However, how this infrastructure will scale and how future-proof that solution will be (regarding sample volume, finances, regulatory issues, etc) should be taken into account. In such a situation, it is advisable to evaluate and describe the appropriateness of this solution before committing to it, to avoid any potential sunk cost fallacy situations.
 ### How much does the infrastructure try and solve: Layers of concern
 
 There are a multitude of options for bioinformatic computing infrastructure deployment. The best solution will depend on the specific constraints imposed on a laboratory by their Central IT, Procurement, and other institutional entities. It is important to be aware of the range of solutions available (and unavailable) to make an informed decision. These solutions can be categorised by their degree of abstraction, i.e. the amount of infrastructure that is managed by the user or is deferred to others (Figure 1). Most solutions will belong to one of three major tiers, with SaaS representing the higher abstraction/deferred tier, and IaaS the lowest abstraction/deferred tier:
@@ -180,7 +180,7 @@ Using structured workflows and deliberately planned computational infrastructure
 
 ### Context specific considerations
 
-Many implementations are partially motivated by institutionally-specific considerations. The first consideration would be whether there is a pre-existing infrastructure a lab should or must utilise. If there are existing solutions that can be used, then continued and adapted use of that infrastructure is often incentivised. However, scalability and future-proofing consideartions (sample volume, finances, regulatory issues, etc) should be taken into account before committing to a solution based on pre-existing resources. If there are outside factors dictating the use of an existing infrastructure, it is advisable to evaluate and describe the appropriateness of the existing solutions to ensure that all parties are aware of the actual costs that would be involved.
+
 
 The second consideration would be the expected data generation throughput for the lab. The average number of specimens to be sequenced and analysed per month may determine how much resources are invested in the setup. An institution that will analyse hundreds of isolates per year most likely needs a different setup than the one that will analyse thousands of samples per month. A bigger operation will require more resources, more up front design and development of the process, and more standardisation of both processes and analyses. A smaller operation might however choose to either co-opt other existing solutions, or to outsource the process to someone with a larger setup, i.e. most likely go for a SaaS like solution.