== LAMP Proposal ==

A draft spec for the BRICCS services is attached at the end...[[BR]]
Discussion points, not in any particular order:

=== Live Production Systems ===
Following details are required:
  * Number of users
  * Hours of use during the day
  * Peak or sensitive periods
  * Level of activity (transactions per day)
  * Quality of service
    1. Speed of response for a user
    1. Speed of restore after failure
    1. Can we afford to lose transactions?
    1. Turn around time for a support request. _Advice please on this one_.
  * Type of data stored and usage. I'm not sure how to characterize this. What about:
    1. Transactional
    1. Research

These are my guesses so far for...

==== Labels Webapp: ====
  * Number of users: 1 at any one time
  * Hours of use during the day: 8:00 to 17:00
  * Peak or sensitive periods: None.
  * Level of activity. Fifty transactions per week if recruiting 50 participants per week,
  * Quality of service:
    1. Speed of response: within 10 seconds.
    1. Speed of restore after a failure: ?
    1. We cannot afford to lose transactions, which would give rise to the possibility of duplicate id's.
  * Type of data: Transactional.

==== caTissue: ====
  * Number of users: 10 at any one time. (At the moment there are only three)
  * Hours of use during the day: 8:00 to 17:00
  * Peak or sensitive periods: None.
  * Level of activity. 300 transactions per week?
  * Quality of service:
    1. Speed of response: within 5 seconds.
    1. Speed of restore after a failure: ?
    1. We cannot afford to lose transactions, which would give rise to losing the locality of samples.
  * Type of data: Transactional

==== i2b2: ====
  * Number of users: ?
  * Hours of use during the day: 8:00 to 17:00 by clients. However, it is possible updating/inserts into the system might become an overnight batch task.
  * Peak or sensitive periods: None, but reference the above.
  * Level of activity: ? 
  * Quality of service:
    1. Speed of response: ?
    1. Speed of restore after a failure: ?
    1. Some client side activity is transactional: System admin at least. What about batched updates/inserts?
  * Type of data: largely Research.

=== VM's and Applications ===
To keep applications separate, it would be a good idea to have one application per VM.

Is this a good idea? Can anyone see variations on this? For example:
  * Does it apply to test systems?
  * Does it apply to dev systems (eg: TRAC, svn)?

=== Managed versus Capacity only Systems ===
This is my (Jeff's) understanding of this. "Managed" is seen from an RCS point of view. That is: 
  * A "Managed" system would be one administered by RCS.
  * A "Capacity Only" one is seen as being administered elsewhere. RCS supplies only the capacity.

I'm not sure exactly what this would mean in practice. Perhaps it's just a rule of thumb. But there are important considerations behind this...

  * Will the live production systems (eg: Labels Webapp, caTissue, i2b2) be administered by RCS? If not BRICCS must supply the admin side of things. 
  * The level of admin might need to vary. Take test systems. This could be Unit testing, Integration testing, or Acceptance testing. I can see this range of testing being required where the admin side of a live system is complicated. See next point.
  * Whoever manages the i2b2 data warehouse (University or UHLT), the live systems cannot be administered in isolation. The two systems must be synchronized in some way. A failure on one side will have ramifications for the other.
  * The i2b2 side can support numbers of projects and within a project, numbers of ontologies. What constitutes a project is open to debate, but a good first idea is to take a source/stream of data (eg: the Onyx questionnaire) as a project. Now each project has its own set of SQL tables, and each ontology within a single project can have one or more ontology SQL tables. So one could expect over time that a live system would change the number of SQL tables within its remit, which would suppose some DBA activity. Who would own that activity?

I cannot see a simple way through this wood at the moment. If I were asked to administer a system, I would like to have some say before I took it over, even if it were only to vet and test the procedures.

=== Acquisition of VMs ===
It seems unlikely there will be creation and access to new VM's on demand. So there would need to be some forward planning of what is required for a given future period.