So now we're gonna go back to our architectural diagram, but you'll see here that we've actually filled in some of the specific technologies that we've chosen for our claims dashboard. So starting with the front-end user interface, we've decided to go with the Web UI that will be written in a combination of HTML, CSS and JavaScript. And then that front end makes requests out to the API, which is our middleware, which we've decided is gonna be a REST API. And we're going to write that in Python using the flask library. And then our API is going to connect our front end to our back end, which we've decided is gonna be a standard relational database. And remember, this is where we have our policy and our claims table that we designed and this relational database is going to be postgres. And finally, we've added an additional piece, which is our four primary data sources, which are claims and policy raw databases, which are going to be fed into our back-end postgres database using Apache NiFi. 

It's important to remember that this is just one example. And while we've discussed specific technologies that would work for our Acme claims dashboard example, these are not the only technologies that would work for your organization. You might choose different technologies because something might just work better for you. Or you may have a technology in-house that's preferred. So, for example, you might prefer to write your REST API in Node JS, either because that's your preferred technology solution, or maybe that's just what your API developers know. So use this as a roadmap and a prototype, but not necessarily the be all and end all that you have to do a similar BI dashboard tool in exactly the same way that we discussed it in this course. 

So finally the moment of truth has arrived. We're going to take our finished product, or at least the first version of the finished product, and go back to the Acme claims team, and we're going to show it to them. And hopefully, if we followed the development plan that we came up with all the way back in the planning stage, we're gonna have something that's very close to, if not exactly, what they want. And the good news is, hopefully we've made our claims team very happy. The bad news is what often happens is when you do a good job in these sorts of projects, people want to keep adding more onto the product, so this does tend to be a bit of an iterative cyclical process. You do need to be a little bit aware of scope creep because of that, but in general it's a really good sign when users say this is really wonderful, can we expand it? Can we do this and that and another thing?  That means you've done your job well and you've built a good product that's useful for your users. 

So that's our case study in a nutshell. I hope that everyone listening to this course got a bit out of it, and I know this was a bit of a quick hit, but hopefully it gives you a good overview of how you would design a BI dashboard and hopefully the real-world insurance example, bringing it back to what you would do for the Acme Claims Department, helped to make this process more concrete. Thank you so much for your time and attention, and now I turn it back over to Chris to wrap things up.

Lectures

Introduction - Case Study Scenario - Planning - Building the Database - Front-End Design - Middleware Design