Dave McComb: Semantic Modeling for the Data-Centric Enterprise – Episode 29

By /

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS

photo of Dave McComb, expert on semantic modeling for data-centric enterprises
Dave McComb

During the course of his 25-year consulting career, Dave McComb has discovered both a foundational problem in enterprise architectures and the solution to it.

The problem lies in application-focused software engineering that results in an inefficient explosion of redundant solutions that draw on overlapping data sources.

The solution that Dave has introduced is a data-centric architecture approach that treats data like the precious business asset that it is.

We talked about:

  • his work as the CEO of Semantic Arts, a prominent semantic technology and knowledge graph consultancy based in the US
  • the application-centric quagmire that most modern enterprises find themselves trapped in
  • data centricity, the antidote to application centricity
  • his early work in semantic modeling
  • how the discovery of the “core model” in an enterprise facilitates modeling and building data-centric enterprise systems
  • the importance of “baby step” approaches and working with actual customer data in enterprise data projects
  • how building to “enduring business themes” rather than to the needs of individual applications creates a more solid foundation for enterprise architectures
  • his current interest in developing a semantic model for the accounting field, drawing on his history in the field and on Semantic Arts’ gist upper ontology
  • the importance of the concept of a “commitment” in an accounting model
  • how his approach to financial modeling permits near-real-time reporting
  • his Data-Centric Architecture Forum, a practitioner-focused event held each June in Ft. Collins, Colorado

Dave’s bio

Dave McComb is the CEO of Semantic Arts. In 2000 he co-founded Semantic Arts with the aim of bringing semantic technology to Enterprises. From 2000- 2010 Semantic Arts focused on ways to improve enterprise architecture through ontology modeling and design. Around 2010 Semantic Arts began helping clients more directly with implementation, which led to the use of Knowledge Graphs in Enterprises. Semantic Arts has conducted over 100 successful projects with a number of well know firms including Morgan Stanley, Electronic Arts, Amgen, Standard & Poors, Schneider-Electric, MD Anderson, the International Monetary Fund, Procter & Gamble, Goldman Sachs as well as a number of government agencies. Dave is the author of Semantics in Business Systems (2003), which made the case for using Semantics to improve the design of information systems, Software Wasteland (2018) which points out how application-centric thinking has led to the deplorable state of enterprise systems and The Data-Centric Revolution (2019) which outlines a alternative to the application-centric quagmire.

Prior to founding Semantic Arts he was VP of Engineering for Velocity Healthcare, a dot com startup that pioneered the model driven approach to software development. He was granted three patents on the architecture developed at Velocity. Prior to that he was with a small consulting firm: First Principles Consulting. Prior to that he was part of the problem.

Connect with Dave online

Resources mentioned in this interview

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Knowledge Graph Insights podcast, episode number 29. Every modern enterprise wrestles with its data, trying to get the most out of it. The smartest businesses have figured out that it isn’t just “the new oil” – data is the very bedrock of their enterprise architecture. For the past 25 years, Dave McComb has helped companies understand their data, discovering along the way the importance of adopting a data-centric mindset that reveals the essential nature and the true value of this precious asset.

Interview transcript

Larry:
Hi, everyone. Welcome to episode number 29 of the Knowledge Graph Insights Podcast. I am really happy today to welcome to the show Dave McComb. Dave, I think it’s safe to say he’s a legend in the ontology and knowledge graph worlds. He’s the author of three books. One early book called Semantics in Business: The Savvy Manager’s Guide, which was probably ahead of its time, which is fine. Dave’s that kind of guy. He also wrote the books Software Wasteland and The Data-Centric Revolution, which set the problem that we have in current enterprise architectures and the proposed a solution. Those, by the way, are both under revision. By the end of 2025 or so, we should see new editions of those.
Welcome, Dave. Tell the folks a little bit more about what you’re up to these days.

Dave:
Great. Thanks, Larry. Well, we’re still running a company here. We have Semantic Arts, probably it’s about 30 employees. 20 ontologists and five semantic developers doing God’s work, making companies more data-centric. That’s what we do now. We go into companies, mostly medium to large-sized companies, and help them.

Dave:
What we’ve done since the publishing of the book, we started doing it around the publishing of the book, is just figuring out a methodological, and fairly safe and incremental way to get there. Because I think a lot of companies are burned out from so-called legacy modernization projects and digital transformation projects that didn’t go well. There’s a lot of scar tissue there. We’ve figured out a way to, first, move some of your data, get it into the graph, get you used to it. Then start moving more, and then more functionality, and just gradually get people there.

