>> From Cambridge, Massachusetts, it's The Cube, covering MIT Chief data Officer and Information Quality Symposium 2019. Brought to you by SiliconANGLE Media. >> Welcome back to Cambridge, everybody. We're here at Tang building at MIT for the MIT CDOIQ Conference. This is the 13th annual MIT CDOIQ. It started as a information quality conference and grew through the big data era, the Chief Data Officer emerged and now it's sort of a combination of those roles. That governance role, the Chief Data Officer role. Critical for organizations for quality and data initiatives, leading digital transformations ans the like. I'm Dave Vallante with my cohost Paul Gillin, you're watching The Cube, the leader in tech coverage. Mark Chrisco is here, the deputy, sorry, Principle Deputy Director for Enterprise Information at the Department of Defense. Good to see you again, thanks for coming on. >> Oh, thank you for having me. >> So, Principle Deputy Director Enterprise Information, what do you do? >> I do data. I do acquisition data. I'm the person in charge of lining the acquisition data for the programs for the Under Secretary and the components so a strong partnership with the army, navy, and air force to enable the department and the services to execute their programs better, more efficiently, and be efficient in the data management. >> What is acquisition data? >> So acquisition data generally can be considered best in the shorthand of cost schedule performance data. When a program is born, you have to manage, you have to be sure it's resourced, you're reporting up to congress, you need to be sure you have insight into the programs. And finally, sometimes you have to make decisions on those programs. So, cost schedule performance is a good shorthand for it. >> So kind of the key metrics and performance metrics around those initiatives. And how much of that is how you present that data? The visualization of it. Is that part of your role or is that, sort of, another part of the organization you partner with, or? >> Well, if you think about it, the visualization can take many forms beyond that. So a good part of the role is finding the authoritative trusted source of that data, making sure it's accurate so we don't spend time disagreeing on different data sets on cost schedule performance. The major programs are tremendously complex and large and involve and awful lot of data in the a buildup to a point where you can look at that. It's just not about visualizing, it's about having governed authoritative data that is, frankly, trustworthy that you can can go operate in. >> What are some of the challenges of getting good quality data? >> Well, I think part of the challenge was having a common lexicon across the department and the services. And as I said, the partnership with the services had been key in helping define and creating a semantic data model for the department that we can use. So we can have agreement on what it would mean when we were using it and collecting it. The services have thrown all in and, in their perspective, have extended that data model down through their components to their programs so they can better manage the programs because the programs are executed at a service level, not at an OSD level. >> Can you make that real? I mean, is there an example you can give us of what you mean by a common semantic model? >> So for cost schedule, let's take a very simple one, program identification. Having a key number for that, having a long name, a short name, and having just the general description of that, were in various states amongst the systems. We've had decades where, however the system was configured, configured it the way they wanted to. It was largely not governed and then trying to bring those data sets together were just impossible to do. So even with just program identification. Since the majority of the programs and numbers are executed at a service level, we worked really hard to get the common words and meanings across all the programs. >> So it's a governance exercise the? >> Yeah. It is certainly a governance exercise. I think about it as not so much as, in the IT world or the data world will call it governance, it's leadership. Let's settle on some common semantics here that we can all live with and go forward and do that. Because clearly there's needs for other pieces of data that we may or may not have but establishing a core set of common meanings across the department has proven very valuable. >> What are some of the key data challenges that the DOD faces? And how is your role helping address them? >> Well in our case, and I'm certain there's a myriad of data choices across the department. In our place it was clarity in and the governance of this. Many of the pieces of data were required by statute, law, police, or regulation. We came out of eras where data was the piece of a report and not really considered data. And we had to lead our ways to beyond the report to saying, "No, we're really "talking about key data management." So we've been at this for a few years and working with the services, that has been a challenge. I think we're at the part where we've established the common semantics for the department to go forward with that. And one of the challenges that I think is the access and dissemination of knowing what you can share and when you can share it. Because Michael Candolim said earlier that the data in mosaic, sometimes you really need to worry about it from our perspective. Is too much publicly available or should we protect on behalf of the government? >> That's a challenge. Is the are challenge in terms of, I'm sure there is but I wonder if you can describe it or maybe talk about how you might have solved it, maybe it's not a big deal, but you got to serve the mission of the organization. >> Absolutely. >> That's, like, number one. But at the same time, you've got stakeholders and they're powerful politicians and they have needs and there's transparency requirements, there are laws. They're not always aligned, those two directives, are they? >> No, thank goodness I don't have to deal with misalignments of those. We try to speak in the truth of here's the data and the decisions across the organization of our reports still go to congress, they go to congress on an annual basis through the selected acquisition report. And, you know, we are better understanding what we need to protect and how to advice congress on what should be protected and why. I would not say that's an easy proposition. The demands for those data come from the GAO, come from congress, come from the Inspector General and having to navigate that requires good access and dissemination controls and knowing why. We've sponsored some research though the RAND organization to help us look and understand why you have got to protect it and what policies, rules, and regulations are. And all those reports have been public so we could be sure that people would understand what it is. We're coming out of an era where data was not considered as it is today where reports were easily stamped with a little rubber stamp but data now moves at the velocities of milliseconds not as the velocity of reports. So we really took a comprehensive look at that. How do you manage data in a world where it is data and it is on infrastructures like data models. >> So, the future of war. Everybody talks about cyber as the future of war. There's a lot of data associated with that. How does that change what you guys do? Or does it? >> Well, I think from an acquisition perspective, you would think, you know. In that discussion that you just presented us, we're micro in that. We're equipping and acquiring through acquisitions. What we've done is we make sure that our data is shareable, you know? Open I, API structures. Having our data models. Letting the war fighters have our data so they could better understand where information is here. Letting other communities to better help that. By us doing our jobs where we sit, we can contribute to their missions and we've aways been every sharing in that. >> Is technology evolving to the point where, let's assume you could dial back 10 or 15 years and you had the nirvana of data quality. We know how fast technology is changing but is it changing as an enabler to really leverage that quality of data in ways that you might not have even envision 10 or 15 years ago? >> I think technology is. I think a lot of this is not in tools, it's now in technique and management practices. I think many of us find ourselves rethinking of how to do this now that you have data, now that you have tools that you can get them. How can you adopt better and faster? That requires a cultural change to organization. In some cases it requires more advanced skills, in other cases it requires you to think differently about the problems. I always like to consider that we, at some point, thought about it as a process-driven organization. Step one to step two to step three. Now process is ubiquitous because data becomes ubiquitous and you could refactor your processes and decisions much more efficiently and effectively. >> What are some of the information quality problems you have to wrestle with? >> Well, in our case, by setting a definite semantic meaning, we kicked the quality problems to those who provide the authoritative data. And if they had a quality problem, we said, "Here's your data. "We're going to now use it." So it spurs, it changes the model of them ensuring the quality of those who own the data. And by working with the services, they've worked down through their data issues and have used us a bit as the foil for cleaning up their data errors that they have from different inputs. And I like to think about it as flipping the model of saying, "It's not my job to drive quality, "it's my job to drive clarity, "it's their job to drive the quality into the system." >> Let's talk about this event. So, you guys are long-time contributors to the event. Mark, have you been here since the beginning? Or close to it? >> Um... About halfway through I think. >> When the focus was primarily on information quality? >> Yes. >> Was it CDOIQ at the time or was it IQ? >> It was the very beginnings of CDOIQ. It was right before it became CDOIQ. >> Early part of this decade? >> Yes. >> Okay. >> It was Information Quality Symposium originally, is that was attracted you to it? >> Well, yes, I was interested in it because I think there were two things that drew my interest. One, a colleague had told me about it and we were just starting the data journey at that point. And it was talking about information quality and it was out of a business school in the MIT slenton side of the house. And coming from a business perspective, it was not just the providence of IT, I wanted to learn form others because I sit on the business side of the equation. Not a pure IT-ist or technology. And I came here to learn. I've never stopped learning through my entire journey here. >> What have you learned this week? >> Well, there's an awful lot I learned. I think it's been... This space is evolving so rapidly with the law, policy, and regulation. Establishing the CDOs, establishing the roles, getting hear from the CDOs, getting to hear from visions, hear from Michael Conlan and hear from others in the federal agencies. Having them up here and being able to collaborate and talk to them. Also hearing from the technology people, the people that're bringing solutions to the table. And then, I always say this is a bit like group therapy here because many of us have similar problems, we have different start and end points and learning from each other has proven to be very valuable. From the hallway conversations to hearing somebody and seeing how they thought about the products, seeing how commercial industry has implemented data management. And you have a lot of similarity of focus of people dealing with trying to bring data to bring value to the organizations and understanding their transformations, it's proven invaluable. >> Well, what did the appointment of the DOD's first CDO last year, what statement did that make to the organization? >> That data's important. Data are important. And having a CDO in that and, when Micheal came on board, we shared some lessons learned and we were thinking about how to do that, you know? As I said, I function in a, arguably a silo of the institution is the acquisition data. But we were copying CDO homework so it helped in my mind that we can go across to somebody else that would understand and could understand what we're trying to do and help us. And I think it becomes, the CDO community has always been very sharing and collaborative and I hold that true with Micheal today. >> It's kind of the ethos of this event. I mean, obviously you guys have been heavily involved. We've always been thrilled to cover this. I think we started in 2013 and we've seen it grow, it's kind of fire marshal full now. We got to get to a new facility, I understand. >> Fire marshal full. >> Next year. So that's congratulations to all the success. >> Yeah, I think it's important and we've now seen, you know, you hear it, you can read it in every newspaper, every channel out there, that data are important. And what's more important than the factor of governance and the factor of bringing safety and security to the nation? >> I do feel like a lot in, certainly in commercial world, I don't know if it applies in the government, but a lot of these AI projects are moving really fast. Especially in Silicon Valley, there's this move fast and break things mentality. And I think that's part of why you're seeing some of these big tech companies struggle right now because they're moving fast and they're breaking things without the governance injected and many CDOs are not heavily involved in some of these skunk works projects and it's almost like they're bolting on governance which has never been a great formula for success in areas like governance and compliance and security. You know, the philosophy of designing it in has tangible benefits. I wonder if you could comment on that? >> Yeah, I can talk about it as we think about it in our space and it may be limited. AI is a bit high on the hype curve as you might imagine right now, and the question would be is can it solve a problem that you have? Well, you just can't buy a piece of software or a methodology and have it solve a problem if you don't know what problem you're trying to solve and you wouldn't understand the answer when it gave it to you. And I think we have to raise our data intellectualism across the organization to better work with these products because they certainly represent utility but it's not like you give it with no fences on either side or you open up your aperture to find basic solution on this. How you move forward with it is your workforce has got to be in tune with that, you have to understand some of the data, at least the basics, and particularly with products when you get the machine learning AI deep learning, the models are going to be moving so fast that you have to intellectually understand them because you'll never be able to go all the way back and stubby pencil back to an answer. And if you don't have the skills and the math and the understanding of how these things are put together, it may not bring the value that they can bring to us. >> Mark, thanks very much for coming on The Cube. >> Thank you very much. >> Great to see you again and appreciate all the work you guys both do for the community. All right. And thank you for watching. We'll be right back with our next guest right after this short break. You're watching The Cube from MIT CDOIQ.