3. Edge and central lake-DCAE needs to support a variety of applications and use cases rang- ing from real-time applications that have stringent latency requirements to other analytic applications that have a need to process a range of unstructured and structured data. The DCAE storage lake needs to support all of these needs and must do SO in a way that allows for incorporating new storage technologies as they become available. This will be done by encapsulating data access via APIs and minimizing application knowledge of the specific technology implementations. While there may be detailed data retained at the DCAE edge layer for detailed analysis and trouble-shooting, applications should optimize the use of pre- cious bandwidth and storage resources by ensuring they propagate only the required data (reduced, transformed, aggregated, etc.) to the core data lake for other analyses. Analytic framework-the analytic framework is an environment that allows for develop- ment of real-time applications (e.g., analytics, anomaly detection, capacity monitoring, The Network Operating System congestion monitoring, alarm correlation, etc.) as well as other non-real-time applications (e.g., analytics, forwarding synthesized or aggregated or transformed data to Big Data stores and applications); the intent is to structure the environment that allows for agile introduction of applications from various developers. The framework should support the ability to process both a real-time stream of data as well as data collected via traditional batch methods. The framework should support methods that allow developers to compose applications that process data from multiple streams and sources. Analytic applications are developed by various organizations; however, they all run in the DCAE framework and are managed by the DCAE controller. These applications are micro-services developed by a broad community and adhere to ONAP framework standards. 5. Analytic applications-the following list provides examples of types of applications that ca