The Evolving Role of Data in the Enterprise

Turning data into decisions has never been easier for companies with the resources to capture the right information and ask the appropriate questions. Large retailers like Target, Home Depot, and Amazon use data to drive how they build their marketing engines, but has it gone to far or not far enough? The CCPA, GDPR, and CASL all aim to protect the consumers rights against harassing sales tactics and yet most enterprises still function in silos.

This week on The Summit, we sit down with Mark Skiles of Integrity Works International and discuss the thought of “data” as the new oil. What does this mean for companies and how can they quickly uncover the greatest value in their data. In this episode we cover:

  • What is a Chief Data Officer?
  • Why is a CDO important?
  • What are the common data challenges for enterprises
  • Large enterprise data project showcase
  • What is a data catalog?
  • How do departments use this catalog?
  • What’s going to happen with Data Lakes, Cube, and NLP search for companies?
  • What can we expect in the next 3-5 years with data?

Listen in now as our host Kyle Hamer and special guest Mark Skiles talk all things data in a non-binary way.



Kyle Hamer: (00:05)
Oh and welcome to the summit, the podcast where we bring you knowledge and insights from industry leaders and professionals. My name is Kyle Hamer. I’m your host of the podcast and owner of Hamer marketing group. Today I’m here with my good friend Mark Skiles. Mark Howard today. Dan fine. Thanks Kyle. That’s awesome. Mark. Uh, Mark and I are going to be talking about the new role of a chief data officer and what’s happening in the world of [inaudible] data

Mark Skiles: (00:31)
and operations and how businesses and enterprises can, can expand or maybe leverage data in more intelligent ways. But before we get into that, Mark, why don’t you tell us a little bit about yourself? I’m sure you have kind of a, have a, a bit of a varied, an a, a, uh, background here. So started out in networking, um, worked on that for a few years, became kind of an independent consultant back in the early nineties, and, uh, did a variety of projects as a part of that. But, uh, over time it’s kind of fell into the whole data world, uh, primarily managing SQL servers, right? You kind of a DBA, uh, and so you work with the data a lot and then you start thinking of something more than just moving these bits and bytes around. What do they mean to people? Right? And so you start thinking about that, uh, kinda migrated towards the, from a technical side to more of a business in tech, business intelligence sphere, right?

Mark Skiles: (01:25)
How do you use this stuff, make it work and it get some good value out of it. And so you had the mantra for a while from data to decisions, integrity works, uh, any of our company integrity works. And, uh, you know, this whole idea of finding wherever the data that you’re looking for is at. So we started throwing around this banding about this, find it, get it and present it right in the BI. In the BI world, reality is, it’s not just about the reporting, but a lot of different things around data quality. Uh, you know, being able to get what you want when you need it, whether you’re a data analyst, data scientist, kind of person more on the business side or you know, a different set of challenges from the it side. And that’s, that’s kind of where the CDO really came into play, right?

Mark Skiles: (02:05)
That the it folks are really focused on getting you the data. Uh, they can locate the different systems, but what’s, what’s the most value to an organization and what are the business drivers for that data? You know, how do we want to focus its efforts? And so that’s really kind of where the CTO came from and it’s an evolving role. Uh, right. Organizations have these kinds of challenges when they’re trying to push through to, to, um, this whole, um, data-driven, you know, world that everybody throws around. Um, and there’s just a lot of pieces. Moving parts to that point from a CDO is just drive from the business side more. I have a C at the C level table, uh, as opposed to being just focused on information and kind of reporting kind of thing. It’s, it’s really help us kind of navigate this whole thing and you could get dry the business value out of it. So when you say, when you see drive drive the business value, one of the, one of the things when you were explaining this to me, the first time we chatted about it was the, um, the silos that information

Speaker 3: (03:00)
and data lives in. Can you expand a little bit more about what you’re seeing happen in the market for, uh, reasons that people will need data or to consume data information and how it’s impacting enterprises that have normally functioned in information silos?