Larry:
That’s the classic smart consultant, baby steps, proofs of concept.

Dave:
Yeah.

Larry:
Small work out there.

Dave:
Yeah.

Larry:
Hey, let’s back up a little bit and talk about, because I’m going to guess that many if not most of my listeners are familiar with you. But for those who aren’t, can you talk a little bit about the philosophy? Because you’ve got a well-articulated philosophy set out in two books about the problem this application-centric quagmire that enterprises got themselves into, and then the data-centric way. Can you talk a little bit about the … I’d love to know where the idea occurred to you, how you identified the problem, and then a little bit about the two books.

Dave:
Yeah. I started my career with Arthur Anderson, the accounting firm, but they had a consulting division which originally was just called the Administrative Services Division. How innocuous. We worked with the accountants a lot. Then it, as we know, eventually grew into the consulting division, which was Arthur Anderson Consulting, which is now Accenture. They grew like crazy. But back in those early days, we built and implemented mostly accounting systems. I had a career of going around the world, implementing, often building from scratch because it was early days, accounting systems. Including two pretty major full-function ERP systems built from the ground up, and one of them in multi-currency. Pretty sophisticated.

Dave:
It’s two things I thought I knew at the time. One, I thought I knew accounting and accounting systems. And I thought I knew the right path for building enterprise applications. But then, right as I was leaving and then as I was doing some independent work on the side, I started to see what was actually going on. That companies were just implementing system, after system, after system. You’d go into a client and they’d have a dozen inventory control systems. You’d go, “Wow, not only do you have a dozen of them.” By the way, I’m going to update that and I’ll give you some metrics about how many systems most of our clients currently have.

Dave:
What bothered me more was they’re all completely arbitrarily different. Not only did every single one of them, which had hundreds or thousands of tables, and each table had dozens of columns, and every one of them had some totally made up name. Some of them, German acronyms, all kinds of stuff. They were even structured differently. You’d go, “Wow. What would cause several different smart people to design an inventory control system and have them come out that different?” We studied database design, third normal form, and all that. If you’d laid out the problem exactly the same, you’d do third normal form, and you’d get to the same answer, but they were not starting from the same place. Then you go, “Wow. Why not? What’s going on here?” This is the early ’90s.

Dave:
This is back before the World Wide Web, you would have to go to the library to do research. And so we’d go to library, and find magazine articles, and photocopy them, and all those. I know I still have a three-ring binder. There were four articles at that time about applying semantics to information systems. We had devoured, I think, everything that was known at the time. Now, of course, if we did a Google search, there probably was other stuff that we didn’t find. We invented this thing we called semantic modeling and said maybe, if you started from what things really mean, you’d actually figure out that inventory actually really means widgets and bins, whatever it is. But you’d hopefully start from the same place and end in the same place.

Dave:
Yeah, that was my observation and how we got into this. A few minutes ago, I’d promised I’d come up with some metric. As we’ve been going from client to client now, and this is not an exact metric but it’s close enough to be scary, take the number of employees you have in your company and divide it by 10, that’s probably about how many applications you’re currently managing.

Larry:
Wow.

Dave:
Think about it. Some of our clients have 100,000 employees. This one of them I’m thinking of in particular has 11,000 applications that they manage. Which is kind of crazy.

Larry:
Yeah, because the fundamental … I love the focus, the early focus on semantic modeling. Because if you look at it from what do we got here, you’re not going to end up with 11,000 things.

Dave:
Yeah.

Larry:
Much less even tables or concepts that you’re dealing with.

Dave:
Yeah.

Larry:
What did that early … This is before RDF and OWL, and all these.

Dave:
Yeah, right.

Larry:
How did that model manifest technologically?

Dave:
Yeah. Obviously, it was hand-drawn circles, and arrows, and triangles, and all this, to design the model. The first place we implemented, we were doing a joint venture with the architects that designed all the Walmarts. It’s kind of an interesting distinction. There’s one architectural firm in Tulsa, Oklahoma, that designed all of the Walmarts in North America. It’s not a design achievement, but it’s a logistical achievement because, at the time, Walmart was opening a store a day. These architects were racing around the country.

Dave:
We ended building, we’d built a semantic model. What really ended up training that light on was something they called the volume building industry. That there was something peculiarly different about building lots and lots of the same buildings rapidly than there was building nice, big projects. In fact, one of the differences, I don’t know, I used to have a project management software company for a while. When you’re running a project and something slips, you reschedule the whole project and move some things around so you can still hit that end date. That’s not how you do it when you’re trying to open a Walmart a day. You use a whole bunch of other different techniques.

