Open machintim opened 1 year ago
manics
commented
1 year ago Thanks @machintim, this is very helpful! Would you like me to copy some of the terms into the WIP glossary we've started in https://github.com/sa-tre/satre-specification/pull/160 Or would you prefer to keep all the discussion here for now?
machintim
commented
1 year ago We also have the glossary here: https://docs.google.com/document/d/1SJ6CJG8yHzsvtU7MyzdNOF_S0fZVJb_i/edit
Do you think this glossary should actually sit in the SATRE spec? Probably makes sense, I guess we should decide it across the community and draw all the terms together. I don't mind but as with everything else keeping the content consistent is the challenge
manics
commented
1 year ago Similar points were made in https://github.com/sa-tre/satre-specification/pull/160 One of the points made was that the spec should be self-consistent which I agree with, especially from a usability perspective. The ideas of pillars and capabilities are foundational to this spec, and it's not very accessible if the first requirement before reading the spec is to go to a different specification/glossary to read up on several terms.
The other major issue is we've already got an internal definition of these terms- it's just that we haven't written them down. If the external glossary were to define capabilities differently I presume we'd need to reword this spec to either fit in, or to define our own alternative term.
harisood
commented
1 year ago The other major issue is we've already got an internal definition of these terms- it's just that we haven't written them down. If the external glossary were to define capabilities differently I presume we'd need to reword this spec to either fit in, or to define our own alternative term.
This feels important - I think all terms should be consistent across the DARE projects, and the external glossary be a formal, easy to use report that we have stored somewhere
Summary
Additions to "What is SATRE?" Section and clarification of meta-model
Source
Personal contribution (WP3) formalisation
Detail
A few points on current content:
Here is some content for structure section: The high-level architecture will be universally applicable to all TRE implementations and consist of three parts, principles, capabilities and capability decompositions.
Architecture principles provide fundamental guidelines that inform the design, decision making and implementation for a TRE. These principles provide a framework to ensure that the design of the underlying components of a TRE are aligned to consistent goals, values and best practices. The SATRE principles reflect a level of consensus across the TRE community (all stakeholders) and embody the spirit and thinking on what a TRE is and how it should operate. These principles should be applied across the capabilities and components. In some cases, a principle may be difficult or even impossible to meet fully. In such cases a deviation may be accepted in consultation with impacted stakeholders.
Capabilities are an ability that an organisation possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. The reference map provides a structure for organizing and understanding the capabilities required to deliver a TRE. It helps identify, define, and categorize the key elements needed to create and operate a TRE. The maturity of each capability can then be measured using a capability maturity model. The application of a consistent maturity model allows benchmarking of TREs and TRE operating organisations to create roadmaps for improvement.
Capability decomposition will map out the components that realise the capability. These components will vary depending on the nature of the capability. Business focused capabilities will be realised by business processes, roles and services with more technology focused capabilities realised by applications, application services and interfaces. In addition to the components realising the capability a catalogue of standards, frameworks and controls linked to the capabilities will provide guidance on how to implement the capabilities safely.
Decomposition Elements
The decompositions show how the capability is realised by showing roles, processes, applications and data an organisation may need to deliver the capability.
Requirement
A set of needs that must be met by the architecture.
Example: The SATRE architecture has a set of information governance requirements relating to things like leadership and how the TRE must be supported.
Actor
A person, organization, or system that has one or more roles that initiates or interacts with activities.
Example: The SATRE architecture needs actors such as researchers and internal auditors.
Business Process
A set of actions which produce a specific desired outcome.
Example: To access the TRE a researcher needs to complete an onboarding business process.
Application Component
An encapsulation of application functionality which is modular and replaceable.
Example: To perform work within a TRE a researcher might need access to a Desktop or command line interface application component.
Data Object
A store of data or information.
Example: To know what data is stored within the TRE a study database data object is needed. This contains information on the data assets within the TRE, who owns them and other compliance information.
Decomposition Diagrams Below you can see a view of how the decomposition elements relate to each other. Components combine to realize a capability which in turn realizes a set of requirements.
Design Pattern Library and Implementations
Built on top of this standard architecture will be a variety of implementations. These will have varied process flows, application sets, code and underlying platforms and technology. For example, TREs built in Azure and AWS would conform to the same standard architecture with divergent code and technology components. To make the reference architecture as useful as possible for implementers a design pattern library should provide a set of configurable resources implementers can customise to implement a TRE in line with the SATRE standard. These designs will provide recognised solutions which conform to the reference architectures. They can be provided as design documents or shared as code. Implementers can then utilise these design patterns in their organisation’s TRE implementation. Implementations can be documented using the reference architecture and referencing elements from the design pattern library if they are implemented in part or in full. This will provide a detailed description of the implementation in a common language.
Where
What is SATRE section under structure
Proposal
I think I may have put this in the wrong section (see above)
Who can help
@jemrobinson @manics @edwardchalstrey1 @craddm Hopefully this makes sense. I intended to get more done today but several things came up. Be great to get comments and help merging it in.