Closing Keynote: Deliberate Data Engineering - New Solutions to Notorious Data Challenges

When there’s a generational shift in technology, you have to reevaluate how you approach specific challenges – sometimes even how you define the challenge in the first place. Just because you did something a certain way in the past, it does not mean you should still be doing it today.

In this session we shall explore new solutions to a number of notorious data engineering challenges.

Transcript:

Jack: Well, I don't know about everybody else. But I gotta say, pretty excited. There's lots and lots of things that have been really interesting that people have talked about today. But I think that the other thing that I think is, is that it can be a little bit overwhelming, it can be a little bit, kind of scary at times, I know that everybody's got, you know, data engineers, we're frequently pulled in a bunch of different directions by different, different requirements, we don't necessarily control the data and who's producing the data, we now have a bunch of different business users who are also desiring specific things from us. And that can be a lot of demands on us. And so what I suggest when you're thinking about challenges where you're might be overwhelmed with something is to try to be deliberate.

And that's really what Matthew and I want to talk to you about today. And there's really kind of, you know, deliberate is about making choices, trying to think about things in a concrete way, and really sort of evaluate your options. And when we talk about deliberate, I think there's two things that I'd love for people to take out of this conference. The first is that if you can take out of any one session, one idea to solve one tactical problem that you have, if you can come up with a new way to solve something, if there's something that's been bothering you and you heard someone talked about that, that would be really great. I think the other thing is, is what Matthew and I want to talk about, which is the more the strategic side of things, which is, there was often a situation where you've made decisions, because, you know, at the time you made a decision two or three years ago, the decision made sense, you didn't know as much about the information about your particular use case at the time. And you made that decision, and you kind of move forward in that way. But sometimes it's important to take another look at those things.

Because there's two things that happen over time. The first is that you always learn more about your use case. And then the second is that the world around you is also changing all the time. So there's new technologies, there's new solutions, and that can potentially help you solve your problem in an easier way. And so how do you do this? Well, when I think about this, I think about it in the context of a brain twister that I learned when I was younger. It's a pretty simple brain twister, if you've already seen it, you may know the answer to this. But it goes something like this, imagine you have, you know, a grid of dots, you know, nine dots in a grid, and you ask someone to say, Hey, I'm gonna take a pencil, I want to draw a line through the dots, I need to have a contiguousline with no more than four segments. And can I cross out all the dots. And so when people will sit down and do this, and usually it's with kids, right, the kids will sit down and do this, they'll try to do it. And they'll come up with line, the start with a line here, they'll say, Okay, I'm crossing out through some of the dots, I'm crossing out some more of the dots, I'm crossing out more the dots. Okay, I've just used up my four lines. And guess what I've actually missed a dot. And what's happening here is something that happens in our day to day lives.

And that is that we build these boxes around these dots. So there's no box here, I just built a box when I drew these lines. But the reality is, is that we naturally imply an implicit box in this around this problem. And that makes it impossible to solve. And so the actual solution to the problem is to actually go outside the box and say, Okay, well, I'm gonna start working outside the box, write these lines separately, and all of a sudden, I can find the solution. And this is the same thing that we need to do when we're thinking about data problems. You know, if you're working on data problems on an ongoing basis, it's very natural to think about every problem as a tactical problem. But sometimes you might find that it's just impossible to solve. It's too complex, it takes too much time, there's too much technology that needs to be built. And in those situations, you need to think about the frame that you're working within and think about this diagram and start thinking, Am I structuring my questions too narrowly. And this is just something that an engineer always needs to do is to say, Hey, is that is the set of conditions under which I'm trying to solve my problem too narrow, and I need to expand the frame that I'm focused on.

And that's really what we want to talk about, here's four different places where we think there's some really interesting changes in the market. And those changes in the market mean that there's probably an opportunity for you to expand how you think about things, to potentially give you a new tool for a way to solve things in a long term basis, you know, tactical wins, things that you can take out of these other sessions might be able to help you on a short term basis. But in order to be successful in long term basis, and get ahead of the ball, instead of always feeling behind. It's all about making strategic decisions to improve things. And so there's other topics. The first one that we want to cover is about data lakes. And so data lakes is a really interesting story. So data lakes, originally, they were about cheap storage, right? So 10 years ago, storage vendors were killing everybody on how much it cost to store something. In this thing.

