Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Change]: Review of architectural principles #280

Open
jawsgrant opened this issue Oct 5, 2023 · 0 comments
Open

[Change]: Review of architectural principles #280

jawsgrant opened this issue Oct 5, 2023 · 0 comments
Labels
proposed change A proposed change to the specification

Comments

@jawsgrant
Copy link

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

@jawsgrant jawsgrant added the proposed change A proposed change to the specification label Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposed change A proposed change to the specification
Projects
None yet
Development

No branches or pull requests

1 participant