9 Solution architecture design

 

This chapter covers

  • Organizing architecture design sessions
  • Learning C4 architecture diagram notation
  • Using and collecting architectural drivers
  • Understanding design patterns for data product architecture
  • Turning the database inside out
  • Designing the data product’s solution architecture

In this chapter, we will come much closer to the code and technical details. We will step into the Messflix software architect’s shoes to design technical architecture for our data products.

In the previous chapters, you learned the principles, such as what data product boundaries should look like, how to apply product thinking, how governance should be set up, and what an underlying platform is. We can imagine you are now looking at diagrams of your current systems and asking yourself: how should we extend this particular system to the data product? What should the design look like? In this chapter, we will help you answer these questions. After this chapter, you will be able to do the following:

  • Organize a design session for your team
  • Choose the proper notation to capture architecture
  • Capture architectural drivers of planned data products
  • Make design decisions based on architectural drivers
  • Choose between design patterns using tradeoff analysis or a pro-con-fix exercise
  • Design the technical architecture of a data product

Let’s start by explaining what software architecture is and how to capture its current state in your organization.

9.1 Capturing and understanding the current state

9.1.1 What is software architecture?

9.1.2 How to document architecture: The C4 model

9.2 Understanding architectural drivers of a data product design

9.2.1 Architectural drivers

9.2.2 Capturing architectural drivers for a data-product design