Mark Skiles: (03:20)
Well, one of the challenges, especially to business users, right, is, is they have a question. They have to go to it to get it. And so they can go through the whole, you know, I get it on the project docket and kind of work through the logistics. They are, take some time, take some money. Um, they don’t really have any way to get their, their hands in the pie and really ask them questions. So part of this is kind of been pushed where, where the business says, you know, I need it when I need it and I want to have to wait six months for it. Right? So the silos really are this idea that we’ve got a lot of systems in our environment, enterprises, large enterprises, but small, small companies had the same issue. It really just different scale. And that is, you know, my QuickBooks for example, is as locked my financial data up somewhere and it doesn’t really talk very well to my, uh, I don’t know invoicing or my, my, uh, you know, my customer management or, or whatever it is, right?

Mark Skiles: (04:07)
The, the, the, the, we’ve got a lot of walls but not a lot of bridges. And so really this is around how do you build bridges with these different systems? Not so much from a technical standpoint, but from an organizational understanding and ensuring that the things that are really important to us, uh, get, get kind of elevated focus, whether you’re, you know, in publishing. And so it’s the, the authors and the author data there, the book contents, whatever it is, right, that the right things get the right focus as opposed to it sometimes being driven by the current project on the list. And uh, anyway, it just is trying to drive the value from the folks who are using it right. And can really say this is what I value the most as opposed to kind of its current priorities at the time. That makes sense.

Speaker 3: (04:51)
It absolutely makes sense. I mean, it helps better understand why this role is, is becoming so important because I think 20 years ago information was there, but data wasn’t integrated. People weren’t wanting to automate and bring things together, even ask larger questions. It just, you’d send one person out to go comb through the catacombs of each, you know, each set of filing cabinets and they came back and they were the Oracle of truth. Whatever their personal opinion was, was the interpretation of that information and the assessability of, of software and technologies really forcing us to look at how we deal with information, uh, differently. But, but what, what’s not fully clear to me is, is why organizations are saying, okay, well we need a data officer versus making this part of like a chief information officer role or a, um, security officer. Like what, what is different about a CDO than say like a CIO?

Mark Skiles: (05:55)
That’s a good question. So the, for example is a chief information officer, right? And so a lot of times we’re really involved in collecting the data, right? But the focus really isn’t on the delivery and the benefit of that data. Um, and so if just collecting it, put in a data warehouse or put it somewhere, doesn’t give me everything that I need. Um, how do you keep your limited resources focused on what are doing, what really gives you the most benefit? And so the CDO really kind of gives you that clarity and direction for your attention. And it’s also focused on collecting smaller data sets as well and govern them and maintain them in a, in kind of a, uh, you know, more focused manner.

Speaker 3: (06:32)
Well, that, that’s interesting. So a lot of organizations have lax at best. I mean, they may have data governance, but data hygiene is something totally different. Um, but how our, how our organization’s handling the change or, or thinking about the change of, of data governance from silos to, okay, I have a chief data officer now, or we want to, we want to provide assessability of data across different silos. How’s that, how that forcing them to think differently.

Mark Skiles: (07:07)
Well, one thing is really on the data quality, right? Because in the past you kind of looked at just, just we have volumes of data, we’ve collected all this stuff, but you know, we might have different reports at different totals, different, you know, the, there’s conflict seemed, uh, facts if you will. Right? And so somebody really can of focused on, um, putting some oversight and saying, these are the things that organization we really value the most. And this also bleeds into the security conversation, right? Organizations really need to really to say, um, for the, for the most important things in my company, I need to have a higher level security for, I don’t need the same level security for every piece of data, my organization. But I do need to understand what’s critical for my business. And if something went down, for example, um, you know, what’s our, um, not backup plan, but you know, our, our, our stake in the ground and says we can’t live without this.