Hadoop came along and said, Hey, we're gonna give you a much cheaper way to store things. And so people were like, great, if I can have storage, that's two magnitudes cheaper, that's just a big win to me. And I'm just gonna start throwing all sorts of things in that. And that wasn't really an analytic solution was just solving for storage, right? But very quickly, people were like, Well, wait a minute, if I can use that for analytics as well, that would be a very, very powerful paradigm. And so they started say, hey, let's try to treat this thing like a database. And what happened was, it didn't go very well, because the reality was, is that were 20 or 30 years of maturity in the data warehousing market. And what I described as open storage approach to things was much more limited in what it can do. And so there was a bunch of things that data warehouses has always provided us things like transactions and performance, the ability to things like snapshotting, and rollback, those were very good in the context of data warehouses.

And then when you try to work with things that were in the sort of storage environments in this sort of data lake environment, or what we conventionally called Hadoop, or big data, it was very, very hard to solve these problems. And so there was a bunch of technologies that came out, people got very excited, because the idea of open storage, and the ability for multiple systems to have first class interaction with that storage is very, very powerful. The downside is, is that the delivery wasn't there in the products themselves. And so we had a substantial amount of disillusionment. And probably a lot of you went through that process and actually got very frustrated with early technologies like high for Impala, or hawk or early versions of Spark SQL and shark which came before Spark SQL. And so those technologies, really a lot of promise, but didn't necessarily work well. And so what happened is people started to trend back towards traditional data warehouses, which made a lot of sense, because those were mature, that allowed you to solve your problem and really focus on your business, as opposed to like these dynamics of all these sort of intricate technologies that were relatively mature. Now, that was 10 years ago, and over the last 10 years, things have changed, right.

And so if you five years ago said, You know what, I'm burned out on this whole model of open storage. And I'd rather have the benefits of private storage. That made a lot of sense five years ago. But guess what things have changed. And so what happened is, is that you saw the rise of several different open technologies. Open technologies, like iceberg, and delta Lake and hoody. And those open technologies said, hey, you know, what, we can actually continue to provide an open storage approach to these things, but still saw the same set of capabilities that traditional data warehouses provide. And so all of a sudden, we're now in a new world, where there's a lot less distinction or difference in sort of benefits of one technology over the other. And that really allows you to say, hey, on a per use case basis I can make a choice about what kinds of things I want to do. And I can stop worrying about sort of missing out on a particular approach. So when you're thinking about things, thinking about storage, and how you approach it is a key way to sort of consider what kind of options you have. So next up, I'm gonna have Matthew take over, he's going to talk a little bit about the decoupling of BI and some of the opportunities there.

Matthew: Right. Thanks, Jack. So if you've been around data for any amount of time, you'll realize it's very close to what's happening with fashion. stick around long enough, you'll see new themes come back. And I'm going to talk about one today. So the rise of headless BI, which might sound a little strange, but when we think about what does the analytics consumption look like today, it is exploded. We've got people and dashboards, desktop BI solutions, ad hoc analysis and excel, data scientists in notebooks, across the whole gamut of solutions out there, people are consuming data more rapidly than ever before. Now, if you went back 20 years ago, it was generally always through one layer, you might be using IBM Cognos or OBIEE, or business objects, and everything was very much controlled. Then we saw the rise of Tableau Desktop BI solutions, which gave a lot of flexibility to business. And so business took advantage of that. And in doing so, they got some great results. But there was a dark side to this, it wasn't all hunky-dory.

And there were some weeds in the Rose Garden. And we'll talk a little bit about those weeds, and how we can fix those with some headless BI concepts. So if you think about what's actually happening, we got these data sources, and they come into these different solutions. And then we have these applications, where there's the desktop business, intelligence solutions, you name it, you've got your favorite preference, whether it's Power BI, Tableau, Clape, etc, or MicroStrategy. But what are the some of the challenges in those solutions, you define all your calculations, your models and your semantic layer within the tool? So you might go and say, I'm going to define net profit, fantastic. My business user gets it comes up with a number 37.25 million. Sounds about right. Data Scientist comes along, says, Well, I'm using my notebooks. So I'm going to come up with the same data. But I'm going to go ahead and put in my calculations to define what net profit is 36.75? Close enough seems about right.