Dave:
What they wanted, which was prescient now as I think about it, was a way to collapse all of these other contractors and subcontractors, and even the marketing people, because everybody was queuing up for this store in Springfield to open on a particular day. You had to have the hiring plan, and the marketing plan, and the final construction, and all that. They wanted to collapse it into a single common denominator, this one project management, I think we called it the ACH, now I forgot what that stands for. It’s the way the banking system moves funds around, we were going to move scheduling around.

Dave:
Actually, we ended up building that in C++, but now I’m trying to remember what database that was on. It can’t have been anything interesting. Although, the next project, we then moved into a healthcare information system and stumbled into an object-oriented database called Matisse. God, it was a great database. And built this whole semantic model on top of an object-oriented database. It was kind of a shame they didn’t catch on. Yeah, that’s what was happening in the early-

Larry:
That’s interesting. I don’t know a lot about C++, but an object-oriented database, that seems more graphy than a table-based relational database.

Dave:
Absolutely.

Larry:
Yeah, interesting. This was proto … Were you just relieved when RDF and all these ensuing standards came along?

Dave:
Yeah, yeah. Yeah.

Larry:
Tell me how that … We have this generic problem that you’re helping people solve of they’re just mired in this application-centric thing, sourcing data willy-nilly, and tucking it away in silos. Talk about data-centricity and how that helps fix this.

Dave:
Yeah. There’s one belief that, which is a true belief which is why it persists, that we have thousands of applications, each of them have thousands of concepts in them. If somehow we could just learn all this and bring it to the surface, we’d have a data fabric, or at least we’d have access to all our data, or something. But it really just doesn’t work. It doesn’t work because it’s too much work and people aren’t … It is too much work, it’s just gigantic, the scale of it.

Dave:
But it turns out, it’s almost like if you look through the telescope the other way, “Oh, yeah, this is actually simple.” This isn’t anywhere near as hard as you think it is. We have this process where we go in and help people, we say we uncover their core model. There is, hidden in all that noise, is a single, simple model that ties everything together. That single, simple model, we often call it the core model of that enterprise, is typically around 200 to 4 or 500 classes, and a few hundred properties. In a graph database, it’s like Tinker Toys, there’s a node, an edge, and a node. Those nodes belong to classes, not in the way that even object-oriented or certainly relational. It’s not a hard structure like that. They are sets and they can belong to multiple classes. The key that you do want to define and figure out, what kinds of different things are there in this realm.

Dave:
Maybe, we’ll have a tangent and we’ll talk about gist is our upper-ontology starting point, which we’ve evolved out of probably over 100 projects now. We’re pretty confident that it’s a very solid starting point. You’d start with that, make sure you’re not getting sloppy about your concepts. Find the rest of the distinctions in that enterprise. Then, armed with that, then you go into an application and say, “Okay, where are these things?” It’s much easier because you’re dealing with a few hundred things, instead of millions of things. You just go in, “I know there’s some inventory in here, I know there’s some product specifications. Where are they? Show me where they are. Okay, there they are.” Which is way easier.

Dave:
Then after you’ve done that, we did this in a funny way with a subsidiary of one of our clients. After you’ve done that, you then say, “Okay, is there anything else in this database that’s important?” You look around. “Well, yeah, there’s this other thing.” Okay, give me that other thing. Okay, good, that’s it. That’s all you got.

Larry:
Interesting. A lot of ontologists take some balance between the top-down and bottom-up approach. It sounds like you’re very much a top-down, “Hey, let’s see what’s going on here,” and then articulate that. But then, there’s still the need to account for all those instances below. How does that fit in your ontology process?

Dave:
Well, the way we keep ourselves honest, and we didn’t originally in the early days. We would design things top-down, but not implement them because we were architects for a while, but now we’re actually building. The process of actually building is the thing that keeps you the most honest. You bring in the data. Is it complete? Will it tie back to this? It’s mostly a matter of a lot of reconciliation. Over here, you had 80,000 employees in your employee database. When we finally converted it all to the graph, “Oh, yeah, good. We got 80,000.” Or whatever.

Dave:
But then, at some point, to your point, “Well, okay. What else is there that we don’t have?” Then they articulate that. There’s an amazing amount of redundancy in existing systems. Not only within systems, but between systems. Especially between systems, but even within systems. They’re always copying stuff to another table just to have it there, and de-normalizing out the wazoo. A lot of that goes on. You don’t need extra copies of the same stuff, for sure.

Dave:
There’s also a lot of just process variables that aren’t necessarily needed. Unless you’re trying to recreate the process, which eventually you will. 90% of them are peculiar to the way that application did a process, not to its essential nature. Yeah, there’s just a lot of stuff like that that, over time you realize, yeah, most of that you didn’t need. Oh, and there’s always a whole bunch of columns of stuff that just aren’t used or aren’t used anymore. Mostly if you buy a package, three-fourths of that stuff you don’t use at all, and one-fourth of it you haven’t used for five years. We don’t need that.

Larry:
Yeah. I love that you said the essential nature of the data. One of the things that, to me, data-centricity implies is, and you’ve talked specifically about this. Data, it’s this precious enterprise asset that should be treated as such, not some willy-nilly thing that just some application developer sources on the fly. How does that manifest? Just having said that out loud, I’m like, “Oh, yeah, and you just ask people to do it and they do it.” Well, of course that never … How do you actually do that in an enterprise setting?

Dave:
Yeah. Yeah, you were not quite making fun of me, but when I was describing, before we started, our process, you said, “Yeah, that’s what most consultants do, baby steps.” Yeah, but you have to for two to three reasons.

Dave:
One, enterprise have lost their appetite for these giant moon-shot, we’re going to fix everything even if we knew exactly what it was. I think you have to be incremental in that way. But it also, the idea is just enough different that people don’t quite get it. We’ve gone in with a lot of partners and stuff to do a proof of concept, and people largely don’t get proofs of concept either.

Dave:
What I’ve discovered after watching this for quite a while, it’s not until they see their exact data in some different form, that’s when the light goes on. If you show somebody something very similar or with mocked up data, or whatever, they just look at it like, “Well, I don’t know how that applies to me.”

Larry:
Interesting. Every practitioner I know has some kind of, not parlor trick, but this jiu-jitsu thing that you do to show, “Okay, here’s what’s actually going on.” Instead of boilerplate examples or something, you’ll say, “Hey, can you give me this database or this table,” or whatever, “We’ll do it this way.” This, to me, is where this is how their understanding of their data as this precious thing comes to light. Is that the technique there?

Dave:
Yeah, absolutely. Yeah, absolutely. Then, the idea of the preciousness of it, when we first tripped to this, it might have been also back in the early ’90s. There was an article and I’ve had a tough time finding it again. I’ll go look harder. By an Egyptian guy, and it was talking about enduring business themes. His whole point was there are a handful of things in business that really endure for decades, or even centuries. That the applications come and go, and they have different fads, and different structures, and they call them different things, and we do some for a while, but these enduring business themes just persist. If you can build your systems on the enduring business themes, you’ve got some real permanence. Which even gives you the flexibility to do the fad of the month. “We’ll do the fad of the month and do whatever we want to do, but we’re going to do it on this solid bedrock.” Which, by the way, is your essential data.

Larry:
Interesting. That’s a great way to look at it, too. It’s a lot more solid than data is the new oil.

Dave:
Yeah, right.

Larry:
It’s a way better metaphor. It’s like, no, no, no, it’s the bedrock, the very foundation of our business.

Dave:
Yeah, yeah.

Larry:
Yeah, that’s a way better metaphor.

Dave:
Yeah.

Larry:
I want to go back, you mentioned early on you were at Arthur Anderson doing a lot of accounting consulting there. Is this a full circle thing? I know one of your current interests is around accounting. I’d love to learn a little bit more about that.

Dave:
Yeah. Like I mentioned earlier, started my career with Arthur Anderson, built accounting systems. But then, got into semantics and, for one reason or another, I’ve not looked at accounting for 25 years now. I think most of our clients now wrongly believe it’s a solved problem. Or they don’t want some boutique firm coming in and messing with their books. Okay, I get it. We’ll go over and do something else, fine.

Dave:
But at one point we said, “You know, … is right and we’re making progress, but it’s kind of slow in these big companies.” I’d like to be able to get a medium-sized company completely data-centric in a finite amount of time, like a couple years. Still a hard problem. Then I thought, “What would have to be in place for that to be possible?” I’ve decided, I think it was four or five things that had to be in place. You had to have a complete ontology, core model ready to go, before you started the project. You had to have all of their common use cases already implemented – in an architecture that would allow you to change them rapidly because you’re not going to get them exactly right. You’d have to know all of their existing systems, because you got to mine the data out of them and do it efficiently, so you got to know what all those table names and stuff are in the common systems. And you have to know what’s important, the key values and all the jargon.

