Attachment 4 - Detailed Solutioning Document Template.pdf

Acquisition Sensitive – Do Not Forward

Department of Veterans Affairs

[DMND <DMNDName>] [DMND<DMNDNumber>]

Detailed Solutioning Document

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

[Date]

Detailed Solutioning Document Template V1.3 January 2024 1

Document Version History The document version history will be used to track document changes throughout the cycle of the capability planning process. When changes are made, please provide the version number, name 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 <Name and organization of the person updating>

Initial Draft

V0.2 <Name and organization of the person updating>

<Example: Incorporated feedback from MM/DD/YY meeting.

§2 Included/update XYZ.>

Table 1: Document Version History

V1.3 January 2024 2

Table of Contents Purpose

1.1 Scope Statement

1.2 Points of Contact

System Status

2.1 Current System

2.2 Use Cases

2.3 Known Issues & Projected Needs

2.4 System Architecture

2.5 High Level Infrastructure Requirements: Responsiveness, Capacity, Availability and

Supportability

Dependencies Review

Roadmap

Risk Review and Recommended Mitigation

Future Recommendations and Next Steps

(Optional) Detailed Cost Estimate (Level 2)

Appendix A: References

Appendix B: Acronyms

Note:

• Template instructions in italics (including in header) should be deleted upon completion of the document.

• All fields should be completed. If information is not available for a certain field, an explanation should be provided.

V1.3 January 2024 3

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

This document will address:

• The current status of the product, including high-level architecture, VA System Inventory (VASI) information correctness, Authority to Operates (ATO) status, Technical Reference Model (TRM), authentication, and Section 508 conformance statuses.

• Provides high-level target architecture with 8-year product roadmap

• High-level infrastructure requirements, which includes responsiveness, capacity, and availability

• Outlines the risks/opportunities, potential impact, and proposed mitigation

• Provides cost estimation based on information available at the time of development of

Detailed Solutioning document

• Future Recommendations & Next Steps

1.1 Scope Statement

To gather product information from VASI, product team, Business Owners, Service Now Demand tool, and Business Integration and Outcome Services. Analyze information gathered from product stakeholders and develop a high-level architecture for <system name>.

1.2 Points of Contact

In this section, provide the name, title and department for the business owners, account managers, portfolio directors, solution leads, and IT personnel who will provide oversight for this Detailed Solutioning Document, and additional stakeholders needed to provide input for this document. Include any individuals who contributed to the content in this document.

Name Title & Office Role First Name, Last Name Title, Office Product Line Manager- <Product

Line> First Name, Last Name Title, Office Product Owner First Name, Last Name Title, Office IT Product Manager (if different from

Product Owner) First Name, Last Name Title, Office Business Owner First Name, Last Name Title, Office Technical Expert, Backup, etc.

First Name, Last Name Title, Office Technical Expert, Backup, etc.

First Name, Last Name Title, Office Information System Security Officer

(ISSO)

First Name, Last Name Title, Software Product

Management (SPM), Corporate Intake & Solutioning (CIS)

Intake Lead

First Name, Last Name Analyst, SPM CIS Intake Analyst

V1.3 January 2024 4

First Name, Last Name Architect, SPM CIS Intake Architect First Name, Last Name Cost Estimator, SPM Cost Estimator First Name, Last Name Title, Business Integration and

Outcome Services (BIOS) BIOS Representative

First Name, Last Name Title, BIOS Business Relationship Manager

Table 2: Points of Contact

System Status

2.1 Current System

In this section, copy and paste the Current System section from the Technical Analysis (TA), if available.

<System name> (<VASI #>), under the <Product Line name> Product Line, <detail information regarding the system in its current state>

2.2 Use Cases

Provide an overview of how the system is utilized and high-level operational process flow if available from the product team. See Business Use Cases from the Technical Analysis (TA) to provide continuity, if applicable.

2.3 Known Issues & Projected Needs

Capture current operational issues known about the system, the impact the issue is causing, and potential/planned mitigation. Include information regarding any projected or forecasted needs that may/should be scoped for a future project or enhancements with applicable timelines, if available.

2.4 High Level System Architecture

Provide an executive-level diagram and supporting text defining a logical framework for the system, to include available components which are/will be leveraged (e.g., existing cloud storage, SaaS, enterprise-level data aggregators, etc.) and VA-required components (e.g., IAM services) used. The supporting text should explain expected interface/integration points with other systems both within and external to the VA. A description of the data to be exchanged and protocols (where known) should be explained. If portions of the diagram contain no content, indicate “None”.

The diagram should conform to the format shown in Figure 1. Where more than one possible implementation for a component exists, show logical names only and use the table that follows to identify optional systems and services. For example, if the architecture includes an interface with a financial management system, show “Financial Management” in the diagram, and use the table to call out specific instances, such as FMS or FMBT, with the associated availability status.

A separate To-Be (Figure 2) may be included if the system is being replaced or there are significant changes planned which would be more consumable in a separate diagram from the As-Is state.

V1.3 January 2024 5

The high-level architecture diagram in Figure 1 shows the System of Interest (SOI) in the center, and its associated VA system interfaces are listed in the right side of the SOI, external interfaces are listed on the left side of the SOI. System users and the use case are listed on the top of the SOI. The high-level architecture also covers the business capabilities, software capabilities and data store information.

Domain-Specific (i. e., Clinical, Corporate, Benefits, Memorials) Platforms/Systems

[Logical System Name]

System 1

System 2

System n

Legend

Available (1)

External (non-VA) Systems

System b

Internal System 3

Under Development

Planned

Out of Scope

Systems Replaced by <subject solution>

Internal System 2

Internal System n

No Integration Planned with <subject solution>

External System

Information Flow (Transport method)

Information Flow (Transport method)

In fo rm at io n

Fl ow

(T ra ns po rt m et ho d)

In fo rm at io n ns po rt m et ho d)

Function 1

Function 4

Function 7

Function 2

Function 5

Function 8

Function 3

Function 6

Function 9

Business Function Supported

Outbound from <Capability solution> Inbound to <Capability solution>

Inbound/outbound

Information Flow (Transport method)

Internal System 1

Systems Replaced (as needed)

Business Functions Supported

External System n

Notes 1- Available means connectivity between the systems has been established and some message exchanges have been tested. Remaining messages need completion.

External System

Platform a

External System

VA Enterprise- Level Systems

Figure 1: Logical High-Level Architecture

V1.3 January 2024 6

To-Be figure to be included only if the system is being replaced or there are significant changes to note. Else, include planned efforts in Table 1 with applicable Legend coloring. Include a separate System Interfaces table if it will assist in

Domain-Specific (i. e., Clinical, Corporate, Benefits, Memorials) Platforms/Systems

[Logical System Name]

System 1

System 2

System n

Legend

Available (1)

External (non-VA) Systems

System b

Internal System 3

Under Development

Planned

Out of Scope

Systems Replaced by <subject solution>

Internal System 2

Internal System n

No Integration Planned with <subject solution>

External System

Information Flow (Transport method)

Information Flow (Transport method)

In fo rm at io n ns po rt m et ho d)

In fo rm at io n ns po rt m et ho d)

Function 1

Function 4

Function 7

Function 2

Function 5

Function 8

Function 3

Function 6

Function 9

Business Function Supported

Outbound from <Capability solution> Inbound to <Capability solution>

Inbound/outbound

Information Flow (Transport method)

Internal System 1

Systems Replaced (as needed)

Business Functions Supported

External System n

Notes 1- Available means connectivity between the systems has been established and some message exchanges have been tested. Remaining messages need completion.

External System

Platform a

External System

VA Enterprise- Level Systems

Figure 2: Logical High-Level Target (To-Be) Architecture

Following is listed as the interfaces to <system name or acronym> and is collected from information existing in VA System Information and product documentation provided by the product team:

System Name

VASI

ID Interface Description Current/planned. Unidirectional/bidirectional to/from

