Understand the technical landscape

The partner’s technical landscape will impact how you plan for the future “to be” state. You will want to work with your engineering lead to ensure that you have a solid understanding of your partner’s current systems and processes, and the implications for defining a path forward. Understanding the technology they’re currently using and their interdependencies will help your team identify factors that complicate or constrain your options. Understanding their security and privacy requirements and the processes they rely on to remain in compliance will help your team plan ahead and identify opportunities to “shift security left” to increase efficiency. And understanding the resources and skill sets they have available will allow you, your engineer, and your acquisitions lead to consider strategies for maintenance and sustainability.

Considerations: A good understanding of the technical landscape...

• Identifies key technical and security risks, requirements, and/or restrictions that will influence your planning for the future "to-be" state

• Identifies the current digital/physical systems used to carry out Continuous Integration (CI) processes

• Evaluates the current tech team capacity to maintain and support the product post-build to determine an appropriate vendor acquisition strategy

Activities: How to get there

Technical discovery will typically be led by engineering, but product managers should support this work and understand the implications of the findings.

• Develop a system map that outlines the front-end and back-end systems that are involved in delivering the “as-is” process, as well as their interdependencies.

• Evaluate the security considerations existing within the “as-is” process, including

  • Organizational security requirements
  • FedRAMP level of the system
  • Existence of Personally Identifiable Information (PII)

• Conduct an assessment of the partner’s DevSecOps maturity to understand which practices and processes are understood and implemented, and which will need to be introduced.

• Discuss ATO implications with the OCIO and CISO to assess its possibility.

• Consider implementing a “Hello World” prototype to validate the path to production.

• Assess the cost and time investment put into maintaining existing systems.

• Take inventory of the tools, people, and skills that exist within the organization, and engage your acquisitions lead to review contracts.

Incorporation: What to do next

• Report out on assessment in order to facilitate a decision amongst stakeholders on the best available solutions.

• If gaps in knowledge or confidence exist, timebox a quick prototype (ideally with a real use case or data) to further assess technical feasibility.

• Draw on your research to develop a technical roadmap that will help your partner reach their desired future state.

Resources

• 18F only, How to assess DevSecOps maturity [1]: An example of a checklist developed to help an agency assess technical work from vendors, but that can also be used to assess the agency’s DevSecOps maturity level.

• How to assess DevSecOps maturity [2]: A description of the expectations, scope of responsibilities, maturity model, and metrics associated with any DevSecOps platforms, such as change management, logging, credentials, testing, backup and data lifecycle maintenance, etc.

• 18F only, What is an ATO: An introduction to ATOs (Authority to Operate), why we need them, and the key people and components involved in an ATO.

• 18F only, How to validate the path to production: How to test an agency's ability to host and deploy prior to a contractor starting