CapTech Trends

Machine Learning for Beginners

January 05, 2021 CapTech
CapTech Trends
Machine Learning for Beginners
Show Notes Transcript

If your organization is new to Machine Learning (ML), there are some best practices and common pitfalls you must be aware of. Often, organizations become interested in the promise of ML, or they want to play catch-up with their competitors, and they decide that it’s time to adopt ML too. But it’s not something that happens just because you want it. Often, leaders don’t know what problems ML can solve for or how to make the right business case to reach great results. To be successful, you must first build a strong core team comprised of the right cross functional talent who know the best practices to follow and pitfalls to avoid. In this podcast, Vinnie Schoenfelder, Tom Estella and Ramon Matos dive in on the details of making your new ML initiatives work, and yield powerful results.

Speaker 1:

[inaudible] hello.

Speaker 2:

Welcome to cap tech trends, a place where we meet with thought leaders and subject matter experts to discuss emerging technology design and project methodology. I'm your host, Vinny Schoenfelder principal and chief technology officer at CapTech consulting today. We're discussing machine learning for the non-expert. We'll go beyond the basics for sure, but we'll be taking the perspective of someone who may be entering into machine learning for the first time or wants to move beyond white papers and into experimentation. I have two guests with me today. First is Thomas Stella. If you're a frequent listener, you'll remember Tom from an earlier podcast, Thomas, a thought leader in advanced analytics and machine learning and Thomas, a managing director working out of our Atlanta office also with us today is Ramon burritos and engagement manager who recently delivered a machine learning initiative. Ramon is a director and also works out of our Atlanta office, Tom Ramon. Welcome. Thanks Vinnie. Thank you, Benny. Great. So why don't we just get started with, um, the very beginning, I don't, I don't necessarily want to take a rigid approach of a project life cycle through this, but maybe loosely. So let's start at the beginning. Uh, you're new to machine learning. You want to dig deeper? Uh, what's the first thing you do.

Speaker 3:

Hey, this is Tom. The first thing we do is we try to come up with a business idea. So sometimes clients come to us and they say, Hey, we have this concept. We have this idea of what we want to do. And sometimes they just say, we've got a lot of data, a lot information. We're not sure exactly what we want to do, but we know we want to start getting into machine learning. We want to get into advanced analytics. Um, so the first thing to do is to kind of really find out what that concept is that we're trying to work on. Now, if they don't have an idea or we can't build on it, then we'll start with a workshop to just start to understand what it is that they're trying to accomplish.

Speaker 2:

If they don't know what they can do with it, why do they feel a need to do it? Is it external pressures that maybe they're being left behind? Competition's doing it. Where's that desire coming from? If they don't know how to apply it? I think one of the things here, um, they need, that's actually a great point, is that it, you know, industry-wide, it's a buzz word. Everyone's talking about it. You see it in the news. Uh, you see other clients, various colleagues talking about it, and it's just a general interest in, in what machine learning advanced analytics can do and help them to solve things. I think that's part of, part of the equation there.

Speaker 3:

Yeah. And they also, they, you know, when you, when you hear about it, you think it makes us more efficient, it reduces costs, it increases revenue. It does these things. So people are interested in one to understand what what's the art of what's possible. So how could we, how could we leverage this to make a more efficient environment?

Speaker 2:

So where I get wrapped around the axle on that from a starting point, uh, is you have people in the business who know their industry really, really well. Um, and they maybe are light on machine learning or haven't made the paradigm switch in their head in terms of how to think and there's way. So they they're, they're struggling coming up with a business case. You can hire a data scientist, uh, but that person coming in may be really strong in math and statistics and whatnot, but they don't know your business. And so how do you take those two extreme positions and find something meaningful to work on that will also be sort of a quick win? So you're not spinning your wheels.

Speaker 4:

Tom hit on this one a little bit. Um, in the previous part of the conversation around, uh, the workshops, just coming up in ideation to understand what are some areas that are ideal in the, in the business environment to be able to address with advanced analytics. But I think another part of that is also needing to make sure you have really good subject matter expertise within the business, around the business processes, what they're trying to accomplish and good understanding with some stakeholders that know and understand the data, the data that's going to be used for the analytics.

Speaker 3:

