[Discussion]: Is the specification for platforms or deployments? #74
Comments
|
I've always been thinking along the lines of 'platform/codebase'. A lot of that is probably because, compared to 'deployments', it covers most of what my work involves. I think there may be advantages to taking that approach to. It is more aligned with the ideas from the Newcastle commitment (where we talk about source code, community). It might also help distinguish the specification from existing accreditations which apply to a particular instance (including its tech, people, procedures). |
|
I definitely prefer the "deployment" side as if you just worry about the code, you're leaving out a lot of the hard-but-important things like: legal requirements, data handling, processes. We might not have perfect answers about "your information governance must look like this" but we should be acknowledging that these are important (and that we have opinions about them). In terms of what the specification looks like I think we want something less intimidating than ISO27001 but more prescriptive than eg. DSPT or 5 Safes. Something that a TRE operator can go through and answer "here's how we meet this (or why we don't)" for each point and come out with a score against the specification (eg. the traffic light style diagram). |
|
I think it should be both: "SATRE: A Standard Architecture for Trusted Research Environment software platforms and deployed instances" The deployments part includes things like governance processes, but not so much the institution-specific processes (but perhaps even references some of these as case study paragraphs) Information governance: Seems like a deployment specific thing, however it can still be part of the SATRE architecture that describes at a high level a TRE software platform if you're saying things like "You should have an information governance procedure" as oppose to "This is how to do information governance" |
|
My feeling is that the survey has been useful in many ways, but also has distracted us on some details which are implementation specific. E.g. pasting text vs tiering Those are capabilities which can be implemented on a local-level, but don't change whether something is a TRE or not. |
|
I like @edwardchalstrey1 think the specification has to cover both - but as it is an architecture the question becomes where does it get to (levels, types of thing being covered etc). So for example the architecture can lay out all the key components of a TRE ( eg workflow governance to control construction of any deployment (projects, users, collaborators etc), role architecture for managing the transfer of data from source to experimenter, identity management and access control, charge events and billing, audit and compliance reporting from metadata collected, etc) and how they (should / must) connect and work together. It could/should also specify the actual detail of the roles, the detail of identity mgmt, the detail of the approval interface, the detail of the charge events, the detail of the compliance reporting, the detail of the deployment components. @drchriscole I also think the definition of what a TRE is being informed by this. You will have seen my inputs on this which may be slightly different :-) not sure. The TRE term seems to have many intersecting and overlapping meanings - generally having the same purpose - but I think the architecture can be more authoritative in what is meant. If federation is going to be a thing (I have made my thoughts on this (at the project level) elsewhere #51 ) then interoperability becomes a thing that will probably force more detail into the specification. |
|
Hi @crickpetebarnsley |
|
Hi Simon,
Thanks, I would love to help more. I hope the wider points make a cohesive picture that helps shape the overall TRE specification.
This was whether it was a instance or an platform.
If a platform, will the spec cover approval orchestration and workflow, identity management and audit and compliance reporting too?
Cheers,
pete
From: Simon Li ***@***.***>
Sent: 27 June 2023 15:52
To: sa-tre/satre-specification ***@***.***>
Cc: Pete Barnsley ***@***.***>; Mention ***@***.***>
Subject: Re: [sa-tre/satre-specification] [Discussion]: Is the specification for platforms or deployments? (Issue #74)
External Sender: Use caution.
Hi @crickpetebarnsley<https://github.com/crickpetebarnsley>
After a bit of reworking we've come up with the idea of "capabilities" which should eventually encompass all areas that the architecture needs to cover. It also gives us a hierarchical structure so that we can drill down into the details where necessary.
The latest version of the spec is in https://satre-specification.readthedocs.io/en/latest/ and we've already got more PRs open to refine the overall structure. Based on that I'll close this issue. Thanks for your input here and on the other issues, especially whilst we figure out how to bootstrap the specification/architecture!
-
Reply to this email directly, view it on GitHub<#74 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANNFL6NGYCPLNYEPFPHYQYTXNLXP7ANCNFSM6AAAAAAYT22HD4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
The Francis Crick Institute Limited is a registered charity in England and Wales no. 1140062 and a company registered in England and Wales no. 06885462, with its registered office at 1 Midland Road London NW1 1AT
|
|
It should cover most of those, for example see |
Summary
Is this a specification for platforms (i.e. codebases) or deployments (actual instances)?
Source
#71 (comment)
Detail
Is the SATRE specification going to cover:
This is important because some of our discussions have been about the platform/code base, e.g.
Some have been about the deployed instance, e.g.
Since this directly affects the content of the specification I think we need to agree as soon as possible.
Intended Output
Decide the scope of the specification
Who can help
Everyone!
The text was updated successfully, but these errors were encountered: