You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be useful to reference TOGAF as the rational behind adopting this approach? Should the roles in this page include links
Architectural principles influence and shape the way you design and deliver a SATRE-aligned TRE. They are a set of guiding considerations that sit above any specific architectural, should/could this be 'functional'? requirement, and can be applied across the entire architecture.
Usability
Implications
perhaps seems to largely focus on the research users and workspaces. Is there a need for implications that relate to operators etc. beyond what is in the second Implication 'Other users include ...' e.g. Clear runbooks and guides combined with automating deployment improves repeatability for TRE Builders and Operators
Maintaining Public Trust
Personally I would have this first. IMO It is most important
Rationale
Should there be something specific in this section around How to maintain trust and why? e.g. secure solutions, transparent auditing? If public don't trust they can withdraw consent, request their data removed damaging potential impact of research
Implications
Are these within remit or 'implications'? Access to public sector data should be reviewed by an independent panel and follow agreed-upon governance to ensure projects using this data are in the public benefit, and provide clarity around any commercial access. A strong public engagement programme takes time and resource. TREs holding public data should consider allocating specific staffing to public engagement activities.
Observability
Statement
Does this extend to the research itself, may just be confused and misunderstanding, but perhaps needs more specific wording. Are we saying 'All Processes, deployments and operational changes to a TRE should be logged and auditable?'' This seems to be the meaning attributed through the rationale and implications.
Human initiated and automated processes resulting in change within the TRE should be observable.
Should there be a dedicated Specification Pillars, Capabilities and Components page
Summary
Suggestions on architectural principles
Source
Personal contribution
Detail
Architectural Principles
Would it be useful to reference TOGAF as the rational behind adopting this approach?
Should the roles in this page include links
Architectural principles influence and shape the way you design and deliver a SATRE-aligned TRE. They are a set of guiding considerations that sit above any specific architectural, should/could this be 'functional'? requirement, and can be applied across the entire architecture.
Usability
Implications
perhaps seems to largely focus on the research users and workspaces. Is there a need for implications that relate to operators etc. beyond what is in the second Implication 'Other users include ...' e.g. Clear runbooks and guides combined with automating deployment improves repeatability for TRE Builders and Operators
Maintaining Public Trust
Personally I would have this first. IMO It is most important
Rationale
Should there be something specific in this section around How to maintain trust and why? e.g. secure solutions, transparent auditing? If public don't trust they can withdraw consent, request their data removed damaging potential impact of research
Implications
Are these within remit or 'implications'?
Access to public sector data should be reviewed by an independent panel and follow agreed-upon governance to ensure projects using this data are in the public benefit, and provide clarity around any commercial access.
A strong public engagement programme takes time and resource. TREs holding public data should consider allocating specific staffing to public engagement activities.
Observability
Statement
Does this extend to the research itself, may just be confused and misunderstanding, but perhaps needs more specific wording. Are we saying 'All Processes, deployments and operational changes to a TRE should be logged and auditable?'' This seems to be the meaning attributed through the rationale and implications.
Human initiated and automated processes resulting in change within the TRE should be observable.
Should there be a dedicated Specification Pillars, Capabilities and Components page
Where
https://satre-specification.readthedocs.io/en/latest/principles.html
Proposal
No response
Who can help
No response
The text was updated successfully, but these errors were encountered: