Attachment 3 - Technical Assessment Template.pdf

Department of Veterans Affairs [Request Name] [Request Number]

Corporate Intake Technical Assessment

Corporate Intake & Solutioning (CIS) Corporate Services Portfolio (CSP) Software Product Management (SPM) Office of Information and Technology (OIT)

[Date]

Acquisition Sensitive - Do Not Forward

DMND000XXXX Demand Name Here 1

Document Version History The document version history will be used to track document changes throughout the cycle of the Intake process. When changes are made, please provide the version number, name, job title and organization of the person updating, version date, and a description of the basic changes made by the respective version of the document.

Version Number

Person Updating

Version Date Version Description

V0.1 CIS Intake Initial Draft V1.0 CIS Intake Review and updated per CIS Team feedback V1.1 CIS Intake 1/24/2024 Added a section to capture CISD team’s Demand discovery and analysis

DMND000XXXX Demand Name Here 2

Contents

1. Intake Technical Assessment Purpose

2. Executive Summary

2.1. Business Need

2.2. Problem to be Resolved

2.3. Corporate Intake & Solutioning (CIS) Team Inputs

2.4. Corporate Integrated Intake Team Inputs

2.5. Recommendations:

2.6. Consequences of Inaction

3. Technical Assessment

3.1. Current System

3.1.1. Current Veterans Affairs System Inventory (VASI) System

3.1.2. Current Product Architecture

3.1.3. Security & Standards Compliance

3.1.4. System Dependencies

3.1.5. Business Dependencies

3.2. Technical Assessment of Proposed Play

3.2.1. Five Play Compliance

3.2.2. Reuse

3.2.3. SaaS Solutions

3.2.4. COTS/GOTS

3.2.5. No Code/Low Code Solutions

3.2.6. Custom Development Solutions

3.2.7. Containerization of Legacy Systems

3.3. Guardrail Compliance

3.4. Risk Analysis

3.5. Assumptions

4. Rough Order of Magnitude (ROM)

5. Appendices

5.1. Assessment Team Points of Contact

5.1.1. Key Points of Contacts

5.1.2. Intake and Analysis POCs

5.2. Epic and Technical Assessment Artifacts

5.3. Acronyms List

5.4. Business Use Cases

5.5. Template Version History

DMND000XXXX Demand Name Here 3

DMND000XXXX Demand Name Here 4

1. Intake Technical Assessment Purpose Purpose of this assessment is to review the customer demand request in collaboration with a core team consisting of business, Corporate Intake & Solutioning (CIS), Corporate Portfolio’s Technical Subject Matter Experts (SMEs), and appropriate Office of Information Technology (OIT) groups.

The analysis involves aligning the architecture, solution, or product against the Enterprise Architecture and focuses on identifying the best fit Software Factory (SWF) play and Product Line (PL) ownership for a given request. Detailed design and solution management will be the responsibility of the assigned SWF and PL.

Objective of the document is to provide play recommendations from one of the five software factory plays. The five Software Factory plays are:

1) Reuse – Is there an opportunity to reuse an existing solution to address the request

2) SaaS – Software as a Service

3) COTS/GOTS – Commercial-off-the-shelf/Government-off-the-shelf

4) Low-Code/No-Code (Platform solutions such as PEGA or UiPath)

5) Custom Application (High-Frequency/ Differentiated)

6) Containerized Legacy Application (Low-Frequency/Differentiate)

This TA is for DMDN # and the product line aligned to this DMND.

2. Executive Summary

2.1. Business Need

In this section, the analyst should tailor these paragraphs to provide a high-level summary of the Technical Assessment. This will be equivalent to the Bottom-Line Up Front (BLUF) slide in the assessment deck. The executive summary should be a brief overview of this document that emphasizes the business impact of the preferred solution. This section should not exceed half a page. Detailed content should be elaborated on in following sections within document.

How to Populate this Section – For CIS Staff

Business Need to be completed by Business Analyst: high-level summary of the sponsor’s problem and customer’s objectives.

1. Discussion and Recommendations to be completed by Solutions Architect: high-level summary of CIIT recommendation.

For direct TA-to-DSD efforts, state the following:

To better serve the intake demands and IT requests for Corporate Portfolio, CIS team has a need to understand the software components and technical specifications of the corporate products.

DMND000XXXX Demand Name Here 5

A document called a Detailed Solutioning document will be developed for products in collaboration with product lines Point of Contacts (PoCs). Detailed Solutioning documents will help CIS team to create a baseline for the products and projected roadmap which will enable us to assist with better solutioning that are in alignment with the product specifications and roadmap.