Yeah. I, you know, often it's, it's about asking the question of what do you do today that you want to do better? Um, you know, if you're, if you're marketing to people and you want to market to people that are more relevant or more targeted, if you are, whatever it is that you're trying to do, um, let's just talk about those business problems you have, and let's get 10 of them on a piece of paper and we can then start to narrow it down to which ones are, are best suited for, for advanced. Yeah.

Speaker 2:

Right. And if you're in a workshop situation, you have your data engineers in there to tell you whether or not they have the right or enough data to do to do that. And you have the machine learning people in there to know what kind of models may be available or how to build them. Right. So I guess, I guess that's the full, is there anyone else who needs to be in that room or developers in that room? Are there any usability people in the room thinking about the front end or the customer experience?

Speaker 3:

There's actually a lot of people. In fact, I think you have to have a full team there. So if you think about marketing, as I just said, right. And that's just one example, um, w we have to understand, could we actually market to them? Do we have their contact information? Do we know what we would say to them, why we would say that to them when we would say it to them, what we're trying to, all of those different pieces. So you may need UX people, you may need creative people. You may need strategists. You, you really need a full team of everyone together to kind of come up with the ideation of it.

Speaker 4:

I would add in there the product management team. So a lot of the things, um, that we're looking at from an analytics standpoint potentially will be leveraged or used by a downstream application. So having the product management team or representatives from the applications team that are going to be consuming, the output of the analytics being part of those conversations are important as well.

Speaker 2:

Gotcha. Uh, maybe you guys can hit on this for me. One of the things that, that I've seen people struggle with is that paradigm shift I mentioned earlier, uh, you know, probabilistic models in place of deterministic SQL queries, right? So I'm thinking about what's changed and what, and how w how the problem solving changes and how the workflows change. Um, do you see that being a problem that you guys have to a, um, a mental model you have to work through early on in machine learning? Or is it really not that big a deal when people make that turn rather quickly?

Speaker 4:

I think he hit on this one a little bit, Tom, cause I think there's some, some other pieces here, um, that I, you know, from, uh, the, what type of analytics we want to use, that's going to be part of the deeper conversation around what we want to solve and why, and, and also just the general data, right. We've mentioned that a couple times, but I think there's a, there's a deeper sense. And I think th th the example that you give around the pieces around, like, uh, let's just say that the Coke bottle in the ocean example that you like using maybe, maybe hit on that. And I think that that's going to help some of the conversation here.

Speaker 3:

Yeah. I'll start with, like, when we talk about deterministic versus probabilistic deterministic, if you can, if you can create a deterministic query to understand whether someone's where there's, something's happening or not happening, there's no need for machine learning. There's no need for artificial intelligence. There's no need for any of this. Right. If I can tell you that, uh, um, I'm trying to think of an example of that. But if, if we look at a, um, if we're trying to predict fraud, and if we look at something and say, what, without a doubt, this is, if they break into the vault of a bank, it's fraud, they've stolen something. Well, if we see that they've broken into a vault, then we know they broke, they've stolen something, but it's, it's the other, it's the smaller, um, it's, it's the things that are not as clear. So when we try to predict whether or not something may have happened, that's when we talk about probabilistic modeling. Um, and so Ramon, I think the, the, the, the example you were given is really to talk a little bit differently about what modeling technique we use instead of do we use modeling, or do we use, uh, uh, queries? Um, but when it comes to a query, um, you know, they're, they're really useful. That's we would rather create queries and just say, Hey, is this happening? Is that happening? That's much simpler. And it gives you a more determined answer. Yes or no, what happened or didn't happen? Um, modeling comes in, in the, in the gray areas. So it's not black, it's not white. We're not sure exactly where it is. Well, where should we spend our time? So we try to get the, the transactions, the customers that are on the cusp. We're not sure whether it's going to go one way or the other, and those are the ones that we're able to kind of push in the direction that we need, eat them to go.

Speaker 2:

Yeah. I think about workflows a lot too. Like if you take an example of, um, college admissions and, you know, a bunch of applications are coming in and you run them through a machine learning model, um, and there's an 80% chance that these people would, you know, not be good fits, you know, fail at the first year or whatever else you can't just reject them. Right. Because there's a, there's a 20% chance you're wrong on all those people. And you hate, you'd hate to have to try to explain that that's why somebody wasn't accepted, but you could flip it and say, you know, we can accept without a ton of like maybe a much lighter review process. The ones that we, that we predict will do very well. And the other ones go into a more human process. So I'm curious about those work, like optimistic workflows versus pessimistic workflows and how you ensure that the models are being used in an ethical way.

Speaker 3:

That's a, it's a great point, right? So you can, if you thought of college admissions, anyone that received over 1550 on their SATs and had it over X GPA, it can be an, almost an automatic approval, right. Or a two question, do you have this? Do you have that? And we approve it's the other ones that, that, that are in the, in the middle that you can say, which ones do we spend the most time on? So there's a willingness to go deeper because you're right there on the, on the cusp. And based on the statistical model of who was predict, who was, um, built on the fact of who was accepted last time, we could say their likelihood to be accepted. And that could give us a better understanding of what are the key factors, who are the people at the top of the priority list, all of those different,

Speaker 2:

Yeah. I was talking to a university, I guess probably a year ago. It's just pre COVID. And they were, they were saying that they were looking historically, uh, at, who ended up doing well and looking at those models. And it turns out that a lot of the traditional things they looked at, like you said, um, a couple of key elements in many, many cases, they were, they were wrong. They, those, those students did do well. Yes. But the students that really did well, um, perhaps didn't have the, the, the easy markers they had, you know, 10 or 15 other subtle markers that would be very difficult to suss out. Um, so it's, it's, it's kind of encouraging to think that it's not reduced to SATs and GPA and whether or not you were, you know, in one or two clubs or, or sporting teams, but that there's 15 to 20, let's say more subtle things that machine learning can help us understand. And so they were using those findings after people graduated to then build models, um, for admissions. So, so what are some other, um, key use cases? So we're, we're coming new to this, and it's going to be a lot of people on this call who are thinking through their first problems. Um, let's just talk through some common use cases since we're in the getting started section.

Speaker 4:

Yes. And, um, one of the things, and actually, but before we go into that one, I wanted to give you guys another example, um, on, on the machine learning. So, you know, where we are today in the world with the pandemic, uh, one of the things that we worked on on our client was a COVID-19 analytic around, uh, fraud, waste and abuse on trying to understand how COVID was impacting, um, health care and the needs of the patients. And, um, what was that resulting in that? This was actually an interesting one. Tom, if you recall, we worked on this one very early in, uh, in the spring timeframe. And as a team did some analysis on, on the COVID 19 data come to find out that they ended up identifying areas where, um, behavioral health was really, really, really impacted as a result of the shelter in place, um, that were happened at the beginning of the year. Right. And, um, as, as they were looking through that, they further dissected and looked through the data and identified that this was actually an area that was getting a lot of, uh, fraudulent claims coming in as a result of telehealth being kind of coming in and fresh, tele-health kind of picking up. Um, and, and patients needing to have those visits. They typically don't have, um, on a day-to-day basis and they ended up having to have those more often as a result of the shelter in place. So that was another area of kind of like the university example that you gave, where it helped to identify some things and to provide some predictive things, to look at as a result of the analytics that were in a positive way by identifying who needed to help, um, not necessarily that it was fraud, but just at some certain areas, certain patients needed more help than others as a result of the shelter in place. And the impacts of that.

Speaker 3:

Yeah. In that use case, we, for, for this, uh, for the healthcare industry, we often predict what normal behavior is for providers. So how they interact with their customers, how they interact with their patients. Um, we were able to very quickly see the changes in how they were interacting. So how often people come in, how long they stay on a phone with the person, all of those different pieces, we were able to predict that, and we were able to see and create a new profile for that, that, that, that interaction, and that allowed them to understand what was different from that profile and who was acting abnormally compared to their th their peers. Um, so we were able to help find fraud, waste, and abuse within that sector.

Speaker 2:

Yeah. So I hear a lot about fraud detection, and you guys have mentioned that a couple of times, just like rapid fire, give our audience a couple other, um, common use case.

Speaker 3:

Sure. One of them is a financial services. So understanding on a general ledger on a GL file, um, if you were doing an audit, which transactions are the highest risk, which ones look the most abnormal, that's a great one to use

