Lexicon

Agile Methodology: Iterative, flexible software development approach.

Applications (Apps): Software performs specific user or application functions. 

Architecture: Design principles for constructing software systems. 

Back End: Server-side part handling data processing. 

CODE VA: Formerly the VA Developer Portal, A dedicated website or platform that serves as a central hub for developers. It provides access to various resources, tools, documentation, APIs, code samples, and other materials that developers need to build applications or integrate with a particular software or service.

Containerization of Legacy: There is an ongoing effort to migrate systems to containers in the VA Enterprise Cloud (VAEC) to reduce cost, increase geographical load balancing, and improve fault tolerance. When an existing system is being assessed for modification, the developers and architects should consider containerizing the solution to move it to VAEC.

Compliance and Data Safeguarding: Adherence to security standards like FedRAMP.

Continuous Integration (CI)/Continuous Deployment (CD): CI/CD stands for Continuous Integration/Continuous Deployment. It is a method of frequently integrating code into a shared repository and automatically deploying applications. Continuous Integration (CI) involves merging all developers’ working copies to a shared mainline several times a day and running automated tests to catch issues early. Continuous Deployment (CD) extends CI by automatically deploying all code changes to a testing or production environment after the build stage. This process allows for rapid iteration, testing, and release of software.

Custom Development (CustomDev) Factory: The Custom Development Factory within the Software Factory Model is tailored to address highly differentiated needs that standard solutions cannot fulfill. It’s a specialized environment where unique and bespoke software is crafted, diverging from the off-the-shelf offerings of SaaS or the adaptable platforms of PaaS. This factory takes on projects requiring a “Highly Differentiated” play decision, focusing on creating innovative solutions that are as unique as the challenges they are designed to overcome.  Developers should only consider a custom code solution if both SaaS and No-Code/Low-Code solutions are not available. All new and modified code should use the current development guidelines for the specific environment.

Developer Security Operations (DevSecOps): DevSecOps introduces security early and throughout the software development lifecycle, aiming to build and deploy secure software rapidly and reliably. It is an approach that integrates security practices within the DevOps process.   

Development Operations (DevOps): DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the system development life cycle and provide continuous delivery of high-quality software. It emphasizes collaboration, automation, and integration between developers and IT professionals to improve the speed and quality of delivering software. 

Developer Portal: Hub for accessing development tools. 

Digital Transformation Center (DTC): DTC is responsible for accelerating VA’s digital modernization and use of emerging technologies to better serve Veterans and military families. This team helps VA employees navigate the process to request and implement SaaS and PaaS products.

Domain: Provides features that caters to a specific group of business outcomes or customers; capability is not replicated in other platforms.

Existing FedRAMP Play: Estimated to that 1-1.5 years, this play is products where an agency outside the VA has sponsored the FedRAMP Authority to Operate (ATO), and require a VA ATO. In this play, the desired product currently has a FedRAMP ATO but does not have a VA ATO. This play requires validation that FedRAMP ATO sponsored by another agency meets VA standards. Some security work may be required which can impact timelines.

Federal Risk and Authorization Management Program (FedRAMP): Government program for cloud service security standardization.

Front End: User interface part of the software.

Full Stack: Developers skilled in both front end and back end. 

Foundational Platform: Provides features at the enterprise level that are made available across portfolios, i.e., all portfolios can use the same platform for the specified capability.

Intake: The Software Factory Model’s Intake process is the initial evaluation and categorization of software development requests. Upon receipt of a software request, the Intake Process initiates a crucial decision-making procedure within the SWF Model, determining which ‘play’ – Commodity, Customized Commodity, or Highly Different – best serves the project’s needs. 

Low Code/No Code Development: Minimal coding platforms for rapid software creation. Low Code/No Code Development refers to software development platforms that allow users to build applications using graphical interfaces with minimal or no programming required. These platforms enable rapid creation and deployment of apps by dragging and dropping pre-built modules, often making development accessible to non-technical users. Low code may require basic coding for complex functions, while no code offers a completely code-free setup. 

Native App: Software designed for a specific platform or device. 