Mark Skiles: (07:57)
And if we do, it’s going to cost them a heck of a lot money to get it, get it back. Right. And so you just put some energy around that. I’m not talking about technical standpoint, just saying identifying it first. Um, one of the exercises if I bleed over to, uh, to the later conversation is that recognize that we had to understand what are the different things in, in an organization. I’ll use the example of the uh, biotech. So you know, a seed for example, but what goes into this seed? Well, the germplasm is the genetic makeup. Well, for example, that germplasm is, is a, is a part of the, the, the DNA conversation and it means different things to different people. So for the laboratory, this germplasm can, can be a piece of glue in a, in a sample too, right? But for the people in the field who are planting those things, this germplasm comes in the shape of a seed.

Mark Skiles: (08:46)
But the conversation around what are the most important things in our organizational world, what types of information are we do we need? And they wanted the relationships, those pieces of information. So the exercise was kind of this context map around while you use the term different nouns in our world and then you know, how they interact with each other. And so that was why one of the things we learned early on is they really need to kind of take a step back and, and, and find out hoarder all these things. Right. What’s the wet, where is it at? Was kind of a secondary question. But this context, you know, it has different meaning giving different context and so that you kind of had this business glossary need. I need understand what it is, what it means and uh, and what’s the context for it. And so we’ll talk about this later with the data catalog ID is really kind of a way to, to, to manage that, uh, understanding of what the sales things are from a conceptual standpoint all the way to where they’re physically located, what tables are they’re at, where the different columns with they’re at in a way to kind of put those things in a library form.

Mark Skiles: (09:48)
Um, it’s kind of the geospatial approach, right? This whole, I want to find out where it’s at to my data so

Speaker 3: (09:57)
that, um, you know, it’s, when I find what I find fascinating is you touched on several different things there. One is, uh, data governance. You talked about, you know, needing the ability to move faster and different things mean different things to different people.

Speaker 4: (10:15)

Speaker 3: (10:18)
When you have groups that have, you know, their own sort of internal fighting and challenges even in their own departments or silos, what are, what are some of the common challenges that we see organizations having as they, as they open up? I mean, you touched on it briefly as they open up the, uh, the dialogue into, Hey, I need to have access to research and development information or I need to have access to marketing or accounting or whatever the additional, uh, data set is what are, what are some of the core challenges that you see as they begin going down that road as an enterprise or even business ghost in that road.

Mark Skiles: (10:58)
And one of the challenges we ran into and the reason why we kind of started with what’s the, what’s the, I’ll use the term shared language. They use that term in some kind of this domain driven design world. If you’d look that up, you’d see what I meant by that. But, but shared language kinda understands this. Every, uh, every application or development team or something has, has language that they use. And so you try to understand what the different things that they are they talking about the, the objective here that we found or the challenge I guess that we found was that people are using the same word. I’ll use the word inventory without any context. And so the first thing we do is try to understand a, what it is we’re talking about. And then B, what are the different contexts that we’re using and try to shape those in some kind of a, of a, of a language.

Mark Skiles: (11:43)
And we, we took that one step farther where we actually modeled them conceptually. For example, the, uh, the idea of germplasm, the definition from a technical, um, between the field and the laboratory was the same for 80% of the conversation, but the other 20% was unique to the laboratory or unique to the field, right? But, but that gave it context. So, okay, when we talk about inventory, here are the things that we agree on that we’re all, you know, we’re all speaking the same language. Here’s the other parts that we recognize are different. And here’s what we mean by that, right? And so we documented those kinds of things. We, we used a conceptual model to do it. Now there’s a variety of different tools you could do that. But that was kind of our approach. Basically, you just need to understand what, what you have the nouns. We’ll get back to using that term and then how those things interact with each other in, in your organization. Right. We’re not talking technical at this point in time. We’re not talking about how they’re implemented in your database, but just a common understanding of things that make sense.