Speaker 4:

W w workflow. So, um, looking at, uh, the outputs in analytics to help end users prioritize the work for the work that needs to be, um, either riskiest or most important or highest value and helping them to identify those quickly is another example of, of the use case.

Speaker 2:

Yeah. And more generally, what I'm picking up from talking to you guys is common behavior versus uncommon behavior. So one of the ones I like to think of from a, from an internet of things, uh, healthcare perspective is wearables. Uh, I know that, uh, for the elderly, uh, you know, falling, breaking a hip is a very serious thing. And, and they're able to, uh, now study, uh, the movement and behavior of people four or five days prior to that fall. Uh, they know how they're walking, how the gate has changed, uh, the speed, um, whether or not, you know, their patterns are different and they can predict that a, that a fall is coming and then do preventative care. And again, from a workflow perspective, there's no harm there, you know, reaching out to somebody and checking in with them, doesn't create a negative experience.

Speaker 3:

Yeah. W we actually, I actually had a previous life worked on that exact project. We were predicting activities of daily living. So his mom getting up, making three meals a day using the restroom, and then the correct amount of times bathing the correct amount of time, all of those things just based on sensors within the home, and then able to say, mom's not acting the way she did last week. Right. So maybe you should just check in as well as having red flags that say, something looks extremely wrong today. Um, but it gave people, uh, just a little feedback as to how say the elderly are doing.

Speaker 2:

Gotcha. Great. Let's, let's move in more into the implementation of the project. Um, is this just like a regular software development life cycle? Is it, we got agile, we got coaches. We do stand ups. We do a two week sprint. We're good to go.

Speaker 4:

Uh, it's, it's actually much, much harder and more complicated than that. Um, because there is, there is no right answer to begin with. And, and, and even project set up and working through understanding the problem, understanding, um, as you're doing the development work, that the iteration, the back and forth and the discussion that has to happen between, uh, the data scientist, the business, SMEEs the data SMEEs to understand the outputs, that iterative process. Um, you want to try to fail fast and try to understand, um, what adjustments you need to make, but it's a lot harder from that perspective where you can't time box it in certain phases and really worked through from initiation to delivery.

Speaker 3:

Yeah. There's one other thing to remember here, when we talk about the implementation or the actual creation of this thing, it's a solution, right? So it's not going to be just the prototype of a model like this statistical models, one aspect of this, but connecting to data sources, storing that data, then there's the creating of this model. That's going to predict X, Y, or Z, whatever it is you're doing, then that has to be output, put into another system to give to a frontline person that can then make a decision and do something based on that. All of these different components need to touch each other and work together. So it's not just the data scientists there. It's really a team of people that work on a complete solution, architecture, not just this one little piece in the middle.

Speaker 4:

And that's a, that's a great point, Tommy Kent. It is not, it cannot be a single point solution because of all of the downstream and upstream items that need to connect together to be able to get the data to the analytic, to the consumption end, to end, to be able to leverage the outputs.

Speaker 2:

You said, you have to fail fast and, and keep trying to get it right. How do you know you're right? Uh, we're making predictions. So let's say you're, you're deciding whether or not to, to make a bank loan or write an insurance policy. You're not going to know for potentially a year or two that someone's going to default or fail. That was a bad idea. So as you're creating these models and looking at the results, how, how do you validate some of these long running threads as to whether or not you're you're in the box?

Speaker 4:

Hey, Tom, the way that I was thinking about that when I said it earlier was, was more so about analysis paralysis, right? So I think if you can hit more on, on what that really means from an analytics perspective, I think that we'll go deeper into those details.

Speaker 3:

I'm going to, I'm going to go to Vinny's question. I'm going to write back to you for my, but Vinnie T to your point, when we build models, we look at past behaviors and past data. So we look and we build models and say, if we scored last year and implemented this, how many defaults would we have in the mortgage industry? From that we can say, yes, we are staying at the 1.5% default rate that we expect or whatever that number is. Um, so we actually take past results and we say, we hold them out from our modeling sample, so that we're now building the model on that data. And then we score it and say, how did we perform? That gives us an, an understanding or an idea as to where those cutoffs are, those score cutoffs to say, if we were to accept mortgages at this rate, here's we would have this default rate.