<system>, explain data exchanged, include any intended future changes

Table 3: Software Interfaces

V1.3 January 2024 7

The following table lists all the identified software capabilities supporting the business functions:

Software Capabilities Description For ex – Workflow Management, Document Management, Business Rules Management

Provide a description for the software capabilities with respect to the product’s business function

Table 4: Software Capabilities

The following table shows alignment of the logical architecture-supported business functions with VA’s Enterprise Architecture Business Reference Model (EA BRM).

EA BRM

Alignment to Business

Functions Business

Functions Description Enter here relevant EA

BRM

functions at the lowest level; e.g., 1.1.1.1.1

Provide Member Access

Enter here the supported Business Functions from the logical high-level target architecture (Figure 1)

Provide a description for each supported Business Function

Table 5: Business Functions

V1.3 January 2024 8

2.5 High Level Infrastructure Requirements:

Responsiveness, Capacity, Availability and Supportability

Provide a summary of defined high-level responsiveness (performance/efficiency), capacity (workload), and availability (reliability) requirements. Document the current application’s requirements in the table below; all Descriptions should contain content.

Question Criteria Description How much time should/is the system be available (alternatively, how much downtime is acceptable due to an unplanned outage)?

99% availability (< 7.3 hrs downtime per month) 99.5% availability (< 3.65 hrs downtime per month) 99.9% availability (< .75 hours downtime month) Downtime should be measured per month in total service unavailability.

How soon should/does the system recover to full operation after a full hosting facility disaster or outage?

(Recovery Time Objective – RTO)

< 30 days < 72 hours < 12 hours Other (please specify)

What is the maximum amount of data that can be lost after disaster event?

(Recovery Point Objective – RPO)

< 24 hours < 2 hours

Should/Does the solution allow for planned, multiple-hour maintenance periods and if so when?

Anytime After-hours/weekend Never

What is the expected average and peak concurrent user count?

Please specify expected range

What is the current/expected total registered user count?

Please specify expected range

How many transactions will/does each average user perform each hour that are low, medium, and/or high-volume types (up to three answers can be provided)?

High volume is greater than 50MB of payload size per transaction.

Medium volume is from 1MB to 50MB.

Low volume is less than 1MB.

Or please specify expected range.

What are the current/anticipated peak workload times?

Business day (please specify) Erratic Peak (please specify) No Peak (small number of users on system)

How much annual end-user growth is expected?

Please specify expected range and years.

How much annual transaction growth is expected?

Please specify expected range and years.

What kind of information is/will be stored?

Please specify. Example:

Structured Data Stored in Databases (e.g. Oracle, SQL, VistA), Long Text

V1.3 January 2024 9

Documents, Objects (picture, graph), Large Attachment (images, documents)

What is the estimated storage requirement per business transaction?

Small (less than 100KB per transaction) Medium (from 1MB to 5MB per transaction) Large (greater than 5MB per transaction) Alternatively, specify storage requirement per month

What kind of search capacity is supported/required?

Light (less than 10 per hour) Medium (11-1000 per hour) Heavy (greater than 1,000 per hour)

What is the/will be the deployment locations?

Choose one or more of:

Local Regional Enterprise Data Center Internal to VA External to VA (e.g. cloud) Desktop Client Mobile Client

In addition to end-user transaction load, is there a need for heavy workload consumption periods?

Mark as N/A or describe heavy workload and specify workload time, example: end-of-month batch report processing and/or transmission

How many other applications does/will this solution interact with (e.g., transactional application interface)?

Please specify expected quantity (or range)

If not currently in the cloud, does/will the system be capable of cloud hosting as outlined in VA Directive 6517?

Yes/No

What TRM components and Operating System(s) does/will the solution be run on?

List all including version number and TRM status.

If none, then N/A

If the system does/will involve the use of Software-as-a-Service (SaaS), what is product status within the Digital VA Product Marketplace?

Please specify product name and status. N/A if no SaaS products leveraged.

What is the security determination (business impact) for the data that is/will be processed or stored within this project?

