feat: ADR to capture how to structure parking sensor and synapse sample

[devlace]

Type of PR

• Documentation changes

Purpose

• ADR to capture how to incorporate Synapse sample into DataOps repo

Does this introduce a breaking change? If yes, details on what can break

[DavidBurela]

My main consideration is the ease for a final user to be able to pick it up, grok how it works, and use on their project.

• Option 3: I'm leaning towards this (new standalone sample). As it is extremely clearcut that "everything here is the sample"
• Option 2: The separate folders for the synapse/databricks pieces helps break it up for the end user. I would also be comfortable with if it were the same amount of effort. But I'm worried that there is a lot of work that would need to be done to the existing Databricks sample, which may add an extra... 30%? workload to updating and testing those paths. And any regressions caused to the opposite sample if the common pieces are

[sinnypan]

1st preference: Option 2 Reason: Its better configuration for guiding engineers about how many components are common and how many components are dedicated for certain technology choices (Databricks/ADF vs. Synapse). And the code will become more clean and aligned to engineers who want to refer. 2nd preference: Option 3 Reason: If considering that given resources/time we had, we can decide to go with this approach for now.

[jmostella]

I'm leaning towards option 3 (or option2) for the reasons previously discussed:

• Easy to get started
• Don't need to worry about how to refactor the existing Databricks sample (risk and level of effort)
• It fits nicely with planning work into deliverable milestones as opposed to one shot.

For option 2 It looks like we have a good enumeration of the shareable components. Just wondering what the friction will be.