Dave:
All of that argues for going after a narrow vertical industry. We said, “Okay, we can do that. Why don’t we start with ourselves as the guinea pig and get most of this working, and then pivot over to something similar to us?” We’re loosely in the professional services business. We said, “Why don’t we go after architects?” I was fascinated with those architects at the Walmart, and we run into architects all the time. It seems like it should work. There’s not that many, we can go identify them. We sit down to do this and all of a sudden I realize the incredible centrality of accounting in the middle of this core model, and all the use cases, and everything I just rattled off, and the existing systems.

Dave:
We sat down and said, “Okay, how hard can this be? I already know accounting. I know semantics. I’ll just make a semantic model of accounting,” and I did that. But then, you just start digging a little harder and thinking, “Oh, you know, this isn’t satisfying.” The more I started digging, the more we started uncovering, two things started happening simultaneously. One I thought, “Wow, this is way more profound than I first thought and it’s taking longer.” I got a professor of accounting involved in the project, mostly to keep me honest because I go start doing some pretty extreme stuff. We decided to write a book, so we’re writing a book now in parallel with building this internally in preparation for getting ready for the architectural market. But the number of insights, and insights is a misnomer, pretty profound revelations, paradigm shifts I guess, we’ve come across are pretty amazing. I can’t wait to get both the book and the system finished. It’s like I was saying earlier. Until we can show it to somebody, they don’t get it.

Larry:
No, that’s fascinating. Now I’m curious, I know a little bit about accounting, not a huge amount. Is it something beyond or different from the old double entry bookkeeping that’s been around for 500 years?

Dave:
Yes.

Larry:
Oh, interesting.

Dave:
Yes.

Larry:
That’ll be a tiny bit revolutionary.

Dave:
Yeah. I didn’t set out to get rid of debits and credits. But the deeper you get into this you realize, A, they get in the way and they’re not needed to get in the way.
By the way, this is a fun fact. Even with all those accounting systems I built, I didn’t realize literal debits and credits have already been gone for about 50 years. It’s kind of a joke on the industry. If you pop the hood of any of the big accounting systems and go looking for a column heading. I was thinking, “Oh, there’d be one called debit and one called credit,” because it looks like that when we put a trial balance together and stuff.

Larry:
Yeah.

Dave:
Nope. There’s one column there and if the number is negative, in certain reports they’ll put it over on the credits side. At first, everybody listening to this is going, “Oh, surely, no. Come on. They didn’t do that.” We do some little experiments to prove it in different systems. Yes, that’s actually how it’s implemented.

Larry:
Holy cow.

Dave:
Every once in a while, it leaks out when you do certain kinds of reports. There’s just a whole bunch of rules right now to realize, well, the liability accounts, we know they normally are negative. On a trial balance sheet, you’d see them as a credit. But when we actually put it on the financial systems, we multiply them by negative-one so they look sensible. But every once in a while, there’s a contra-liability. It was positive, therefore it would have been a debit on the trial balance, but when you multiply that, and then it will show up correctly negative on the financial statement. All of this rigamarole just to keep the accountants happy.

Larry:
That’s so interesting. I love that you’re getting … And this is based again on semantics which is your core competency, you just looked at it from what do these things actually mean. Well, I can’t wait to see if you can dismantle or reorganize that whole thing.

Larry:
But hey, I want to ask a quick question about that. As you do this, you have this specific use case of, well first, professional services, and then specifically accounting. Then you talked about the core ontological model and common use cases, those two seem like really important parts of that. I know one of the things you’ve done at Semantic Arts is develop the gist ontology, this upper. I think most ontology practitioners probably have what their starter kit, or whatever you call it, for ontologies. Tell me about the relationship between did everything inherit nicely from stuff that already exists in gist? Then how specialized does it get as you go into professional services, and then into accounting specifically?

Dave:
It’s surprising how few essential enduring themes there are in accounting. I’ll just rattle them off here, just to give you a flavor. They are directly derivative from gist.

Dave:
By far, the main thing is the concept of a commitment. Almost everything that shows up in your financial statement is the result of a commitment. In fact, the only other thing are some resources, like the inventory, and the cash, and the equipment you’ve got. Set that aside for just a minute. You decide that you’re going to buy something and you make a commitment to pay for it, and they’re making a commitment to deliver it to you. From that moment forward, you need to keep track of those commitments because you don’t have the goods yet and you haven’t paid for them yet. Most of accounting is keeping track of the commitment and the fulfillment of that commitment, and valuing it in dollars to put on a financial statement.