What else do I check against? And as you can see, this continues different definitions. Because everybody's defining the calculations in every single module, they're not reusable. This lends itself to problems in an organization. This is where you get come confusion over Can we trust the data? Are the numbers trustworthy? Well, your chart is different from what we've got. The predictive data science models don't even match up to the actual numbers the business are showing, what do we do? So in that situation, this is where it's getting exciting because there's these abilities and options for us to kind of take out the analytics or the metadata, the structure, the governance, and place that into one area where the entire organization can benefit from using one singular definition. It doesn't take away though the flexibility of wanting to use all these other tools that you know and love, it should make your life a lot easier. Because now, if I'm an Excel and I want to pull in profit, I just pull it in, I get the same result. If I'm in Tableau, and I want to pull in profit, I get the same result, I don't need to go and calculate it in every single layer.

So having it in that area really brings a whole bunch of benefits, a whole bunch of opportunity for the businesses and the organizations that you support to believe and trust that data. It also from an IT perspective, we want controls and balances, we don't want freedom where people can go in and just create willy nilly what they think a definition of something is, because they're going to make business decisions on that. Auditors will come in and they want to understand exactly what is going on, you've got these reports, where's the data lineage? Where's the governance, all those things become immensely difficult to answer, and you will find you get problems. And you've probably already experienced this. If you can move to a centralized model, using these headless BI concepts, you can really change the way that you approach this. And so that really does unlock a whole ton of options for the business to use those tools and to see that.

So the takeaway from this one, the second one really is going to be how can you better leverage these solutions and this we're seeing more decisions come to market now, like we heard from superset today, where there's solutions out there that have based upon the visualization consumption layer being fundamentally different from the analytics. And that's a super important concept that we need to move towards. So definitely think about this one. If you're ever finding your organization's are saying, can we trust the data? Do we really know it's true? What do we do with audits? Those are areas where this can really come to benefit. So that I'm going to head back to Jack to talk about some specialized analytics use cases. Thanks, Jack.

Jack: Thanks, Matthew.

Matthew: Yeah, so one of the other things that Matthew and I have been talking about and put together for this conversation is, is that, you know, one of the things that happens with any kind of market is initially you come up with relatively general solutions. And general solutions allow you to solve a wide range of different use cases, but typically require more work to be able to work in any particular context. And so when I was thinking about how we would talk about this, I started to think about it in terms of two different spectrums, which is, on one hand, when you think about different types of technology solutions and analytics solutions, you've got this sort of this vertical axis, which is how specialized is the set of capabilities, right. And so you've got solutions that are very generalized in their capabilities, they can work with a wide range of different kinds of data. But they aren't necessarily specialized in any particular shape of data.

And then you've got technologies that kind of move up towards the, to the top left quadrant of this diagram, which are much more focused on specific shapes of data. So maybe I'm talking about time series data, or I'm talking about data that's unstructured, or I'm talking about data that's coming in at a very, very high volume of creation. And so when you're thinking about solutions, you have to think about them in the context of like, well, there's generalized things, but then I can also use these specialized technologies. At the same time, you also have this horizontal axis, which is talking about how I'm actually going to use these technologies, right? And like, how specific are they to my business needs? Right? So are they focused on a wide range of different kinds of business categories and use cases, or are they very much verticalized, and focused on a particular set of needs the nine to solve, and so you've got that axis as well. So you might be able to say, Oh, this is very much focused on my particular vertical. And then in the top right quadrant, you have something that's even both the most specialized of all, and that is a solution that is not only customized in terms of the shape of the data that you're working with. So maybe it's highly normalized data, or maybe it's real time data or something like that. But it's also very verticalized, and focused on a particular subset of use cases, and built very much for that.

And so when you think about this grid, none of these quadrants are any better than any others, it's just about which use case you're working on and thinking about which kind of category is most appropriate for you. And the way to think about it is, is that as you move either up or to the right, or both, you get to something that's more specialized. And that typically means if you choose, right, it's much more close to the business need that you have. And therefore you have to do less work to make use of it. Right. Whereas if you think about things that are the lower left hand side of the world, right, they are going to work for a wide variety of use cases. But generally speaking, you're going to have to bridge the capabilities of what they can do with what you need, with people, right, you're gonna have to put more people against it to make sure that it's customized to your particular use case. And so one of the ways I like to think about this model is in the context of someone you might hire as a trades person, right? And so, in the lower left hand quadrant, you have something like a handyman, someone who can do a wide range of different jobs and can do them reasonably well.