FISMA Low – limited business impact FISMA Moderate – serious business impact FISMA High – severe or catastrophic business impact

TBD

How does/will the system authenticate users?

Identify Access Management Single Sign-On (IAM SSOi) Active Directory Direct PIV Other, please specify

V1.3 January 2024 10

What is the status of the Authority to Operate (ATO)?

Authorization to Operate (ATO)/Approved Expired In progress No security boundary required

Does/Will the application process/store VA 6500 sensitive data (e.g. PII, PHI, financial, acquisition sensitive, VA infrastructure sensitive)?

Please briefly describe. If unsure, please consult the system ISSO or host facility ISSO for guidance in answering this question.

What is the status of Section 508 conformance?

Conformant Unassessed Non-conformant

Table 6: High Level Infrastructure Requirements

Dependencies Review The purpose of this section is to indicate the sequencing and relationships between external activities necessary to complete a given set of functions per the most recent capability roadmap documents.

How to Populate this Section Populate the table provided below:

• Identify any governing or authoritative influences (Congressional or legal requirements), including associated deadlines for delivery or provision of service.

• Address any political interests or implications associated with development/deployment.

• Identify any internal interfaces, joint, or external interoperability dependencies.

Note: Dependencies can come in the form of software/solution, system/network, and business implementation. The strategic level technical assessment document includes a summary of strategic level service architecture which captures software/solution dependencies and additional analysis to identify system/network dependencies.

Table 7: Dependencies

Roadmap Populate the roadmap information in VASI – SAM view for the product and verify with the product SME if there is any change to the existing disposition statuses. Document the updated

Capability Dependency Constraints Stakeholder

Type Key

Stakeholders Name of Capability

Describe dependency

Describe Constraints

Internal or External?

List names of stakeholders

Name of Capability

Describe dependency

Describe Constraints

Internal or External?

List names of stakeholders

V1.3 January 2024 11 status changes in the comments section. Engage the system owner and technical stakeholders to forecast work needed to address areas of non-compliance. If any difference found from what is currently documented in VASI, add action to §6

Key:

Modernize Maintain

Retire Decommission Modernize Encapsulate Refactor Replace Rehost Replatform Sustain Enhance

Product Disposition Roadmap:

Fiscal Year Quarter

Disposition Status Comments

2024 Q1

2024 Q2

2024 Q3

2024 Q4

2025 Q1

2025 Q2

2025 Q3

2025 Q4

2026 Q1

2026 Q2

2026 Q3

2026 Q4

2027 Q1

2027 Q2

2027 Q3

2027 Q4

2028 Q1

2028 Q2

2028 Q3

2028 Q4

2029 Q1

2029 Q2

2029 Q3

2029 Q4

2030 Q1

V1.3 January 2024 12

2030 Q2

2030 Q3

2030 Q4

2031 Q1

2031 Q2

2031 Q3

2031 Q4

2032 Q1

2032 Q2

2032 Q3

2032 Q4

Table 8: Product Disposition Roadmap

Risk Review and Recommended Mitigation To help ensure the success of the final solution, it is important to proactively monitor risk. In this document, risks include internal and external events that could affect any product objective including costs, schedule, or technical in a positive or negative way. This section outlines the risks/opportunities, potential impact, and proposed mitigation as evaluated by the Corporate Integrated Intake Team (CIIT).

In this section, identify any risk (negative) or opportunity (positive) associated with this capability, possible impact, and possible risk mitigation using the following matrix. Risks can be related to business, organizational, technological, execution/implementation, complexity, or operational.

# Risk/Opportunity Potential Impact Risk Mitigation 1 Example: RISK: Example: There is a significant Example: Remap MySQL to

Product Roadmap - Disposition Statuses & Definition (for reference only) Migrate - Migrate system/data as-is to another platform (e.g., hybrid, VAEC), or another infrastructure with no new capability, but can include any modifications needed to accommodate the new hosting location.