Speaker 3: (12:41)
Makes perfect sense. And I think the thing that’s interesting, what I think about, um, writing down what we have, you know, I would imagine that inside your catalog there has to be some level of description and, and for a period of time, silo a or silo B will come in and they’ll look at it, uh, a term and there’ll be thinking as if they’re in their own silo. But it’s really referencing more how the other silo, um, plays with it. So there’s the, the, the uh, the description component almost becomes more valuable than even the, what the description of what it is. You know, it’s, its definition is probably more valuable in creating common language. Then the descriptor, the, the, the name itself,

Mark Skiles: (13:28)
one of the tools we used is a context map. And that was really just a bunch of boxes and squares. They kind of took all the nouns, right? And they have this idea of some upstream and downstream stuff, you know, so an experiment for example, it takes a lot of different pieces. A location, right? The different timing, the different chemical components. And those are all kind of sucked into this idea of what is an experiment? Well, if you looked at it on their little context map, you’d see a box for experiment, you’d see a box for germplasm, you’d see a box for um, you know, chemicals, those kinds of things. And then you might see coming out of the experiment box some other things that are kind of, you know, outputs from that, things that are produced. So you have this upstream, downstream kind of thing.

Mark Skiles: (14:12)
So one of it is the Hoyts and then like I said, they kind of interact with each other and we kind of put that into what we call the context map. It’s not a unit, you know, in, in the manufacturing they have like a, a entity relationship kind of things. Um, but it’s basically someone to visualize that and then begin to, to speak to those things and peel them apart. Right. And then you start building these models out from there. Are these definitions to use your term around what these things are, right. Give them some kind of a shape.

Speaker 3: (14:41)
Well, it’s, I mean, it sounds like, to me the, I mean, I know this because we’ve chatted about it, but it sounds to me like this, this, um, this rule of a CDO or [inaudible] fractional CDO, uh, you, you played this role in a project where it really was orchestrating many of these things coming together. Can you tell me a little bit about some of the core challenges or maybe core business questions that the business is trying to ask that that kind of led to the evolution of this for, for that specific project?

Mark Skiles: (15:13)
Well, first of all, her most recent project really wasn’t a, it didn’t start out as kind of a CTO role. It kind of evolved in a kind of a semi CDO. And it was, it was based in the, the R and D department of a biotech company. And so they really were going around this data integration path and using API. So they brought me in to kind of say, um, you know, help us gather, uh, from a design standpoint, the, the, the, the things that we need to be building these core API as they call them, right? At DNA integration layer. What evolved from that initial conversation? It was focused on building APIs. We realized they really needed to be some common language around um, the, the, if we’re going to do something core and I’ll use core just to mean shared right? Integration between the common definitions of something, then then w we have to understand what it is we’re talking about and everybody had a different definition of stuff.

Mark Skiles: (16:02)
So, so we kinda went back to the drawing boards. Okay, now we need to focus on the data governance side. We’re going to inequality at data quality out of this equation. We’re going to have to tow people. They needed to be a common understanding of what we’re talking about. And so that we kind of backed up the bus a little bit and started going down this path of this context mapping exercise and some some conceptual modeling that became very valuable cause they, what happened, we were able to find a tooling that took those conceptual models and came up automatically. We call the auto-magically, right? But we could automate some things. It pushed him up to a website and this, these, a web publishing of these conceptual models became something that we would walk into a room with an application development team and it gave us something to speak to write something visually.

Mark Skiles: (16:43)
I could look at that. It became a conversation piece. It didn’t have to be exact, but it was enough for everybody to get an understanding of what the shape was. And you could even involve it in the conversation. Oh well we’re missing a piece there. Okay. We’ll add it to the laboratories piece of that equation because that’s what we’re talking about, right? Throw it right in there is we’re using the design tool and display it on the screen. Everybody’s happy. Go back and publish it again. Right. So here’s an evolutionary kind of process. But it was a conversation. And really if I saw one value out of this whole thing, it was forcing the conversations that people hadn’t taken the time to do in the past. And just a common awareness of some of the challenges we were facing and trying to figure out a way to, to, to address them. So, um, I, I really see myself as kind of an early, uh, chief data officer. We didn’t have a lot of things figured out. We were kind of walking through the process and, and, and, you know, they love the things we do differently, uh, doing it again, but we learned a lot. And so that now I had placed myself in a, in a, you know, a phase to CDO. So