Speaker 2:

Well, that, that makes the assumption that people have that historical data available. Right? So I, I know as a, as a prerequisite to doing machine learning, it's getting your big data, right. And getting, you know, valid data, enough data, you know, uh, so I guess the, the, the, the takeaway is to make sure your data engineering, uh, is in place as early as possible, because otherwise you're not going to be able to do that sort of historical trending, uh, to validate your models. Right.

Speaker 3:

And now for remote's question, and that's what I like to say knowing good enough is good enough. So when we're building models, it's, it's almost more of an art than it is a science there's scientific factors and, and guardrails on the process, but it's, it truly is an art of how we create that statistical model. Just like any other piece of art, you could always make tweaks and changes. And at some point you have to say, this is good enough, let's move to the next step in the process. So understanding when, when, when to w when to finish your masterpiece is, um, is, is a really difficult part and just takes years of experience of doing it.

Speaker 2:

Yeah. I wanted to talk about bias too, and I didn't know if we should introduce bias in this section or the previous section. And what I mean by bias is kind of two parts. One is, um, knowing that some of the data that's collected may be biased just because the nature of what's being collected, what is, is being, um, and then the second part is when you do show there's those, uh, the results of the models bias in the, in the analysis of that data, right? So do you talk about bias and think about that in the first section, when you're trying to find what problem to solve, or you free of that and just brainstorming. And then as you get into the implementation, you start worrying about those constraints. Where does that come in?

Speaker 3:

That's the data scientist. So that's really after you've kind of gotten through the ideas and the concepts, you've gotten the data set there, there's ways that you can, you can, you can adjust your data set to make sure that you're not being biased. There it's actually one of the Vinnie we've talked about this before. It's one of the reasons that, like these point and click solutions for advanced analytics, I think are, um, are, are dangerous. Um, yes, you can create the model, but if you don't really understand the data and the mathematical process behind it, there's a good chance that you will have some bias in there, or you will have something incorrect about your data infrastructure. So it really is important to have a data scientist, someone who's done this before to understand what that data is that goes into those models. Now, those tools, they make my life easier as well, because once that data is prepped properly, I click a button and the model's created right. You gave that example yesterday that I, or the other day that I,

Speaker 2:

Yeah, I always, I always think about chainsaws when I think about automated tools. So just because you can put a easy start button and a nice heavy strap on a chainsaw, you shouldn't hand them out to a bunch of five-year-olds and send them out into the woods, right. There's someone's going to get hurt. So I, you know, I, I joke about that with other technologies as well, but I think it's relevant here, because especially when you think about the biases and, and the predictions you're making, those have real impacts on people's lives. And so to that point, going further, we have bias. We also have the fact that models deteriorate over time. So they may be very accurate today, but then the nature of the data you're collecting, and the fact that you're acting on that data can change the data that you're collecting. Right. Cause you're treating your customers differently, perhaps. So how do you ensure weeks and months into this, that a bias is not being introduced and B that your models haven't deteriorated to the point where they're no longer accurate in who does it, how does that work? What's the process.

Speaker 3:

There should always be a measurement plan at the backend of your model so that you understand how it's performing, and you can watch that over time. So you'll see that degradation, um, if the models not performing at the same level as you go forward, um, if you're, if your model is more of a machine learning model where it's actually recreating its coefficients on a regular basis, it should be keeping up with the trends within the data. But if it's not that type of model, if it's more of a deep learning model, then you, you will have to kind of recreate that, recreate that process on a more regular basis. What I fear most more than any of that is the data sources that you're getting your data from change. So before we were building models on this data, but now that data is not in that system anymore, it's coming in in a different way. And maybe it's being captured in a different light. And that could change the, the, the actual predict predictiveness and change the accuracy of your model. So you do have to continue to monitor that model over time and see where those, those blips are happening. And when there is significant change in the results, go in there and understand why it is

Speaker 2:

Right. So, so what are some common pitfalls then I've tried to throw a couple out there around like bias and model deterioration, but from your guys' point of view, if you were to give like the top three reasons, these initiatives fail. And even if, even if it's restating something, we already said, what would you say are the common?

Speaker 4:

So Tom, I'll start us off here. I think that the, to begin with, and I know we've said this one a couple of times, but it is so, so important to understand the problem that's trying to be solved or to the decisions that you're trying to help make. Um, with, with the analytics, the other one, there is also making sure that you have strong stakeholders that are bought into, um, into the work and strong executive sponsorship, driving the initiatives so that when, when the decision-making needs to occur, it's being made, um, by, by the right stakeholders that are going to be impacted or going to be driving those decisions based on those analytics.

Speaker 2:

Would you add anything to that, Tom?

Speaker 3:

I, you know, I, I have a great example of that. One of what Ramon just said. So w we created, um, a process that was finding fraud, waste and abuse within, uh, financial services. So for audit purposes. Um, and when we, we, we built this tool, it actually saved the client like 75% of their time and effort of all of the data manipulation, all of the statistics, statistics that they were doing in Excel at the time, all of this was automated done online, quick, cheap, easy. Um, this was a, this was a reseller of this and the, the executive sponsor at the end said, now that we have this, we don't have to sell it. So forget it. We're not going to use it, even though it was a better solution, it was created, it worked better, it was faster. It gave better results. The executive sponsorship, wasn't behind the fact that we'd have to change the entire business model. And so it sat on the shelf. So you really do have to understand kind of the entire, how this is going to work completely and have your executives behind you.

Speaker 4:

T take that point just a little bit further. There also, Tom, um, a lot of times the, the analytics potentially they're going to be causing a change in a business process. And if you don't have the business stakeholders bought into, uh, what, what you're trying to solve for and understanding that there could be downstream changes to, to the business processes, you're might be building something that's not going to get used. It's not going to get adopted because people are not going to be bought into the, why are we doing this? Especially if it changes

Speaker 2:

What people do for their job or, or actually removes responsibilities.

Speaker 4:

Yeah. And in all, in all reality, that could be a fear that I'm going to lose my job as a result of this automation or optimization of the process. Right. Um, and this is part of the change management aspects of the project that need to be taken into account.

Speaker 3:

I have another pitfall and this happens a lot. So you really have to focus on, on, on this. I remember actually being a pretty junior person. This is probably 20 years ago, and I was asked to build a statistical model for the company I was working for. Um, and I built it, but I, they expected me to do all of the data engineering at the front end, which I did. Um, I wasn't a data engineer. I was a data scientist, but I did that work. It wasn't the most efficient way of doing it. And then do all the system, the data visualization on the backend so that it could, it could be presented to the, to the end user and then do the system integration. So that, that it, it worked in the system. There was probably five or six different roles that I had to play on that, on that team. And I did them all. Okay. I did the data, scientists were great, but the other four roles, I probably did a good job on them, not a great job. And the solution was slow. It didn't have the UX aspect of it, of the user experience on the backend. All of those different pieces were done on an average rate, not on a great rate. Um, really you need to look at those different pieces and have the right person build each of them. I think that's an important part to think about.

Speaker 2:

Yeah, we spoke about this. I probably in the last podcast that we did together, where, uh, just because of data scientist has the word data in the title, it doesn't mean they're a data engineer. Right. And so these, these are very different roles and you probably need what one data scientist for every six or seven data engineers you have, because it's just gonna take that much more work to get the data clean, the right data, the right volume, the right velocity, all your five V's of data. So, um, yeah, it's not a one-to-one and it's a different skillset, right?

Speaker 4:

Yeah, that's right. The other point there, um, Vinny is the, um, uh, prototype doesn't necessarily mean it's a production ready analytic, right there. There's, uh, engineering best practices that have to be accounted for in hardening of the code to make it, uh, production ready. And that takes time to go along with the overall effort.

Speaker 2:

Yeah. One more, one more question on that, because I remember, gosh, four years or so ago when, um, it was a little more immature from a tooling perspective, uh, you would see, um, machine learning happening on someone's laptop or on a, on a server under the desk kind of thing, as opposed to the mature application development that the, that the systems integration, uh, teams will be working on. Um, and I know that for a lot of that, that that's fine because you're not creating a production element that needs to be used in production. You're using a model that can then be exported and used in production. Right. So is there a more formal, um, lifecycle, I mean, maybe not a full SDLC, but something that's more formal now in terms of creating these in, in more robust environments.

Speaker 4:

And I would say, so that's actually one of the things that we've, we've, we've worked on our current client, um, is about standing up in an analytics, um, development process, uh, to help with the ideation help with the intake of the analytic help with the prototyping, um, and then working our way through review and analysis with the business stakeholders and then working towards, um, moving into production as production ready code. And so, so by helping put that structure in place and helping them understand the different phases of the life cycle, that it takes to get the models into production or the analytics into production, it's, it's helped tremendously, um, with business stakeholders to understand, you know, I'm putting an ask now I understand what I'm getting and why, and I I'm able to participate and be a voice of within the process to understand the analytic, um, and to validate the analytics is going to help me.

Speaker 2:

Great. Thanks. Um, so yeah, uh, closing thoughts, uh, I, I kind of want to get a little bit closer to the metal on this one and say, okay, if you guys were advising me, I've got a technical background, um, used to be developer, done architecture work, and I want to get into this. Where do you point me? Do I go to AWS? Do I, do I go to Azure? Are there, is there a machine learning in a box, you know, data science in a box or as a service? Um, what's, uh, what's a good place for me to go maybe a good website, or what, how do I get started?

Speaker 3:

My personal opinion is Azure and AWS are almost interchangeable. They both have tools that have the ability to do all to do everything that we need to do here. So whichever you're more comfortable in you've worked in, in the past is probably the right one for you. Um, in terms of how to learn, how to, how to do this again, you're going to start with the business problem. So understood understanding what it is you're trying to accomplish and how you flow through the solution is going to be the most important part. So work with someone to understand the solution architecture, work with them, to, um, understand the different components, and then start to focus on each of those components of the solution and learning how to do each of those so that you, you grasp the concept of the solution.

Speaker 2:

It sounds to me like we've said this a couple of times without coming out and saying it takes a team. So maybe the best way to get started, uh, if you're looking to get started is to find a couple of colleagues that are in those other disciplines and forming like a small, uh, you know, study group working team or something that can do a proof of concept. Um, get someone who knows the data to get someone who knows the data, science, get someone who knows, um, you know, some of the cloud tooling and such, and just treat it that way. Um, I guess I would also suggest this is probably a common pitfall as well, not biting off more than you can chew, right? Doing something that has a small turnaround time and still has a, an obvious impact to the business so that you can get some excitement. Um, and of course, that's just the best practice with technology. Anyway, get small frequent wins, get people excited. You get that momentum behind you, as opposed to taking months and months and months. And then people questioning the output

Speaker 4:

And, and set your goals. So have a goal. We're going to do X. We're going to be able to predict why we're going to, it should be better than Z have those goals and either hit them or don't hit them. But if you just build it and say, let's see what happens. Um, you never know if you're successful

Speaker 2:

Or not. Yeah. State of vision. Yeah, it's

Speaker 4:

Good. And just from an expectation setting standpoint, it's not a magic bullet, right? This is not, this is not an easy button to get things done. It takes, it takes time. It takes effort. Um, it takes definitely subject matter expertise across all the disciplines that are going to be doing the work and have realistic expectations on the, on the outcomes and how long it's going to take to, to achieve those goals.

Speaker 2:

Great. Well that wraps up this podcast. Ramon, Tom, thanks so much for joining us. Great input. Really appreciate it for those listening. If you haven't had a chance to yet, please subscribe. So you can be notified when new podcasts come out. Thank you guys. Thank you.

Speaker 1:

Thanks that

Speaker 2:

Our contents in designing this podcast are the property of CapTech or used by CapTech with permission and a protect under us and international copyright and trademark laws. Users of this podcast may save and use information contained in it only for personal or other non-commercial educational purposes. Nobody uses this podcast may be made without Catholic's prior written permission, Catholic Nixon warranty guarantee or representation as to the accuracy or sufficiency of the information featured in this podcast. The information opinions and recommendations presented in it are for general information only. And any reliance on the information provided in it is done at your own risk cap, technics, no warranty that this podcast or the server that makes it available. It's free of viruses, worms, or other elements or codes that manifest contaminating or destructive properties, Catholic expressly disclaims any and all liability or responsibility for any direct indirect, incidental, or any other damages arising out of any use of, or reference to reliance on or inability to use this podcast or the information presented in it.