No VA Data Play: Estimated to take 12-18 weeks. This play is for products that do not involve VA Data and therefore do not require an ATO. If a product is determined to be “No VA Data” it means a vendor will not be require to get a VA ATO, as the product does not use VA data that requires these security documents. This play requires validation that the requested product does not contain Federal Information.

Platform as a Service (PaaS): Cloud services allow application development without complex infrastructure.

Platform as a Service (PaaS) Factory: In the Software Factory Model, the PaaS Factory provides a cloud-based framework where developers can configure, run, and manage applications without the complexity of maintaining the underlying infrastructure. It represents a “Customized Commodity” play decision, offering a slightly customized solution that enables developers to adapt and extend pre-built services to meet specific application needs while maintaining the efficiency of a standardized platform.

Play Decision: In a Software Factory context, a “Play Decision” refers to the process of evaluating a software request to determine the best course of action or approach to take in development. It assesses whether to use a standard solution (Commodity), a slightly customized solution (Customized Commodity), or to develop a completely new and unique solution (Highly Differentiated) based on the specific needs and requirements of the project.

Product Line Management (PLM): Estimated to take 12-18 weeks. This play is for products that do not involve VA Data and therefore do not require an ATO. If a product is determined to be “No VA Data” it means a vendor will not be require to get a VA ATO, as the product does not use VA data that requires these security documents. This play requires validation that the requested product does not contain Federal Information.

Quality Assurance (QA): A way of preventing mistakes and defects in manufactured products and avoiding problems when delivering solutions or services to customers. 

Risk Management: Process of identifying and addressing development risks. 

Software: Core programs enabling computer task execution.

Software as a Service (SaaS): Applications hosted online, accessible without local installation.

Software Factory (General): Environment applying standardized processes to software development for enhanced efficiency and predictability.

Software as a Service (SaaS) Factory: The SaaS Factory is a component of the Software Factory Model that specializes in delivering Software as a Service solution. As a standard solution, it aligns with the Commodity Play Decision, which leverages pre-existing, off-the-shelf software applications to meet operational needs efficiently and with rapid deployment. This approach allows for a streamlined delivery process that is both cost-effective and time-efficient, catering to standard requirements without the need for extensive customization.

Stakeholder Engagement: Active involvement of stakeholders in development.

SWF Intake: The Software Factory Model’s Intake process is the initial evaluation and categorization of software development requests. Upon receipt of a software request, the Intake Process initiates a crucial decision-making procedure within the SWF Model, determining which ‘play’ – Commodity, Customized Commodity, or Highly Different – best serves the project’s needs.

SWF Utilities: Are a set of shared tools and services that provide essential and common IT capabilities to Product and engineering teams and developers via standardized tooling, at a lower cost than acquiring a new COTS, SaaS, or Custom solution. Utilities are easily discoverable, documented in a standard format and enabled via self-service when possible.

Technical Debt: Future costs from temporary solutions. 

UI (User Interface) Design: Design focused on aesthetics and smooth user interaction.

UX (User Experience) Design: Design aimed at creating products that provide meaningful and relevant experiences to users, encompassing aspects of branding, design, usability, and function. 

 

VA IT Product Line: A functional grouping of like Business Services (IT Systems/Products) intended to support a specific VA Capability or Function. Product Lines respond to validated mission requirements necessary to achieve a desired business outcome for VA. 

VA’s Software Factory Model (SWF): A software factory, in general, is an environment applying standardized processes to software development for enhanced efficiency and predictability. The Department of Veterans Affairs (VA) Software Factory Model (SWF) is a specialized framework developed by the VA’s Office of Information and Technology (OIT) for better, faster, and safer software development and delivery. This model is designed to address the unique needs of VA and its mission to serve Veterans. 

VA Sponsored FedRAMP Play: Estimated to take 1.5 – 2 years, in this play the product needs VA Sponsorship for their FedRAMP Authority to Operate. In this play, the desired product does not currently have a FedRAMP ATO nor a VA ATO. In this play, the VA will be the sponsoring agency for a FedRAMP ATO. 

Version Control: System for tracking and recalling file changes over time.