chapter three

3 Reading the context

 

This chapter covers

  • Reading the system context you're changing
  • Assessing the team that will own the result
  • Recognising the forces in your company shaping the decision
  • Working through a complete context assessment

Two data engineering teams are deciding how to bring a few dozens of data sources onto a new data platform. The requirements they've been given are identical: a certain batch latency that’s acceptable per data source, some compliance constraints, data volumes and business priorities behind them. Both teams would narrow the option space to the same candidates: build on open-source tools with custom connectors over a streaming system like Kafka, or buy a SaaS alternative like Fivetran.

Imagine that one team works inside a large engineering organisation with multiple data groups and engineers who've operated Kafka at scale. The other one is the only data team in a relatively small company who just finished a year-long platform build, with one person holding most of the knowledge of the legacy code they're migrating away from. Would the two teams choose the same option? Should they? The requirements alone won't tell us that. The requirements tell both teams what problem to solve. They don't tell either team which solution will land well in their specific situation. That second question is what this chapter is about.

3.1 System context

3.1.1 The 5W questions

3.1.2 What exists in the system today?

3.1.3 Where is the component used?

3.1.4 When was it built?

3.1.5 Why is it the way it is?

3.1.6 Who owns it, who knows it deeply, and who has the historical context?

3.1.7 Understanding whether your findings are solid enough

3.2 Team context

3.2.1 Team knowledge

3.2.2 Talent availability

3.2.3 On-call setup

3.2.4 Team preferences

3.2.5 Understanding which forces are binding

3.3 Company context

3.3.1 Business strategy

3.3.2 Technology strategy

3.3.3 Company scale

3.3.4 Industry norms

3.4 Reading context: a worked example

3.5 Summary