And so you might say, hey, handyman, fix my leaky faucet. I need to lay some pavers in the backyard. Maybe I need to fix that fence. A handyman can do all those things. And the benefit of doing all those things is you can work with one person, and you get a large variety of things done. It's a very simple interface in order to get things done. Now, that being said, sometimes there's more complex problem that has a specialized set of needs. So for example, let's imagine you're in a situation where you have a big electrical job that you need to do Sure, you can get a handyman to do it. But you might be better off hiring someone like an electrician, who specializes in just electrical work, because they know the codes, they have vendors that have specific capabilities, they're gonna solve the different problems that you have. And so that's really what's in the top left is basically specialized skills, that there's benefits to that, but they're not gonna go solve as wide a set of use cases for you. And then you also have that vertical categorization again, moving over to the right.

And so as an example, I at one point, owned a large boat, and that large boat, I could have used a handyman to work on different projects there. But there's actually a specialized kind of handyman, a boat, boat worker, someone who works on boats, who knows about the special things that are nature in nature about there's still a handyman, they do a wide variety of skills, but they're specialized to a particular domain. So they know about fiberglass repair, and diesel work and things like that. Okay, and then you've got that top right quadrant. So if I'm gonna work on something like my the diesel engine in my boat, I probably want to hire a marine diesel mechanic, because that's the best possibility. Now, in the case of tradespeople, right. There's been years and years of specialization. And so we have all of these choices. In the case of analytics, it's taken, it's much, much younger market. And so it's taken longer to get to specialization.

And so when you actually think about different technologies in each of these categories, and we'll kind of pick out one or two and each of these categories, you have different choices, and all these things. And so most organizations start in that lower left quadrant, they choose a generalized tool, because it can solve a large variety of different challenges. And that's a really, really great place to start. But what's happened over time is you started to see a lot more specialization develop. And so if you look at the things in the other quadrants, in many cases, they're much younger technologies. That's because specialization takes time to occur. But when you look at say, in the top left quadrant, you see things like, you know, we heard from Pinot, people were using Pinot earlier today, Pinot and druid are really great at doing data analysis against time series data for, you know, user analytics at very low latency.

And so anytime you move up in this graph, you're generally gonna probably improve on efficiency, right, you're gonna be able to do more with less amounts of infrastructure or less amounts of cost. And then you've got things that are sort of in the bottom right corner here, which are things that are very specialized in particular verticals. So for McKesson, for example, has a bunch of analytical capabilities focused on pharmaceutical goods, right, but they're generally speaking, built on top of generalized technologies, right. And so then in the far top right corner, you have things that are most specialized in the verticals that they focus on, as well as the technical solutions that they solve for. And so you think about something like HEAP analytics, which is very good at product analytics.

And they've not only come up with a bunch of ways to look at product or with analytics, specifically, but they've also come up with a bunch of different ways on the infrastructure, the technology side to solve for analytics, right. And we also heard from, you know, meta earlier today, talking about their experience, working through these kinds of problems with Incorta. Incorta, does both financial analytics, it also does things like supply chain analytics, very focused vertical solutions to problems, but also a lot of specific technology that's customized to those challenges. So I've got a large scale, highly normalized schema, I can solve that well. And so, you know, 10 years ago,you basically hadn't choose general solutions, because there weren't a lot of specialized solutions. Now, there's a lot more opportunity to choose specialized solutions. And so when you look at each of your use cases, you want to think about whether or not you can actually use one of those specialized solutions. Because when you can, that means you spend a lot less of your people resources, trying to bridge the gap between what the generalized solution can do and what you need. So next up, I think Matthews going to talk about data pipelines. Thanks, Matthew.

Matthew: Thanks, Joe. So that fourth line that connects all those planets is decoupling transformation. And quite honestly, this is probably the most difficult part of anything that you do with analytics. And so when you think about looking back over history, and if you do a Google search for like data warehousing architecture, data architecture, you will get a whole smorgasbord of these kinds of charts and visualizations. Some of them are really dated, because honestly, they are, they're from the 90s. And then some of them are more modern, but in essence, they're all the same thing. They all have a large transformation component to them. That really is the backbone.