2.2. Problem to be Resolved

For direct TA-to-DSD efforts, state the following:

CIS team is requesting documentation for all corporate products including <product name>, to develop a detailed solutioning artifact. This artifact will document the as-is status of the product information and create a baseline for each product that can be used for strategic planning and future acquisition purposes of corporate products.

2.3. Corporate Intake & Solutioning (CIS) Team Inputs

In this section, include a include a summary of discussions from the Demand triage and discovery meetings. Information and requirements gathered from these meetings.

2.4. Corporate Integrated Intake Team Inputs

In this section, include a include a summary of discussions from the Corporate Integrated Intake team meetings conducted with CIIT members, any impacts it had on the Play Decision. Include feedback from all the voting members.

2.5. Recommendations:

Play Decision:

For direct TA-to-DSD efforts, state the following:

We recommend a detailed analysis of the product to produce a Detailed Solutioning Document (DSD) to support CIS and BIOS team with strategic planning and solution support.

Product Line Alignment:

2.6. Consequences of Inaction

In this section detail the consequences to the Veteran, the VA, and applicable mandates and standards which are not met if this solution is not implemented.

Use this section to describe the current state and its future implications if no action is taken. This alternative is always an option and stakeholders may opt for this route; however, you should be able to identify certain risks or consequences of choosing to take no action.

Type of Consequence Consequences List Legal Compliance VA could possibly not meet the Office of Inspector General (OIG) rulings to add the new six-year timely filing parameters on insurance filing limits.

Impact to Veterans Failure to file within a timely manner could cause insurance claims to be rejected. (Example only) Guardrails not met None known at this time

DMND000XXXX Demand Name Here 6

Strategic Compliance The current manual methods of handling data are not in compliance with current VA technology directives.

Technical Debt None known at this time Schedule None known at this time Monetary cost Refer Rough Order of Magnitude (ROM) analysis document Number of Veterans impacted Veterans who fail to file within time limits; approx. # not known at this time Impact to VA employee None known at this time Number of Employee impacted VHA Finance staff; approximate number not known at this time

Table 1 - Examples of Consequences

Examples provided above, to be updated as applicable to the Demand.

3. Technical Assessment This section provides additional details of the Technical Assessment findings, as well as recommendations, VIP compliance/alignment gaps satisfied, and a high-level roadmap to achieve the recommendations, if requested.

3.1. Current System

Provide a summary of the current system; include information about that is not covered in the appliable sub-sections.

3.1.1. Current Veterans Affairs System Inventory (VASI)

System

VASI link

3.1.2. Current Product Architecture

Provide additional architectural Diagrams of the product, if avaailable. Add description of the strengths and weaknesses of the current product. If not available, include the following statement:

This information is not currently available and is recommended to be defined in a Detailed Solution Document.

3.1.3. Security & Standards Compliance

Provide any reports of cybersecurity weaknesses in the current system. Include any areas that are not incompliance with current VA standards. e, 508, 2FA, MOU/ISA, ERA & ATO status

3.1.4. System Dependencies

In this section, describe known upstream/downstream interfaces/systems that may be impacted by this request.

S. No System Name VASI ID Product Line Dependency Type Upstream, Downstream

DMND000XXXX Demand Name Here 7

Table 1 - System Dependencies

3.1.5. Business Dependencies

In this section, describe known programmatic, business process, project dependencies

S. No Dependency

Table 2 - Business Dependencies

3.2. Technical Assessment of Proposed Play

3.2.1. Six Play Compliance

The sections below need to be filled out for all intakes. In the sub-sections below, provide an analysis of the applicability of the solutions in analysis to each of the 5(Five) software plays.

In this section describe which software factory play(s) is/are being proposed

No. Play Description

1. Reuse Explore reusing an existing technology solution (pre-existing APIs/Services vs legacy). Analysis should explore if reuse meets needs or can be expanded to meet needs.

2. SaaS/XaaS Software as a Service (SaaS) Anything as a Service (XaaS)

Improving access and accelerating delivery of SaaS/XaaS solutions is one part of VA’s diversified portfolio goals for developing and deploying more complex digital modernization efforts. When possible, a reuse of SaaS/XaaS should be used for existing and new systems. COTS may qualify as a XaaS if it’s run as a service at the vendor’s location

3. COTS/GOTS –

Commercial-off-the-shelf/Government-off-the-shelf