Speaker 3: (17:43)
that’s a,

Speaker 3: (17:45)
that’s really cool. So like when, when, when I say it’s really cool, I, I’m thinking about, you’re talking about the, the common language and the sorting things out and you know, creating visualizations. It’s like, it was also mostly you were building, uh, the building the role as you were building visibility for the company. And I can’t imagine what kind of impact that was having for teams around. You talked a little bit about the impact of getting access to information or creating common language with your, with your catalog. What, what that meant or what kind of the aha, like what were some of the big revelations for this company?

Mark Skiles: (18:22)
Well, first of all, just to clarify, this company doesn’t actually have a data catalog as of yet. They recognize a need for it and they asked me to do a lot of research on it and so I came back with some, some recommendations which haven’t been implemented yet. And that’s more of a timing thing, uh, as opposed to anything else. But, uh, in terms of elevating in the, in the value, um, what happened was as, as upper management began to see these things and people were using them in kind of a practical way, the data governance came, all of a sudden got escalated to, you know, tending a lot of meetings. People wanted to know, you know, not just what you’re working on, but how does this affect, cause they were going through a merger and acquisition and that’s one of the times this is really, really important, right?

Mark Skiles: (19:02)
You’re bringing in a new company and you need to know that. Do you mean the same thing when you’re talking inventory? Right? Uh, and so that those really got elevated into the upper management levels and because it was conceptual, they can kind of grip on, get a grip on those things as opposed to, you know, talking about the bits and bytes or the table definitions or that kind of a thing. Right? They could begin to understand how these concepts fit together. And so it became a very critical and highly valued piece of the upper management’s, um, evolution too. Because they could get a grip, they could, they could chew on those conceptual things and get a picture of them, um, as opposed to showing them table table definitions. Right? We constantly harping on that this is not a table definition. It does not map to all the columns in a table. Right? So just to understand this as a, this is a business conceptual model, not a data, not a, not a database table structure.

Speaker 3: (20:01)
I can, I’m, I’m chuckling cause it’s like, I can’t imagine, depending on the type of executive, they were probably some or even senior leadership that you would be talking to if there were some that were really, really relieved that you weren’t talking about database structure and there are others that were really annoyed that you were talking about concepts that weren’t tied into tables.

Mark Skiles: (20:19)
Well usually that came in like your data modelers or your, your DBHs or your, you know, even your data warehouse guys. A lot of times they’re so focused on what the table structure was or something. They had a hard time pulling themselves out of that. Uh, so, you know, the conversation was great, but everybody had to do a little learning. I’m okay. When we walk in the room with Mark Skiles with David Bowen, we’re not talking about, you know, table structures and uh, that was a learning process for everybody.

Speaker 3: (20:45)
As you, as you kind of go through this process or this project, it sounds like a lot of the, the silos had to be torn down. Did you take a, a warehouse and a cubing approach or a, you know, is this a dealing with data lakes? What does this, what does this really mean for how data is not necessarily interpreted, but how data is accessed and

Speaker 5: (21:08)

Speaker 3: (21:10)
Cattle catalogs probably you already got the word most the how, how it’s accessed, how it’s, uh,

Mark Skiles: (21:17)
well, one of, one of the things if this, if this, I’ll use a higher level model at the moment just for that conceptual idea is that different systems kind of, um, and, and there’s different levels of abstraction, you know, and database world, you have this conceptual, logical, physical kind of kind of a moment within data models. Right? Um, and so how would you take a data from system a using this conceptual model and somehow bring it into the data warehouse or system B? Right. So they created something called a, uh, I think we call it a data pump, remember what it was, but it basically used, took this conception model, took from system a transactionally, turned it into this XML file kind of thing. And think could be re-read on the back end and sucked off the, the, the data pump, right. In a way that, that uh, they could kind of rearrange it on the other end of the way they wanted to, but they had this common definition of things and said, okay, this is the way it’s, uh, uh, we can read it dynamically, right.

