 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining today's DM Radio Deep Dive with the program Data Governance Sunright, sponsored today by Attunity. It is a deep dive in continuing conversation from a live DM Radio broadcast a few weeks ago, which if you missed, you can go listen to it on demand at dmradio.biz under podcasts. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right hand corner for that feature. For questions, we will be collecting them by the Q&A section in the bottom right hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DM Radio. As always, we will send a follow-up email within two business days, containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now, let me turn the webinar over to Eric Kavanaugh, the host of DM Radio, to introduce today's webinar and speaker, Eric. Hello and welcome. Hello and welcome, ladies and gentlemen. Thank you so much for that introduction, Shannon, and thanks to all of you for being here today. We're going to have a very interesting webcast, and we're going to get really topical. We don't normally get the chance to be this topical, but we got a chance today. The timing just turned out to be rather serendipitous about events in the world, and it's in particular in Washington, D.C. The topic, as you've heard, is get with the program. Data governance done right, so let's dive right in. This is a slide about our speakers. I'll be talking to Matthew Hayes, VP of SAP Business at Atuniti today, and there's yours truly on the right hand side. Quick note, feel free to tweet to the hashtag of DM Radio. We'll try to monitor that during the show. So let's dive right in. Headwinds are approaching, my friends, for those who don't recognize that rather unsettling image. That was Katrina shortly before she made Landfall way back in 2005. I just thought of that as an interesting image because things are changing in the business world, folks. I promise you there is a whole new wave of regulations approaching us right now. It's going to be more difficult to do business is the bottom line. I've been in this business for about 20 odd years now in the industry of information management, and we usually view information as an asset, as something to be used, to be leveraged for all sorts of different reasons. We'll talk about that. But there are headwinds right now, and we're going to learn about that in our broadcast today. And large organizations in particular, especially those in heavily regulated industries like financial services and healthcare, are particularly in the crosshairs. So let's take a look at the past. Remember this guy? Good old Jeff Skilling, member Enron. I actually watched his testimony live. I just happened to be home that day way back in early 2002 in February. And I watched his testimony, and I have to say at the risk of sounding like I'm defending him because I'm not, the man was incredibly smart and skillful and did a tremendous job just weaving all around the congressional interrogators. Of course, he got his comeuppance in the end. But what happened? Of course, that was Enron. There were some really bad things that went on, some terrible shenanigans in the accounting space, and it led to the Sarbanes-Oxby Act, which was a very far-reaching set of regulations that came out of Congress and really fundamentally changed the responsibility level and the penalties and the protocols for board members, for accounting in general, and had a lot of effect on business overall. And honestly, the SOX compliance issues were really serious for quite some time. It's still out there. SOX, you don't hear about it too much anymore, but SOX is still a very major component of big business these days in terms of how you're supposed to report. Of course, it had dramatic impact on the accounting field for obvious reasons. And I would say that we're right now on the precipice of another sea change that is just as significant, just as far-reaching. So what am I talking about there? Well, who watched the news yesterday? I actually took this shot of poor Jim Zuckerberg. He did not look good. My goodness, the man looked like he had just seen 87 million ghosts. Of course, this is the big scandal, the Cambridge Analytica scandal, where this company apparently was able to access tons, just tremendous amounts of data from Facebook, correlated with data from the so-called dark web, and then used that information to do very targeted advertisements and content sharing, potentially fake news, as we've heard about over the last couple of years, and arguably had some significant impact on the election. Well, this is obviously very, very serious stuff, folks. I mean, we're talking about a deep and fundamental violation of privacy in lots of different ways. A lot of us in the business know that this is just the way things work these days, and frankly, trying to rein it in is not going to be easy. In fact, Facebook yesterday talked about an AI engine that will be used to screen content, a.k.a. a sensor. We all hear about terms like hate speech as one of the things that they use, but the point is that we're seeing a very significant development in the industry right now, and it's all about the data. That's the key. It's all about the data and responsibility and practices and policies around data management. Of course, Facebook does have all sorts of different policies and different levels, different thresholds, different privacy settings that you can choose to use or not use, but as we discovered, some entities, partners in fact with Facebook, have been able to pull out tremendous amounts of data and do some pretty remarkable things with them. Well, if you watched the testimony yesterday, you heard the straws of the wind that I heard, and it's interesting because there is a major set of regulation coming out of the EU right now, or very soon. In fact, May 25th, I think, is the deadline when it kicks into place. It's called GDPR, the General Data Protection Regulation, and let's face it, it's coming this way. So, technically, it's for the EU, but it's also affecting US companies who have customers in the EU, and I'm bringing this up because I think yesterday's events finally brought into focus for many American companies what the EU has been talking about for a while, and I would argue, and I've said this to several analyst friends of mine, we are about to see regulation of social media, and that regulation is probably going to move into the areas of data protection and data privacy at the same time. Because of all the breaches that we've seen, we've heard all these just amazing stories about massive breaches of data, of security, protocols like passwords. All these things are combined to create a very strange and troubling environment out there in the world of information management. So, several of the senators who were questioning Mark Zuckerberg asked him, do you think the Europeans have it right? This is what they're talking about. So, let's just take a step back and think about what this whole means, especially from a data governance perspective. Because when you talk about governance, you talk about policies and procedures and protocols and rules and regulations, and how you actually manage the collection, the use, the analysis of data, that's what governance is all about. So, for the entire time of my career, we've viewed data as an asset, right? It fuels business, it fuels transactions, it can be analyzed to improve various processes, to streamline processes, to understand market opportunities, to figure out which new products to roll out, to figure out where you should roll them out, how should you market them. There are countless positive ways that data can be used to improve business. And of course, at the end of the day, what you really want to do is improve that customer experience. You want to have a data policy and a set of regulations and protocols that collectively result in you taking care of your customers and not jeopardizing their privacy and not jeopardizing the sanctity of their data. Well, that's one side of the equation, but there's another side of the equation. Data is also a liability. So, as we've seen in recent years, it certainly can and will be used against people. It can be stolen. It can result in very serious fines with GDPR. It's something like 4% of what they call annual turnover, which basically means gross revenue. Can you imagine if Facebook gets tagged by the EU, by the GDPR for 4% of their gross revenue? Holy Christmas! Some people were saying this could be the beginning of the end for Facebook. Remains to be seen. I doubt that's going to happen, quite frankly. But the point is that's how serious the situation is. And there are other major, major organizations that have had these huge data breaches, and all of this speaks once again to the importance of governance, the importance of having procedures and policies in place. And the people in the data governance field know that. We've been working on this stuff for years. Only recently has it become top of mind for many businesses. I can tell you from my perspective as a marketer in the field of data management, data governance 2, 3, 4, 6, 7, 8, 10 years ago, snoozer. You could send out an e-mail blast with data governance in the headline. And you'd be lucky if 5% of the people opened it. You'd be lucky if maybe 5% of those people actually clicked on something. It just wasn't very interesting. We were more interested in business intelligence, data warehousing, analytics, big data, IOT, all this stuff. But now in the last two years from my experience, and I'm squarely in this field, I can tell you that data governance is now a very hot topic. Many organizations realize why. And that's why I'm saying this recent event with Facebook just testifying before Congress yesterday and today, I promise you it spells a future raft of regulations that are coming down the pike. And I would recommend that all of you out there be prepared for that. So it actually brings to light an old concept, data life cycle management. Who's been in the business long enough to know what that means? Well, that's basically cradle to grave. Well, you have a policy for how you deal with when you access data, when you grab that data or create the data in the first place, how it is managed over its life cycle, how it's used, where it's used, who uses it, all that kind of fun stuff all the way until the end. Now think about data lakes. We keep talking about data lakes. And there is a presumption in the data lake conversation that you want to save all that data and use it because someday you might be able to analyze it while analyzing past behavior of customers, for example, can be very useful to understand and to customize the experience for those customers. If you have a big, complete picture that's so-called 360-degree view of a customer or a client or a partner or some corporate entity, that can be very useful. So the tendency is to think we should keep this data forever. I promise you that is going to change. There are issues like e-discovery in the field of legal worlds. You want to be concerned about what you keep around. You only want to keep data as long as you have to keep it because if you keep it any longer, it's just going to turn up in some e-discovery search and can be used against you. But I promise that is going to fundamentally come back into the picture data life cycle management. What's old is new again. We're going to have policies that are much more shrewd about dealing with data. And we'll talk about that later on in the show. Specifically, one part of the GDPR is the so-called right to be forgotten. Well, the right to be forgotten basically says that if someone, a consumer, wants XYZ Corporation to not maintain their personal data anymore, that company has to go find it and eradicate it. Well, that's going to be tough. I can tell you right now. Think about Google. Think about Facebook. Think about LinkedIn. But then think about all of the big box retailers, all these companies in the Fortune 2000. They have tremendous amounts of data about you. And just to be completely blunt, the objective here I think is frankly unachievable. There's really no way that organizations are going to be able to find every last tidbit of data about you and get rid of it. So what are they going to have to do? They're going to have to focus on critical data assets. And most of that's going to be data in production. So the production data that is running operations for these companies, that's where they're going to need to have obfuscation or eradication or some other mechanism for making that data go away. So what does this mean for data governance professionals? What does this mean for organizations everywhere? Well, I love it when a plan comes together. I think the bottom line is we're going to have to have a plan. And again, if you think about the regulator's perspective, a regulator comes in, an auditor comes in. Think about when the Enron collapse happened. Auditors came in, they started poking around. I'm looking for stuff. Well, if and when that happens, I guarantee you're going to be much better off if you have a plan in place, a data governance plan that is achievable, that is effective, that has some really good thought that's gone into it, and that is defensible. And this is the key, because again, I think a lot of times it's going to be impossible to track everything down, but the regulators are going to be reasonable people, most likely. So if you have a plan in place and you demonstrate that you're acting on that plan, you're going to be okay. So what is data governance? Well, really there are four corners to data governance. People, technology, data, and processes. Now one of the challenges is that most organizations have scores, if not hundreds of information systems. Those systems are not very well connected, just to be blunt. A lot of times they are connected in fairly fragile ways or fairly limited ways. And frankly, that's why we wound up with the whole concept of data warehousing years ago, was to pull data together from multiple sources, be able to put it into a warehouse and then analyze it. Well, we learned a lot over those years. We learned about how to move data. We learned about data movement policies. We learned about access policies, et cetera. These are all critical components in having some sort of a data governance plan. I think we will see technologies like data catalogs really come along and fill a lot of the gaps. But nonetheless, by and large, organizations will need a whole complement of technologies and a whole host of different processes and procedures and policies to be able to manage that kind of thing, to be able to have a plan, once again, that you can put into place that is effective, that is moving through time and getting better over time, and that is defensible to the regulators. So this is all really important stuff. And one of the key issues really in terms of policy is that typically a policy, if it is not dynamically connected to an information system, it is not very enforceable. If you rely on people to read policy documents and then just behave in a certain way, that is not a very defensible posture. But the problem is that very few policy systems are dynamic enough to connect to operational systems and enforce those policies, especially if you want to change those policies over time. We are getting there. I want to change a little bit, but this gets us into the whole space of risk management, and yours truly actually spent a number of years focused on the GRC space, governance, risk management, and compliance. Well, control points are a key component in any governance program, in any risk management program. And let's face it, a lot of these things are overlapping now, and this actually is one of the challenges for data governance because you have lots of different teams whose behavior or activities either overlap in the data governance space, or should be controlled or at least shepherded by a data governance program. Anyone in a large organization knows it's very difficult to get all those cats herded together and to get people to listen to you and to follow rules and so forth. Ideally, you want some kind of a technology that's going to manage that. I think we're going to see that space light up in the next two to four years, quite frankly. But the control point is a very key component of governance. Control point is a walking, talking control point. A human being can be a control point at almost any point of the day. It's a control point at some point at which you can leverage control, at which you can make some change. Turn it on, turn it off. Give someone access, take the access away. These are the kinds of things you need to be able to do if you are going to have some kind of effective governance program. But really, any access point to a software application, well, what does that mean these days? Control points. Application program interfaces. This is how the cloud communicates these days. And an API is a control point. Well, artificial intelligence is going to throw a pretty hard curveball at this whole scenario. And we're going to watch as that plays out as well. Because AI, theoretically, is also representing a control point. But it's kind of a difficult one to manage. But any point at which data is entered or modified in an information system, that is a control point. A control point outlined in your plan. So here again, this is what I was talking about a minute ago, the power and problems with policy. Unless policies are dynamically connected to information systems, it's going to be very difficult to make them work. So I think that this is going to require a lot of time, a lot of attention. There are certain basic protocols, like LDAP, of course, where you can control access to different systems. One of the nice things about the cloud, as a matter of fact, is so much metadata and so much policy is baked into these cloud platforms. Whereas in the old days, because it was all done manually and you had distributed systems, just finding the language, finding the instructions for where things are stored was kind of a challenge, quite frankly. But a lot of these new data catalog technologies are excellent at just basically crawling through your landscape, finding all the different systems, and helping you ferret out where those control points are. So it's going to be really critical in helping companies get good, robust, solid data governance programs in place that are defensible if and when someone comes knocking. And my last slide, before I hand it off to Matt Page of Attinity, who's going to go into this whole right to be forgotten, which is a significant component of GDPR, is attention, architects, and modelers. Over the years, you could control access and you could manage policy really either where the data lives or where the application lives that was referencing the data or using the data. So either at the bottom or the top. But if you think about most, even mid-sized organizations, you've got scores, again, if not hundreds of applications. So trying to manage access across a whole range of disparate applications, that's tough. I mean, it's borderline impossible. I will say there is one big benefit in this case of using a big box retailer like an SAP, for example, which, let's face it, focuses on core business processes. That's where SAP makes a lot of their money, is core business process, enterprise resource planning, and all the basic functionality around that. Accounting, for example, transactions for procurement, all that stuff. If you have a system from one vendor that manages all that stuff, well then you're actually able to curtail at least a significant amount of the negative activity through policy management. But the other very interesting thing that's happened in the last couple of years is a lot of data modeling technology has started to adopt policy management. And if you think about enterprise architecture, if you think about data models, one of the cool things about them is that they extend through the entire information landscape. So now in your models and some of these newer technologies, you can actually bake in attributes or rules, policies for access to information. And what you obviously want is to be able to enforce controls, change those policies as laws change, or as the board decides it moves in different directions, and be able to have visibility and auditability through all of that through that entire matrix. So I think data modelers and information architects are in a very good position right now to help their organizations tackle this rather significant challenge of data governance. And with that, I'm going to hand it off to Matt Hayes of Attunity. Matt Hayes, take it away. Thank you, Eric. Thank you. And yeah, what a great presentation. You know, the GDPR problem is something that most companies globally are going to have to face. It's focused on the EU right now, but this might be the model moving forward. Eric, like you, I was watching a little bit of the Zuckerberg testimony this morning, and, you know, it's clear that this is really, you know, circling down into a compliance issue that's going to be handled at a governance standpoint. You know, it feels like every week we wake up and we hear more, we hear about a new data breach. You know, it's like, you know, I heard Panera Bread had something not so long ago. So you have all these little ones where there's some level of exposure, but then there's a big one, and you know, the Facebook one is something that affects everybody. There's not a lot of people out there that don't have, that aren't either on social media themselves or have family and friends and chitin' kids on social media. So data is definitely an issue and the protection of that data is an issue. So as we get into this, I'm going to zero in on a couple specific concepts around GDPR. First of all, a little bit about attunity. So my role, my name is Matt Hayes. I'm the VP of SAP Business at Attunity. I focus squarely on our data solutions for the SAP market. So we work with companies' data all the time, or we help companies work with their data. We help companies provide data or provision data from wherever it is to wherever it needs to be. So for example, if you wanted to copy some production data down into a sandbox or a test environment, we can help companies leverage their SAP data in that fashion, but we can also help companies replicate data. So Eric, you mentioned data lakes. Data lakes are definitely something that's a growing concept for large enterprises today. People are using Hadoop for distributed data lakes. They're using cloud-based technologies. All you have to do is look at what Microsoft is doing with Azure or looking at what Amazon or AWS is doing with their products, and there's a number of products out there that help companies move and store data. Some of these are just basic landing spots for data. Other places are more thorough data warehouse models so that you can actually churn and burn on that data and make good business decisions. So the two products that we have at Attunity that deal with data that we'll focus on here are Attunity Goal Client and Attunity Replicate. Attunity Goal Client focuses specifically on SAP Test Data Management. So the ability to provide production data into testing environments. This is a product that we've had in the market for over 15 years. Obviously providing production data into a non-production system creates exposure. So what I'm going to get into is some protections and scrambling and obfuscation rules that we've had in that product for many, many years that right now has worked itself right into the sweet spot for GDPR compliance. And of course with data replication, any time that you're replicating data from a system of record to something else, you want to make sure that whatever protections you've taken into consideration in that system of record, that you can transcend those protections downstream to wherever that data is going. That was literally no pun intended. I said downstream and we're talking about data lakes, but that's just happening in my head right now. So the focus for GDPR that we look at is the right to be forgotten. You know, there's a lot of aspects of GDPR. Some of them revolve, some of the requirements revolve around reporting when there is a breach. Some of them involve being able to provide data to you so if you can take your data with you to another company or another vendor. Some of them deal with, you know, something as basic as opting in and opting out of communications with a company. So right to be forgotten though deals specifically with PII data, which is your personally identifiable information. I apologize. I have a tendency to talk ahead of my slides and I got a little bit ahead of myself here. Here's another slide that basically covers what we do on providing data anytime, any data, any place, anytime, lets you kind of see what we do there with Go Client, with Replicate. We also have some data automation, data warehouse automation software with a product called Compose. And then we have a product called Visibility that helps with optimization of data optimization. So where you're managing that data we can help identify hot and cold data, what's being used, what's not being used, and help you move off the data that's not being used. So back to kind of some of the areas that Eric's already covered. May 25th, that's the drop dead date. So that's when this all goes into effect and it remains to be seen how aggressive the EU is going to be at enforcing this. So there's a lot of people feeling that they're going to be, there's a lot of people that are going to feel that they're going to be pretty aggressive right out of the gate to make sure companies are ready for this because obviously many of them are not. So the fines are a big one. You know, 20 million euro or 4% of your annual turnover, tremendous amount of exposure here for a lot of companies. And these are numbers that get CEOs' attention. So it's obviously designed as a mechanism to help companies take this seriously and realize that it's better to be compliant with GDPR than it is to just pay the fines as you go. So getting into it a little bit here, PII, personally identifiable information. You'll hear me talk about PII quite a bit. So PII is basically data that helps you identify an individual. So obviously something like your name, your address, your phone number, your email address, anything at all, any aspects of the data at all that can make it so that people can figure out who you are. And of course, when you've got PII data in a system, you've got data that comes off of that. So if you're a customer, then you obviously have transactional history. You've done business with that company. So there's transactions that come off of that. The business needs to be able to use those transactions in addition to your data. So some companies will want to use your data to market directly to you. Other companies might look at the order history in order to do their supply chain planning and figure out how they need to plan their business. But the PII data is the stuff that's at risk here. And what we're going to be talking about is specifically systems of record. And specifically in this webinar, we're talking about SAP because that's what I deal with. So companies that run SAP are typically going to be companies that are very large in nature. A lot of the Fortune 500, the Global 2000, these are companies that run their business on SAP. So SAP is often the system of record. That's where their customers are managed, their vendors. They'll run payroll, so employee data might be in there. So there's a tremendous amount of PII exposure in SAP systems. Of course, if you're on the webinar and you don't run SAP, you can, you know, this is analogous to any other system that you run your business on. So, you know, again, we're going to, you know, my expertise is SAP, so we'll focus on that. So, you know, what does compliance look like? You know, having appropriate security of personnel data, including protection, protections against unauthorized access, accidental loss, destruction, damage, and what constitutes a breach? You know, a breach is when, you know, people have access to that data or there's risk to that data being used outside of its intended business purpose. So it's not just about losing the data, it's about who has access to it and what they can use it for. So given the size of the EU customer base, GDPR is really expected to be a big focus. It's also not technically prescriptive. This is really interesting because when we talk to customers in Europe, we find that a lot of people say, well, what are we supposed to do? And, you know, it's not a matter of what you're, exactly what you're supposed to do, but you have to be able to interpret the requirements and prove that you're meeting the requirements of the GDPR initiatives. So for example, the right to be forgotten, there's nothing in GDPR that says you have to delete and destroy customer data and you have to produce, you know, A115 report that says blah, blah, blah, blah. So it's not that descriptive. It just says, you know, you need to be able to do this and you need to be able to demonstrate that if a customer calls you up and says, please get rid of all my data, that you have a mechanism in place to do that. And again, of course, a customer might be stored in numerous systems in your enterprise. SAP could be one of them. You could have data stored in Oracle. You could have data stored in a CRM solution, something like Salesforce might be an exposure area as well. So you have to kind of look at the bigger picture. And, you know, for us, being in this market, SAP is often the system of record. It's often the central place where this data is stored. So there are high-level requirements. So you have to evaluate how many touch points have PII data. And we're working with companies in the EU. And a lot of it's really obvious. Like I said earlier, name, address, phone numbers, email address, that stuff's really obvious. But we're seeing requirements come out of customers that are really obscure. So, for example, if you have a company car, the company car is an asset. So the asset's stored in the system. And there might be information on that asset that says this company vehicle is currently in the possession of this employee. It could be the employee number. It could be the employee name. There might be a license plate information. So, again, that's stuff that qualifies as PII data. If I can go into a company's asset data and pull information on vehicles, and I see, you know, who has a company car, what the license plate is, that's sensitive information. And that's definitely data and information that would be exposed here. So there's going to be some variance from company to company that go beyond the obvious. So track usage of company records and keep only as long as necessary. This deals with retention. Most companies have data retention policies. This talks about data life cycle management. How long does data need to live in your system? Well, for most companies it's illegal in a financial question. How long do you need to keep data in your system to be compliant with regulatory tax requirements and things like that? But now this is another factor. You know, if I have a customer in my system that I haven't done business with in six or seven years, I might have a need to keep the transactional history longer, but I might not have a need to keep their PII data. So I might be able to take a customer and scramble or obfuscate the PII data while retaining their record history so that I can be compliant in multiple areas of governance. So isolating and anonymizing or deleting records on demand is important, and this is what I talked about earlier with the right to be forgotten. If a customer calls up and says, you know, get rid of all my data, you need to be able to do it and demonstrate that you have done it. We're obviously working with a lot of companies that want to do this proactively. They're going to, the compliance organizations are going to set rules in place that say, okay, just to be safe, you know, employee data. If we have an employee that hasn't, more than five years ago, we want to get rid of their data so that we're not at risk here. So there's definitely going to be some proactive aspects of this, and of course demonstrating how you comply is key. So this is... Another thing that's really interesting here is that in the U.S. here, there's not a lot of companies that understand this. You see the bullet at the end that on the go live date of May 25th, expectation is that only about 50% of E.U. companies are going to be GDPR ready. So that's a pretty low number, and of course the level of your readiness is going to vary. Some companies are going to be 10% the way there. Some companies are going to be 60% the way there. Some companies aren't even going to know. So, but when it comes to the U.S., a lot of companies in the U.S., especially if you don't do a lot of business with Europe, you don't know what this impact is going to be. So we've got a quote up there that's kind of funny from a panel discussion. A major healthcare provider here in the U.S., a $15 billion company, the VP of IP said, what's GDPR? They hadn't heard of it before. So this is definitely something that's going to gain more attention and focus as it's enforced. And of course the high profile finds that that's what's going to get people's attention. So it all depends on how aggressive the E.U. is in enforcing it. So complying with GDPR and managing risk, it's all about managing risk, right? You want to look at your business processes. You may have to re-engineer some business processes to handle the stuff, or to make sure that they're optimized for GDPR. You want to minimize the data. You don't want to, again, the data becomes a liability, like Eric said. The longer you store the data, the more risk you have. You need to be able to identify where the PII data is because that's going to be your areas of highest risk. And of course, improve security. Improve security is something that, I mean, that's an always-ongoing thing, right? You're always protecting the data at its source in your system of record, but you also need to protect the data when it's being used for testing purposes. If you're testing an upgrade of your system and you're using production data to do that, you might have that data in a less secure environment or a system that has less scrutiny than a production system. So there's a lot of concern around security. Of course, when you move data to data lakes or Hadoop, there's different security that's involved there where you have to re-protect the data. So you have to do a lot of assessment. You have to map things out. You have to look at the business case, look at the risk areas, and get a detailed roadmap in place. And that's what we're focusing on with customers is looking at it and saying, okay, the detailed roadmap. If we're looking at S&P as a system of record, what data and what pieces of the data? So we're getting down to the table and field level even. So attunity and GDPR, this is something that's very important to us because all we deal with is data. So whether it's data replication, whether it's test data management, like our software deals with our customer's data. So it's really important that this becomes a focus for us. And with it being a focus, we have to look at what our products do already, where our products can be enhanced to help companies be more compliant with GDPR, and if there's any risk created by using our software that we raise that with our customers. So the most direct application that we make that has value for GDPR compliance is our goal client product. Again, this would be for companies that run their business on SAP. So our goal client product is traditionally used to copy data from a production to a non-production source. So we have functionality in here that anonymizes that data. So we can say if we're copying an employee record from production to development, we can change the name, the social security number, the street address, the phone number, the salary information. We can do a lot with that PII data to protect it in a non-production environment. The reason we did that was because, again, the production system is intensely protected with high levels of security. But the minute that you start propagating or proliferating that production data to non-production environments, you now have a different audience of people using that data with different levels of security. So if I copy employee data and customer data from a production system to a sandbox environment, I may have an offshore firm doing some development for me. I may have some outside consultants in the organization. These are people that have IDs and access on the sandbox system. They don't even have IDs in production. So I don't have to worry about it in production. I've got production locked down. But if I'm proliferating production data in a sandbox environment and I've got an offshore provider, I've got guys halfway around the world that don't even work for our company that now have access to that data. So it's incredibly important to protect that data and protect that PII data from unauthorized access. And this is functionality that we've provided through our Go Client product for 15 years. So many SAP customers and obviously the customers that use our software, this is an important feature in our software that they use today. So the next thing naturally to do is to figure out how that technology can be leveraged for production. And that's what we've done for GDPR. We've taken those rules and made it so that our customers now can apply those rules against the production system and create that same level of protection and data scrambling at the production level that creates GDPR compliance. So a couple of our other products, Attunity Replicate, we have the ability to secure file transfers. There's an audit trail so that you know when you're proliferating or when you're replicating data from a source to a target. And there's some filtering that you can put into place where you can filter out columns and fields that contain PII data. And then I mentioned earlier that our visibility solution, this helps companies look at their data warehouse and say, okay, we've got 10 terabytes of data in our data warehouse. What are we using? What are we not using? So visibility gives you that. It basically helps you understand the data that you're using and the data that you don't use or rarely touch. And that data that's not used or rarely touched can easily be either removed or offloaded to, you know, another system or cheaper storage. And if it's PII data, you can obviously look at it as an opportunity to be destructive with that data to ensure compliance. So, you know, I keep coming back to the right to be forgotten. Individuals can opt out. Again, customer can call up and say, get rid of my data. You know, you have to erase their, any PII data that can attribute the transactional nature of the data with an individual. Scramble and obfuscate production data with Goal Client. This is what I just talked about, that we've extended the features and capability of our existing solutions to make it so that that right to be forgotten can be enforced in your SAP system of record. And then scrambling and obfuscating the data at the system of record, if you're then replicating that data into data lakes or using it for analytics, you've got another level of protection. So, I might want to look at order history and supply chain information in my company over the last five years, but I don't want to have customer data that long. So, I might use our technology to scrambler obfuscate the data in that production system, but now if I'm replicating that data into a data lake, even if I'm replicating the data, you know, the tables and fields that have PII data, if I've already taken care of that data at its source, then there's no sensitive data to be replicated. So, for me, it keeps coming back to the system of record. Where does the data originate? Where do we control it? You know, and again, master data management comes into play here. You know, if I've got one system where all my customers are created and then those customers are disseminated to all my other systems, if I've got that one central point where those customers are controlled, as long as I'm compliant there, then I know whatever gets passed downstream to any other systems is going to be protected. It's going to extend that protection. So, a little bit again, I've talked about our Gold Client solution. It might be helpful just to kind of let you know what that does. So, what that Gold Client product does is it lets SAP companies and projects move production data into test, sandbox development environments so that they can test developments, test migrations, test where they're going with their ERP solution. So, you can easily select and protect the data. So, we can scramble that data prior to it being moved. We can rapidly migrate the data, so you can move large amounts of data. So, if you wanted to move a month's worth of sales order history from production to development, we have the ability to do that. We can synchronize data across SAP applications, and this applies to the scrambling as well. So, if we copy data at the ERP level, SAP is a number of different applications that you might be taking advantage of or using. So, you know, the data might be generated in the ERP system, but you could be using SAP's VRM, DW, SCM. There's a number of SAP applications where that data might get extended to. And again, if you're scrambling the data at the central point, then as it gets proliferated and copied out to all those extended SAP applications, you extend that protection. And our, you know, us being in the SAP space, we work very closely with SAP, and our products are certified with SAP. So, we have integrated certification, not only at the SAP application level, but also on their HANA and S4 HANA technologies. And for people that aren't aware, HANA is the database platform that SAP is built to run their applications on. In the past, traditionally, you'd run SAP applications and run your business on a platform that could run on Oracle or SQL or DB2, any kind of database platform. And the future of SAP is ensuring that the applications run on their HANA database, which is an in-memory database, very high performance, columnar store, a lot of technical advantages to that technology. So, again, WearGo client helps reduce your risk. It ensures the customer records that are copied to non-production systems that are optimized. We can precisely delete or, you know, delete data. So, something like a phone number or an email address, that's not a key field. So, unless you need it, you can just safely blank it out. You don't have to change it to something indistinguishable. You can just blank it out. And then, of course, you know, the right to be forgotten extends that scrambling functionality to the production systems. And like I said, we're working with customers in the EU to identify the PII data that they see at risk in their SAP data model in their landscape. And, again, I would say 80% of that is consistent, but about 20% of it's variable from company to company. So, you know, a little bit technical here. Again, on Go client, when we copy data from production to non-production, our goal is to help companies move small amounts of reliable, recent production data into these non-production environments. If you run your business on SAP, you may know that the only way or the typical way to do this in an SAP environment would be to copy the production system. So, there's a lot of SAP companies out there that are copying the entire production system off to a sandbox or a QA or a training environment. And every time that happens, you're moving not only the data that you want, but you're moving all of the data. Everything that you have in your SAP system is getting copied to a less secure and unless you're doing some scrambling using our software or some other method, that data is as is in that non-production environment. So, there's a tremendous exposure there. So, we not only help companies reduce that exposure by scrambling the sensitive data, but by moving a subset of the data, that ensures that you're only moving current data from production as opposed to the whole thing. So, you don't have some offshore guy halfway around the world running a balance sheet off your sandbox system and then manipulating your stock with it. So, again, when we set up these scrambling rules, you know, we do this through our software. It's a customizable user interface. You basically select the type of data that you want to scramble and what you want to do to it. The rules are mandatory. So, there's security within our software that says, you know, if an HR manager sets that scrambling rule, he can make it the default rule. So, anytime you're moving HR data throughout your landscape, there's no way to turn it off. It's always on. It's flexible, it's configurable, and it cannot be reverse engineered. So, when we scramble the data, the data runs through the scrambling mechanism and then when we apply the data to the target, whether it be non-production or production, it cannot be removed. It cannot be reversed. And with SAP, that means that we're also having to clean up the change log history. You can imagine that if you're changing data on a customer record, there's a change log that's created that says, oh, it was this and now it's this. So, if I change your email address from your real email address to nothing, there's a change record that says, well, it used to be this. So, the change record needs protection, too. So, we need to make sure that we do proper cleanup to make sure that nobody can reverse engineer the process. It's, you know, there's no, you know, sound encryption magic where you push a button and everything turns back into what it was. Once you apply the rule, it's applied. It makes the change and that's a permanent change. So, back to, you summarize the details on what we do. You know, the data records and fields are anonymized during the export process or at the source. So, data never leaves the production system unless it's secured, whether we're scrambling the data directly in production or we're using that data downstream, whether it be a non-production system or through data replication. The data is controlled at the source. The rules are mandatory, cannot be reverse engineered, and any scrambling that we do applies to all SAP applications. The compliance can be easily demonstrated because when these jobs are run, we have logs that point it out. The logs will note when a job is run, what was done, it won't have the detail. So, if I've just scrambled and deleted the email address of all my customers, we'd have a report that would list the customer numbers and the activity that happened, but it wouldn't actually store any of the data. So, it would tell you that the scrambling's been done and that the email addresses were removed, but there's no log saying what the email addresses were. So, that way you can demonstrate compliance pretty easily. You know, I mentioned, you know, SAP is a big market and a lot of large companies run SAP. So, many of our customers are some of the largest customers, largest companies in the world. You know, British American tobacco is one that sticks out on the screen, but you know, this is something that's right at the core of a lot of large enterprises, and large enterprises typically run large EIP platforms like SAP. So, you can imagine the customer base that we've built up on this solution. Another aspect of our technology on the far right there talks about divestitures. This is interesting and unique in that when you, you know, as companies operate, they're acquiring and divesting businesses. So, a unique capability of our technology is the ability to carve out an individual company so that you can maintain compliance there as well. So, if a company, if your company divests or spins off a division, we can actually carve and spend, carve off that data from the SAP system, create a new SAP system so that divested business can operate and move off in their own direction and maintain their own compliancy. So, you know, we definitely limit the risk if there is a breach. So, if you're protecting the PII data at its source, then if there is a breach, the exposure is less for sure. With replication technology, we recommend that customers use column and row filtering to take, you know, to make sure that if they're using business data, that they're eliminating the PII data. Companies run their businesses on data. So, understanding what they're trying to do with their data and where they're creating a competitive advantage sometimes just deals with the operations of the business. How many orders do we process, you know, month to month? Is our business seasonal? What does our supply chain look like? You know, what are our shipping routes? You know, things that affect the data that don't affect PII or that don't impact PII. So, we're encouraging companies that when they're doing analytics and they're building data warehouses and they're loading data lakes, that they're carefully looking at it and choosing the data that they want in those environments based on the business need. So, you know, typically you might look at it and say, well, let's just take everything and move it into the data lake. Well, that could create risk. So, a lot of times we're looking at companies saying, okay, what's the business problem you're trying to solve? What are you trying to do in the analytics and how are you trying to use that to impact your business and create a competitive advantage? A lot of times it just deals with the logistics of the business and not the PII data. So, in those situations, we're encouraging companies to do filtering and make sure that they're not proliferating PII data where they don't have to. So, a lot of people ask us, are we GDPR compliant? You know, there is no GDPR compliant certification process. So, it's not a prescriptive technology. Companies have to interpret the requirements and apply them accordingly. So, where attunity comes in is, we want to be a positive aspect of every company's enterprise. So, every large company, small, medium and large company that has data, we want to be seen as helpful in your GDPR journey. Some of it might be really obvious, like with the right to be forgotten, but as you proliferate data and use data in your organization, we want to be able to help companies look at that, understand their interpretations of GDPR and figure out where we can help. No, that's a good point. Yeah, we wanted to leave a few minutes here for Q&A and we had a bunch of really good commentary going in the chat window. I always love seeing how engaged people are over there and there were a number of questions around how to solve the broader issue of data governance. And of course, GDPR is a good reason to... it's a good catalyst, I suppose, to focus more broadly on data governance practices. I've spent a lot of times working with large organizations and maybe, Matt, I'm just going to get your commentary on this. But a lot of times, you really do need a crisis or some kind of catalytic event to kick people into gear and to get things rolling, because otherwise, you just kind of have the status quo. So, I throw two things out, two questions out to you. One, have you seen that GDPR is serving as a good catalyst to get people talking about data governance programs? And then the other question I ask you is about having some adversarial role within the program, meaning have someone whose job it is to act like the regulator and to poke around. I mentioned, I think, during the webcast here, the concept of the Chaos Monkey. It's very interesting, if you look on Wikipedia, you can look up Chaos Monkey or just Google it. But basically, it's a program at Netflix where they actually will use this Chaos Monkey to shut down production systems and see how well they respond. So, there would be a similar idea here with a person whose job it is to just poke around and find trouble. Pretend to be the regulator, poke holes, call people out in meetings and so forth, and use that as your mechanism to, frankly, prepare for if and when that regulator comes along. So, first of all, have you seen these regulations and that's actually just we're going to get some new ones coming down the pike real soon, not just around social media, but a guarantee around data use and privacy here in the U.S., most likely inspired by GDPR. So, do you think that's a good catalyst? And the second part is, what do you think about the idea of having a pseudo-regulator on your team? Yeah, I think they're both great ideas. You know, what's happening with GDPR is a convergence of news with a law. So, you know, if there was no news on this, if this was not a problem and this law was coming down, it would definitely be having less impact. But the fact that there is, every week, some new report, you know, like I don't know, Eric, I use LifeLock and, you know, that protects my credit and protects my identity. And every time there's one of these breaches, I get a notification. And it's interesting because, you know, sometimes it impacts me if I'm a customer of that company or not, other times it doesn't. But what boggles my mind is how often this is happening, how often people have data breaches. And, you know, GDPR is coming along right at the right time. And, again, with what's going on in Washington right now with Facebook, people are going to be looking for a model. And they're not going to want to reinvent the wheel. And if this works for the EU, I can see this becoming a standard. So I see a lot of what's happening in the news being a catalyst for ensuring compliance and possibly broader adoption of this. I've never... Go ahead. I was going to say, one of the other threads going on in the chat window here deals with artificial intelligence and AI just in the background crawling around looking for different systems, different data sets to align. I think that's really going to be the future for data governance is to have some kind of machine learning in the background constantly looking for holes, poking for holes. And, of course, you have to train these algorithms so when they find holes, when they find problems, there's a pattern that they're going to see underneath the covers here, one aspect of which is probably going to be related to personnel. We notice that we keep finding this particular person is involved in projects that have difficulties or have holes. That has to be one way to do it because trying to manually work through all this stuff, that's almost impossible, especially at these larger organizations. So I see AI as being really rather important in the near future for being able to deal with data governance. What do you think? Yeah, I agree 100%. AI is being used in that scope right now. A lot of our banks or a lot of our customers are banks and banks have fraud detection programs. A lot of people on this call and me included, we've had the situation where we buy something on a website that we normally don't or we're traveling and we make a purchase in a manner that goes outside of our purchasing habits and your credit card gets shut down and it's amazing how fast those fraud detection algorithms kick into gear and what drives that is data. Again, that's why Atunity has a number of large banks as customers because companies need to process that data on the fly and that's where AI comes in. AI means we have data streaming right now from multiple sources and we need to be able to analyze and act on that data right now. That's where our replication technology comes in because you've got to keep that data moving. If you've got your AI algorithm set up, whether it be fraud detection or security risk and compliance here with GDPR, AI definitely is going to play a larger role long-term. Yeah, the other big component here is just culture and the people involved. Data stewards are going to be really important. You want all the right people in your data governance program to be at the table and to have some stake that obviously requires a significant amount of effort but it seems to me that the cultural aspect is really important and culture is very hard to change. How do you change culture? It's not an easy thing to do and I think that the other topic we didn't really dive into is that of the CDO, like who should be responsible for all of this. It seems to me the data governance program really should roll up to the Chief Data Officer but what do you think? I agree. We're seeing a new role out there called a DPO, a Data Protection Officer. When we talk to an EU company about their GDPR requirements, one of the first things I ask them is, what does the team look like? What does your compliance team look like? What aspects of the business make that team up? What aspects from IT, et cetera? There's a lot of common threads and one of the things that's a common thread is the DPO. There's a Data Protection Officer. There's even companies that have a DPO for every region. How data is used in Finland and how GDPR is enforced in Finland might be different than how it's done in Germany. These are growing roles. I would throw out again this concept of having a pseudo-regulator within your organization who pokes around and looks for problems and documents those problems and that can be used as spotter by the head of the Data Governance Program to make changes where necessary. We need to realize that not everyone is cut out for a role in data governance. Not everyone is cut out for a role in analytics. It just depends. But you need to document who you are tracking, what you're doing, what kind of efforts you're making. The key, if a regulator shows up, is to have that documentation. Folks, we are burning through the end of the hour here, so I'm going to hand it back to Shannon Kemp to wrap us up. Thank you so much for all of your time and attention and thanks to our friends from Atunity for bringing us their perspective. Shannon? Thank you, Eric, and thank you, Matt, for these great presentations. And just a reminder, I will be sending a follow-up email by end of day Friday for this webinar with links to the slides, links to the recording of this session. And thanks to our attendees for the great questions. Just love that. And I hope everyone has, and thanks again to Atunity for sponsoring this Seed Dive Radio Program. So I hope everyone has a great day. Enjoy. Bye-bye.