View a markdown version of this page

People and culture - AWS Well-Architected Tool

People and culture

Every workload needs an owner, and many people and teams may be involved in the lifecycle of a workload. However, before running a WAFR, define a single-threaded owner (STO) for the workload.

This person must be able to make decisions and control the budget, headcount, and roadmap. Examples of this role are a product owner, product manager, head architect, or engineering manager.

Ultimately, this role is responsible if the workload no longer functions as intended.

It's important to run a WAFR with an STO to improve your outcomes. For example, you may find improvement items for the workload but have little success in prioritizing them on the product roadmap. Alternatively, you may struggle to acquire funding or resources to carry out the work.

This often results in gathering an unachievable list of backlog items. The STO helps you avoid this outcome, as they own the WAFR and are invested in the process.

Single-threaded owner

Required stakeholders

The STO can't answer all the questions. Many people and teams are involved in either architecting, developing, securing, or operating a workload. Depending on the organization and size of the workload, the number of stakeholders and teams involved will vary.

Team structure diagram showing single threaded owner above suggested WAFR participants

Consider the following questions regarding stakeholders:

  1. Who needs to be present to answer each category of questions?

  2. Which stakeholders are required to be present during which parts of the WAFR?

  3. How can you inform different stakeholders of the questions in advance?

Pillar sponsors

The Well-Architected Framework consists of six pillars. While defining an STO is crucial, it's as important to gather support from pillar-specific sponsors or champions to accelerate and increase the value of the WAFR process.

Team structure diagram showing single threaded owner above six pillar specific champions

Define pillar sponsors or champions who can:

  • Attend specific parts of the WAFR to provide information or guidance

  • Own the outcomes for their subject matter area

  • Define, influence, and communicate strategic cross-organizational changes

Does your organization have a Cloud Center of Excellence or Cloud Community of Practice? Start small and grow a group of like-minded people who can support each other with architectural health discussions and improvements.

Create a safe space

Developing a healthy organizational culture is crucial to healthy, productive discussions about technology choices. The group of people involved in the WAFR could be new or old to the workload, of different tenure and seniority, or involved as partners and third parties. It's critical to nurture a healthy, respectful conversation about a workload to improve the likelihood of lasting, useful improvement.

Set a positive intent from the beginning and re-emphasizing throughout to maintain alignment and focus on discovering improvement opportunities. Technology and best practices evolve, so a WAFR must be framed as an opportunity to discover improvements.

A WAFR is not an audit. While the findings can help you meet different compliance standards, the process does not exist to "score" a workload. Focus on increasing architectural health.

A WAFR is a chance to ask "where are we?" and to capture a point in time view of the workload. Then, you can use the findings to make an informed decision to answer "where should we go?"

Architectural improvement is a journey that AWS Well-Architected guides. Consider the following questions as you begin your WAFR process:

  1. Why are you running the WAFR?

  2. What do you hope to get out of it?

  3. How will the experience benefit everyone?

  4. Where are you now, and where do you want to get to?

Resources