That's your breaking what most of you probably feel that pressure, right? That's where most of your time is spent. It's how can we transform and change what we're seeing in these layers. And so, really, for 30 years, we've been doing the same thing. It's the same transformation modeling. It's the same way that we think about it and approach it. And that's where we really have to think about how can we decouple this in the same way as we decoupled the BI not having everything with the calculations being inside? How can we decouple the Transformation Lab? So let's talk a little bit more about this.

So Think about it, the Earth is the weight of the data, right? There's all of this very rich data that we become experts are quite honestly capturing. We capture every business event that goes on, we capture every click, and we're capturing so much data in our world today through IoT devices all the way to transactions on systems. And that weight of that data is really being felt like a lot of people struggle just to move data, a lot of the conversation is where can I even store this data going back to what I just spoke about at the very beginning of our session. And so when you bundle all these things together, you start to get some friction, because on the right side, here, we have the weight of the business requirements.

Even though Mars technically has less gravitational pull, it probably should be more like the sun, right, in terms of just the pull of that DEBs requirements, and what are the business requirements? Really, the business requirements is not the load and the extract of the data. It's really about how do I use it? How do you get value from it? How do you serve the business users that are asking questions constantly, that you know, every day probably will require you to go back in, and probably maybe sometimes pull the data, because you don't have it. But it almost always requires you to transform it in a new way that was not seen or not known before. So you got the business requirements pulling in one direction, you've got your ETL all bundled together, and it's being pulled in the other direction, from the weight of the data and just the complexity of moving objects around.

How do we get out of this friction? So you look at ELT and you go, well, great, we got ELT Was that enough? I think it was a step in the right direction. But we need to go beyond that and go a little bit further. So when we think about decoupling this, we really want to say the weight of the data and what's coming in on the data side is just extract and load, we need to get that data replication because we know we cannot run those queries against the source systems. If we could we would, if we could just go against our ERP system and run queries against all the historical transformation or all their historical transactions we had, and actually get that back in fast time, we would totally do it.

You could probably try it and have a DBA on you within five minutes. Like why have you brought my system to its knees, and you probably won't get a result in 24 hours. But if we could do it, we would. Now if we can get that data out and have it in the new system and somewhere else this optimized, as Jack was talking about for specialized reporting on that, that scale and other things, it becomes very much interest a lot more interesting. So bringing the transformation to be closer to the business requirements. Meaning, if there is a new transformation needed, I don't need to go back and grab that new piece of data, I already have it. This is really important when you think about what happens if a new question comes up. And you say we've never been tracking that information. We can start today.

But it'll take us a few years to actually start to collect that data. And to have it so we can actually do something with it. That doesn't work. You want all your historical data, because you just know, no business user gets everything right out of the gate. No one knows exactly what they're going to be asking next week, next month, certainly not a year from now, what are the business questions we're going to be asking? And so being able to decouple this is key. So if we can decouple the transformation, keep it closer to what we're doing in the business. What should we be doing in this area? We heard from DBT today, obviously, there's a lot of excitement around with the work they're doing because this piece is really critical. It's where you probably find you're having a whole lot of pain. There's a lot of things you need to think about and transformation. It's not just an old like Clover graph that you'll be using in the past, you need to understand what is this? you need to think of your transformations as code. And so now you have a rich set of tools that enable you to think about that and address some of these things like version control, and logging and documentation, of course, which is super, super important for you to understand exactly what you're doing.

But I want to talk specifically about two pieces out of here, this section here that I've been really focused on for the last eight and a half years. And that's what we do about reshaping and what we do about specialized analytics processing. At the end of the day, the reshaping is what kills us. If every question requires it to be a data transfer transformation before we can answer it that inhibits our ability to move, to be agile, for you to support your business users, for you to feel like you're actually not just kind of weighing the business holding them back. But you can actually become an enabler you can see as a strategic partner of your business because you're able to adapt to their new questions, because let's face it, the business users don't understand what we do. They don't understand what a third normalization for model is a relational data set these topics we talked about, they don't understand. And to be honest, they shouldn't have to write, they don't need to understand. But in reality, they don't understand the complexity of the world in which you live in, where they ask for requirements. And you're like, I wish it was easy as just writing one piece of SQL, and it would give you your answer.

