Current state technical discovery
A comprehensive technical discovery template for capturing the current state of a project or product, covering strategy, architecture, operations, security, and infrastructure.
This technical discovery template is intended to capture comprehensive information about the current state of a project or product. It provides discussion topics across the breadth of a product — from product strategy and purpose, to technical execution and operations.
Current state findings
| Project Summary | |
|---|---|
| Customer | Customer name |
| Primary contact(s) |
|
| Summary | Provide a summary of the product, including goals, in the customer’s own words. |
| Next steps / actions |
|
| Meeting cadence | Decide on regular meeting cadence in situations where multiple working sessions are needed. |
| System Overview | |
| Business purpose |
|
| Requirements, use cases |
|
| Application Demo | |
| Sample screen flows, UX models |
|
| Demo of selected portions of the application, if possible |
|
| Team Organization | |
| Organization, roles, numbers of resources, key skills, open positions |
|
| Key development, operations, support roles |
|
| Key Risks and Issues | |
| Risk identification process | |
| Risk log and disposition; how are risks managed and tracked to conclusion | |
| Discuss open key risks and issues | |
Current state limitations
| Current Pain Points | |
|---|---|
| Cost, cost reduction, and maintenance related | |
| Feature needs (time to market, “fit for purpose”) | |
| Customer satisfaction (customer service, product design) | |
| Quality issues (design flaws, bugs, user satisfaction, data integrity) | |
| Operations issues (uptime, recoverability, data loss, scalability) | |
| Technical / business constraints (cost or resource limitations, technical boundaries, security, compliance) | |
Application metrics
| Application Demographics | |
|---|---|
| Number of users | |
| Number of transactions | |
| Scope and importance to organization | |
| Languages used and for what | |
| Geographic deployment | |
| Volumetrics | |
| Numbers of: tables, classes, lines of code, web pages, reports, batch / asynchronous processes, servers |
|
| Current, growth rates, per-client ratios, transaction volumes, interface transaction and data flow volumes, storage | |
Requirements management
| Requirements and User Stories | |
|---|---|
| Looking for well-formed user stories to drive agile maturity | |
| Test strategy/approach (including documentation, test style, policies) | |
| Requirements or user story tracking (including tools, documentation methods) | |
Development practices
| Development Methodology | |
|---|---|
| Development methodology being used, agility | |
| Identification of development standards | |
| Design standards/templates | |
| Package and class naming, coding standards, unit testing, SQL standards, security standards | |
| UI standards | |
| Directory structures / application structure (functional or procedural) | |
| Documentation standards and naming | |
| Testing and other quality assurance practices: design and code reviews; use of pre/post conditions, assertions; approaches for unit, assembly, and system testing; test plan checklists | |
| Standards policy (e.g. are above standards and policies implemented in CICD) | |
Software / application architecture
| Architecture | |
|---|---|
| System strawman diagram and high-level blueprint providing an overview of major application capabilities | |
| Monitoring | |
| Diagnostics | |
| Context diagram, boundaries and identification of external interfaces | |
| Identification of user types and major use cases | |
| Processing Styles | |
| Composition | |
| Appropriateness of decomposition into: online, services, batch, asynchronous processing, other styles | |
| Application Layering and Stereotypes | |
| Logical architecture | |
| Application logical tiers, layers, or matrix model | |
| Module stereotypes | |
| Frameworks and libraries | |
| Open-source frameworks and 3rd party software used | |
| Custom architecture frameworks | |
| Software Architecture Deep Dive | |
| Walkthrough selected major use cases with the aid of sequence diagrams or interaction diagrams for each use case / scenario; attach diagrams as exhibits | |
| Trace through stereotypes | |
| Blocking vs. non-blocking execution | |
| Data flows | |
| Transaction volumes | |
| Performance targets | |
| Key hardware and software components involved | |
| Other technical considerations | |
Integration points and extensibility
| Application Integration & Interfaces | |
|---|---|
| Transport layer |
|
| Protocols (industry standards, custom) |
|
| Interface discovery (e.g., service catalog management, API and service discovery capabilities) | |
| Appropriateness of asynchronous versus synchronous models | |
| Walkthrough of external interfaces, including: data flows, physical interfacing mechanism | |
| Transactional requirements, frequency | |
| Data volumes and SLAs | |
| Appropriateness of synchronous vs batch vs asynchronous interfaces | |
| Guaranteed delivery and retry architecture | |
| Transactionality and Data Consistency | |
| Transactional requirements and eventual consistency bounds, calls across multiple services and/or databases | |
| Error detection and recovery for logical transactions spanning multiple services and/or databases | |
| Application of eventual consistency to reduce transactional requirements, traffic, volume | |
| Extensibility and Resilience to Change | |
| Extension points | |
| APIs provided by the application | |
| In-built frameworks, reference architectures, reusable libraries | |
| Planned and/or plausible future changes/additions to business requirements or technology impacting the application | |
| Impacts to the application or architecture | |
| Designed-in resilience to change (e.g. reusable frameworks, microservices, separation of concerns, decoupling) | |
Error handling, logging and resiliency
| Error-Handling and Logging | |
|---|---|
| Note: points below are relevant for both server-side and client-side in case of SPAs | |
| Exception/error-handling discipline, exception hierarchy, error codes, correlation IDs, non-use of system.out, log entry formatting, no exception eating | |
| Error handlers, including last-resort error-handlers | |
| What are the different kinds of errors, how does the system respond to and log them? | |
| What are the log destinations, how do they integrate with monitoring infrastructure | |
Performance and scalability
| Performance, Scalability, and Availability | |
|---|---|
| Use of virtualization, IaaS, CaaS, PaaS, FaaS capabilities | |
| Horizontal/vertical, use of high bandwidth, CDNs, caching, load-balancing, data partitioning, etc. | |
| High-availability: availability % targets, MTTR (mean time to recover), MTTA (mean time to acknowledge), RTO (recovery time objective), RPO (recovery point objective), planned down-time, architecture to achieve high-availability | |
| Awareness of / ability to capture DORA-4 metrics | |
Infrastructure and security
| Infrastructure | |
|---|---|
| Hardware and network topology diagram(s) and capacity | |
| Geographic distribution and disaster recovery architecture | |
| Hardware, 3rd-party software, network, data centers | |
| Source of record / source of authority discussion | |
| Major data sources | |
| Major (external) integration points | |
| Security | |
| Secure access to/from clients and business partners, authentication (strength), single sign-on, authorization, integrity, non-repudiation | |
| Encrypted communication between machines on local network | |
| Identity management, privacy, physical security, Zero Trust Architecture | |
| Data security, data in transit/rest, what kinds of data classifications (public, private, protected, crown jewel), what kinds of encryption keys, where are they stored, rotation policies | |
| Application security, including: security coding standards, custom frameworks, authn/authz, custom code vulnerability (XSS, CSRF, SQL injection, validation), 3rd-party library vulnerability | |
| Network, hardware, procedures (e.g., hardening), monitoring processes, security management and administration processes and COTS software (including patch management) | |
| SIEM integration, trust management and alerting | |
| Regulatory compliance / policy management, control process capture and implementation | |
| Control process capture in the CICD pipeline; security control automation | |
Operations, CI/CD and incident management
| DevOps | |
|---|---|
| Assessment and testing: internal vulnerability assessment, external audit, penetration testing | |
| Identification of non-production environments (development, test, staging, performance testing, etc.) and discussion of their differences with respect to production | |
| Major development tools used: programming (IDE and programming productivity aids) | |
| Testing (unit testing, UI testing, test coverage, profiling, performance/stress testing, etc.), configuration management, code generation | |
| Testing lifecycle (times and how they’re being acted on; test timeliness as a strain on engineers in the SDLC) | |
| Data modeling and database administration | |
| 3rd party libraries, project collaboration and communication (intranet, groupware, etc.) | |
| Developers’ workstation tools provisioning and updates, automation | |
| CICD | |
| Deployment frequency | |
| CICD architecture | |
| Orchestration | |
| Build automation — commit drives build to standalone server | |
| Deployment package generated and delivered to client | |
| Builds deliver a single binary (no recompile for higher environments) | |
| SAST / DAST | |
| Code quality procedures | |
| Secret detection | |
| Penetration testing, dependency scanning, vulnerability scanning | |
| Operations and Support | |
| Help desk, escalation paths, production troubleshooting, application maintenance, DBA support, deployment of releases/fixes | |
| Operations and support turn-around SLAs | |
| Deployment timeline, frequency, and typical downstream impact | |
| System and network capacity management | |
| Backup, archiving and recovery | |
| Performance management | |
| Change control; software configuration, distribution, and deployment; scheduling; application startup, shutdown, restart | |
| Event monitoring and response, telemetry | |