Well-Architected Framework
Map your current workflows
Automating processes without understanding current workflows leads to confusion rather than efficiency. Mapping your current workflows identifies what tasks teams perform manually, where bottlenecks occur, and which processes are the most valuable to automate. Workflow mapping produces written workflow documentation, baseline metrics, and a prioritized backlog of automation tasks.
Why map workflows
Workflow mapping addresses the following operational challenges:
Identify high-impact automation opportunities: Without understanding which processes consume the most time or cause frequent failures, teams automate the wrong things first.
Establish measurable baselines for improvement: Claiming automation reduced deployment time from "a long time" to "faster" lacks credibility. Workflow documentation provides specific metrics like current deployment duration, failure rates, and resource requirements that demonstrate automation's impact.
Create institutional knowledge and reduce dependency on individuals: When process knowledge exist only in a few individuals, vacations and departures create operational risk. Documented workflows transfer knowledge to the entire team and new hires.
Document current processes
Identify processes that are candidates for automation. Focus on workflows that teams perform frequently, that produce errors often, that consume significant time, or that block other work. Common candidates include infrastructure provisioning, application deployments, database operations, security compliance checks, and incident response procedures.
For each process, document what the process accomplishes and why it exists, who performs the process and what skills they need, when the process is triggered and how often it runs, and what constitutes successful completion. When you finish mapping, you should have a set of workflow documents that teams can follow and a baseline you can measure improvements against.
Document operational details including permissions and access required, dependencies on other systems or processes, common failure scenarios and troubleshooting steps, and typical time required for each step. Include examples of actual executions, capturing screenshots or command outputs that show what success and failure look like.
Workflow documentation template
The following template provides a structured format for documenting workflows:
## [Workflow Name]
**Owner:** [Team or individual responsible]
**Frequency:** [How often this workflow executes]
**Duration:** [Typical time required to complete]
**Priority:** [Critical / High / Medium / Low]
### Purpose
[What this workflow accomplishes and why it exists]
### Prerequisites
- [Required permissions or access]
- [Dependencies on other systems]
- [Tools or credentials needed]
### Workflow steps
1. **[Action description]**
- Tool/system: [What executes this step]
- Time: [Typical duration]
- Owner: [Who performs this step]
- Command/action: `[Specific command or procedure]`
2. **[Decision point or validation]**
- Condition: [What determines the next action]
- If true: [Path A]
- If false: [Path B]
3. **[Next action]**
- Tool/system: [What executes this step]
- Time: [Typical duration]
- Owner: [Who performs this step]
### Success criteria
- [How to verify the workflow completed successfully]
- [Expected outputs or results]
### Common failures
- **[Failure scenario]:** [Resolution steps]
- **[Failure scenario]:** [Resolution steps]
### Metrics
- Time consumed per execution: [X minutes/hours]
- Failure rate: [X%]
- Monthly executions: [X times]
This template provides a standardized structure for documenting any workflow in your organization. Use this template to capture the who, what, when, why, and how of each process, creating consistent documentation that reveals automation opportunities and serves as a blueprint for implementing automated solutions.
Store workflow documentation in version control alongside your infrastructure code. Use markdown files in a docs/workflows/ directory, wiki pages in your repository, or documentation platforms like Confluence. The key is making workflow documentation accessible to your entire team and keeping it updated as processes evolve.
Database backup workflow
The following example shows a documented database backup workflow:
## Production Database Backup
**Owner:** Database team
**Frequency:** Daily at 2:00 AM UTC
**Duration:** 45-60 minutes
**Priority:** Critical
### Purpose
Create point-in-time backup of production PostgreSQL database for disaster recovery and compliance requirements. Retention: 30 days for daily backups, 12 months for monthly backups.
### Prerequisites
- AWS credentials with RDS snapshot permissions
- VPN access to production environment
- PagerDuty integration for failure alerts
### Workflow steps
1. **Verify database connections**
- Tool/system: PostgreSQL client
- Time: 2 minutes
- Owner: Automated script
- Command: `psql -h production-db.example.com -U monitoring -c "SELECT 1"`
2. **Check for active long-running queries**
- Tool/system: PostgreSQL monitoring query
- Time: 1 minute
- Owner: DBA on-call
- Condition: If queries running > 30 minutes, wait or notify application team
3. **Create RDS snapshot**
- Tool/system: AWS CLI
- Time: 40 minutes
- Owner: Automated script
- Command: `aws rds create-db-snapshot --db-instance-identifier production-db --db-snapshot-identifier backup-$(date +%Y%m%d-%H%M%S)`
4. **Verify snapshot completion**
- Tool/system: AWS CLI
- Time: 1 minute
- Owner: Automated script
- Command: `aws rds describe-db-snapshots --db-snapshot-identifier backup-20240115-020000 --query 'DBSnapshots[0].Status'`
5. **Update backup metadata**
- Tool/system: Internal tracking system
- Time: 1 minute
- Owner: Automated script
- Action: Record snapshot ID, size, completion time in backup database
6. **Delete snapshots older than retention period**
- Tool/system: AWS CLI with date filtering
- Time: 5 minutes
- Owner: Automated script
### Success criteria
- RDS snapshot status shows "available"
- Snapshot size matches expected database size (± 10%)
- Backup metadata recorded in tracking system
- No error alerts in PagerDuty
### Common failures
- **Snapshot fails due to storage space:** Increase RDS allocated storage or reduce backup retention period
- **Long-running query blocks backup:** Identify query owner and determine if safe to terminate
- **AWS API rate limiting:** Implement exponential backoff in automation script
### Metrics
- Time consumed per execution: 45-60 minutes
- Failure rate: 2% (network issues, long queries)
- Monthly executions: 30 times
- Monthly time investment: 22.5-30 hours
This documented workflow identifies the 45-60 minute daily time investment and 2% failure rate as automation opportunities. The structured format shows dependencies, decision points, and failure scenarios that must be addressed in automated solutions.
Identify pain points and prioritize
As you document workflows, identify problems like steps prone to human error, inconsistent execution across team members, lack of validation that work completed successfully, and missing error handling or rollback procedures. Look for inefficiencies such as manual steps that involve copying and pasting, redundant work across similar processes, bottlenecks where work waits for approvals or resources, and time spent on administrative tasks rather than delivering value.
Prioritize automation candidates using impact, effort, and risk factors. Assess impact by measuring time the process currently consumes, criticality to business operations, and value automation would deliver. Evaluate effort by considering process complexity, available tools and systems, and team skills and capacity. Consider risk including consequences of process failures, required testing and validation, and potential impact of automation bugs.
HashiCorp resources
- After documenting workflows, you can create reusable modules to standardize repeated infrastructure patterns and implement version control to track workflow changes
- Explore automation maturity models to assess your current automation state
- Learn to standardize workflows after mapping to create repeatable processes
- Define infrastructure as code to automate mapped workflows
Next steps
In this section, you learned how to identify and document current manual processes to create a foundation for automation. You explored techniques for mapping workflows, identifying pain points, and prioritizing automation opportunities based on impact and effort. Map your current workflows is part of the Define and automate processes pillar.
Visit the following documents to continue building your automation strategy:
- Use standardize workflows to turn mapped workflows into repeatable processes
- Implement CI/CD to automate mapped workflows
- Get started with Terraform tutorials and read the Terraform documentation to automate mapped workflows