<aside> 🎯 In this chapter, you will learn how to select different types of participants and considerations for specifying the timeline.

</aside>

Getting the appropriate participants involved in your TDR is important to its success. If you select too many or the wrong people, your decision may stall. Without the the right people, the decision may be vetoed or struggle with implementation. It is important to identify participants early, be clear on their roles and set the decision up for success.

When selecting and documenting participants, consider each of the following roles:

1. Creators
2. Team members to consult (those who are impacted by the decision)
3. Decision makers

We'll discuss each of these roles independently but you may be asking "What about everyone else?" We believe that transparency on decisions is very important but this doesn't mean everyone is invited to provide their opinion. You should be intentional in the selection of TDR participants but as the TDR matures, it should be made widely available for consultation within the organization before the decision is implemented.

Creators

These are team members who are responsible for developing and authoring the technical decision record. A specific decision record may not be the sole responsibility of the architect. Instead, it should typically include team members closer to the problem. Ensure each person is aware of their role in the development of the TDR and it's okay if you are looking for their input only on specific aspects of the decision. Think about who you need to provide input to understand feasibility, effort, and potential gotchas.

Consider the example of selecting an Identity Provider for a solution. For this kind of foundational technical decision, you should consider a broad range of creators.

• Frontend Developers may provide input on how the frontend application must be adapted for authentication, account recovery, user management, profile management, session management, and role-based access control.
• Backend Developers may need to make adjustments for identity mapping, authorization, and session management. These efforts may influence the decision.
• DevOps will likely need to alter provisioning and deployment plans. Evaluation of an Identity Provider solution should also consider availability needs and disaster recovery strategy.

Depending on your organization, there may be others who should be included in the authoring group of TDR. Ensure that you do not open up the TDR to be architecture by committee however. Ideally, identify one representative from each group that needs to contribute and have them to inform the evaluation for their specific area of concern.

Team Members to Consult

In a large enterprise it becomes more important to include people who will be possibly impacted from the decision. They may be interfacing with the solution you are developing as a consumer or producer or they may end up having some responsibility in the eventual implementation plan. Consulting these people now will reduce the chance that your plan will be blocked by some unforeseen issue after the decision is made.

In our experience, it is best to go through the bulk of the evaluation first and then consult these stakeholders once the preferred option (or two) is determined. You are looking for red flags that could derail the approach or for other considerations that could sway a close decision.

If we look again at the Identity Provider decision, there are a number of groups to consider for consultation.

• Product owners should have their primary requirements included in the needs and requirements section but the decision will likely impact the future feasibility of other items on their roadmap. In some cases, one Identity Provider option may be heavily preferred because of the future flexibility it affords while in other cases the product owner(s) may devalue that flexibility in favor of time to market.