Beyond the Dashboard: Designing Premium, AI-Powered Operations Apps on Databricks

Summary

This video defines operational applications as going beyond analytics to surface recommended actions, and shows how Databricks Apps, Lakebase, Model Serving, and Genie can serve as a single governed substrate for building them.
Four design principles are presented for creating AI-powered operational apps that feel like products rather than dashboards, demonstrated through an aircraft fleet management app and a real-time sports analytics application.
The video explains how to shape noisy operational telemetry into decision-ready gold tables and orchestrate multiple AI agents to deliver contextual recommendations without adding friction to existing workflows.

Beyond the Dashboard: Designing Premium, AI-Powered Operations Apps on Databricks

Connected systems generate massive operational telemetry, yet most teams still consume it through generic dashboards that can bury insight behind filters and grids. Turning raw signal into decisive action across hundreds of assets is as much a product and design challenge as a data one. this video shows how to deliver branded, business-facing operations experiences on Databricks using Apps, Lakebase, Model Serving and Genie as a single substrate for data, AI and product. We follow an operations lead through a custom app built around an aircraft fleet: a top-level overview, deeper insight views with recommended actions and an AI chat that answers natural-language questions on the same governed tables. The talk focuses on patterns you can reuse: shaping noisy telemetry into decision-ready gold tables, designing apps that feel like products rather than dashboards and orchestrating multiple AI agents.
Talk By: Amine Charifi, Senior Solutions Engineer, Databricks ; Samwel Emmanuel, Senior Solutions Architect, Databricks ;

Chapters

FAQs

What is the difference between an operational app and a dashboard in Databricks?

According to this video, dashboards stop at the analytics layer—they show data but require users to determine what to do next. Operational apps go further by surfacing recommended actions in response to signals in the data, turning insight into decisive action within the same interface.

What is Databricks Apps and what can it be used for?

Databricks Apps is a flexible application framework that runs natively on the Databricks Data and AI platform, inheriting Unity Catalog governance and enterprise authentication. This video demonstrates it being used to build an aircraft fleet management app and a real-time sports analytics application, highlighting its range across operational and complex analytics use cases.

How do you design AI-powered apps that feel like products rather than dashboards?

This video presents four design principles for building product-quality operational apps: keeping data and AI in one governed workspace, augmenting users with AI as a tool rather than replacing their judgment, surfacing recommendations without adding friction to the workflow, and treating the app as a first-class experience for the business user.

How can you orchestrate multiple AI agents in a Databricks application?

The presenters show how Genie can be embedded alongside model serving endpoints and structured gold tables within a single Databricks App so that different agents handle different analytical tasks. This architecture keeps all data and AI governance in one workspace rather than requiring users to stitch together results from separate systems.

Full transcript

