CaRCC Capabilities Model Capabilities by Facing

Researcher-Facing Topics and Associated Capabilities

Research Computing Data Awareness and Support

• Are researchers made aware of RCD use cases and how to access relevant RCD services and resources available to them via the institution?
  

  Examples of this could include:

  • Researchers are provided with communications and/or other outreach about resources made specifically available to constituents via the institution (e.g., support, training, computing, data storage, library and data services, related centers or institutes), whether operated or procured by the institution, or via collaboration/resource-sharing by a partner institution.

  A minimal Service Operating Level for this might include basic documentation, e.g., on a website or service catalog.

  A basic Service Operating Level for this might further include an RCD staff role (or roles) that include responsibility to create awareness of RCD resources and services available on campus, as well as training and advice on tools and techniques.

  A strong Service Operating Level for this might further include efforts to target materials to under-represented researcher communities (e.g., non-traditional users of computing and data tools beyond the typical physical sciences and engineering disciplines), and a practice of ensuring that documentation, training materials, etc. follow accessibility standards (e.g., WCAG).

• Are researchers made aware of RCD use cases and how to access relevant RCD services and resources available externally?
  

  Examples of this could include:

  • Researchers are provided with documentation, communications, and/or other outreach about available cross-institution, regional, national, and/or commercial resources not available specifically via the institution.

  A minimal Service Operating Level for this might include basic documentation, e.g., on a website or service catalog.

  A basic Service Operating Level for this might further include an RCD staff role (or roles) that include responsibility to create awareness of RCD resources and services available externally, as well as training and advice on tools and techniques.

  A strong Service Operating Level for this might further include efforts to target materials to under-represented researcher communities (e.g., non-traditional users of computing and data tools beyond the typical physical sciences and engineering disciplines), and a practice of ensuring that documentation, training materials, etc. follow accessibility standards (e.g., WCAG).

• Is there an institutional practice of proactive outreach to new or prospective faculty and research groups to raise awareness of RCD services and external resources?
  

  Examples of this could include:

  • RCD staff contribute to discussions with prospective faculty or graduate students
  • RCD staff have the skills and capacity to contribute to new graduate student orientations for computationally and data-intensive domains.
  • RCD staff have the skills and capacity to conduct outreach to instructors who are teaching computationally and/or data-intensive methods.
• Are researchers made aware of researcher-facing services and staff available via the institution?
  

  For example, are researcher-facing services promoted as part of and beyond other RCD outreach and web-based resource listings, perhaps in materials distributed to prospective or new faculty and other researchers, or via other IT and campus communications, etc.

Research Computing and Data Implementation Support

• Are researchers provided with individualized consultation for selecting and gaining access to the most appropriate RCD resources available via the institution or externally?
  

  Examples of this could include:

  • Support guides for new and emerging technologies and techniques.
  • RCD staff contribute to onboarding or orientation for new researchers and/or instructors who are teaching computationally and/or data-intensive methods.
• Are researchers made aware of relevant externally-provided learning materials and opportunities, including training and events relevant to using specific RCD tools, services, and resources?
  

  Learning resources might include user documentation, how-to guides, training videos, and training events for common RCD tools, programming languages, and external RCD resources (e.g., nationally-funded, commercial resources especially if via the institution, etc.), including multi-topic sources like The Carpentries. Awareness may be achieved via webpages listing ongoing learning resources and upcoming events, emails notifying researchers of these, and/or presentations to groups on campus highlighting such resources and events.

• Are researchers provided with documentation and/or other self-service learning materials for using RCD services and resources available to them via the institution?
  

  Examples may include written user documentation and how-to guides, training videos, and other self-service formats produced by the institution and promoted alongside the relevant institutionally-available resources.

• Are researchers provided with training events and/or other synchronous learning opportunities for using RCD services and resources available via the institution or externally?
  

  Examples may include any institutionally-developed or procured synchronous training events, series, or for-credit courses teaching generalizable skills (e.g., paid or institutional-staffed Carpentries workshops) and/or the use of specific RCD tools or resources.

• Are researchers provided with individualized consultation and responsive user support for optimizing and troubleshooting the use of specific RCD services and resources available via the institution?
  

  For example, are researchers able to access individualized help via email, office hours, chat, and/or scheduled meetings for the use of locally-available RCD resources and services? Are these mechanisms accessible and known by researchers, and are they adequate for designing, optimizing, and troubleshooting end user workflows and practices on the relevant resource(s)?

• Do researchers have access to support for using RCD resources for the development and/or application of AI/ML models and methods?
  

  For example, are researcher-facing staff equipped to guide the selection and use of computing and data resources for the development, training, tuning, benchmarking, and/or application of learning models and other AI/ML methods, including such work toward the development of new AI platforms? See the CaRCC AI Facilitation Handbook for more details: https://carcc.github.io/CaRCC-AI-Facilitation-Handbook/

• Are researchers provided with individualized consultation for planning the integration of RCD services and resources across the research project lifecycle?
  

  Examples of this could include:

  • Researchers are supported during proposal development, during the active award, and post funding.
  • Researchers have access to support for project planning and proposal development.
  • Researchers are supported in preparation of publications.
• Do researcher-facing services include support for specialized and emerging use cases and technologies?
  

  This may include support across different areas, including newer/evolving hardware and appropriate use cases (e.g. GPU systems, FPGAs, quantum computing, etc.), the development of complex workflows and/or platforms for multi-system automation, etc.

Researcher-Facing Processes and Continuous Improvement

• Do RCD staff leverage structured systems for executing and tracking researcher support conversations?
  

  Examples might include:

  • The use of an email-based list or ticket-tracking system - or other systematic approach - for researcher-facing communication, issue tracking/resolution, and coordinating involvement among RCD teammates.
  • Regular practices of reviewing open communication threads, leveraging internal note-taking and/or status indicators to inform and prioritize ongoing action.
  • Periodic analysis of issues, response times, etc. to inform service management.
• Do researcher-facing staff communicate user challenges and desires via RCD/IT leadership and governance, to inform the evolution of existing and potential new RCD services?
  

  Examples of this might include:

  • RCD staff conduct periodic review of support requests to identify common problems, challenges, and/or gaps in services.
  • RCD staff use common requests for help and/or training to improve, augment, or prioritize documentation and or training resources.

Back to top 

Data-Facing Topics and Associated Capabilities

Data Management, Discovery, and Creation

• Do researchers have access to (and are they made aware of) consulting, documentation, and/or training for data lifecycle requirements, management, and planning?
  

  For example, documentation, examples, consulting, and/or training for determining data lifecycle requirements and data management planning that applies data organization and access control approaches, naming and metadata conventions, solutions for reusability, etc. This is especially useful during the data creation stage.

  • A minimal Service Operating Level might include pointers to external documentation on data management approaches, tools, and funding agency details about requirements and Data Management Plans (DMPs).
  • A basic Service Operating Level would add advising on the use of tools/platforms (e.g., Open Science Framework, electronic lab notebooks), on approaches and project-specific planning for managing a project's data, and on DMP development.
  • A strong Service Operating Level would add training and/or campus-procured tools for Data Management, e.g., Lab Notebook software, Open Science Framework.
