[MUSIC PLAYING]
Ever wanted to go behind the scenes of a Foundry demo?
In this series of videos, we're going to explore the Foundry
Reference Project.
If you're already a developer on the platform,
then you'll find resources here that you
can start to use right away.
And if you don't have access to Foundry yet,
this series can serve as a quick introduction
to what a simple use case implementation looks
like on Foundry.
Keep in mind that as we go through this series,
it's not really going to be a demo.
We're not going to dive into advanced data analytics,
or look at any complicated application implementations.
Instead, we're going to focus on what
you need to know as a Foundry developer to get
started with your first use case right away.
With that said, let's get going.
In this example, we're going to be looking at data
from the aviation industry.
And to orient ourselves, we'll start at the end
with an operational workspace configured for an industry
analyst to act on alerts about the performance
of different flight routes in the U.S.
The landing page provides quick access
to relevant data about the industry,
including flights, routes, airlines, and aircraft,
as well as the alerts themselves.
There's also tailored applications
for triaging alerts and tracking the national and regional
overview.
We'll follow the analysts into their triage inbox
to understand their workflow.
In later videos, we'll go into edit mode
and understand how an app like this works.
The main table of the inbox lists all the alerts.
But we're just interested in those
that haven't yet been assigned.
Filtering by status and priority leaves us with two alerts
to check out.
The "Details" view shows alert metadata
and summarizes the reason for the alert priority,
as well as showing us some context with alerts triggered
about individual flights on the same route as the one
we're currently looking into.
We can get more details about the route
and its overall performance in the preconfigured dashboards.
This view lets us compare arbitrary cohorts of flights
on the same route to explore hypotheses
about the underlying root cause of performance issues.
We can even dive into the granular flight data
if we need to do more detailed investigation and analysis.
For our purposes though, we just want
to open this up and assign it to someone else
to do the follow up.
So we returned to the alert view and take a quick action
to find and assign an owner while also changing the status
to "Open."
After we've made the change, we can
see that the alert itself updates
as well as our inbox, which now shows
a single alert pending triage.
And if we update our filters, we can
see that our alert has joined one other that's
currently assigned to me.
So there's our little vignette.
On the surface as simple as it could be,
filter and review a little bit of data, and take an action.
Under the hood though, there's so much
more fun stuff going on.
To get the engineer's perspective on this project,
let's jump into the data lineage tool,
starting with a high level view of how
data flows through the resources that make up our project.
All the way on the right are our applications.
And immediately to the left in yellow,
we can see the data that backs up those apps.
Labeled here with a little bit of Foundry lingo as "Objects."
Upstream of these Objects, we cross
a conceptual and technical divide,
and move from the object representation of our data
into its data set representation.
We'll return to this in a later video
about the ontology to better understand
the details of what's going on here.
Further back from these data sets,
we have our pipeline of cleanup transformation and enrichment
steps, all leading back to three different source systems.
We can expand out this grouped view
to see the individual resources: the Object types and data
sets and the logic that links them together.
In our next video, we'll start from the other end
and understand how to build up a data lineage view like this
for an existing project, and identify
the different distinct resource types that are involved.
Let's stop here for our overview.
We've got a general idea of one workflow
within our use case, the application for triaging route
alerts.
And we've seen the general flow of data
through the resources that make up a project.
In the rest of the series, we're going to return to each
of these components within our use case --
the data transformation pipeline,
the ontology data model, and the application implementation
itself --
and go into more details.
Make sure that you subscribe to follow along
as we get into the weeds of each of these patterns
across our Foundry Reference Project.
[MUSIC PLAYING]