[00:08] All right. Uh, good afternoon everyone. Uh, thanks for coming in. Um, I am Samuel. I'm a senior solutions architect here at Data Bricks. I've been a data bricks for three and a half years. I work with uh, customers in
[00:20] sports and entertainment. And this here is Amin. Amin, you want to do a quick intro? >> Sure. Good afternoon everyone. My name is Amin. I'm also a solutions architect here at data bricks based in France and I work with some of our leading French
[00:33] customers in manufacturing and Irispace. Okay, so first quick housekeeping you will see a long forward-looking statement on the screen. The short version is please make your purchasing
[00:46] decisions based on products we have in the market today. We might reference some items on the road map. If we do just take them as direction, not as a promise. All right, so that's a summary. You can read it of course, but >> we're going to pause for five minutes
[00:58] until you read all of it until the end. Cool. >> So, we're here today to talk about best practices and principles for designing AI powered uh operational applications.
[01:12] And before we go any further, we wanted to get very clear on what we think operational applications are and how you think about them. The main distinction between operational applications and other data apps that you've built in the
[01:24] past is that operational applications don't just stop on the analytics side, right? They go a step further, a few steps further, that is, right? They also surface some decisions from your analytics, but they also recommend some
[01:36] actions that you could take in response to signals in your data. So, that's kind of like the framing we're going to take here. and we're going to talk about how you can use data bricks apps to design effective AI powered uh operational
[01:49] applications. A quick oneliner for this entire talk is apps is the most flexible way for you to serve data intelligence for everyone in
[02:01] your organization and for any use case. Okay, so like they can power a lot of different use cases but for this talk we're going to focus on two main things. Okay, so that operational workflows uh path, but we're also going to focus on
[02:13] how to use apps to power very very complex analytics that you may not be be able to power through traditional dashboards or other means. Okay, so two two main things. All right, so let's set up the problem
[02:26] first. Okay, so um uh imagine you're looking at a contract margin uh on this screen, right? Um and you realize that the number has declined significantly. it's negative 645,000,
[02:39] right? But you don't just want to stop there. You want to take action, right? In re in reaction to that to that number. So, what you would normally do today is uh a few manual actions, right? You might look at this and perhaps take
[02:52] a screenshot, right? Uh to just kind of like share with colleagues on maybe Slack, right? So, you ask your colleagues, does this look right? And then maybe you might do some further actions. Open a few tabs, do additional research, add context to it, and only
[03:06] after you've validated your assumptions. Only then perhaps you send an email, right? Get confirmation, and then you take an action. And I want you to stop and think about what you just did here, right? Every step you took here took you
[03:19] further away from your analytics and even further away from your action, right? So you're spending time hopping between different tools, Slack, email, right? uh before you even take the action on data that you know exactly
[03:32] what it's telling you, right? So this is this is kind of like the framing here and what we think here is that um you know um these these steps that you're taking they they can be consolidated by
[03:44] database apps. So that's kind of like the framing we're going to take here uh today. Okay. And the summary here is that really most of us in the room are data professionals. We've been doing data for a long time. So uh we've gotten really
[03:56] good at going from a mess of data to a set of analytical product or a number right and going from data to analytics is an easier problem. The the harder challenge is now everything that happens
[04:09] downstream of that. Okay, so you got the analytics. What do you want to do? Uh uh uh downstream. That entire exercise involves a few things, right? You have to gather
[04:21] context from a number of different services, right? Um you also have to make judgment about that context that you're gathering and then perhaps you have to coordinate across those services. Those are all services other than your analytical product, right? So
[04:34] you already have the data, but you you you're having to coordinate across a number of different services in order to in order to make that decision. That gap between the insights that your data tell you and the decisions and actions that
[04:47] you might take to mitigate it, that that is the gap that we think database apps solve really really well.
[05:00] Okay. So apps sit in between your your insights and some further actions that you have to take like decisions and actions. Okay. And the reason apps is best positioned for this is because they are a way for you to surface other
[05:12] services from within your database workspace. Not just dashboards, not just analytics, but other services like jobs, SQL warehouses or uh motor serving endpoints and a bunch of different services. Okay.
[05:25] And the summary for this is that operational workflows um don't just stop at analytics. The work continues to insight to decisions and actions. Right? Okay. So with that framing, this is
[05:39] going to be our quick agenda for today. Okay. So first of all, we're going to talk about what databicks apps are and why you should use them. Okay, in general. And then we're going to focus
[05:51] on those principles and best practices for designing effective workflow applications. Uh and then we're going to see two different demos. Right? So I talk about two different use cases, operational workflows, but also complex analytics.
[06:03] So we're going to see demos for each one of those. And then after that, we're going to summarize with some quick takeaways and then we're going to leave some time for questions. Okay.
[06:18] So let's talk about dataix apps. What are they? uh and why should you use them? The way you should think about database apps is a way for us to give you very flexible way for you to build uh
[06:31] interactive web applications from right within your database workspace. Okay. Um these interactive web applications are sitting right next to your data in
[06:43] the same workspace. And that is the key takeaway. You're not shipping your data to some external tools and build apps there, right? We're bringing apps over to your data and AI. There are few benefits for doing that of course,
[06:56] right? So the app sits close to your data and AI that's obvious and other services within databris. So you will see here motor serving right with mosaic AI you'll see DBS SQL maybe SQL warehouses. You also see lakebase and
[07:08] some other services. The apps sit next to your data and AI and other services that power that. That's number one. The other thing with this is that because the app sits within your
[07:20] workspace, it inherits all of the Unity catalog uh governance and permissions that you already set up. So, it's permissions, audits, and authentication. So, you do not have to stand up a separate stack just for those things.
[07:33] So, that's the second thing. And the other thing is that these apps are also open, right? So, um if you've built some apps before, there are a couple frameworks that people like to use especially for data apps. Maybe people like to use streamllet, dash, flask. All
[07:47] of those are open frameworks that are supported within apps. So this is a quick way to think about data apps. Functionally though, you might be wondering um yes, I get all of that, but
[08:00] practically what can I actually do with it? I like this slide a lot. The more functional and practical way to think about database app is a gateway to all services that already sit within
[08:14] your database workspace. Okay, so it's a front end or looking glass for all services that sit within your workspace. So you will see on my slide here I have SQL warehouses, I have jobs, motor
[08:26] serving endpoints, I have vector search, AIBI dashboard, Genie Lakebase, but I also have a bunch of other services at the bottom. I'm talking about external APIs. So if you have to maybe integrate other services like uh a service to send
[08:39] an email or you have to integrate Slack or some other external APIs, those can also be surfaced from uh your database app. So when you look at this, think of it as a way for you to pick and choose which components you want to surface on
[08:52] the app. And if you think about what we're talking here today, we're talking about a way for you to build operational applications. I mentioned earlier operational applications don't just stop at the analytics, right? There are other actions you need to take, right? maybe
[09:04] recommend some decisions and actions that you have to take. So when you connect those two ideas together, you should think about all of these surfaces as building blocks for constructing your operational workflows. And of course,
[09:16] you don't surface all of it, right? You pick and choose which slices are needed to be stitched together in order to build that workflow that allows you to not just stop an analytics, but also go to surfacing decisions and then taking
[09:29] actions. What are some example of these actions you could take? It might be sending an email. It might be, you know, uh pinging a colleague on Slack. It might be scheduling a maintenance uh
[09:42] uh uh you know, uh um session for maybe something that went bad. Okay. So, this is a picture that we would like to encourage you to think about as you think about uh designing operational applications on data bricks. Okay.
[10:02] So a lot of people take this for uh granted or maybe underestimate the value of this because uh when we speak to a lot of customers, one thing that comes up a lot is vibe coding, right? So everybody's vibe coding these days and um yes of course you could vibe code a
[10:15] UI in an afternoon pretty fast. Um but even that just takes you halfway there, right? Most of the challenges people have to deal with building enterprisegrade applications is not just building the UI. That's just maybe
[10:28] halfway there, right? You have to deal with a bunch of other things. One of those things is basically maybe authentication or SSO. How do people log into your apps, right? If you're building it on your own, you have to stand that stack app yourself. That's
[10:41] number one. So people have logged into your app, but there's another problem, right? What type of data permissions do they have in your application, right? Um so um you have to define governance and access control on top of that app as
[10:54] well. There's also like managing infrastructure. What is the actual compute that powers your application, right? Uh if you're building your own, you have to manage that as well. There's also integrating with the rest of your
[11:07] uh networks, right? So um does the app go outside or within your internal uh organization networks and then of course there are obvious ones like how do you maintain state for this app? Right? So um there are also
[11:21] things like how do you integrate with observability tools and then how do you figure out audit and and and access logs right who's logging into your apps what are they doing when how
[11:35] and then lastly if you have to upgrade some packages or containers and things like that. So all of these things I've talked about apps give you for free. You do not have to stand a separate stack for any of this. So the complete picture
[11:49] becomes you can vibe code things pretty fast and then because we take care of all the backend infrastructure you get an enterprisegrade application without the hassle of you standing up this these
[12:03] individual services yourselves. Okay. Okay. So in summary data bricks apps give you three main things. Okay. uh they bring apps to your
[12:17] data and AI so you don't have to ship your data out to some other external tool. All right. And every component from within your database workspace becomes just another component to allow you to construct this workflow that you
[12:30] want to build for your analytics. The second thing is security and governance. By default, databicks apps are secure and governed. You do not have to implement your own security and
[12:42] governance layer. Um when we talk about vibe coding with customers, uh this is a question that comes up a lot. How do I ensure the security of my data apps? You don't quite have to think about that
[12:54] because everything lives within your database workspace. Of course, it inherits um access and permissions of your other um uh asset and resources that you've already defined in data
[13:06] bricks, but you don't really have to think about authentication or authorization and things like that. it's all taken care of because they inherit the uh security and governance policies of uni catalog. And the last thing uh is
[13:18] that database apps are open. So you can bring any framework that you're used to. If you want to write um streamlit apps or dash or flask um you could do all of that. If you want to write custom UIs
[13:30] maybe in uh some JavaScript frameworks like react those are also supported. Okay. So this is a quick summary for everything I've talked about so far.
[13:44] So now that we know what database apps are, we know why you should use them. Let's talk about some example use cases that you can build with datab and I work with a lot of customers every
[13:56] day. So we see a lot of these different use cases. We've collected a few that come up very often. You can use database app to build chatbot UIs, right? You could use them to build data exploration
[14:08] applications. You could use them to build data API services and a bunch of other things. One of the most common ones that I see is ML inference services where people build a model and then surface it on the app. So
[14:22] a user comes in with a bunch of data and then they score that based on that model. And the model is just being served from a motor serving endpoint from within your database workspace. Okay. So there's a bunch of use cases. You'll see them a lot as you start using
[14:34] database apps. But for this session, like we said, we wanted to focus on two, right? So, we want to focus to uh uh to and look at operational workflows and we also want to focus on custom advanced visualizations that you may not be able
[14:46] to do with custom uh dashboards. But just keep in mind that the picture is much more broader than this. Okay.
[14:58] So we've looked at data bricks apps, why you should use them, example use cases, and then grounded it back to operational workflows and advanced analytics. So now we want to transition and talk about how you can design
[15:10] effective AI powered operational applications that people really want to use within your organization. This is based on practical experience that we've gotten from working with a bunch of different customers in the field. So
[15:22] we're going to share some of these uh uh principles. First of all, I'm going to talk about some some of these principles that you should keep in mind while you're designing these apps. Uh if you attended this morning's uh keynote, you know that things are changing pretty fast. So the tools and how you you know
[15:36] you use to build them, those are changing all the time. But there are some key principles that are not changing and I think you need to think about them as you keep working on your use cases. So I'm going to talk about these principles and then I'm going to let Amin take it a little bit further.
[15:50] uh take this principles and then uh reduce them into patterns that you can actually adopt as you build. Okay. So I'm going to ask you to um imagine um
[16:05] Jamila who is an operations uh maintenance lead for an aircraft management company. Right? So um uh and and as I talk about these principles, I want you to connect it back to that persona.
[16:17] So the first thing you want to make sure as you design these apps is that you want to make sure they're always ro specific. Okay? So they are built around a very specific role to answer very
[16:29] specific business uh problems. They're not built to just answer any type of question that could be answered by the data. That's number one. And they're not just built to answer a question uh from
[16:41] anyone who has a a question about the data. Okay? So it's very specific to the role because again they're operational. They're supposed to take the workflow and encode it into a series of things that you could do uh uh within an app.
[16:55] So that's the first thing. The second thing is that the app should be workflow aware. It should always remember right um the steps that needs to be taken in order to reach a decision
[17:09] and ultimately take an action. Okay. And the app should guide you or take you through the steps that you need to go in order to get there. There's a lot of things you could surface in an app. You
[17:21] don't want to do that. The most important question you want to ask yourself is like what can I remove, right? And just leave the key insights or components that lead a user to a decision and ultimately an action. Okay?
[17:33] So they are workflow aware. The third thing I want to talk about is statefulness. The app should remember what has been done already. Okay, so um as you use an
[17:47] app as a user, right, there's context that is being accumulated, right? Maybe you filtered a few um uh a few options. The app should keep state, right? And progress you as you move through uh your
[17:59] usage of the app. If it doesn't do that, it's just another dashboard, right? We've all used dashboards. You go into a dashboard, you click a few filters, right? But then when you come back tomorrow, you have to redo that. The app should remember. Okay.
[18:18] The fourth thing I want to talk about is AI augmentation. So AI is everywhere and yes, you want to include it in how you design your apps. But there's a key thing we want to point out here. You want to bring intelligence as a tool that helps you reach a
[18:30] decision and then take an action. The kind of AI you want to have in operational workflows shouldn't just be a chatbot that sit on the bottom right of your screen and ask you how can I help you today, right? It should be able
[18:43] to uh move closer to where the cursor is. As I click around, I have to see some of these recommended actions and decisions that I can take to react to some signals in my data.
[18:56] And then the last and maybe the most important thing is that all of these apps should be actionoriented. So we like to say that the app should earned in a in a in a verb. Okay. So either
[19:08] maybe I have to schedule maintenance or I have to reroute some aircrafts or maybe I have to email uh my my manager and and inform them of of something that's going wrong with my data. Okay. So these are five key principles that
[19:22] we've collected from working with a bunch of different customers and we wanted to share with you here today. Okay. So these are principles. Now I'm going to let Amin take the stage and show you how you can take these principles and adapt them into a set of
[19:34] best practices as you're building uh an app. Okay. Right. Thank you Samuel. So let's take a closer look to some best
[19:46] practices and patterns that reflect what Samuel just told us and that can help you uh build beautiful functional apps that will be adopted by your users and
[19:58] ultimately that will drive action and drive outcomes. So first one is um avoid throwing this endless field of possibilities to
[20:10] explore for your users and focus on surfacing what matters the most to them and essentially what needs their attention. A common anti- pattern we're seeing is once teams um lay the
[20:23] foundations of the data platform and they have all of the data they need. Well, we might get a tendency of just adding a chart here and a metric here and a KPI here, etc. And it could look good and interesting, but ultimately
[20:36] what we care about is are we able to surface to a user when they land on our app exactly what needs their focus immediately. Second one and Samuel mentioned this um
[20:49] AI. We like AI it can do super stuff but it's very interesting to think about the different ways with which we can interact with AI and using conversational interfaces is certainly
[21:02] one good starting point but ultimately the whole goal again is to think of the users workflow like what are they trying to achieve? what are the steps they are taking to achieve that and how can we
[21:14] surface those AI recommendations or AI insights in that workflow in a very seamless and frictionless way whilst of course keeping a separate chat tab because every app needs that
[21:29] and last again and I've mentioned this earlier as well as Samuel let's try to understand the user's workflow like ultimately what are the outcomes they are trying to reach what actions do they
[21:41] need to take to reach those outcomes, the decisions they have to make to take those actions and just make sure the app takes the user throughout that journey. So from data to insights to decision to
[21:54] action and outcome. Let's just do a deeper dive into these and then we will show you a couple of examples. So from exploration to prioritization um I think human beings uh don't deal
[22:09] well again with the endless field of possibilities like throwing endless charts and visualizations usually will lead the user to analysis paralysis or
[22:22] to decision fatigue. Um, and again, it's going to take the user further away from the end goal, which is decision, action, and outcome. Instead, and this is one great example
[22:35] of less is more, can we just surface to the end users exactly what needs their immediate attention right now? Of course, we're going to have deep dive pages. We can click to do drill
[22:48] throughs, etc. But, I mean, time is important. And ultimately what I care about the most is priority one, two, three, and here's what I can do next.
[23:00] So open on the decision path, not on uh different charts and letting the user figure things out and explore things on themselves. Chat and AI. And again, it is very nice
[23:14] to have conversational interfaces. Um but AI should not just be a chatbot tab and it's very interesting to reflect on this because this is how we're interacting with AI most of us. Um, this
[23:29] is a very good way of doing it, especially to ask those first questions we have when we're not sure of what we're looking for exactly or and this is something we do very well with Genie.
[23:41] Once we've seen something that matters to us, we always certainly going to have some follow-up questions, then we can take it up with the AI. But it's also interesting to think about all of the AI
[23:53] recommendations and agentic workflows we can do in the back end and surface those outputs wherever the user is where the cursor is and not have the user switch between tabs and ask questions here and there etc. So again it's all about
[24:06] thinking through that whole user journey and try to make it as seamless and as frictionless as possible. Put the intelligence where the cursor is.
[24:18] And last, as Samuel said, the app, the beautiful charts, the beautiful data insights, that's not the end goal. The end goal is the outcome and it is the action. with apps and the
[24:33] the fact that it can integrate with all of those back-end services and APIs that Samuel mentioned, you will have the ability to directly surface to the users um the the capability to trigger those
[24:46] actions to review actions and trigger them directly from the app, leveraging all of the powerful back end of the platform and again without having to switch between countless tabs and you know uh adding more friction into the
[25:00] workflow. So, so the end goal is the action and this the outcome we're going to get uh from those actions. And just to try and summarize all of this and touch also on what Samuel
[25:12] mentioned about how apps enable uh us to or give us uh so much flexibility into how we can present data and AI. Keep in mind that the way you present data and
[25:25] AI to your users is ultimately going to influence and shape what gets done with that data and AI and the outcomes you're going to get from that. And this is not to say we should stop using dashboards
[25:37] etc. Dashboards are very powerful when used for the right scenarios like monitoring high level monitoring making sure everyone is going to speak the same language making sure everyone is going to track the same KPIs and numbers etc.
[25:51] But if we're thinking about operational workflows and if you want to actually help users derive insights from data to actually help them in their day-to-day
[26:03] operations then apps gives us that open canvas with uh you know theoretically infinite flexibility.
[26:16] So lots of slides. Let's actually take now a look at some concrete examples. And the first one is from Talis inflight experience. So if you were here this morning in the keynote, uh you probably saw this highlighted. uh Talis inflight
[26:30] experience uh builds the inflight entertainment uh devices, the hardware, the software uh that millions of passengers use every day. So essentially
[26:43] this is those backseat screens you have and the servers powering them and the entire infrastructure powering them that you have on the aircrafts and that you usually are very happy when they are working and contain good content in a
[26:57] 12-hour long flight. Um what Talis does is they collect lots of data from these uh systems including uh usage logs uh content engagement
[27:11] data, system health data. They consolidate this data into their data platform and now they are leveraging all of the data platform with apps to build this solution I'm going to show to
[27:23] tackle some key use cases that matter a lot to their operations as well as to their airlines around uh content management around uh system health and
[27:35] maintenance and ultimately passenger satisfaction and how can we improve the passenger experience for the airlines working with I like this app so much for a couple of main reasons. First of all, um I'm
[27:49] working closely with Talis, so they are my customer and I'm very proud of this work they've done. And second of all, um for numerous factors, I can go into here through this talk, I can get myself to
[28:02] sleep for longer than 10 minutes in a flight. So, I'm very happy to work on something that actually makes sure all of those backseat screens are always up and working and containing some good content. And let me show you exactly what it looks like.
[28:22] So, I'm going to start with this chat tab again because as I mentioned, we all like AI. We all need to have AI somewhere. But I'm not going to go into too much details here. Just showing you some example of questions. What I want
[28:35] to show you is beyond having this dedicated chat tab in this UI here. Instead of having the users to come here and ask questions about content engagement, what movies should we renew,
[28:48] what movie should we retire, in which route, etc. Well, we can actually just go directly to something they see, the people in charge of passenger experience, content, engagement on a day-to-day basis and surface the AI
[29:01] recommendation there directly, whilst giving them the ability to continue chatting with AI if they need further information. So, this view here shows for a given airline, all of the movie titles they have on their fleet
[29:14] currently, the different distributors they work with, different engagement scores, and What's interesting here is one of the decision points these um these airlines
[29:28] have to make on a regular basis with regards to their catalog is how is this title doing? Should I renew it for the next cycle? Should I retire it? Should I expand it? Etc. And typically the way to
[29:40] do that before is I'm going to look at different charts and I'm going to try to make some sort of judgment call on my own and then decide. The second way of doing way of doing this is well I'm just
[29:52] going to ask AI to do the analysis for me and you know I'll look at the answers but again then I'm going to have to switch tabs go look somewhere else then make the call. How about we combine all of this into showing all of the data
[30:05] related to this movie right here. the um engagement uh metrics throughout the life cycle, the performance breakdown by routes, but ultimately surfacing directly what the next best action for
[30:19] this title here would be and why. So in this case, this is a title that's doing good. The recommendation would be to renew the license for this title and everything gets done in the same place. And just for the sake of example, we can
[30:31] take a look at another title that's behaving differently. Different trends, different um root performance breakdown. It's only doing well in one route. So here the recommendation is to retire and
[30:44] we can take that action here directly. And so we can make these calls around uh retiring or expanding or renewing movie
[30:57] uh titles or content titles in general. But it also matters to the airlines to understand how does this affect their passenger experience. So let's take a look at this other view where we get to
[31:09] see actually how each seat uh was behaving or was engaging with the content throughout the flight. uh how each seat screen uh was behaving from a system health point of view. Uh and
[31:23] ultimately again if we go back to that whole concept of insight decision action recommendation the very cool thing here is that we can combine all of those to project an NPS score a satisfaction
[31:35] score for a given flight at the flight level but also at individual seats level. And again, this would allow customer experience teams to make some calls directly without having to reach
[31:47] out to passengers and ask for their feedback. I get the data, I have the insights, I can actually know if I should reach out because you will be a detractor, promoter, etc.
[32:02] So that's just one example of how Talis inflight experience are leveraging their data
[32:20] Okay. Um, so you've all taken your flight to Floan to San Francisco. You've watched some movies on the plane and uh there's a World Cup going on. So, uh, let's do a rematch. Um, and, uh, this example is from a customer of mine, the
[32:32] Philadelphia Union. They are a major league soccer team. And sports is a very interesting area because the kind of data you get in sports is highly complex, right? It's a lot of frames per
[32:46] second, right? So in this case, there's just 25 frames per second, right? It's a lot of highly nested JSON data that you can't really make sense of. Okay. Um that's number one. But there's also event data. What is happening during a
[32:59] match? Okay. Is it a goal? Is it a corner? Is it a uh uh you know a save? All of these things have to come together somehow. This is an example of complex analytics that you cannot serve
[33:11] using a dashboard. Okay. So this is that second example that we promised you. Um so the Philadelphia Union have built um a much intelligence platform on databicks. Behind the scenes I talked about there all of those services that I
[33:23] promised, right? There's uh um uh Spark declarative pipelines for transformation. There's community connector for bringing data in, right? And then there's like Delta Lake for saving serving that data. And then there's Lakebase for doing like low
[33:36] latency serving. And then there's motor serving where we've served models and they're helping us uh predict a few things uh as the game progresses. So this is the complexity part, right? So the the union can go out and replay the
[33:49] match, reconstruct it from the uh you know uh tracking data and uh get the chance to analyze it uh a little bit more closely. Okay. So um as you look at the app, it opens with a coach view. It
[34:02] keeps memory of what the coach is doing. Every action they take as they analyze players in this case, how much distance they ran, you know, uh when they had the top speed movement. Uh all of this data
[34:14] is in service for player development and also doing postgame analysis and also doing opponent uh research so they can plan for the next game. Okay. Um, so as you move through the app, right, you
[34:27] first of all, I want you to get I want you to get an appreciation for how complex this is and the fact that you can't really serve it using a dashboard. Okay. And the second part, of course, ties in very very closely to what Amina was talking about about uh creating
[34:40] these operational workflows. Ultimately, we want an action should be to be taken off of this. It's not just showing charts. Yes, I know this player ran a lot. Uh I can go out and basically look at um different layers, maybe look at
[34:53] like uh past networks for different players. So I can I can go back and basically see uh what options did they have for for passing the ball? Did they actually did they actually do it? Okay, but that's all analytics trying to
[35:05] understand the data. Ultimately we need to make a decision. So in this case uh the union have actually integrated AI to surface some key recommendations. So if I zoom out a little bit here, there are a bunch of sequences that happen as you know they get the this tracking data,
[35:18] right? And how can we reconstruct all those sequences and then basically get a summary of what was happening during that moment. So in this case there's a lot of uh movement and scenes but all of it basically sums up to like line break
[35:31] sequences for for for the team. Okay. And then ultimately after the coach takes all these actions understand what the passing networks are they want to go uh ahead and be able to uh basically uh
[35:44] create a report and share it with their stakeholders right so this is kind of like you can think of it as that action that ultimately gets taken after understanding all of this and previously what they would have to do is basically
[35:56] stitch all of these things together right the events data tracking data and then maybe build a few dashboards uh and then take screenshots create like a PDF f and do all of that stuff uh like that. But in this because all of it is
[36:08] integrated with a bunch of different services, all they have to do is export and share to their cultures who still prefer to consume via PDFs. So, so, so, so this you can think of it as that action that you can take. Okay.
[36:21] Okay. Yeah. Okay. So, um with that, um there you go.
[36:39] With that, let's summarize it with some key takeaways. Um, so the first thing is that uh the bottleneck has moved, right? Uh, producing analytics is no longer a challenge. The challenge is what needs to happen after that, what actions, what
[36:51] decisions needs to be made. Okay. And the second thing is that dashboards cannot close that gap because they are static in nature. They don't persist state. They don't remember. And apps are the solution for that. The other thing
[37:03] that Amin talked about is the interface is a decision, right? The way you present your data ultimately determines what gets done off of it. And then we've looked at three very concrete uh shifts that make an app, right? So, first of
[37:16] all, opening with a decision, right? Uh and then putting the AI where your cursor is and then uh ending with an action, right? Or a verb. Uh and lastly is data bricks apps is why all of this
[37:29] is possible because it's not only able to stitch together different services and allow you to create these workflows more comfortably but it also gives you the uh enterprise infrastructure that you might as well uh you you might you
[37:41] might have to design manually yourself if you're building an app off from scratch. So this is a quick summary of all this and u thanks again for uh taking time to listen to us here today. We're going to take a few questions.
[37:53] Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.