Dave:
We take the commitment and turn them into two major types, which we call rights and obligations. In that little example I had, you have the right to receive that whiteboard you ordered from Amazon, or whatever it is, and the obligation to pay. In this case, you’ve satisfied your obligation to Amazon by getting your Chase credit card, and now you have an obligation to Chase. You’re not going to get out of this. Eventually you decide to pay Chase and you’ve fulfilled that obligation. And you wait for the whiteboard to arrive, and they’ve fulfilled their obligation. Except it’s all crooked and broken, but don’t get me started on that one.

Dave:
You’ve got these obligations. Then you’ve got the events that change the state of the obligation. There’s just a few dozen events. There’s receiving, and committing, and invoicing, and billing, and a few things like that. Timecards, blah, blah, blah. Which are just recognizing that consumption of a resource, a temporal resource in this case. That’s about it.

Dave:
One of the early breakthrough ideas. We used to agonize back at Anderson when I was building these systems, about accounting policy. Accounting policy is the sum total of everything a firm has decided to do. It’s a derivative of generally accepted accounting principles, norms in your industry, and procedures you’ve written, and things you’ve decided to do. It’s in some Wiki page somewhere, and a whole bunch of smart people. It involves what account number should I put on this particular transaction? How should I cost this? Especially, especially, when do I recognize this expense? Recognition just means what is the timing, when it shows up on the income statement.

Dave:
All of that can be reduced to a very simple table for your industry, for your company. A table obviously put in a graph. Such that, when an event occurs, it just immediately bumps up against that table, it knows exactly how to classify, and how to value it, and how to recognize it, all those things. It will be on the financial statement within seconds. I don’t know if you know much about accounting, nothing gets on the financial statement within weeks. It’s ridiculous.

Larry:
It’s essentially real-time financial reporting that this permits then?

Dave:
That’s the title of the book.

Larry:
Oh! Okay, oh.

Dave:
That’s exactly-

Larry:
I guess my editorial instincts are still intact.

Dave:
It took a year for us to come to that title. It’s funny. That is very good.

Larry:
That’s funny.

Dave:
Where were you a year ago? We went around and around.

Larry:
Oh, sorry. Yeah, I was busy. Hey, I can’t believe it, Dave. We’re coming up close to time already. Before we wrap up, is there anything last, anything you want to make sure we share with folks before we close?

Dave:
Let’s see. We didn’t talk about our conference.

Larry:
Oh, yeah!

Dave:
We should do that.

Larry:
For sure.

Dave:
We have this, it’s very much a practitioner conference. There’s no booths, there’s no marketing going on, any of that stuff. It’s just people who are interested and committed to doing this data-centric thing and recognize that, at the moment, you cannot buy data-centric. In fact, in a few years, if you’re an architectural firm, you might be able to sort of, but everybody else. As in a lot of emerging technology in the early days, the implementers have to build it themselves.

Dave:
There’s a lot of people getting together. Some of them are vendors who have pieces of the solution, and many of them are enterprise architects at large firms who are trying to figure out, “What pieces do I need to put together in architecture?” That’s why it’s called, the conference is the Data-Centric Architecture Forum, because it’s what do you need in place to make this work.

Larry:
Nice.

Dave:
That’s the first week of-

Larry:
Yeah. I recently added an events page to my Knowledge Graph Insights Podcast web and it’s already on there, but I’ll put it in the show notes as well.

Dave:
Yeah, yeah, yeah. First week of June, it’s in Fort Collins. Yeah, Colorado.

Larry:
Nice. How many folks usually show up?

Dave:
It’s not big, it’s 50 people, something like that.

Larry:
Oh, nice. That’s cool. I love that kind of event.

Dave:
Yeah. Yeah, this will be our seventh annual.

Larry:
Nice. Well, great. Hey, one very last thing, Dave. If folks want to follow you or connect online, what’s the best place to find you?

Dave:
Yeah, I have a LinkedIn. I’m not one of these people that hang out on LinkedIn, it’s getting a little weird there. McComb at Semantic Arts is probably the best. Go to our web page, it’s not hard to find me. Yeah. I answer emails, so if anybody’s got a legitimate question, I’ll just respond.

Larry:
Excellent. I’ll put those in the show notes as well. Well, thank you so much, Dave. This was a really fun conversation. I really enjoyed talking with you.

Dave:
It was fun, yeah. Thank you, Larry.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top