Mark Skiles: (22:11)
Cause it was XML based or, or uh, uh, it could be Jason Bass, however you defined it. But the data pump I think was a XML and a CSS stuff. Um, so anyway, I don’t know if that answered your question as far as how they were doing it, but it’s, it, it wasn’t so much a, um, you have this element of data mapping. But the other thing was just automation around taking these conceptual models and, and using them as a common, like a, uh, almost a schema kind of thing. And those of you in your data world would kind of understand the scheme of conversation. That’s really the shape of any given, given data coming in. And they use it in the Jason world a lot where some things are coming in off the internet or you know, some sensors sending me data in a certain shape, right? They would call it that data schema, right? So, um, the different ways to kind of move from this, this conceptual thing to something that’s, that has more shape, right? And so we had tried to do some automation things to leverage those models and then you could plug them in and they can automate, uh, the moment of from point a to point B, given the use of those, those common definitions,

Mark Skiles: (23:16)
that’s probably a little too nebulous for you. I’m not sure how much detail you’re asking for. I’m not trying to avoid your question, but I just hesitated, jump too much into technical details. So

Speaker 3: (23:25)
yeah, I’m glad. I’m glad you didn’t go any deeper. Why I might’ve like come out the other side, Mark. But that being said from a, it, it’s fascinating to me because I hear about, you know, and I have enough, I have enough knowledge to be dangerous, you know, usually like the, to, to um, to have the, to understand what’s being talked about. But not everybody fully appreciates, you know, how nebulous and fine tuned detailed like how much information and structure is buying the information that they need.

Mark Skiles: (23:56)

Speaker 3: (23:56)[inaudible] do you think, do you think that like do you think in this, like the project that you set up for, for this company and, and the role of the evolution of this data officer and how companies are thinking about it, do you think that there’ll be a,

Mark Skiles: (24:13)
the [inaudible]

Speaker 3: (24:13)
point in which information will be free flowing and we won’t be dealing with, not necessarily governance per se, cause you want to protect your IP but deal like, will we be in a spot where marketing can access what research and development is doing and is three years down the road and seeing how that may be influenced by what they’re seeing happen in the market today? Or is it well we get information flowing that direction or is it gonna really stay continued in silos? It’s just, you know, maybe business adjacent, there’s value in doing this.

Mark Skiles: (24:45)
Well that’s a good question. I think it’s going to have to [inaudible]. And what I mean by that is, you know, you had this, this idea of um, Oh, what’s the term they use, can have a um, uh, a person who could do their own analysis. Right? The, the, the um, let me just forgot the term off the top of my head, but the point is accessibility is going to be a big deal because I want to ask questions in, in more real time as opposed to being hung up waiting on it. So to do that you can have to give, uh, the marketing department or the accounting department or something better access to their data cause really it’s theirs, right? It’s just been kind of locked up in systems. So the answer to your question is yes, it’s gonna evolve that way. The timeframe will be a little question Mark.

Mark Skiles: (25:27)
I think companies are going to have to invest in that. And it does take a little time and money, right? This, this catalog ideas. But one of the solutions to that is not the only approach, but this geospatial guide kind of serves as the library if you will, from the data definitions. Oftentimes like the data glossary, right? You add the context into the equation so people could look up, you know, where’s, where’s germplasm at? Well first of all, what’s it mean? Okay. Given the context of lab, that’s what I’m talking about and we look specifically at labs context, but where’s that labs are unpleasant located, what kind of systems is that? Well, the data catalog kind of give you access to that and especially in a machine learning catalog was kind of in the next evolution. A Gartner calls is the new black. Those, those data catalogs will actually um, scrolls, want more right there.