Explore COTS/GOTS solutions that can be VA Managed. Analysis should explore if COTS/GOTS meets needs or can be expanded to meet needs.

4. Platform as a Service (PaaS) - Low-Code/No- Code (LCNC)

If a SaaS/XaaS solution is not available, then a Low-Code/No-Code solution should be considered.

5. Custom Solution 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.

6. 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.

Table 3 - Proposed Software Factory Play(s)

DMND000XXXX Demand Name Here 8

3.2.2. Reuse

Add any text here to describe this section. Delete the play recommendation section that does not apply to this demand.

3.2.3. SaaS Solutions

Delete the play recommendation section that does not apply to this demand.

Product Comparison

List the potential SaaS products that meets requirements. Refer to SaaS Market Place.

Product Pros Cons

Product Name #1 Product Name #2

Table 4: Potential SaaS Products That Meet Requirement

3.2.4. COTS/GOTS

Add any text here to describe this section. Delete the play recommendation section that does not apply to this demand.

3.2.5. No Code/Low Code Solutions

Add any text here to describe this section. Delete the play recommendation section that does not apply to this demand.

3.2.6. Custom Development Solutions

Add any text here to describe this section. Delete the play recommendation section that does not apply to this demand.

3.2.7. Containerization of Legacy Systems

Add any text here to describe this section. Delete the play recommendation section that does not apply to this demand.

3.3. Guardrail Compliance

In addition to the five plays, new and existing system architecture designs should also follow the guardrails for the Corporate Services Portfolio. A guardrail is a policy or practice for budgeting, spending, and governance of products in the portfolio. Guardrails provide a mutual understanding of the level at which level of the organization IT decisions are made for the products within and across the portfolio.

Guardrails should include measurable and auditable factors.

Note: The Guardrail Compliance listed in the table below are obtained from Health Services Portfolio.

Guardrail Current Solution

New Solution

Cloud Fit Re-Use Compliance Required Minimize or Eliminate Duplication of Data N/A Compliance Required

DMND000XXXX Demand Name Here 9

Deployment Design N/A Enterprise deployment solution Monitoring Strategy Unknown Compliance Required System Deprecation Unknown N/A Zero Trust Architecture Unknown To be determined Cybersecurity Compliant Compliance Required 508 Compliance Non-compliant Compliance Required 2FA Compliant Compliance Required New ATO security boundary required N/A This includes FedRamp if SaaS/PaaS External Solution connection required N/A Security assessment (MOU-ISA) and ESECC external connection establishment External Web Publishing N/A Web hosting and compliance

Table 6 - Guardrail Compliance

Examples above to be updated as applicable to the Demand.

3.4. Risk Analysis

Add any text here to describe this section. The black text in the table below is static and may remain.

Please update the italicized rows with Demand Specific risks.

No. Risk Description Probability (Low, Medium High)

Impact

1 The system is unable to obtain FedRAMP High certification

High HIGH: The system should be able to obtain FedRAMP compliance. E.g., If Enterprise Health is not FedRAMP approved then it will be not allowed.

2 The system is unable to obtain FEDRAMP high certification and is not able be run as a VA Managed instance.

Medium HIGH: If the systems is not able to get a FedRAMP High approved and is not able to be installed as a VA managed instance, then the solution is not viable.

3 The system is unable to get an

ATO

Low HIGH: If the systems is FedRAMP approved then the solution should be able to get the needed ATO. If not, then the solution is not viable

4 The solution is not able to meet the business needs upon implementation

Low Medium: An analysis of the systems indicate that they will be able to meet the business needs. This risk can be mitigated by requesting that needed functionalities are added in near future releases.

5 Cost of solution is unacceptably high

Low Medium: Bulk user licensing cost & associated overheads should be verified for the large-scale deployment.

6 Security - If the new solution does not comply with VA and VHA cybersecurity standards then the solution cannot be implemented.

Medium Medium. Proper measures can prevent a breach of security. All SaaS/IaaS solutions should be FedRAMP approved.

7 Compliance: If the solution does not comply with rules and best practices regarding PHI and PII then the solution cannot be used.

Medium Low: only compliant SaaS/IaaS with secured PHI and PII data are reviewed.

8 Data Privacy & Migration: If the effort to migrate existing data to

Medium Medium: Obtain meta data, sample data, and procedures from each location currently

DMND000XXXX Demand Name Here 10 the archival system is significant then the approach to migrate may need modification during design and/or implementation.

performing the processes now and map a migration solution.

Table 7 - Risk Analysis

