Changes between Version 6 and Version 7 of LEGACY - LAMP proposal

Timestamp:

11/16/10 13:29:59 (14 years ago)

Author:

jeff.lusted

Comment:

--

LEGACY - LAMP proposal

@@ -25 +25 @@
 === 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 managed by RCS.
-  * A "Capacity Only" one is seen as being managed elsewhere. RCS supplies only the capacity.
+  * 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 managed by RCS? If not BRICCS must supply the management side of things. 
-  * The level of management 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 management side of a live system is complicated. See next point.
-  * Whoever manages the i2b2 data warehouse (University or UHLT), the live systems cannot be managed in isolation. The two systems must be synchronized in some way. A failure on one side will have ramifications for the other.
+  * 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 manage 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.
+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 ===