• Do researchers have access to (and are they made aware of) consulting or other resources supporting data discovery?
  

  Examples might include:

  • Consulting, websites, hand-outs, or other resources to help identify appropriate data repositories (on campus, in domains, and more generally). Note: this may come from Research Computing and Data staff, library staff, or other partners.
  • Some form of data inventory of datasets currently licensed or otherwise available to campus researchers.
• Do researchers have access to (and are they made aware of) consulting on responsible data use based upon any terms-of-service / data-use agreements?
  

  Examples of this can include:

  • Are there any library or other staff with knowledge about common Terms of Service for frequently crawled websites/data repositories and best practices guidance?
  • Are there library or other staff with skills and capacity to inform policies and educate researchers on data use agreements (DUAs)?
• Do researchers have access to (and are they made aware of) software supporting data collection?
  

  Examples might include:

  • open source packages and other software for data crawling, web scraping, and other data gathering.

  A minimal Service Operating Level for this might include basic documentation on the topic, with pointers to existing software packages.

  A basic Service Operating Level for this might include advising from RCD staff on the selection and use of such tools, and documented pointers to external training and documentation resources.

  A strong Service Operating Level for this might include institutionally-offered training on the selection and use of data collection tools, and/or staff who can provide hands-on assistance with the creation of data collection scripts and workflows.

Data Analysis

• Do researchers have access to (and are they made aware of) consulting and/or learning resources on data wrangling/manipulation and analysis?
  

  Examples might include:

  • Guidance on cleaning, transforming, integrating, validating, and documenting research data.
  • Training and consultations on data analysis methods and best practices.
  • Access to software and computing resources that support data preparation, analysis, visualization, and reproducible research.
  • Assistance selecting appropriate tools, methods, and workflows for research projects.
  • Support for reproducible and scalable approaches to data analysis.

  A minimal Service Operating Level for this might include basic software and self-service documentation covering common data preparation and analysis tasks

  A basic Service Operating Level for this might include institutional supported software, training, and consultation services that support routine data wrangling and analysis activities. Strong Service Operating Level

  A strong Service Operating Level for this might include both advanced software resources and staff expertise capable of providing project-specific guidance on data preparation, analysis, reproducibility, workflow optimization, and scaling analytical approaches to meet research needs.

• Do researchers have access to (and are they made aware of) software that supports data wrangling/manipulation and analysis?
  

  Examples might include:

  • Spreadsheet and tabular data tools.
  • Platforms for data cleaning, transformation, and integration.
  • Statistical analysis, machine learning, and visualization software.
  • Interactive computing environments and research computing platforms that support data analysis workflows.

  A minimal Service Operating Level for this might include general-purpose software suitable for basic data preparation and analysis.

  A basic Service Operating Level for this might include a range of institutionally supported software and platforms designed for data cleaning, transformation, statistical analysis, visualization, and related research activities.

  A strong Service Operating Level for this might include a well-supported ecosystem of software, platforms, and computing resources capable of supporting data-intensive and advanced analytical workflows across a broad range of research disciplines, with support for datasets and workflows that exceed the capabilities generally available to individuals on a workstation or personal storage subscription.

Data Visualization

• Do researchers have access to (and are they made aware of) consulting and/or other learning resources on data visualization?
  

  A minimal Service Operating Level for this might include basic documentation on the topic.

  A basic Service Operating Level for this might include training and advice from RCD staff.

  A strong Service Operating Level for this might include staff with expertise who can assist in creating or refining data visualization projects.

• Do researchers have access to (and are they made aware of) software that supports data visualization?
  

  Examples might include:

  • General-purpose tools for creating charts, graphs, and other visual representations of data.
  • Interactive visualization platforms that support exploration and communication of research data.
  • Software and environments for creating customized visualizations, dashboards, and interactive data products.
  • Visualization tools and workflows that support large, complex, multidimensional, or discipline-specific datasets.

  A minimal Service Operating Level for this might include access to general-purpose software suitable for creating basic charts, graphs, and visual representations of research data.

  A basic Service Operating Level for this might include a range of institutionally supported visualization tools and platforms that enable researchers to create, customize, and share visual representations of their data.

  A strong Service Operating Level for this might include a well-supported ecosystem of visualization software, platforms, and expertise capable of supporting advanced visualization workflows across a broad range of research disciplines, including interactive, large-scale, specialized, or custom visualization needs that exceed the capabilities generally available to individuals using general-purpose desktop tools.

Research Data Curation, Storage, Backup, and Transfer

• Do researchers have access to (and are they made aware of) consulting and/or learning resources to help them identify appropriate data repositories (on campus, in domains, and more generally) to place their data?
  

  Examples of such repositories include generalist repositories such as Figshare, Zenodo, Dryad, and Open Science Framework (OSF), as well as domain-specific ones like GEO (Gene Expression Omnibus) for biology, NCBI Sequence Read Archive (SRA), RCSB Protein Data Bank (PDB), and dbGaP, and/or institutional repositories, as well as collaborative data grids such as OSN, iRODS, etc.

  Examples of such services might include:

  • Support for identifying data to be preserved, archived, or discarded, and with the consideration of generalist repositories (e.g., Figshare, Zenodo, Dryad, and Open Science Framework), domain-specific options (e.g., Gene Expression Omnibus, NCBI Sequence Read Archive, RCSB Protein Data Bank (PDB), and dbGaP), and/or institutional repositories.

  A minimal Service Operating Level might include self-service documentation, training materials, and information on available resources.

  A basic Service Operating Level might include expertise and assistance in identifying resources and depositing data.

  A strong Service Operating Level might include access and support for the physical and/or cyber resources and facilities (including those supplied by third parties) that will provide data storage, archival, and/or preservation beyond the term of grant funding.

• Do researchers have access to (and are they made aware of) resources (e.g., staff) who can advise and assist with database creation and data organization?
• Do researchers have access to (and are they made aware of) tools/software that support data backup, storage, and integrity checking?
  

  A minimal Service Operating Level for this might include iCloud or Windows Backup for workstations.

  A basic Service Operating Level for this might include backing up workstations and servers, possibly using tools such as Veeam, Rubrik, Naviki, Cohesity, or others.

  A strong Service Operating Level for this might include staff with expertise who support the development or integration of tools/software that support data backup, storage, and integrity checking for research workflows.

