This is Kim Barkus with the HR open standards consortium. Thank you for joining our podcast on the HR canonical data model. Benefits of using open standards. Our speaker today is Randy as an enterprise data analyst and architect for J M family enterprises. He's a certified data professional and a certified business intelligence professional experienced in designing and implementing data. Ray will share how he used the HR XML standards as a data model for the JM family enterprise program management office. Welcome Ray.
Speaker 2:Hi, great to speak with you Kim. How are you doing?
Speaker 1:I'm doing well. Thanks. I hope you're doing well too. So really I had some questions for you and so I thought we just kinda jump right in. Um, I think the audience would be interested in hearing a little bit about your experience, um, in general and HR with, with HR open standards and any integrations that you might've been completed.
Speaker 2:Sure. So we had a project called HR remediation and our view was to upgrade. What many other organizations have point to point communications between multiple systems and is most of everyone hearing this knows the HR human resources, the persons tend to be integrated with almost every downline system. And so we wanted to modernize our infrastructure for data transformation and that included using, if we could find a canonical model for HR and that we could use an API gateway, an API method instead of some, uh, data files and other types of integrations, uh, that people do. And so since we started down this path, um, I did some investigation and found the HR open standards and it was really refreshing to see that a global community had gotten together and said, Hey, we have names for these data elements and we have definitions. And then even amazingly, um, data values for some of the fields like marital status. So it was really good to begin to analyze it and say, would this be a positive thing for our project? And the conclusion was instead of creating our own data model from scratch for our company by using this, uh, open standards, HR open standards from the global community just made so much sense to us. Uh, that I started implementing it and we started by using it to map existing integrations to our core HR system. And then it ended up flowing into becoming a business glossary. And I think this is a really key thing that some people may not be realizing, which is why I'm on this call, is you can use the HR open standards, canonical data model. We decided to go with XML first because it's more verbose and it has a hierarchy to it. But we used it to be able to say, now we have a term that everyone agrees to and this is the definition. And then allowed our business team to decide if they wanted to change the finishing a little bit. But it began, it began a common language, which is what a cap canonical data model is. It is a common language across the enterprise for HR, which happens to be our most important asset.
Speaker 1:Great. Great. We can, we've had that. A lot of people have mentioned that terminology and that's one of the, I would agree with you obviously. Um, one of the benefits of this, uh, standards in this model is that coming up with something that's common that we all can share this terminology because even in a context, um, for example, if you have, uh, a what, an open date or something, what does that mean? Or um, any of the properties that we have, making sure that we all agree with what those mean and how they relate to each other. So I think that really, um, has been beneficial to our members and to our implementers. Is there anything, Oh, go ahead. I'm sorry.
Speaker 2:Yeah. What we found was that it's beneficial in these other ways and these are all opportunities that our members can really embraces that we're all in meetings discussing about the HR domain. We spent a lot of time re discussing what these terms mean. Especially when you get to any technical metadata in a system. This application has these terms. We're always talking back and forth about terms and trying to understand each other. Also, we found that it saves a lot of money. Uh, when you're talking about integrating with systems and everyone's on the same page, what we're going to send. So our view was to use the canonical data model to come out of an API gateway. And I'll talk more about that, that when someone made a request for their system, their application to use HR data, it would always have the same column or data element names. And it would mean the same because the public glossary is out there. And then every application that can consume it directly would, and if not, they would write a little translation program that would write that integration to what that system may be even a legacy system could understand. But now we have this one common bit of knowledge of data. And when you request data, you receive a very standardized message and an XML or a Jason is a message that contains data from your system in this very formatted, uh, organized way. And now we could publish and say, this is what it means. So even humans can look at both of those messages and make sense of what it means without the old days of looking at all these column headings from all these different systems and trying to map them and understand them. So from a standpoint of of project integration, application integration, it saves a lot of money. Now the other thing we learned in this is that having an API gateway, which is also a method of all the systems today are starting to go getting away from sending flat files and Excel files and CSV files and trying to read them and integrate them cause they're not secure. But an API is a black box in a gateway where you request through a web service and it returns back is beta. So even security by using your model within that, that technical environment of an API, you can shield a lot of the information, which as we all know, HR is a very, should be a very guarded PII type data set. So we found that even from that perspective it was very valuable. So what started as just finding, you know, um, an industry model ended up providing a lot of benefits all through the project and we're now implemented in production and we're finding a lot of benefits in doing that.
Speaker 1:That's great. Yeah. Um, we're going to talk about it too much, but we do have, and I don't think you've implemented the new Jason, um, uh, standards yet, but in that Jason standards, we do have data privacy, um, a section it talks about who has access and what type of access and how long we can access that data. So that's something that, um, we've definitely made sure that we can handle. Um, what about anything else with like data governance and data security? Has standards open standards help with that?
Speaker 2:Yeah, so what it did was it started this idea that I could use the standard to create this um, glossary and then we could tie the message. So the business glossary has the term like person ID. It has the definition of what person ID is and then I could actually connect it to what the message and either Jason or XML, that little piece of the data element looks like. And then we could link it as part of governance to the applications that use it and say, well, this maps to another application, let's say core HR can say it's MPD. So part of that governance became a way of disseminating information, linking the systems. And then for data security, uh, we created, uh, data classifications off of this through governance, which is a framework and a process we created, um, to the glossary, a matrix that said certain data elements, like for example, person legal ideas, social security for us is one of the most highly guarded restricted data elements in HR. Well now, besides everyone knowing about it, we, we've put these data classifications saying this is restricted. No one can get it without high level approvals. It is highly sensitive. And so you can disseminate information of data security so that people building systems, people modifying systems and people requesting data can all be on the same page of what the governance provides and links to security and say, we need to guard this. We need to have a very specific way of dealing with that data. And, uh, before it was hard to do those things, to link all these things together, but using the standard to create the glossary, to govern it and then branch out to things like security was in my mind, uh, of win-win.
Speaker 1:Oh, that's great. That's great. Yeah, it's definitely been something that, you know, is on the top of everyone's minds right now. So, um, I mean you say it's win-win. Was there something from a business perspective that you saw that benefiting your organization?
Speaker 2:Yes. Specifically that people and applications are not getting data that they may in the past that now is considered because of regulatory. So as we know, there's a lot of regulatory, um, uh, laws out right now, like CCPA, GDPR, many compliance standards that are out there. And now this gives us a way to say, Hey, some of these data elements are governed by these compliance and now we can track track them. There's also the way of knowing who's, you know, we can get into data sharing agreements and when someone asks for data, we can ask and say, Oh, this is restricted and highly sensitive. So we're not just going to give that to someone unless they can give an amazing business case and it gets, uh, an approval from the right level of data owner to say they can get this. And so it's a level of, of security, of control in a positive way and reduces risk of not meeting compliance and reduces the risk of having not having the most strong security and having someone get something that they shouldn't have. So it, it, that is a huge benefit. People don't realize today that a data breach is all about, uh, the dark web trying to get this kind of data, especially HR data and using it to sell it and to, uh, be able to make money off of it. And by putting the standard with these data governance and data security and aligning it, you're actually protecting your organization. Uh, both reputation and financially.
Speaker 1:That's, that's really good and very important. Thanks. Um, so as you were doing some of these changes and doing the canonical model, did you receive, did you get any resistance from your, um, internally, from whether management or the users of the system
Speaker 2:you use it? Most of the stuff we did was back end, which is data integration. First level there will be much, much more going forward. So not so much a day to day people using an application and seeing it, but we did as, as anything else that has to do with change, you know, as a change management issue. So looking at the world differently, realizing that now we need to be more diligent, uh, being more, uh, diligent and following a process, uh, making updates and communicating updates that someone wants to get data that they were before, maybe got more freely and they would have in the past, uh, being able. But the benefits also were so amazing that someone could go to a portal and see, Hey, this is what person ID means. This is what marital status and these are the values of marital status. So there was some challenge and most of the challenges is most projects are dealing with the changes of people, but we were able pretty quickly to show value and I, and that's my encouragement. Anybody listening is show value soon. You know, do it in an agile process where along the way you're reporting value, they're seeing benefits and then, um, that will allow you to be proactive of getting folks to say, yeah, I get it. This is, this is fantastic.
Speaker 1:That's great. So just in general, what was your big, do you have a biggest challenge that, um, that you had with the integration that you haven't discussed yet?
Speaker 2:Uh, I would say the first one was even trying to sell the HR open standards as a, as a reference to do what we needed to do. Uh, most companies that do canonical data models, they come up with their own. And so it was new to believe, um, I needed to, to sell the idea to say, look, we have a lot of knowledge in our organization and we have a lot of capabilities. But when you go out to a global community, you're bringing in the best practices and knowledge base of hundreds and potentially thousands of organizations that have agreed to decide that this is what these elements mean. This is what they should be called. And these are some of the values that should represent those data elements. And so, um, it took a little bit a while to warm that this is what we should do. And then once I got past that, people were all for it. And then not everyone had understanding because you have to be more of a data architect from the implementation. So we always looked at this, this is a business, um, HR open standard and the canonical data model should be a business project. Just us people that are both business and technical have to help you with physical implementation of integrating systems and things. So once business people get it, that this is a ubiquitous language that can be shared. Uh, and even with outside vendors that, uh, in the future as more vendors upgrade their systems that you could potentially plug and play and get an HR related systems in a data domain of HR that already has all these data elements and already have API. It just makes integration so much cheaper, so much quicker, so much better. And so it's, it's a very, very positive, positive, uh, usage. And it was, uh, getting to that point of overcoming, uh, something that's new.
Speaker 1:Okay. It's actually interesting when it come in on both of those, those, uh, items you've brought up. I was on a call earlier today and one of the people mentioned that experience that um, that, that shared experience that everyone's had, that we have hundreds of years worth of experience of people that have, are contributing to the standards. So rather than having you know yourself that you're trying to deal with this or you just a team of two or three or five or 10 these, this is a group, it's an international group that has been working on these standards. So that's really great. Um, base of knowledge. The other thing you mentioned was those, those skills. So you talked about the business side that, you know, yes you need to have the business people and then they also have to have the developers. It really takes all of those different skills, whether it's a practitioner, whether it's the, the business person on analyst, a programmer. It takes all of that group to be able to the standards and to be able to implement them because you guys have the experience, you know what it is and you know what you're needing and looking for. So it's really been a great opportunity for everyone to work together. So I do have, um, uh, one last question. Do you have any other recommendations in the last recommendations for an implement or considering an integration?
Speaker 2:I would just say consider, um, organizational change management as a component. And do it as I did, as part of a kind of a narrow project if you can do it. So let's say you may want to consider integrating one system to another and just doing one to take the time as part of change management to explain the standard why we're doing it, what are the benefits, how we can cut costs of, uh, so much time in meetings, trying to decipher things. Uh, having standardized glossary, being able to connect to things like security and governance and, and, uh, more, uh, sharing more information about this, uh, treasure trove of information. So I think by doing that upfront and doing it in a limited project, it opens up the organization. They can absorb it, change, get the understanding, and then commit to it. And that's one of the things I think you have to commit, uh, to use the standard and realize that applications in the future as they get modernized, we'll be using the standard and that the benefits are so high. Um, it would be no reason not to commit to it.
Speaker 1:Great. Yeah. And that actually ties into what you said earlier. You know, having one integration, being able to show the benefits of it early, you're going to get that buy in for future projects for the next step. So that's,
Speaker 2:I found that we have dozens of systems that need information about our people, which is HR. So once you start standardizing that and having a method, a decoupled method of point to point, but let's say using API APIs, which is very secure, it's a black box, it's very controlled. You can't get data out without it being very implicit and authenticated. By doing that, you're really reducing your risk and you're also getting consistency that all these systems that do require to know something about your people is done in a very disciplined manner is a win-win. Great.
Speaker 1:That that is a really, really great, uh, information for our, for our audience. Do you have anything else you'd like to share, any last comments?
Speaker 2:Uh, just that I'm excited about it. I thought I was just learning a little bit about canonical data model and going through some data integrations and it became a much, much bigger thing. And we're actually going to do a presentation, um, here at our company about it and what we've done and the ideas to start using this, uh, across the enterprise even more, not just HR, but other canonical models and under industries. And this has become, uh, uh, a great teaching tool and also just, um, a great way to improve our organization.
Speaker 1:That is wonderful to hear. I'm glad her up and was helped, was helpful and being one of the initiation initiators in your, in your direction. So, Ray, I want to thank you so much for your time today, sharing your story about James family use of the standards. We hope our audience enjoyed their time with us today. And there are more resources available on your website and you can follow us on social media at HR open standards.