Modernize (DME)- Reengineer/Redesign/Update (e.g., to address issues in Legacy system or adapt Legacy system to other more modern platforms / infrastructure). This includes modifications needed to subsume capability from another system or activating an existing capability that will subsequently perform this inherit function.

Maintain (Sustainment) - Continue to operate system with no major changes or migrations. Includes break/fix maintenance activities to comply with 508 or existing security requirements would still be possible for a system with this disposition.

Retire- Continue to manage system ONLY as emergency backup; In coordination with all stakeholders, validate that the system can be turned off, and get approval to do so; initiate planning for decommissioning Decommission- Turn system off; Initiate system disposal activities, to include removing system software from system infrastructure; unplugging/sanitizing/dispositioning system hardware; archiving data; canceling maintenance agreements and reassigning personnel; VASI Production Status changes to “Inactive”.

V1.3 January 2024 13

Database uses MySQL requiring yearly ISO approval.

administrative burden to continue ISO approval and the current ISO approval expires in 2017 and will not be approved again.

Microsoft propriety SQL. This action would curtail deployment and place the project into a development status. Application deployment may be suspended until testing is completed in

FY2020

Table 9: Risks & Opportunities

Future Recommendations and Next Steps This section will contain recommendations from CIS, Business and Portfolio. Display in order of priority when applicable.

• System Owner to communicate/track product information within VA Systems Inventory (VASI) via the Update Form.

• Business users or Project Manager to submit a SNOW Demand for further analysis of a new request or enhancement.

If solution is not conformant with Section 508 requirements: <Role> to contact Section 508 Office to conduct a Section 508 Audit.

If solution is not compliant with authentication requirements: ISSO and System Owner to engage Identity and Access Management team to address authentication needs. See the PIV Compliance SharePoint site for additional information regarding potential authentication methods.

Include below recommendation regarding ATO when applicable:

• ISSO to engage ATO/Enterprise Mission Assurance Support Services to initiate actions toward updating/implementing/assessing ATO via the Unified System Registry Intake.

• System Owner to review the Authority to Operate (ATO) status information in VA Systems Inventory (VASI) regularly to ensure that system has an active ATO (including security boundary).

• ISSO to engage proactively with the ATO team before ATO expiration to ensure the ATO is renewed and in place before expiration.

• ISSO to ensure products platform ATO is active before deployment if re-platforming.

(Optional) Detailed Cost Estimate (Level 2) 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 Analyst to populate the Cost Estimation Questionnaire, but the Cost Estimation Analyst is responsible for the creation of an estimate.

https://dvagov.sharepoint.com/sites/OITEPMOAESVASI/SitePages/VASI-System-Update-Form.aspx https://vaww.section508.va.gov/Procedures.asp#intake https://vaww.section508.va.gov/Procedures.asp#intake https://yourit.va.gov/va?id=sc_cat_item&sys_id=f4bffc211b18181412979796bc4bcb47&cat_id=a7ff40ec1b352850a25d0d08ec4bcb6f&catalog_id=1e105b9c1b062010a25d0d08ec4bcb03 https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/PIV%20Compliance/PIV%20Compliance.aspx?OR=Teams-HL&CT=1656012404796&params=eyJBcHBOYW1lIjoiVGVhbXMtRGVza3RvcCIsIkFwcFZlcnNpb24iOiIyNy8yMjA1MDEwMTAwOSJ9 https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/PIV%20Compliance/PIV%20Compliance.aspx?OR=Teams-HL&CT=1656012404796&params=eyJBcHBOYW1lIjoiVGVhbXMtRGVza3RvcCIsIkFwcFZlcnNpb24iOiIyNy8yMjA1MDEwMTAwOSJ9 https://leaf.va.gov/NATIONAL/103/cybersecurity_request_portal/?a=newform

V1.3 January 2024 14

Once a cost estimate is generated by the Cost Estimation Analyst, the Intake Cost Estimation Analyst will import Table 1 from the CE Tool.

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

A version of the document without the cost estimate will be uploaded to the public-facing DMND Documents (No Cost) SharePoint folder, with naming convention “CIS_DetailedSolutioningDocument_DMND#_DMNDName-NoCE”. The Intake Analyst should add the following statement to the NoCE version of the document:

Contact OIT Business Integration Outcome Service (BIOS) for a version of this document with the Cost Estimate.

The Cost Estimate for this initiative is displayed in Table 1.

To prepare the final version with cost estimate, the Intake Analyst will forward to the Intake Lead with the file name “DetailedSolutioningDocument_DMND#_DMNDName-CE”. The Intake Lead will upload the full and final version of the DSD with the cost estimate to a SharePoint location with restricted access and submit the document to BIOS and/or Business Owner via email containing a link to that folder.

mailto:VAITAMIntake@va.gov

V1.3 January 2024 15

Table 10: Cost Estimate (Millions $)

This is for internal VA use only and is not intended to create or contribute to any contractual estimate for services or other legal obligation. This is a high-level cost estimate, driven by historical VA cost estimating data and other assumptions.

V1.3 January 2024 16

Appendix A: References This section contains a list of supporting documents and references.

• SNOW Demand <name, number, link>

• Reference documents provided by the product team are in the “Analysis <link>” folder:

o <Document name>

• Visio version of the High-Level architecture is in the “Detailed Solutioning <link>” subfolder within the DMND folder in CIS SharePoint.

• < SharePoint links, links to additional resources as applicable>

• VASI <link>

• TRM: <link(s)>

• Digital VA Product Marketplace- SaaS Catalog

• PIV Compliance https://digital.va.gov/marketplace/saas-catalog/ https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/PIV%20Compliance/PIV%20Compliance.aspx?OR=Teams-HL&CT=1656012404796&params=eyJBcHBOYW1lIjoiVGVhbXMtRGVza3RvcCIsIkFwcFZlcnNpb24iOiIyNy8yMjA1MDEwMTAwOSJ9

CLARK, SARRAH E. (MIND COMPUTING INC)

Epics are not applicable to DSD efforts.

V1.3 January 2024 17

Appendix B: Acronyms This section contains a comprehensive list of acronyms referenced in the document.

Acronym Meaning ATO Authorization to Operate BIOS Business Integration and Outcome Services BRM Business Relationship Manager CE Cost Estimate CIIT Corporate Integrated Intake Team CIS Corporate Intake & Solutioning DTC Digital Transformation Center EA BRM Enterprise Architecture Business Reference Model FMBT Financial Management Business Transformation FMS Financial Management System iFAMS Integrated Financial and Acquisition Management System ISSO Information System Security Officer POC Point of Contact SaaS Software-as-a-Service SME Subject Matter Expert SPM Software Product Management TRM Technical Reference Model VA Veteran Affairs VASI VA System Inventory VistA Veterans Health Information Systems and Technology Architecture

Table 11: Acronyms

Add/remove acronyms as applicable. Include all acronyms included elsewhere within this document.

V1.3 January 2024 18

Template Version History Date V# Notes

May 2023 0.1 Template initiated from prior PAD 2 template.

Sept 2023 1.0 §1 Standardized text for ‘Purpose’.

§2, 2.1 Added guidance.

§2.2 Included Software Interfaces table.

§2.3 Removed unapplicable sections.

Formatting standardization of text and tables.

Nov 2023 1.1 §1.2 Added PLM and System Owner as required.

§2 Included Product Line is standard template text.

§2.2 Added guidance regarding To-Be architecture when applicable.

§2.3 Relocated Known Issues from §5 to §2 sub-section §2.4 Added questions regarding ATO, DTC status, and authentication. Removed questions not applicable to DSD efforts.

Rephrased for as-is scope.

§6 Added standard template text for PIV Compliance.

Added standard reference material.

Jan 2024 1.3 §1.2 Added more detailed standard POC roles and moved Intake POCs from §8 to consolidate stakeholders.

§2.5 Added Section 508 question.

§6 Updated language and added links.

§Appendix A consolidated SNOW link into References Appendix.

Added template space to capture additional applicable links.

Table 12: Template Version History