A system serves no purpose unless it can be used to convince the stakeholders of its importance. The stage at which insight is usually provided to stakeholders as to what you plan to build arrives soon after the requirement phase and the strawman phase is over.

A quick note on strawman: a strawman is a concept during the requirement clarification phase where the stakeholder and the system builder sit together, brainstorm on the requirements provided, and try to clarify any things that may not have been explicitly captured in the requirement documents (also referred to as PRD, or the Product Requirements Document). During this phase, the system architect or designer produces rough sketches that resemble the system the stakeholder may want. Once the strawman phase is over, the drawings and scribblings feed into defining the reference architecture of the system.

The following diagram shows you the business view of a data-intensive reference architecture:

Let's dig a bit deeper into this reference architecture.

If you remember from a Chapter 1, Exploring the Data Ecosystem, the reasoning behind building a data-intensive architecture is so that we could support a variety of use cases, all of which revolve around data.

Looking at the preceding diagram, you will notice that it lists these varieties or categories of use cases:

• Machine learning use cases
• Data enrichment use cases
• Simple extract, transform, and load (ETL) use cases
• Real-time querying use cases
• Near real-time use cases
• Analytic or BI-related use cases

Let's briefly look at one such example use case for at least some of the preceding categories. This will help you to relate to the architecture better and, at the same time, provide you with some insight into what part of the architecture is important for your specific use case. But before we start identifying real-life use cases, I want to make one thing clear. It is not important (in fact, it is not advisable) for you to build an entire stack defined in the architecture before you can utilize it. In fact, it is not wise to build an entire stack in one go. Instead, it should be an iterative process. Put a piece of the architecture in place, then validate it with your use case, and, once you have validated one piece, move to incorporating the next one. For example, in the preceding architecture, you can decide to put a big data platform piece in place without thinking of things such as what in-memory database you should use or how your machine learning process should be designed.