3.5. Assumptions

In this section, describe any assumptions made in the development of this document as well as any general assumptions made when conducting the Technical Assessment. Black text in the table below is static.

Assumption # Assumption Description Results if assumption is wrong VA Security Final Solution will need to comply with all VA security policies (such as 6500).

Alternative solutions would need to be evaluated.

Service-Level- Agreements (SLA)

System availability exclusive of planned downtime shall be 99.9 percent for Tier I production systems as defined in the Hosting Scope document.

If not met, system users will have a poor customer interaction.

Funding Future Fiscal Year (FY) Development, Modernization and Enhancement (DME) & Operations and maintenance (O&M) costs will be needed to procure & maintain the solution.

Planned enhancement includes coding change to existing VistA IB module.

The request will be impacted.

Viable Solution Recommended solution will need to meet the functional needs & be acceptable to meet both timeline and budget constraints.

The request would require rescoping or an alternative product selection.

Table 8- Assumptions List

ROM Preparation – Complete the Questionnaire (To be removed after completing and inserting ROM.)

• Will this effort require a new or updated VA ATO?

• Will this effort have any CERNER impact?

• Will a new server hosting environment be required?

• Will this effort result in any SaaS or Software licensing needs?

• Will this effort require new system interfaces (system to system data exchanges) to be developed?

• Do any policies/governance/data dictionaries need to be considered?

• Will the solution add any new types of Personal Identifiable Information or Personal Health Information?

4. Rough Order of Magnitude (ROM) This is a high-level ROM for labor only given products are selected by the Product Line, not HIIT.

DMND000XXXX Demand Name Here 11

This section will contain acquisition sensitive information that should be entered last by the Intake Lead.

The Intake Analyst should work to complete all sections except this section. The Intake Analyst will work with the Intake Cost Estimation Analysts to populate the ROM Questionnaire, but the Cost Estimation Analysts are responsible for the creation of an estimate.

Note: Because cost estimates contain acquisition-sensitive content, once the cost estimate is integrated into the Technical Assessment, only Intake Leads or Intake Cost Estimation Analysts should handle these contents.

Alternate Text for TA without ROM –

This TA does not contain the ROM as it is acquisition-sensitive content and cannot be accessed by all stakeholders.

A version of this TA with ROM updates can be requested from the Demand’s VA intake lead.

DMND000XXXX Demand Name Here 12

5. Appendices

5.1. Assessment Team Points of Contact

5.1.1. Key Points of Contacts

Describe key stakeholders and points of contacts (POCs) as identified during the discovery and kickoff session. This may include program owners. (Use details from epic doc)

Alignment Areas Description

Executive Sponsor and Organization Sponsor Organization:

Business Owner

Product Line Manager PL Manager Product Line Technical Manager Product Line Tech Manager System Owner Technical SMEs and Analysis POCs Key Corporate Portfolio Technical SMEs

Table 9 – Key Stakeholders and Points of Contact

5.1.2. Intake and Analysis POCs

Include intake and analysis POCs in this section.

Role Name Contact

Intake Lead Architect Intake Analyst Intake Cost Estimator

Table 10 – Intake and Analysis Points of Contact

5.2. Epic and Technical Assessment Artifacts

Enter Artifacts link/material here

5.3. Acronyms List

Acronym Meaning

API Application Programming Interface ATO Authorization to Operate COTS Commercial Off the Shelf FedRAMP Federal Risk and Authorization Management Program CIIT Corporate Integrated Intake Team CIS Corporate Intake & Solutioning GOTS Government Off the Shelf HIPAA Health Insurance Portability and Accountability Act of 1996 PaaS Platform as a Service POC Point of Contact

DMND000XXXX Demand Name Here 13

SaaS Software as a Service SME Subject Matter Expert SPM Software Product Management SWF Software Factory VA Veteran Affairs VistA Veterans Health Information Systems and Technology Architecture XaaS Anything as a Service

Table A1 – Acronyms

5.4. Business Use Cases

This section contains a list of use cases if available from the Business.

5.5. Template Version History

Version Date Summary

1 May 2023 Base template built from HIIT template.

2 Aug 2023 COTS/GOTS play decision. Formmating consistency. Standard verbiage within document for DSD with no Play Recommendation. Template version history table.

3 Jan 2024 Added Section 2.3 to capture CISD’s analysis, requirements gathered from discovery ,and recommendations 4 Feb 2024 Updated section label from “Five Play Compliance” to “Six Play Compliance” and fixed

PaaS acronym.