10-Attachment 9 - Technical Specifications Architecture Standards.pdf
PDF 100 KB Posted
- Attached to
- Texas School Climate Program
- Solicitation number
- 721-26069
- Issued by
- Travis County, Austin City, Texas
About this file
Summary: Technical Specifications Architecture Standards
This is a Technical Specifications Architecture Standards document supporting the Texas School Climate Program, a Request for Proposal issued by the University of Texas at Austin. The document establishes the technical and architectural requirements that qualified vendors must adhere to when developing solutions for the School Climate Program. The specifications outline system design standards, integration requirements, data management protocols, and technical infrastructure expectations that vendors' proposed solutions must meet or exceed. These architecture standards serve as a baseline for evaluating vendor proposals and ensuring that selected solutions align with the University's technical infrastructure, security requirements, and long-term operational needs.
The document functions as a compliance and evaluation tool that vendors must reference when preparing their technical proposals and implementation plans. By establishing clear architecture standards upfront, the University ensures that all proposed solutions will be compatible with existing systems, meet institutional data governance requirements, and support scalability for future program expansion. Vendors submitting proposals must demonstrate how their proposed products or services conform to the specified technical architecture, including system interfaces, security protocols, accessibility standards, and performance benchmarks outlined in the specifications.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Attachment 9: Technical Specifications & Architectural Standards
The selected Vendor must adhere to the following technical constraints, architectural standards, and security protocols. The proposed solution is required to be hosted and maintained within the Google Cloud Platform (GCP) ecosystem.
Infrastructure & Hosting
• Cloud Provider: The application must be hosted on Google Cloud Platform (GCP).
• Containerization: The application must be fully containerized using Docker. The vendor must provide all necessary Dockerfile and container orchestration configurations.
• Deployment Environment: Docker containers must be deployed to a suitable GCP service (e.g., Google Cloud Run or Google Kubernetes Engine) to ensure scalability and portability.
• API Gateway & Rate Limiting: All external API traffic must be managed via a GCP API Gateway (or Apigee) to enforce strict Rate Limiting and OAuth 2.0 authentication, protecting backend resources from abuse and cost spikes.
Identity & Access Management (Zero Trust)
• Single Sign-On (SSO): The application must integrate with the Texas Education
Exchange using standard protocols (OIDC or SAML 2.0) for user authentication.
• Zero Trust Access: The solution must utilize Google Identity-Aware Proxy (IAP) to verify user identity and context before traffic reaches the application, establishing a Zero Trust security model.
Database & Storage
• Operational Database (OLTP): For real-time functionality, the solution must use a GCP-native transactional database (e.g., Cloud SQL for PostgreSQL/SQL Server).
Network Security: The database instance must be configured with Private IP only and utilize VPC Service Controls to prevent unauthorized public access or data exfiltration.
• Data Warehouse (OLAP): The application must utilize GCP BigQuery for data warehousing and analytics. ○ Federated Queries: The architecture shall utilize BigQuery Federated Queries (external queries) to read real-time data from Cloud SQL where appropriate, minimizing complex ETL pipelines.
o Data Privacy: The solution must implement Column-Level Security (via
Policy Tags) and Data Masking to protect PII (Personally Identifiable Information) from unauthorized analyst access.
D. Front-End Development (Angular)
• Framework: The front-end must be developed using Angular with Angular Material for the UI.
• Reactivity: Development must utilize Angular Signals for granular reactivity
(ChangeDetectionStrategy.OnPush).
• Accessibility: The application must be fully compliant with WCAG 2.1 Level AA standards (keyboard nav, ARIA labels).
• Architecture: ○ Standalone Components: All components must be standalone:
true.
• Strict Typing: No any types; strictly defined interfaces.
• Lazy Loading: Feature modules must be lazy-loaded.
E. Back-End Development (C# .NET) o Language: Backend API and logic must be written in C# (.NET Core).
o Architecture: ○ Thin Client Model: Business logic must reside in the API, not the frontend.
o Layered Design: Controllers must delegate to a Business Logic layer; no direct DB access in controllers.
o Global Exception Handling: Middleware must catch all exceptions and return standardized ProblemDetails JSON without exposing stack traces.
o Structured Logging: Logs must be serialized as JSON (e.g., Serilog) for GCP compatibility.
F. Security & Documentation o Endpoint Security: All APIs must be secured by default using Claims-Based Authorization ([ClaimRequirement]).
o API Documentation: The API must automatically generate OpenAPI v3 (Swagger) documentation.
o Code Currency: All libraries and frameworks must use the latest stable release at the start of the project.
File details come from the government source that posted it. Updated .