It never is. And so if we can eliminate those reshaping, and so when we start to say, if we can do analytics that needs to be near real time, we shared about the importance at the very outset of this conference from Thomas Kurian, talking about businesses are going more near real time that everyone wants to get access to the data and be a consumer of it. If we want to be able to support that, we need that ability to not reshape and keep transforming the data. So the more that we can eliminate the transformations, the better. Can we always do it, not today, in the future, maybe. But we can, as we've heard from like Shane at earlier today, we're able to do things to reduce the shaping that's going on the reshaping. And the ability to support new questions that come in this bit, I think, is where the largest part of that tea, these buckets, these buckets here are not equal.

In reality, the transformation is where you spend your work. It's where the difficulty lies is where the complexity lies. It's the reason why documentation has to be even more robust, because it's so complex. We all hear the story of a data warehouse project, where someone new comes in and says, I don't know what they build, I don't understand. I'm just gonna build it from scratch again. And they're very nervous, because you also know how we're able to pull this off, can we make this work? What about the things we don't know that they're doing in the transformations that we don't really quite understand, because a lot of these things evolved over time, and there was good reason for them being done.

But this decoupling really does help with that. But if we can get the specialized analytics processing solutions, and bring them into these platforms, with the generic solutions that Jack was talking about, just in the section before, that can become really interesting. So utilizing something like Incorta to help with your relational data become super valuable. I know that this industry is absolutely frantic, noisy, and confusing. I personally as someone who is in this, as someone who builds products, find it today, I think three companies have been mentioned to me that I didn't know this, I can't imagine what it might feel like for you. Every single day when someone comes in and says, Oh, I heard about this company. What do you know about them? And it almost feels tough, right? When someone says that there's a sense of, I'm expected to say this, it's almost like saying, I'm a movie buff, and I don't even know Top Gun is coming out this weekend.

So people are gonna be like, what kind of movies you into? Like, what do you know? And so in this space, it can be really hard. But there's so many solutions there. A few to navigate through this can feel overwhelming. It's very difficult. We know that making decisions is difficult. We know when there's so many options of where you can eat, it becomes really difficult. And so Tesla has innovative solutions for this sometimes, you know, where should I go to eat? I don't know, I'm just hungry. Let me just, I mean, advocate this decision to Tesla to make it for me, or I don't know, where should we go, let's just feel lucky and just go. And so people are obviously trying to address this.

Now, what we're hoping today is this, we have not given you enough information for you to feel any conviction probably on any one of these four topics, for you to say this is exactly what I can do. And I know what I need to do. And I came to zero gravity. And now I am an expert. I'm enlightened. We're going to implement this tomorrow, and we're going to be super successful. Now hold your horses. There's a few things you need to understand. While Jack and I today have really just wanted to kind of scratch the surface is to get you curious. At the end of the day, there's things that are going on that we think you should begin to comprehend more. We're not in a 30 minute conversation going to cover four topics and the depth that they would need, we probably need hours on each one of these topics to really unpack them. But hopefully maybe something here seemed that could be impactful to my business that could be impactful to my day to day job. I think this could this could make difference.

The ask that we have from this entire conference really is around will you take that next step to go from curiosity from here maybe about something that you think is a different approach, or a new way of doing something that honestly in some respects we weren't doing 10-15 years ago, but we've renovated them? We brought them back with a different perspective based upon the transformations and changes we've seen in the industry across the last decade. Digging deeper, go back and listen to the some of the sessions. There's some great information here that you can go and glean more from various topic that we've already mentioned today. Get to that point where you have conviction that you understand. And you can make a commitment and be deliberate. Choose wisely. Make those choices. But feel confident that you know, if you are following this process, then there's people around you.

You're hearing, you're engaging, you're listening to what are the other people in my industry doing stay connected, I believe there is hope that you will be successful that the pressure that you are probably feeling you are under between the business, requirements, the data sources coming at you, the veracity, the veracity of all of this, that can feel very overwhelming, is going to get better. We're dedicating our lives to that people are on the stage today. And then you've heard from the sessions are dedicated to it, whether they're building solutions for their businesses, or whether they were building products to serve you as the practitioners better.

I hope you find today's sessions helpful. Move from that curiosity to comprehend, dig in deeper, take advantage of some of the virtual hands on labs that are being offered that can help unpack and explain maybe some of these concepts. Think about how specialized platforms, specialized data pipelines can really coexist with what you have today, to take you forward and to totally change the way in which you might think about your role and your job.