Mark Skiles: (26:11)
They’ll, they’ll, they’ll troll through your environment, all yours, your, your different SQL non sequel, you know, different kinds of data sources and, and kind of pull those out and say, well these are what’s out there. You tell me what’s good or not. And somebody that the data owners, data stewards cause some crowdsourcing. We would go out and say, okay, this kid is, has an 80% data quality. If you really want stuff, look at this column. Right? And they can kind of pull those pieces together and get to see even in a big data environment, these are the, the the, the piece of information in this big pool of information that you want to on, right? We’ve been using this for our testing or we’ve been using this set of production environment. Don’t waste a lot of time and other stuff. This is it. As the data catalog gives you a place to put all that stuff you can, you can interact with other people who are using it and it becomes, you know, over time it just evolves.

Mark Skiles: (27:00)
It’s a tooling, nothing more than that, but it gives you a way to kind of put all these pieces together in a way that people could find what they’re looking for. And then many of them now will give you a query mechanism or you can do some discovery queries on the data. Is that the right data? Am I looking for that? Does they have the pieces of information that I need and uh, I can pull them together, create some joints, you know, that’s more of a technical term, right. But, but piece them together, mash them up and then I start asking some questions in a more dynamic fashion and having to wait on on it. So it really kind of, it’s a, it’s a leveler if you will. The data catalog is and a elation and Colibra two companies that we were really researching as far as this machine learning data catalog.

Mark Skiles: (27:38)
You want to look them up cause they just kind of bubbled at the top for the things that we were doing. One Collibra, it’s more focused on the data governance side, a little bit more techie from that perspective in relationship. Really more focused on the user interface and how you interact with the data as opposed to you know, high level really governing this thing from a enforcement and a bunch of rules. So long wouldn’t answer say yes, it’s got to go that way. We’ve got to make it more accessible. It will happen. It’s not. If it’s more of a, when three years that may be a bit aggressive only because of the investments take an organization to get there and you know, depending on the industry you’re in, insurance tends to run pretty slowly too to some more of the rapid environments. Tech obviously serves on the front side of those things.

Mark Skiles: (28:22)
I was just going to ask you, you know, is this a three year, five year, 10 year? Like what, what, what do we, what can we expect to see in the coming years? He answered that a little bit, but what it feels like, what it feels like to me, I hear you saying is, is very similar to what we saw Google do when it began indexing the internet and websites, you know, in the nineties and they, you know, they are now a behemoth of ask a natural language, natural language question in LP, in inside a browser, in tailoring the results to where you know, what they think you’re focused on and what might be most important. Can you see a world where even inside my company, I’m having the same type of experiences where I might have with Google? Absolutely. That’s probably a great analogy, right? I just, I just, uh, crawl through all of my internal stuff, right.

Mark Skiles: (29:22)
And, uh, and create some mechanism that I can, I can query it. Right. Um, so you know that, that’s probably a great comparison. Um, the other thing that’s kind of happening the industry and I, I think when I, you and I spoke earlier, we talked about this a little bit, but to see idea of how the API economy, and I don’t know if you, um, kind of brings into question, so companies instead of just holding onto themselves are gonna figure out ways to expose it externally and, and monetize it. Right? So if, if there’s a way to publicly expose, I dunno, even IP data may be out there for price, right? But whatever they, they, they want to say, okay, we’re going to kind of let you guys have access to our stuff in exchange for, you know, whatever it is. And API APIs become kind of the mechanisms to do that. People can ask questions of these API APIs under the covers using other, you know, programmatically, right. Uh, or I can do it from a browser, but just being as a way to kind of expose, uh, data in a different way and monetize in different ways. So I see the API economy really kind of becoming more and more, um, flagrant, if you will.

