<aside> 🎯 In this chapter, you will learn the key details captured in a TDR with the help of a sample. A more detailed overview of each section is presented in following chapters.

</aside>

Sometimes the fastest way to learn is from an example so below is a short sample TDR for selecting the database technology for an imagined project. This example is certainly not comprehensive or representative of the diligence that might be appropriate for your decision but consider this the Hello World of TDRs.

<aside> 👉🏼 Database Selection (Sample TDR)

Participants & Timeline - @Mark Thompson (Architect), @Rashi Lu (CTO), @Amy Peterson (Product Manager). Decision to be made by January 20th.

Need and Requirements We are developing a new internal app for sharing employee profiles with each other to facilitate better understanding of each other skills. We need to select the type of DB for the application.

Usage patterns:

• View employee profile (frequent)
• Update profile (occasional)

Other considerations:

• New profile fields will are expected to be discovered and needed by users

Options MongoDB, PostgreSQL

Evaluation Administration capability - Currently all internal applications are using PostgresSQL. Introducing MongoDB would be difficult as we do not have anyone who can potentially administer the database including security and backups.

Time to market - Based on the requirements it might be easy to implement the solution using MongoDB Stitch service as it provides MongoDB as a managed database and the ability to use Google as SSO for the application.

Cost - PostgreSQL is available internally and cost would be minimal to host another database. MongoDB self hosted is inexpensive, but new infrastructure may be needed for backups and monitoring.

Decision MongoDB - Time to market and model flexibility are most important to the app. Implementing using MongoDB has advantages for the app in both areas.

Open Risks Risk - Currently MongoDB is not used by any other internal applications, thus there is limited internal expertise to develop and maintain the app.

Mitigation plan - Conduct a PoC, find other applications that are suitable for MongoDB but hesitant to move for same reason.

</aside>

Some TDRs can be that simple when stakeholders are well aligned and the technology choice is rather clear. In other situations, a TDR is key to building that alignment and further elaboration and collaboration will yield a more robust TDR.

Regardless of the complexity or length, we suggest consistency in the format. As a you build an archive of decisions, this consistency will make your records faster to consume and author. Participants can spend more time focussed on the content than navigating the structure.

Each section of the TDR has a dedicated chapter in this book explaining its role and providing guidance to make it most effective. But for quick reference, below is a short description of each.

Participants & Timeline

List the participants who are involved in the decision. This may include creators, folks who would be impacted, and decision makers. This sets expectations for involvement and may drive suggestions about who else should be involved. With the right participants, the decision will proceed more efficiently and the implementation will have the support it needs.

It is also important to provide a target date for the decision. This will help keep the decision from falling into analysis paralysis and also contextualizes the decision when referring back to older TDRs.

Need and Requirements

Describe the use cases that needs to be addressed by the TDR. This could be linked to a User Needs document, a respective JIRA story, or any other documentation driving the needs. Elaborate on the use cases that are relevant to the evaluation and distinguish between must-have and nice-to-have items.

Options

Research options on the web or from past experience and present them with parameters that are comparable to each other. Ask others if they have experience or knowledge of other options and don't be afraid to include options others may not have heard of. Often there are emerging technologies that are worth consideration so be careful not to constrain yourself to known options.

This is the easiest of all sections and can be presented in tabular form. Do not filter out options based on experience yet. Filtering can be done in evaluation.