• Do researchers have access to (and are they made aware of) consulting and/or learning resources on metadata design and use, including good practices for use of identifiers?
  

  Example areas of available consulting, websites, hand-outs, or other resources could include:

  • Establishing controlled vocabularies for metadata and metadata fields for repository systems.
  • Help with designing metadata applicable to their research.
  • Assistance in setting up metadata for reusable data sets, physical samples, and research software.
  • Guidance on recommended use or researcher identifiers; e.g., ORCiD (https://orcid.org/), ResearcherID (https://www.researcherid.com/), Scopus Author ID, etc.
  • Training/learning resources on the above topics.

  A higher Service Operating Level for this might include support such as:

  • Researcher identifiers are supported in the enterprise directory.
  • Researchers have access to mechanisms/services to establish unique digital identifiers (DOIs) for data.

Research Data Policy Compliance

• Does your institution have research data governance processes in place to establish and enforce data policies?
  

  A minimal Service Operating Level might include defining data governance strategy and objectives, roles and responsibilities, and policies and procedures.

  A basic Service Operating Level might also include data quality management, security and privacy infrastructure and practices, and data governance communication and training.

  A strong Service Operating Level might also include data governance measurement and monitoring, as well as a practice of continuous improvement.

• Do researchers have access to (and are they made aware of) information and training on research data policy?
  

  Example areas of information and training could include:

  • Processes to support and inform users on policy compliance, e.g., integrating security and compliance planning into data management plans (DMPs) and the broader research lifecycle.
  • Training on research data security protocols.
  • Advice on research computing and data compliance, security, management, and governance.

  Note that this support should be independent of whether services are provided on-site or externally.

• Do researchers have access to (and are they made aware of) support for analysis of research data sensitivity?
  

  This may include:

  • Cybersecurity education and training tailored to researchers, including faculty, staff, and students, e.g., as workshops, onboarding resources, checklists, and/or plain-language explanations of data protection responsibilities.
  • Data Management Plan (DMP) compliance services (institutional framework, etc.).
  • Data Use Agreement (DUA) review/analysis and consulting.
  • Consulting, expertise, or other resources on contracts and government-mandated data controls (e.g., FISMA, CUI, NIST 800-171, FEDRAMP, HIPAA, NAGPRA/Indigenous data rights).
  • Institutional Review Board (IRB) templates for datasets (with human or animal subjects), from small datasets that don't need HPC, up to large datasets that need HPC or Cloud services.
  • Support at the nexus of the IRB, legal counsel, and an office of sponsored programs.

  Note that this support should be independent of whether associated infrastructure services are provided on-site or externally.

  A minimal Service Operating Level for this might include documentation, policies, training, checklists, or self-assessment resources that help identify data sensitivity and applicable requirements.

  A basic Service Operating Level for this might include consultations or advisory services that help interpret data protection requirements and identify appropriate controls and institutional resources.

  A strong Service Operating Level for this might include specialized expertise and formal review processes that evaluate data sensitivity, compliance obligations, security requirements, and appropriate handling procedures, with coordinated support across relevant institutional offices.

Research Data Security/Sensitive Data Support

• Do researchers have access to (and are they made aware of) computing and data environments to manage and use moderately sensitive data, such as those requiring NIST 800-171 controls?
  

  Examples might include:

  • Secure computing environments for storing, accessing, and analyzing controlled-access research data.
  • Managed storage, compute, and data transfer services with appropriate security controls.
  • Identity and access management capabilities supporting controlled access.
  • Monitoring, auditing, incident response, and user training appropriate to protected research environments.
  • Environments that support research workflows ranging from individual workstations to shared computing and large-scale computing resources.

  A minimal Service Operating Level for this might include researchers having access to documented institutional options for storing and accessing moderately sensitive research data using approved security controls.

  A basic Service Operating Level for this might include researchers having access to institutionally managed computing and storage environments that implement required controls for common categories of moderately sensitive research data.

  A strong Service Operating Level for this might include researchers having access to scalable, well-supported secure research environments with documented compliance capabilities, operational support, monitoring, and consulting to support a broad range of protected research workloads.

• Do researchers have access to (and are they made aware of) computing and data environments to manage and use "notice triggering" data (e.g., PHI, HIPAA, export-controlled, or licensed data)?
  

  Examples of support might include:

  • Guidance on accessing, using, and maintaining secure or compliant research enclaves.
  • Computing, storage, and data movement systems and tools.
  • Brokering access to or providing tools, systems, and environments for secure computing environments aligned with regulatory requirements
  • Data security protocols are in use and monitored.

  A higher Service Operating Level might include tools, systems, and environments that scale from small to large data sets (i.e., up to high performance computing).

• Do researchers have access to (and are they made aware of) computing and data environments to manage and use extremely sensitive data?
  

  For example, data requiring cold room/air-gapped storage and computing, closely monitored access, dedicated data stewardship, etc.

Back to top 

Software-Facing Topics and Associated Capabilities

Software Package Management

• Do researchers have access to (and are they made aware of) support, facilitation, and/or training for research software package compilation and installation**?
  

  Examples of support could include:

  • An inventory of available modules and software packages available to researchers in shared computing environments (e.g., in HPC clusters, etc.).
  • Researchers have access to locally-provisioned training, documentation, and/or support for standard software packages, middleware, libraries, and modules on RCD systems.
  • Documentation and training on how to install and deploy Anaconda distributions, GATK, BLAST, etc., in VM and/or research workstation environments.
  • RCD staff can support the compilation and installation of additional modules.
  • Guidance and support for software citation, licensing, and repository deposition (e.g., Zenodo integration, SPDX licensing).

  A minimal Service Operating Level for this might include documentation and/or tutorials.

  At a higher Service Operating Level, there may be RCD staff who can support the compilation and installation of additional modules (e.g., in HPC clusters, etc.), and/or packages in VM and/or research workstation environments.

• Do researchers have access to (and are they made aware of) support for research software package assessment and validation?
  

  Examples might include:

  • Guidance on evaluating software security, licensing, sustainability, export-control implications, and compliance considerations.
  • Assistance assessing software provenance, maintenance status, community support, and risk.
  • Vulnerability assessment and security review of research software packages.
  • Documentation of software suitability for specific research environments or compliance requirements.
  • Coordination among research computing, information security, procurement, compliance, and legal offices when needed.

  A minimal Service Operating Level for this might include researchers having access to documentation, guidelines, or checklists that help evaluate software suitability, security, licensing, and compliance considerations.

  A basic Service Operating Level for this might include researchers having access to consultation services that provide guidance on software selection, risk assessment, licensing, sustainability, and security considerations.

  A strong Service Operating Level for this might include researchers having access to staff with expertise who can perform or coordinate formal software assessments, security reviews, vulnerability analyses, and compliance evaluations, and provide recommendations for deployment and use.

Research Software Development

• Do researchers have access to (and are they made aware of) resources (e.g., staff) who can develop research software?
  

  For example, staff can be written into grants to architect or develop specific research applications or workflow components.

• Do researchers have access to (and are they made aware of) resources (e.g., staff) who can develop software for wide usage?
  

  This may include software for websites, portals, and related applications.

• Do researchers have access to (and are they made aware of) consulting, expertise, or other resources to evaluate and improve software and/or website usability and accessibility?
  

  Examples of support might include:

  • Documentation and training resources on usability and accessibility practices
  • Access to and support for usability testing tools and/or services that can identify issues and suggest improvements.
  • Access to and support for accessibility assessment tools that can identify issues and suggest improvements.

  A minimal Service Operating Level for this might include basic documentation on the topic.

  A basic Service Operating Level for this might include training and advice from staff skilled in these topics.

  A strong Service Operating Level for this might include services to conduct usability and/or accessibility reviews, and provide suggested improvements or approaches to address issues.

Research Software Optimization or Troubleshooting

• Do researchers have access to (and are they made aware of) performance optimizing tools and techniques?
  

  Examples of this might include:

  • Performance and profiling tools such as Allinea/ARM Map, Intel VTune, etc.
  • Monitoring tools such as Ganglia, NetData, DataDog, etc.
  • Guidance on how to parallelize code, to port to GPUs or other new architectures, to analyze and improve efficiency, etc.

  A minimal Service Operating Level for this might include basic documentation on the topic.

  A basic Service Operating Level for this might include training and advice from RCD staff.

  A strong Service Operating Level for this might include staff with expertise who can assist with performance optimizing tools and techniques (although this generally does not extend to deeper code porting or rewriting for new hardware, GPUs, etc.).

• Do researchers have access to (and are they made aware of) diagnostic and troubleshooting software?
  

  Examples of this might include:

  • Tools such as Allinea DDT, Intel Inspector, etc.
  • Monitoring tools for various computing environments.

  A minimal Service Operating Level for this might include basic documentation on the topic.

  A basic Service Operating Level for this might include training and advice from RCD staff on the use of these tools and techniques.

  A strong Service Operating Level for this might include staff with expertise who can assist with diagnostics and troubleshooting (although this generally does not extend to deeper code review, debugging, etc.).

Workflow Engineering

• Do researchers have access to (and are they made aware of) support for implementing research workflow packages?
  

  For example, Toil, Pegasus, NextFlow, etc.

• Do researchers have access to (and are they made aware of) expertise and basic support to develop or script data workflows?
  

  Examples of such support might include:

  • Guidance on selecting and using tools to automate research data processing, transformation, analysis, or movement.
  • Assistance developing reproducible workflows for common research tasks such as data ingestion, cleaning, quality control, analysis, visualization, and publication.
  • Consulting on workflow design, documentation, version control, automation, and reproducibility practices.
  • Support for scripting and workflow orchestration across institutional, cloud, or external research computing resources.
  • Training and examples that help researchers adapt established workflows to their own research projects.

  A minimal Service Operating Level for this might include self-service documentation, training materials, and information on workflow best practices and available support resources.

  A basic Service Operating Level for this might include consultations, office hours, workshops, training, and guidance on workflow design, scripting, automation, troubleshooting, and reproducible research practices.

  A strong Service Operating Level for this might include staff with expertise who can help researchers develop, integrate, optimize, and scale reproducible research workflows using appropriate tools, services, and computing environments.

Software Portability, Containers and Cloud Computing

• Do researchers have access to (and are they made aware of) support for making software portable?
  

  Examples of such support might include:

  • Good practices in the use of software repositories
  • Tools, training, and support for containerization, e.g., Docker, Podman, and for HPC environments, Singularity
• Do researchers have access to (and are they made aware of) development support for commercial cloud architecture?
  

  Example use cases include: development of project-specific and domain-specific computing and data portals (like science gateways) or other multi-system workflow orchestration leveraging commercial cloud resources.

  Such cloud platforms can include:

  • Local private campus cloud infrastructure
  • National (e.g., XSEDE-supported) cloud infrastructure
  • Commercial cloud platforms (e.g., AWS, Azure, GCP, etc.)

  Guidance or training topics may include:

  • Platform (and vendor) evaluation and comparison
  • Virtual machine management
  • Cloud scaling
  • Cloud architecture (and when appropriate, secure architecture)
  • Orchestration design and development (Kubernetes, Puppet, Chef, etc.)
  • Cloud budgeting and cost management

  A minimal Service Operating Level for this might include documentation and/or tutorials.

  A basic Service Operating Level for this might include training and/or consulting.

  A strong Service Operating Level for this might include resources and capacity (e.g., staff) for architecting and deploying cloud solutions.

Securing Access to Software

• Do researchers have access to (and are they made aware of) credential systems as an element of software security?
  

  For example, is there ready access to and support for integrating research software, research workflows, etc. with systems like CAS, Shibboleth, SAML, Single-Sign-on, etc.

• Do researchers have access to (and are they made aware of) support for utilizing licensed software?
  

  For example, do researchers have access to licensed software that has been procured via institution? Are there license servers supporting such software, available via the institution?

• Do researchers have access to (and are they made aware of) support for managing export-controlled software?
• Are processes defined and adhered to for educating, monitoring, and auditing the use of licensed software by Research Computing and Data staff, other IT professionals, and researchers, to comply with software license agreements?
  

  A minimal Service Operating Level for this might include training on the terms and responsibilities of license agreements.

  A basic Service Operating Level for this might include practices to maintain inventories of installed software and track installations.

  A strong Service Operating Level for this might include the use of Software Asset Management tools to automate tracking and monitoring, as well as regular audits.

• Do researchers have access to (and are they made aware of) support for AI-assisted software development??
  

  For example, are users provided with guidance and or consultative support on appropriate practices for AI-assisted software development, including the use of AI agents, via institutionally-provided tools and resources.

Software Associated with Physical Specimens

• Do researchers have access to (and are they made aware of) software for managing physical collections?
• Do researchers have access to (and are they made aware of) software for discovery and research use of physical collections?
  

  A minimal Service Operating Level for this might include basic documentation on the topic.

  A basic Service Operating Level for this might include training and advice from RCD staff on the software and best practices.

  A strong Service Operating Level for this might include staff with expertise who can provide hands-on assistance in creating or refining software for the discovery and research use of physical collections.

Back to top 

Systems-Facing Topics and Associated Capabilities

Infrastructure Support

• Does the institution have a professionally-managed and reliably functional datacenter(s) available for research computing and data resources?
  

  For example, does the institution maintain one or more full-time IT operations and equipment facilities? Are there staff with time dedicated to managing datacenter infrastructure and following documented procedures, including appropriate access controls and auditing?

  Counterexample: significant server infrastructure is operated in spaces shared with non-infrastructure equipment (a research laboratory, a grad student office space, "closet clusters"), with ad hoc management by non-dedicated staff.

• Are institutionally-available RCD resources operated and maintained via automated processes?
  

  For example, using Foreman, Razor, Puppet, Ansible, Chef, Kickstart, etc.

  As a counterexample, infrastructure is managed with ad hoc scripts and ssh, and new systems are installed using unmodified OS installation media.

• Do systems-facing staff have the skills and capacity to apply container deployment and orchestration?
  

  For example, service-oriented architectures, Kubernetes or Docker for persistent services, Singularity for HPC application portability, etc.

  As a counterexample, all programs are run directly on the host operating system and cannot be easily migrated to another host and/or operating system.

• Do RCD staff maintain documentation of various managed systems, including processes, procedures, and policies for infrastructure management?
  

  Examples could include:

  • a comprehensive hardware and infrastructure inventory: Up-to-date lists of computing nodes, storage systems, DTNs, and network equipment, etc., including lifecycle and warranty status.
  • system and network architecture diagrams: Clear documentation of cluster architecture, storage topology, research network design (e.g., Science DMZ layout, data transfer paths), etc.
  • configuration and build documentation: Standard OS images, scheduler (e.g., Slurm) configurations, GPU/CUDA stacks, etc., including provisioning procedures.

  A minimal Service Operating Level for this might be characterized as "the architecture is obvious if we look at what's in each rack", "the documentation is in my head or in emails spanning multiple years", or "all the relevant commands are in root's shell history".

  A basic Service Operating Level for this might be characterized as having documentation from the original design or installation, but has since gone out of date. New systems-facing staff may quickly get the basic outline of the system, but find themselves adding missing documentation or working with existing staff on documentation updates.

  A strong Service Operating Level for this might be characterized as closely aligning with principles of http://www.infrastructures.org/, https://web.archive.org/web/20250411044045/https://www.opsreportcard.com/, Limoncelli et al's The Practice of System and Network Administration, and similar references. The effort to onboard new systems-facing staff is minimized, and documentation is updated as changes occur.

• Does the institution manage identities and roles to support access to on-campus and external RCD resources?
  

  Identities may be managed and federated using solutions such as Active Directory, Lightweight Directory Access Protocol (LDAP), InCommon federation, and others. Roles may be managed with dedicated identity management (IdM) software solutions, but role-based access is more about architecture and standard practices.

  A minimal Service Operating level for this might only include accounts that are local to each resource or system, lack of multi-factor authentication (MFA), ad hoc access practices like "give this person access exactly matching this other person" or "give this person access to these specific folders".

  A basic Service Operating Level for this might only integrate the local institution's central directory, partial support for MFA, and limited support for defining data access through common roles ("give everyone on this group or project identical access to their shared data, and manage who is included in the group or project") rather than individual identities.

  A strong Service Operating Level for this would allow researchers' external collaborators to use their home organization credentials (or other federated IDs) to access the institutions' systems and data, ubiquitous and seamless MFA, consistent support for role-based access, and tools are provided to faculty and other designated project leads for managing access for institutional contributors (e.g., students and post-docs) and external collaborators.

Computing Infrastructure

• Are high performance computing (HPC) systems and/or high throughput computing (HTC) available via the institution?
  

  HPC: multiple computers connected to a high-speed, tightly coupled network, where software (similar to Slurm, PBS, or LSF) schedules dedicated access to shared resources to solve problems larger than an individual computer can handle. Applications and data are usually accessed from a central location, rather than distributed to local storage on each computer.

  HTC: multiple computers connected over any network or the internet, where software (similar to HTCondor or Folding@home) distributes applications and data to solve large numbers of independent tasks (or small tasks, many times), each of which fits within the resources of a single computer.

  A minimal Service Operating Level for this might include HPC or HTC operated ad-hoc by faculty and/or students on multi-purpose hardware, and made available to others associated with the institution.

  A basic Service Operating Level for this might include some dedicated systems and staff for HPC and/or HTC systems.

  A strong Service Operating Level for this might include fully-supported batch computing systems for HPC, HTC, high-memory, and GPU/AI computing use cases.

  Note: a 'leading collaboration' status effectively equates to running systems for regional/multi-institutional sharing and/or national program (e.g., NSF and/or DOE-funded allocated resources).

• Are specialized computational hardware capabilities available via the institution?
  

  Examples of this might include (depending upon the researchers' needs at an institution): Tensor Processing Units (TPUs), Field-Programmable Gate Arrays (FPGAs), Neural Processing Units (NPUs), Quantum hardware, etc. Traditional GPUs used for simulation or AI are excluded from this capability, since they are often included in HPC and/or HTC systems.

• Are interactive computing services available via the institution?
  

  For example, support for virtual desktop infrastructure, notebooks (e.g., Jupyter), etc., whether via an external or commercial service or an internally managed option.

• Do resources available via the institution apply a standardized set of operating systems (e.g., for HPC, workstations, and virtual machines)?
  

  For example: Are there consistent versions of Linux-based OS (e.g., Rocky, RHEL, or CentOS distribution on all HPC clusters), standard versions of Unix/macOS, or Windows on workstations?

  The counterexample is that various HPC clusters run different OSs, and there are no standard OS distributions for VMs or workstations.

  Considered from an organizational perspective, does the number of OSes supported reflect a considered flexibility for research needs, or is it a consequence of personal preference, local history, and/or a lack of organizational policy and practice?

• Does institutionally-available RCD infrastructure support the safe operation of AI-assisted software development tools and AI agents?
  

  This is the systems-facing aspect for supporting AI-assisted software development: not whether researchers are advised, but whether the infrastructure is configured to let AI coding assistants and agents interact with RCD systems safely.

  Examples of infrastructure support might include:

  • centrally-managed agent context and policy files (e.g., AGENTS.md, /etc/agents.d, managed settings.json) that both restrict what agents may execute and govern context usage — for example, instructing agents not to traverse or ingest an entire shared filesystem, only relevant project paths
  • sandboxed or isolated execution environments that bound what an agent can read, write, run, or reach on the network (e.g., containers or user-namespace tools such as bubblewrap, and the sandboxing available in tools like Claude Code)
  • reliance on existing least-privilege hardening (root-squashed filesystems, /tmp isolation, cgroups, scheduler limits) to contain an agent's blast radius to what the account can already do
  • institutionally-hosted inference and/or vetted MCP endpoints so agent workflows can keep code and data within institutional boundaries

  As a counterexample, researchers run external AI agents against RCD systems with no system-side configuration, isolation, or guidance, so agent behavior is unbounded and untracked.

  A minimal Service Operating Level for this might include basic documentation on acceptable use of AI tools, placing the onus on the user, with no system-side accommodation.

  A basic Service Operating Level for this might include some systems provisioned with agent context files and opt-in sandboxed environments.

  A strong Service Operating Level for this might include maintained agent context/policy files (governing both execution and context usage), robust sandboxing, and institutionally-hosted inference — integrated into standard system provisioning rather than assembled ad hoc.

Storage Infrastructure

• Is sufficient storage for working data available via the institution to support researchers' data-intensive computing needs?
  

  Examples often include:

  • research-optimized and documented support via commercial cloud drives (e.g., OneDrive, Google Drive)
  • active data storage services (a.k.a., "scratch" storage, often a parallel filesystem) sufficient for HTC/HPC.
  • online or near-line storage for large datasets
  • purpose-built S3 or other performant cloud storage

  Counterexamples of this often include storing research data on:

  • individual researcher external drives or servers
  • use of commercial drives via personal (non-institutional) accounts, e.g., OneDrive, Google Drive
• Are technologies available via the institution to facilitate data and access management?
  

  Examples may include:

  • data collection, management, and workflow platforms like iRODS, REDCap, Gen3, Globus Connect/Search, and others
  • tools for automated tiering and data migration.
  • tools for faculty to manage access by students and collaborators

Network and Data Movement Infrastructure

• Is the institution's network configured to support research demands from within the campus(es)?
  

  This is not about a given bandwidth or capacity number, but rather about researchers not being limited in their use of instruments, access to data, or workflows that require a needed scale of datasets to conduct their research.

  Example measures could include:

  • The network is reliable (very little downtime) and accessible (e.g., wired and wireless connection capacity is sufficient for the needs of research and instruction).
  • The network is performant for researchers' needs (researchers can reasonably move data to and from the institution, among labs, etc.).
  • The network architecture is well integrated with regional and national networks.

  Note: this capability is about the network as a general service. More specific capabilities for data-intensive research are described in other capabilities.

  A minimal Service Operating Level for this might include frequent network outages, multiple bottlenecks in network capacity, and predominantly using external physical media and "sneakernet" to transfer research data due to bandwidth constraints.

  A basic Service Operating Level for this might include fewer network outages and a dedicated Science DMZ.

  A strong Service Operating Level for this might include minimal network outages and ample bandwidth for the vast majority of researchers' needs.

• Is infrastructure provided via the institution for secure, performant data movement?
  

  Examples of this could include:

  • a protected subnet or campus/regional Science DMZ (segmenting applicable research data sources and patterns to bypass campus firewalls).
  • virtualized networking techniques such as overlays, etc.
  • dedicated data transfer nodes (DTN)
  • data movement software; this may include Globus Connect, FDT, or BBCP, among others
  • infrastructure for data buffering between high I/O lab instruments and the data center, and/or external resources, including special science instruments like cryogenic electron microscopes (cryo-EM), DNA sequencers, telescopes, etc. (common approaches to this are often referred to as "data capacitors" or "burst buffers").

  A minimal Service Operating Level for this might include a one-size-fits-all network architecture, and predominantly using external physical media and "sneakernet" to transfer research data due to blocked network ports or other security limitations.

  A basic Service Operating Level for this might include a dedicated Science DMZ largely defined by physical proximity to the data center, and some basic data movement software.

  A strong Service Operating Level for this might include a flexible or software-defined network architecture and facilities for secure, performant data movement among researcher client systems, high I/O lab instruments, the data center, and external resources.

Specialized Infrastructure

• Does the institution provide infrastructure support for edge computing and data devices, and/or Internet of Things (IoT) devices?
  

  Edge computing is a distributed computing model that places computation and storage closer to data-collection points and/or instruments. Applications often include specialized scientific instruments such as cryogenic electron microscopes (cryo-EM), DNA sequencers, telescopes, field research, etc.

  Examples of infrastructure support may include:

  • computing and/or data capacity at the site of instruments and field devices
  • wireless communications for field devices such as Cellular, Short-Range Wireless, and LPWAN
  • IoT gateways including: Cellular Routers, LoRaWAN Gateways, Edge Computing Gateways, and/or Industrial Gateways
  • IoT Controllers and cybersecurity support
• Does the institution provide infrastructure support for personal computers beyond normal academic/administrative use?
  

  Here, "personal computers" refers to laptops, desktops, workstations, or similar devices.

  Examples of infrastructure support could include:

  • support for the physical hardware
  • infrastructure to automate the installation and updates of operating systems and common applications
  • flexible policies and procedures to accommodate the needs of research beyond what is generally supported (or allowed) for academic/administrative needs

  Counterexample: support for basic Windows laptop with only academic/administrative applications from a limited catalog, where users don't have any administrative access, so don't mess with it.

• Are specialized, experimental infrastructure environments available via the institution?
  

  Examples may include bare metal hardware, reconfigurable BIOS, OS, and network, or experimental cloud testbeds. Applications may come from fields like network, systems, and computer engineering, cybersecurity, and other applied computer-related sciences.

Monitoring and Measurement

• Is RCD infrastructure monitored for utilization and performance?
  

  Examples of metrics might include:

  • usage metrics of multi-user computing and data systems (e.g., numbers, sizes, and durations of compute or data tasks, files, access patterns, transfers, etc.)
  • device inventory across lab instruments and attached computing and storage devices
  • traffic and performance monitoring of the research-supporting network, DMZ, DTN, etc., leveraging tools such as perfSONAR and/or a workflow environment to support end-to-end network performance troubleshooting
  • measuring/monitoring the energy efficiency and environmental impact of research-computing infrastructure (e.g., PUE monitoring, carbon-aware job scheduling)

  A minimal Service Operating Level for this might only include on-device monitoring.

  A basic Service Operating Level for this might include data visualization tools and/or monitoring dashboards.

  A strong Service Operating Level for this might include tools to detect and report problems or anomalies, predictive analytics to prevent outages, downtime, or security issues, and the practice of using data for operational decision-making.

• Does the institution track and report resource usage at the researcher/project level?
  

  For example, for institutional and funding agency reporting purposes. Counterexample, resource usage is only aggregated at the individual user level, and users are not easily grouped by PI or project.

Best security practices for general-use environments

• Is Research Computing and Data (RCD) security coordinated with institutional IT Security and Compliance?
  

  For example:

  • Is the institutional IT security team leveraged for training and education?
  • Do RCD staff leverage institutional compliance resources/offices?
• Is there a documented process for managing and auditing privileged (administrator) accounts, and do Research Computing and Data staff follow the associated procedures?
  

  Example measures include documented policies and procedures for roles that should have privileged accounts, as well as tracking and periodic review of those accounts.

  A counterexample might be the ad hoc granting of elevated privileges.

• Are Security Best practices implemented, including a security incident response plan?
  

  Example practices could include:

  • security zones defined for different data sets and science workflows
  • security monitoring for intrusion detection, malware, and other threats
  • other recommendations from NIST, trusted CI, CVE, and others

  A minimal Service Operating Level might be characterized as having documented practices and a security incident response plan, and that these procedures are followed when incidents arise.

  A basic Service Operating Level might be characterized as also including review of plans and team membership on a regular basis (e.g., annually).

  A strong Service Operating Level might be characterized as further including:

  • documented system security plans (SSPs) and plans of action and milestones (POAMs) defined for research computing and data environments
  • completion of security assessments and/or accreditation (e.g., CMMC)

Back to top 

Strategy and Policy-Facing Topics and Associated Capabilities

Institutional Alignment

• Does the Research Computing and Data (RCD) team/group have a strategic plan that is updated on a regular basis**?
  

  Examples of this could include:

  • There is a strategic plan and it is reviewed on a regular basis.
  • The team has a clear vision, effective guidance, and strategy for the allocation and prioritization of support resources/personnel.

  A minimal Service Operating Level might be characterized as having a strategic plan that is no more than 3 years old.

  A basic Service Operating Level might be characterized as having a strategic plan that is reviewed on a yearly or every-other-year basis, and reflects institutional (campus-wide) strategic plans for IT, for research, and for the institution broadly.

  A strong Service Operating Level might be characterized as having a strategic planning process and practice for IT, for research, and for the institution broadly that recognizes RCD strategic goals, and in which the RCD strategic plan has clear connections to the broader institutional strategic plans.

• Does the Research Computing and Data (RCD) team/group have a good awareness and understanding of major research efforts/initiatives across the institution?
  

  This awareness might come through regular briefings to RCD and IT leadership and/or engagement with research leadership. A counter example for lack of awareness and understanding is: are RCD and/or IT leadership often surprised by the needs of new grants or research initiatives?

• Are campus leaders and relevant governance groups aware of Research Computing and Data (RCD) strategic priorities?
  

  Examples or evidence of such understanding may include:

  • The institution's research priorities are well-understood by campus leadership.
  • RCD strategic priorities understood and supported by campus leadership.
  • Campus leadership understand and support the need for staff capacity to focus on outreach, training, and other support to researchers in the use of RCD services (whether on campus, from national resources, commercial services, etc.)?
• Is there an understanding across the IT organization, research community, and institutional leadership of the distinction between Research Computing and Data services and standard (enterprise) IT services?
  

  Note: This does not imply greater importance of one or the other, nor is it meant to imply how an organization should support each. Rather, it is a recognition that the goals, constraints, metrics, and support models tend to be quite different.

• Are Research Computing and Data (RCD) resources and services available in support of instruction or other pedagogical uses?
  

  For example:

  • Can and do instructors leverage RCD resources for instruction?
  • Are instructors effectively informed about available resources?
• Is there a governance body (e.g., faculty advisory group) that reviews and advises on priorities for campus-level investments for Research Computing and Data (RCD) infrastructure?
  

  This is generally a dedicated group for RCD, although it may be part of a larger research or IT advisory body, but examples of this might include:

  • A designated group of faculty, research, and/or IT representatives that meets regularly (e.g., quarterly or once a semester) to review and advise on topics such as emerging needs, new technologies, and/or campus funding to sustain or supplement RCD programs.
  • A committee within the overall faculty governance body; at a smaller campus, this may be a general IT committee, but that is prepared to advise and recommend funding on RCD-specific capabilities.
  • A set of one or more committees that each advise on different RCD aspects or units, e.g., scalable data storage services, the research computing unit, software procurement policy, etc. (perhaps at a larger campus with a deeper portfolio and/or multiple collaborative RCD providers).

Funding

• Are Research Computing and Data (RCD) services funded in a sustainable manner?
  

  Some examples or evidence of this might include:

  • There is recurring program budget for the RCD staff and services operations (i.e., these are not primarily dependent upon grants or other non-recurring funding).
  • Campus funding partnerships are formalized with an MOU or equivalent agreement.
  • For activities funded from contracts and grants, there is a strong track-record of renewed funding.
• Are new funding opportunities proactively identified and assessed at an institutional level, for relevance to institutional mission and alignment to Research Computing and Data (RCD) needs and priorities?
  

  Examples of this might include tracking calls from national funders for:

  • Major Research Instrumentation (MRI) grants (or equivalents) that could support new computing and/or data capacity in support of research initiatives
  • Grants that support expanded research cyberinfrastructure
  • Grants or other funding opportunities that support training or professional development of RCD staff

  A minimal Service Operating Level could be characterized as ad hoc review of opportunities, while "Strong support, awareness, & commitment" could be characterized as a structured process coordinated among RCD staff and other institutional stakeholders.

• Do research funding activities actively integrate the campus's Research Computing and Data (RCD)** provider(s)?
  

  For example:

  • Do RCD teams collaborate with the Contracts and Grants teams to be aware of grants with computational or data needs?
  • Is there a means for Principal Investigators (PIs) to indicate that a proposed submission has significant or unusual computational, data, or other infrastructure aspects and/or needs?
  • Do RCD staff assist Principal Investigators (PIs) with proposal preparation (e.g., on hardware specification)?
• Do Research Computing and Data (RCD) services teams submit (extramural) grant proposals for RCD investments and innovations?
  

  A minimal Service Operating Level might be characterized as RCD staff occasionally being involved in grant preparation and being named as Senior Personnel.

  A basic Service Operating Level might be characterized as RCD staff regularly being involved in grant preparation and occasionally acting as Principal or Co-Principal Investigators.

  A strong Service Operating Level might be characterized as RCD staff regularly being involved in grant preparation as Principal or Co-Principal Investigators, and having been awarded such grants.

Service Management, Processes, and Practices

• Do Research Computing and Data staff leverage a structured system for tracking internal work?
  

  Structured systems might include the use of an internal ticketing systems and/or other project management platform within which issues, progress, and 'owners' are documented. These may be integrated/continuous with the system for receiving and handling user-facing issues, or may be separate.

• Does the institution have a process to conduct regular assessment of Research Computing and Data (RCD) services and support, including user satisfaction and impact?
  

  Examples might include:

  • Periodic satisfaction surveys to assess researcher awareness, satisfaction, and engagement related to RCD services and support.
  • Periodic data collection to assess the impact of RCD support. These often include data on publications, grants, etc. for active users, as well as faculty and graduate student recruitment and retention cases supported.
  • Practices (conversation/email logging, surveys, interviews, etc.) to capture informal feedback and/or gather quotes from active research users, perhaps to communicate these to other stakeholders.

  A minimal Service Operating Level might be characterized as occasional surveys, data collection, and testimony capture that is used by the RCD team and in communications with leadership, etc.

  A basic Service Operating Level might be characterized as regular surveys or data collection that is reviewed by the RCD team, and shared with IT leadership, Office of Research, or other institutional leadership to inform budget requests and institutional planning

  A strong Service Operating Level might be be characterized by assessment and impact reports resulting in institution-level leadership recognizing and valuing the impact of RCD services and support (including return/value on investment), and valuing RCD at the same level as or higher than other enterprise services when discussing the prioritization of campus (budget) resources.

• Do Research Computing and Data (RCD) staff follow a formal process for review, planning, and procurement of research computing, data, networking, etc. resources?
  

  Examples of this might include:

  • Defining and maintaining a systems and infrastructure lifecycle plan.
  • Documenting requirements, benchmarks, cost analysis, acceptance plans, terms and conditions, etc.
  • Maintaining a business-continuity and disaster-recovery plan specifically for RCD services.
• Do Research Computing and Data (RCD) planning processes include/incorporate security and compliance considerations?
  

  Examples of this might include:

  • RCD staff monitor and respond to changes in research cybersecurity policy and regulatory requirements.
  • RCD staff engage with campus and national stakeholders to build awareness of likely (or at least possible) future changes in research cybersecurity policy and regulatory requirements.

  A strong Service Operating Level might be characterized by proactive adaptation of templates, internal documentation, and guidance related to evolving federal expectations.

• Does the institution assess, support, and regularly update research cybersecurity risks, standards, and solutions?
  

  Some examples of this could include:

  • There are legal and/or policy oversight practices and controls in place for AI/LLM related activity. These might be informed by a framework like the NIST Artificial Intelligence Risk Management Framework (AI RMF).
  • Researchers have access to (and make use of) resources explaining data security levels/classes and the computing and data services appropriate for use with each level/class.
• Does the institution provide support, risk assessment, or compliance guidance for lab- or faculty-managed research infrastructure that is otherwise outside central IT management or governance?
  

  Examples of this might include:

  • Consultation for securely integrating or mitigating risk on standalone servers, cloud-based systems, etc.
  • Support and guidance on securing workstations that do not benefit from central management.
  • Support and guidance on securing custom (locally developed) applications.
  • Other general consultation and guidance services, like those relevant to meeting Cybersecurity Maturity Model Certification (CMMC) requirements.
• Are solutions in place via the institution that ease the use of commercial cloud services by researchers?
  

  Examples of this might include:

  • There are institutional agreements (e.g., covering legal and compliance issues) and billing processes in place (e.g., that allow institutionally-coordinated charging to research grants).
  • There are technology integrations in place that allow researchers to access cloud resources using their institutional identity.

  A counterexample might be that researchers are forced to use free credits or their own cloud accounts for their research.

Partnerships and Engagement with External Communities

• Do Research Computing and Data (RCD) services teams actively engage with regional and/or national RCD peers/communities?
  

  Examples of this might include:

  • Meeting with or closely following communications from regional research network providers, NSF regional Big Data Hubs, etc.
  • Attending presentations and/or participating in groups at CaRCC, the EDUCAUSE RCD CG, etc.
  • Attending periodic meetings held by CASC, Internet2, Campus Champions, the EPSCoR CI community, MS-CC CI activities, etc.

  A minimal Service Operating Level could be characterized as periodic attendance/engagement, while "Strong support, awareness, & commitment" could be characterized as actively contributing to a working or interest group at CaRCC, CASC, EDUCAUSE RCD CG, etc.

• Are Research Computing and Data services operated or contributed by the institution for external users, via regional or national resource allocation and/or sharing programs, etc.?
  

  Examples of this might include:

  • Operating funded resources as part of a national allocation program like NSF ACCESS, NAIRR, etc.
  • Operating funded resources as part of a regional consortium, e.g., RMACC, GPN, etc.
  • Contributing resources to a regional or national consortium, e.g., the OSG's Open Science Pool.
• Does the institution actively engage in external partnerships for RCD funding and/or resource sharing, with other specific institutions, industry partners, etc.?
  

  Examples of this might include:

  • Resource-sharing among two or more institutions, not necessarily as a part of a formalized regional consortium or national program, but perhaps within the same university system.
  • Active industry partnerships.

Team and Professional Development of Research Computing and Data Staff

• Are Research Computing and Data (RCD) staff provided with opportunities for professional development and career advancement?
  

  An example of a minimal Service Operating Level might be that management and staff discuss career paths for each role.

  An example of a basic Service Operating Level might be that each RCD staff member has a professional development plan and staff are encouraged/supported in pursuing career advancement opportunities including training, professional networking, authoring or co-authoring RCD publications, etc.

  An example of a strong Service Operating Level might be that RCD staff have access to funding (and time allowed) for training, new skills development, etc.

  Note that while some aspects of this (like a professional development plan) will generally be supported by a supervisor or mentor at the institution, some professional development opportunities may be provided outside the institution, e.g., by dedicated programs, or in regional or national communities.

• Are Research Computing and Data (RCD) staff engaged with exploring, testing, and deploying emerging or advanced tools, methodologies, and technologies needed or likely to be needed by researchers?
  

  Examples of this include:

  • Researcher-Facing staff have time allotted for exploring, training, and developing understanding of emerging or advanced tools and methodologies?
  • Systems-Facing staff have time allotted for evaluating, testing, training and developing understanding of infrastructure needs for deploying emerging or advanced tools and technologies.

  A basic Service Operating Level would include regular dedicated time for these activities, while "Strong support, awareness, & commitment" might also include this as a part of professional development plans.

• Are Research Computing and Data (RCD) staff permitted to use staff time to engage in regional or national community efforts?
  

  Examples of this include:

  A minimal Service Operating Level might be characterized as RCD staff occasionally participating in (e.g., attending calls or presentations from) regional networks, Campus Champions work, Linux user groups, CaRCC, etc.

  A basic Service Operating Level might be characterized as RCD staff regularly participating in such activities, and occasionally engaging or contributing to these activities.

  A strong Service Operating Level might be characterized as RCD staff being contributing members of one or more working or interest groups at CaRCC, CASC, EDUCAUSE RCDCG, etc., and/or they contribute to community efforts like Carpentries training materials or activities.

• Is there a policy and practice to ensure (and if necessary, improve) community, accessibility, and belonging, on the Research Computing and Data (RCD) staff?
  

  Examples might include:

  • RCD staff are regularly surveyed/polled/queried on engagement, cultural climate, etc.
  • User-facing communication, applications, and services are evaluated for accessibility.
  • RCD management tracks this over time, and results are used to develop ongoing strategies to improve community, accessibility, and belonging.
  • Hiring practices include measures to expand applicant pools and reduce bias.
• Do Research Computing and Data (RCD) staff have access to training to support community, accessibility, and belonging?
  

  Examples might include:

  • RCD staff have access to training on unconscious bias, different communication styles, multicultural awareness, etc.
  • RCD staff have access to training on identifying and addressing accessibility issues associated with outreach and communications, applications, user-facing services, etc.
  • RCD staff are supported with training, team principles, and practices that ensure a culture of belonging by minimizing discrimination and harassment.

Back to top