Speaker 3: (30:29)
Yeah. Well, and it speaks to a startup. I was part of a mentoring group for several years ago. You know, when we first talked about the idea of this data or API economy, you know, initially it was like, well, yeah, it’s everywhere. APS are everywhere where we would would, this isn’t anything new. But as, as you were talking just now, there’s a component to it that really rings true because this particular, this particular business model was looking at, uh, activities

Speaker 3: (31:01)
for a, what lawyers, how they would, how they would settle a case, how long it would take to settle a case on a specific type of claim. Who the, who the people were that were involved with it from a, from a legal standpoint. And then, um, taking that information and feeding it back to an insurance company to help them settle faster or for the right amount, right. To take the, you know, somebody got injured in a work accident and they had to wait three years to get their $200,000 or whatever the number is, they could, they could settle much quicker. Well, when you think about information that sits inside of organizations, I mean, if I could just figure out a way to access that, this thing over here that would make my life and everybody else’s life so much easier. I mean, I think you’re onto something with that. I mean it, and I’m on the tech side, we think about it a lot, but I don’t know as you think about it as much when you get into, um, services based industries or you know, finance and insurance, they’re always looking for ways to leverage information to make more money.

Kyle Hamer: (32:08)

Speaker 3: (32:09)
But I don’t know, is there fully appreciating or fully vested into the, Hey, if I share information, I could even make more and more money. Like, um, it’s a, it’s a really interesting and kind of a new concept.

Mark Skiles: (32:22)
Well, the whole idea of information sharing, really scared of it. That’s one of the things that kind of bumped into a lot of times because even development teams aren’t used to sharing, they think of themselves as siloed. Right. I’ve just, this data is only relevant to my application. I don’t really care what everybody else thinks about it. Right. I’ll get into the data warehouse that’ll become a single source

Speaker 3: (32:40)
of truth or, or however they, but reality is at an application standpoint, some of these applications needed to talk to each other transactionally in a different way. And so they had to start thinking about it in a, in a, in a, how do we share things? Well, right. That was just a, knew that that was a totally cultural barrier that we had to kind of work through. It’s not done yet. That’s a conversation. That’s not, yeah. Well and I completely, I can completely appreciate that we’re working with another, uh, we’re going on another project right now where we have three disparate systems all looking at singular behavior and we’d like to get it aggregated into a single view because it’s, it’s challenging to say, well, this one tracks where you, where you came from, that one tracks how you behave and this one, this is how we support and sell and serve into that.

Speaker 3: (33:27)
So it’s, it’s, uh, the, the, the more technology we build, the, I think the higher demand there is going to be for that, you know, uh, information exchange or inner polarity between two applications beyond just here’s the API, connect them together using a Zapier where your own custom code. It’s making it meaningful, making it so that I can get access to the information. Yep. Cool. And that gets us back to the data to decisions thing, right? To turn it from just data, Raul pieces of bits and bites of things into something useful for decision making. So, so ultimately it has to, if it’s not, it’s not useful to me in that fashion. Uh, then I spend a lot of money and get not getting the dollar value that I need to out of it. Well, you’re, you’re spot on and you’ve been consistent for years with, from data to decisions. Uh, integrity works. I think that will continue and I love, I love hearing about your project. Well, thanks. Thank you. Enjoyed the conversation. Thanks for the invite. Thanks for sharing today, Mark. Those for those that, uh, want to get ahold of Mark, his email address will be on the website, a Haimer or you can

Kyle Hamer: (34:35)
searching for Mark Skiles on LinkedIn, although I’ll tell you he’s not on there as much as he is his email. Um, but, uh, we do appreciate your time today, Mark. And for those that are listening, tune in next week when we have another episode for summit. Interesting topics, business insights.

Mark Skiles
Mark SkilesFractional CDO
With over 30 years of experience, Mark has led software development teams as a solutions architect and spent the last 15+ years working closely with Microsoft SQL server in a variety of capacities –Data Architect, BI Solutions Architect and more recently Azure SQLCloud Architect. Mark is curious and passionate about finding practical ways to leverage technology to turn data into something meaningful.