CTIO 101 Podcast

How to Improve your Data Quality in 90 days

May 26, 2022 Jon Grainger Season 1 Episode 3
CTIO 101 Podcast
How to Improve your Data Quality in 90 days
Show Notes Transcript Chapter Markers
Fairmont Recruitment
The public and commercial sectors are now offering technology services of equal parity with the comm

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Bret Robinson:

One always great question. I always go to the finance team on day one. When I rock up as a test manager. I say, okay. First tell me, do you spend about one to two weeks processing the previous. month end? God Yes, we do. You're like an Oracle

Malcom:

Welcome to CTIO 1 O 1 Episode 3,. Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe

Jon:

I was born in Dallas, Texas and you can tell from my accent that I came over when I was seven a and a and a really strong, broad Texan accent in the late seventies, wasn't particularly popular in the UK. My parents tell me that within two weeks, I sounded like a Dick van Dyke in Mary Poppins, the, the, sort of the American version of the Cockney accent to try and survive.

Bret Robinson:

Was born in Ohio, so raised a country, boy and grew up in, Kentucky my dad was a electrician in the coal mines, and then we upped sticks one day and went to live in Florida and he built schools down in the Fort Myers Cape coral area. So I started learning. how to fish in the ocean and wind surf and dive off bridges into alligator infested waters.

Jon:

because there was a lot of that going on when we were allowed,

Bret Robinson:

I

Jon:

no S no seatbelts

Bret Robinson:

no seatbelts note

Jon:

in the car was the least of your worries. It was just some miracle. We

Bret Robinson:

as a kid, he used to lean out the window like a dog practically, and hoping you then hit a tree or a push, but

Jon:

w we were talking on the last podcast that did about the chemistry sets, used to get that, that had really dangerous chemicals in them How would you describe yourself if you had to do the the American elevator speech, what would you describe yourself as?

Bret Robinson:

I've been 25 plus years in the testing business. I'm an advocate, a data quality, and that can be in the program. manager space or indeed the actual doing and getting data sorted out so looking at data.

Jon:

You're quite passionate about data.

Bret Robinson:

Yes, very passionate about Data.

Jon:

Where does that passion come from?

Bret Robinson:

You might only do this once in your lifetime. You might only do one migration product project while you're at that company you might change from a massive legacy to a brand new shiny tool And that might be it you're then retire So you only do maybe one or two of these in your career, unless you're a contractor and you do this punishment and you love punishment, like you and I, John. And you do this all the time. Everyone says to me we got loads of production data and the test system. Two things one that's very wrong And two that data's is probably, two, three years old. It's always a thing where the data wasn't brought over properly to the test environment so it's always a case of having to try and find things to make it work.

Jon:

I was doing some research for this Bret and obviously had a little bit of extra time and, being a CIO CTO myself, I've obviously dealt with data. It's part of the bread and butter. In fact, there's a podcast episode, I'm publishing tonight, which refer to people, process technology. And in it, I was actually saying if we were to modify it, if we could add anything to it, what would it be? And I suggested you'd add data. To the people process technology and data. It's such a massive topic, and there's so many different facets to it. One of the things we thought would be a good structure would be the, the challenge. And the challenge is how do you improve your data in 90 days? You might get into the, how long is a piece of string conversation, but, typically in your experience, is there a realistic 90 day approach that you can reuse?

Bret Robinson:

I believe there is because the difference between Master data and Transactional data. So your Transactional data is made up The master data and your master data, as long as you know where that's coming from. And what systems are. yeah, you could look at that Master Data and just make sure it was the right quality level definitely.

Jon:

Just remembering that we're 1 0 1, we've got a lot of people that are listening to the channel who don't have the same level of experience. We do have some folks at the same level of experience who are interested in maybe areas that's not right in their sort of professional expertise, but a lot of folks are looking at this as trying to understand business technology. So there's a really obvious point, which is, what is data attempt to definition Brett? What is data?

Bret Robinson:

Data comes from, numerous sources. You've got Metadata, which is the, the tagging and things like that you keep track of and then there's the Master Data which is your core set up data. Your Suppliers, your Customers, your Products, the things that change but not all the time. And then of course, you've got your third party data that kind of comes into, you via API APIs and things like that. And indeed data that you actually send out. There's many facets of data.

Jon:

And that master data that you described, if I sort of wind back the clock for me, that's like your main. Entities, I'm talking about the old school entity relationship diagram and doing your sort of the one to many's and all that many too many all that stuff. In business technology we are, we express the business in tech and the way we do that, we do all sorts of operations and everything, but we're always doing something with Data. This might seem so obvious to you in terms of. Expertise. Why should I even care about my Data?

Bret Robinson:

There's a number of reasons. One is because we're so more geared now to making sure our data's protected and making sure that the Industry is putting the right level of protection. I just saw something on LinkedIn just earlier, before I come on here about Coca-Cola potentially having a Data breach and you think I don't buy from Coca-Cola where you can have do. And they collect marketing information about you and is that data now compromised. So there's all these different things, about Data that we have to be as a GDPR compliant. or are they, do They have security. From a business point of view you need to make sure that you're reporting the right Data to then better steer your company ship. If you're getting the wrong information, the wrong data, Oh we got so many customers bought this why do we got loads stacked in the warehouse? Did we order more? No, that's the same lot oh, okay. Thought we sold these Well, so the data kind of has to, match, to be able to give your company the right feedback

Jon:

It is blindingly obvious isn't it? When you boil it that down to those principles, but I just think people can get lost do you think you see organizations that describe themselves as data-driven or certainly you get at a certain level in any organization everyone's driven off of, the MI reports, the management information reports, but nobody it's a bit like when people see something printed, if they see printed text, they have a tendency to say that must be true. And if you see it, if you see a report in front of you with columns and bar charts and all the rest of it. This is obviously true but all of that is just coming off of the back of the data. Isn't it?

Bret Robinson:

Exactly that and people sometimes don't realize what it took for to actually make that. And I think that's where these things like BI and, Snowflake and all these other applications come into it where they're trying to get you the best view. But then if you don't have the right core foundation Data to begin with, how can you get that view to correct.

Jon:

Let's say we've got someone listening. They've got something in front of them. I'm just trying to think of the sort of scenarios where you might get really interested in a kind of a 90 day approach, maybe a data migration what can I do in the next 90 days?

Bret Robinson:

They need to find out what's in their data and how it's getting changed by what systems. I think that's very key and starting from there you can then work out, okay, I'm going to do a migration. Okay. You need to just get a data health check. Let's just look it over. Let's find out what's in it Let's offer you some suggestions Let's let people look at it. I think what people tend to do is they really go, oh, I'm going to use Excel. and Okay. I'm only going to use 1.2 million lines, but you've got 6 million somebody asked me the other day, we got 1.2 billion rows We're look at that I said, yeah it doesn't matter. I don't care how long it is. or why it is it's the you need to know what's in it and How it works.

Jon:

So scenario could be, you start a new project. You've come in as maybe a new Head of IT. CIO CTO. And you've got to make that assessment in terms of, I think sometimes I don't know what your experience is Bret but when you go into a new position, you don't often have a full, detailed handover from your predecessor. So there's a bit of work that you need to do. And if you don't do that, if you make some assumptions, you can really set yourself off on a very poor foundation. Can't you? So actually the 90 day scenario could fit quite a few different use cases. Okay. So we've rocked up. It's maybe let's say it's day two, we've had day one, sorting out our laptops and we've got security access and all the rest of it. How do you start with kind of your 90 days, where do you get started with?

Bret Robinson:

I suppose the first thing is understanding what sort of Data Schema they have. So they're using Oracle Hadoop Mongo, what sort of database structures, do they have? And what I like to first know is understand the Data Structure and understand where that data's coming from. is. that coming from the cloud Is it on-premise do you have legacy systems. that feed in how does all your how is your basically your operation work. Oh yeah. We buy some stuff over here We stick it in a warehouse over there and all these people distribute it and then these people buy it from the shop. Okay, cool. So that kind of gives me a little bit of an indication of your architecture what that's gonna look like, And then I need to understand excuse me how that day put together. So what does your data scheme and look like? If you do know, a lot of people don't what Data Schema look like?,

Jon:

And how do you tackle that sort of slightly awkward conversation, Bret? Because if you met me and I was on day one, I would just say to you, we don't know, but if you met me and it was, year two, three plus I might be inclined to say actually that's a very good question, Brett and of course I know what my schema is, but I still don't know. The data architecture it's wrapped up in all the legacy and it's often overlooked, isn't it?

Bret Robinson:

Yeah. And the people you need to go to as you Architects so if you have Solution Architect and people like that, and potentially your DevOps they'll know your architecture they'll know what servers connect to what, and that's what you look for. You look for an architecture diagram. as a starting point then to find, Okay. That's an outbound It's going through the middleware. That's going to FIFO or Trustpilot, or that's coming from there. Or, it's all these different avenues that you need to just make sure. you understand. Okay that's the first that's the first thing up. You need to know where your Data is loaded.

Jon:

Are there any tricks or tools that are available to discover that if the folks, if the DevOps folks tell you we understand this element, but this element over here is a bit of a mystery. I'm just trying to work out if you don't have that local knowledge. Or if you're in a situation where there really isn't a lot of understanding, the systems are being used by the business, but there isn't really that understanding is there a way of getting around, understanding that if you don't have that Solution Architect that you need?

Bret Robinson:

Okay, where is your database point me to where that is where we think it's there So from there for for instance, if it's a SQL server there'll be stored procedures that might bring data in and things like that, there might be some sort of middleware that does. some processing. So I would go to the middleware people in do you do any database calls or pulls or pushes? And I've been looking at that to say, yeah, we pushed data all the time from Trustpilot because people are reviewing this client's products and we push okay. From Trustpilot into our database. Cool. Okay. So you could start working out I've been in it long enough. And I suppose I've been dealing mostly with large ERP and, they're bounded together by sticky tape, and plasters, and then they do various different things through a API, middleware, gateways and things. So it's yeah, it's just, all right. Put me into the database I'll start there and let's go.

Jon:

Okay. Where does the breadcrumb trail lead us to next

Bret Robinson:

Once we'd done that we need to start setting out a plan of what tables we're going to look at. So what I generally ask the folks is what sort of problems you have in that you think that you have? and it's quite encouraging because a lot of the times they'll say, oh yeah, we got salespeople turning up And the person's no longer there, Okay cool So you've got issues with customer addresses Yeah. Fine. and then we've got suppliers that our salespeople buy from, but they don't they shouldn't buy from that one because they're more expensive and we generally only buy from the cheaper one. Okay Yeah. of course So you got issues with selecting the right supplier. Okay. And then, other things like yeah we seem to have disappearing notes as a people will put notes different supplier or customer accounts and they seem to disappear potentially duplication. Okay. And then things like fixed assets or got fixed assets that I they just seem to be like five of them all with the similar sort of name, but which one are they depreciating Which one Aren't they, depending on which person is doing, it, maybe, oh, I always use this one. Oh I always use this one. It's things like that that you need to then start finding out. Okay. Are you having mailers, your marketing team saying, oh gosh, you don't have very good. open rate on your emails. Why is that? Let's look at the email list. So start looking into the problems and finding out what they may know that they might not think as Data related things One, one always great question. I always go to the finance team on day one. When I rock up as a test manager. I say, okay. First tell me, do you spend about one to two weeks processing the previous. month? end God Yes, we do. You're like an Oracle, No, I just tested it happen. Why are you doing that? What are you doing? Oh, we're changing these things. Okay you're changing the transactional data to make it fit because your master data is all wrong,

Jon:

And like you say, it's happening every month because you have, it's literally, you haven't dealt with the root cause. So on, on the data quality side and another thing to throw in terms of those problem areas, one of the things I've experienced quite a lot is where a project or a big program has tried to capture data in a workflow sense, could be a contact center, could be, in some sort of intake funnel and the system that's asking questions, which might be with someone on the phone trying to take information from the customer or the client. It's never perfect. And so ultimately you get to stages where there's something that the system says you must enter, X, Y, Z, and it's just not possible for the agent to get that information. So they don't put in whatever the, that information is. They literally put an X, Y, Z, so that they can get, they've just fell to get through to the next stage. And so what you've got there is you've got data going in. That's never, ever going to be accurate because it's, maybe the system is being too prescriptive. And I know we're not talking specifically about that, but I wanted to know whether you see that in your testing, where you've got people who actually start to use the system, they get to a particular point and they just can't get that information from, the other party. So they insert something, they force through the mandatory fields.

Bret Robinson:

So being at being a test manager, you're dealing with developers If you shifting testing, left and you got your developers. The developer doesn't understand your business processes. So it really doesn't know how the data works. And Generally. My day too is, I'll go to the team and I'll say where'd you get these products from? Oh, I set them up how many fields did you set up? Oh, I only had to do five. There is required. Okay, what about the rest of the stuff where it's not important to me. because I'm testing it in this sort of, yeah. And then And this is the common problem. People doesn't don't understand that this data stacks and builds to form the end result, which is your finance documents. And things like, is it on a pallet? Does there is a row? Is it a box Are they sold Each Or are they sold in bulk? Things like that? Very simple calculation. If you say, oh yeah, pallets 10 quid. When actual fact Each was 10 quid. the pallet is, 5,000 quid. So that's

Jon:

you can make some really big mistakes, but it's interesting. You're talking about how everyone's view of the data builds later on for ultimately, I suppose you call it the finance, reconciliation is meant to be the ultimate piece and they don't have that understanding or mindset to, to look at it wider than what they've been given. So maybe I'm guessing that part of what you're doing is creating that sort of slightly wider view amongst everyone that's working on the project so that people aren't too stovepiped, the classic my, my bit worked, that, that phrase, which I've heard quite a few times. Yeah,

Bret Robinson:

My bet works I don't care about, it was over there, I get, this can be actually within the dev team. So one developers testing, the particular unit of logging in and then there's another developer who's now taking that log in and sticking a profile to it and saying oh, this person has. access to these things even in that very simplistic thing, one developers hand it over to another developer, and you might call that an integration test or system test. And testing the login system as a whole, but then when it gets to it and they get out into the production system, they try to log in and say I don't have access or, oh my goodness, I've got too much access you have to have that. view like your CRM people, you might just think that, oh, I'm just going to type in whatever and answer the question. But then when you go out to your data officer who's just joined it. We just scenario we just said, and then they look at it and say, show me all the people that have got this in that box. And it's there's none. What and then they go to look at it and do the report says X, Y, Z. man. What's that? That's not going to help me do my forecasting. And This is the thing building that data but shaping it. to where everyone is used because it's well in the strictest sense a relational database. Now we all know that there's copies of certain tables all over the place, but in its truest form, relational databases, store once use multiple times.

Jon:

Yes. Yeah. I think for folks who are listening, what Brett's referring to, is it being the most efficient way of modeling your your customer and the orders and stock and all the relationships is the is logically to do at once, but because we're putting it into a computer and a, and you've got lots of people wanting to access data at the same time, you have additional tables, don't you create for performance which you normally do as a sort of a there's lots and lots of different ways of doing it. But I know in the work that I've done or the experience that I've had, often your development. They will be able to create something that's logically sound, that, but then something that runs at any particular speed that's when you're bringing in your DPA's and folks who are more in tune with the, maybe the wider collection of data, what would you say?

Bret Robinson:

Yeah. Yeah, I, and it's very important. I love to talk to SMEs to figure out, subject matter experts who, know the data know the subject, they know exactly that particular business process and it makes it so much easier because they will have most of the frustrations because usually they use the SMEs and an organization to sort out the support calls oh I've got this problem with my data. Okay Let me have a look at it. You sure it's the data, you shared smart the app, or normally They say, I've got this problem with the software It won't work. Okay. What is it? And when they drill down to it, they understand that this master data is wrong We need to correct it. And then, but what they then need to do. for your year end, They have to physically go back, and correct it for the whole year as well. So that's another subject. altogether that we can get down

Jon:

that's quite a lot of coffee, isn't it?

Bret Robinson:

the debt Yeah. it is going down deep.

Jon:

Yeah. And okay, cool. So again, in terms of our kind of planning out on 90 days, you mentioned the subject matter experts. We always see SMEs for folks who are new to that term. And that's the other I special starting to build up a contact list of folks to go to the people that kind of, and th that does seem to be a collection. I haven't found yet in my career, the one Oracle, the one, the one person. And I think if that person ever did exist, they'd be too busy to speak to me in any case. But there is always missing. There's always some detective work, isn't it.

Bret Robinson:

Yeah. And That's why I like to pull all the SMEs together, which never too rarely happens within an organization They're just That's HR, and sales And that's PR procurator payer purchasing it's I don't have time to speak to them to find out what they're throwing me is correct.

Jon:

Yeah, absolutely. Okay. Let's wind the wind, the clock forwards a bit. I don't know what day we're up to. Yeah. We still being successful. Are we going fast enough, Brett, on this one?

Bret Robinson:

Yeah. This is the thing isn't it? I think what would really want to do is, I use it, I use a tool set that, that's really good. Let's call my data and IData. Would it allows me to do is profile your database really quickly. So I can see what's in each table so I can profile the database look into the tables. and say, okay, in IDD you have. 44 different profiles that you can use has commerce has periods, has punctuation, has blanks leading trailing spaces all those sorts of things, And then what you can do is not only look at some of the data and what it looks like, but you can look at how it's set up. So what's the unique parameters. What makes a postcode What makes a telephone number? what makes a a cost center or sales org So you can start looking at those things and handing them to the right people to then say, oh my God, this is totally wrong, or we need to change that We need to fix This And this is what's thrown all of our stuff out. So that data profiling can take, in the data health check if you're doing like a two two weeks or a data health check you could spend probably a week on profiling just making sure you got the right information in front of the right people, maybe four days. And then you want to spend maybe that last. day Looking at over and making some decisions. So when you come back in your second, sort of week you can say right now I have a cleansing plan and that's what we're getting to. Now. You want to correct that master data. don't worry about the transactional. That's already happened, We'll get to that but the main thing is to sort out your core foundation, you don't go and build the walls of the house. You got to take the footings and first. And that's important.

Jon:

Basically let's deal with the root cause rather than a Groundhog day, doing that transactional data constantly you just very briefly that tool that you mentioned, you said it was called eye data. Is that right? I

Bret Robinson:

IData yeah. By, Intelligent Delivery Solutions IDS so you know, that it's a, yeah, it's a great product. It does many things. It profiles data. that compares data. It does similar records within a table. So you can compare different sets Remember I said about suppliers, you might have three different sources of truth of suppliers, three different databases. You can look at all three and find out which is the best one. And also as well, similar records within a table, So duplicates things like that or things that might be that woman changed her surname oh, that's the same. person isn't it? yeah, it is. So you got two records, for him, so which one are you, updating which one are you using? And then of course you've got obfuscating data Now those who might not know obfuscate is mask or security or whatever you want to say about data. You make you change that data. So there's no way back but the deal is you using the structure of that data to create your own cascaded and then generating data and then like I said the compare is probably your best friend, because you're gonna once you got your source data you look at it. That's wrong. You then put it into a cleanse table, I'm going to clean it here. It is nice. And shiny You can then compare those two and then indeed, if you want to then transform that to either another migrated system or indeed into a new database or back in the old one you can then look at all three views But yeah, it's a great. tool. Sorry.

Jon:

No, it's good. It's great. Because I think what's very powerful for people that are listening. Is it something that's practical? It's obviously something that you use very successfully and very familiar with. We might put a link in to, to that tool set of people are interested. Okay. On the office location just wanted to cover that off a bit because I've always thought of it with the view of that. We've got to work on some data, we need to structures and all the rest of it, but there's no way on earth. We're going to have customers details, they're in the test environment or the other great one is where you're trying to create a pre production environment or maybe not pre-prod, but some sort of performance tuning environment where you want lots of data, but you simply just because it's I a pre-production technical endeavor. It doesn't mean that people's data that is in fact is that actually you need to be more secure about people's data, don't you? So do you come across that as, do you think that skillset is common amongst tech teams or is that one of the areas that your expertise is used to people really understand how to do that?.

Bret Robinson:

Yeah, and this is they don't and here's the reason, when you deal with something like SAP, the full version, everything banking everything, has 800,000 tables plus, so that's a lot of tables And, even though you're not using them what is inherent and all that Remember we talked about our relationships So we got a product table, We got a customer table a supply table a sales table We're going to buy said product from said supplier. And the problem is each one of those has a, what's called a primary key and ID field people don't offer skate When people say, I'm going to obfuscate my data. and they're not going to sanitize They say, or secure, and they'll change the email. they'll change the mobile number and they might change I don't know the first name. or something. They don't change anything. else. And the amount of people, even after GDPR that I've seen have real live customer data in their test systems Oh my God, it doesn't even work mentioned. It's not on, but the reason why they don't offer skate to say Ah, that's just too difficult we tried that, what you want to offer is you want to offer a no way back. So I can't take your product purchase that you just made Jonathan on, on, on Amazon, I can't go into their system and take your purchase that you've just done and change your name, your first name your postcode and your telephone number, and your email address. I can't do that because guess what your customer ID is the same and I'll go look in production. Oh, there's Jon it's Jon. That's his name?

Jon:

Yeah. And folks who are listening, this is the this is the primary key. And I think if I remember rightly I wasn't expecting to say this phrase this week, but the posted foreign key I think is in basically you've got two tables of information. One of them is the information which you want to have as your source of truth which and then the other table requires some of that data, but it's, you it's used for another purpose. And all of these things work off of keys. Don't they like your driver's license number, your national insurance number, your, if you're in America and your IRS number, these are keys. These are one number, put it in a system and get a lot of information. And that's what you're saying is people think just because that's not immediately understandable by human, but if you put that number into production, it is literally the key to all the your data.

Bret Robinson:

and that's exactly right. And Being American myself. there's social security. number is now. And You know how everyone here, asks you for national insurance number and you don't think anything about just fostering it and putting it out there. What you used to do anyway, over in America. Now I've been told that Those you only give the last four digits, you know why As in the American air force it was name rank and serial number and your serial number was your social security number. So, there you go. It's stamp on your

Jon:

suppress yeah. I think where we got to where we talking about the, working out what the problems are, and then I think you were describing Brett that you're getting into the phase where we're getting into starting to cleanse the data. I think that's where we left off now in terms of our kind of, thought experiment of the 90 days, are we halfway through or are we just still at the beginning? Where are we on that, that 90 day?

Bret Robinson:

If you're sticking with the same system, we could probably do an in a shorter piece of time, but if you are moving to another system, then I think what's going to really, it's almost like you start that profiling. You start looking at the data And then I think team the B team, what they need to start doing in parallel is they need to start mapping to the new system. So if you go into something like, I don't know, SAP to unit four. So if you go into a unit for ERP system, you might want to start looking okay, what fields do you have available that cover? My processes over here, customers, suppliers, products, things like that. So you get that mapping and then, as the tech team, you now have to make your data field fit into those. And Again, it's a case of using that profile data to then look. what's the best fit because like we've said, data might not necessarily be stored in the same table The whole period of time, you might have changed in the middle and it's now stored in a different table or an amalgamated table, or, something so that mapping process is the critical, but you must have your data profile, know what's in it because please, listeners do not get stung by the SSI the cert system integration. partner that says to you it's time and materials on your statement of work Look under the data section of the statement work it's time and materials, which basically means how long has a better string and how much money do you have in the bank? Because they'll say here's 10 people. They're going to crawl all over your data. And It's going to take six to eight months to okay. Is that project going to be longer than your project? Or, so you have to really understand what's in your data. First be educated about your data. go to your and say We know about it. And we know where the problems are. We know what we need to fix that's kinda how I see that And then that transformation side of things will then be. the, Okay. Let's now take this data and make it fit into this. new

Jon:

Really interesting point. You said that, I think there's an old saying it's not that old because it's too with technology, but it's the, if you're in a canoe yeah. Don't outsource the paddles and you just reminded me of that phrase because, if you go with the SSI and I've worked for some of the, quite few of the big ones over the years. But if you, if they have everything, they have the total scope. And also you've done nothing other than look. I just want to give all of us, it's just too hard to just give it all over to these folks. There are certain elements of any technology project where you've got this, like you say, almost like an open-ended liability. And so if you hand or hand all of that over to one party and you haven't taken the time to really own the quality of your data, Then you are looking at an open-ended, you are looking potentially at something that becomes political, doesn't get fixed, it probably gets worse because you've just introduced a whole new set of relationships with the new system without fixing the data. Do you see that? Cause I think that's a, why is, I think you're getting some really wise counsel to folks to say don't or if you're going to do it really get in touch with your data quality and maybe have that separate to your SSI.

Bret Robinson:

Yeah. And the other thing as well, don't forget when you start these projects your development teams soon as the SIS in the door, they got 10 developers on the ground developing code and you're like, okay. And you might think, wow that's good You're really they're really kicking it off, but they don't have your data. They don't know what data to use. They don't know What changes the data may have to facilitate to fit this new development. So you have no idea. They could charge you for something that and I've seen it. I've seen it. John I've seen people triple charging on some of these, are size for people that they're like one guy is doing three different projects for the same day on three different budget sheets, So they're charging you three times as much. It's like,

Jon:

yeah. Yeah,

Bret Robinson:

mindblowing.

Jon:

it certainly is. I would just want to run a scenario past your breath. So I'd be interested to see if you've seen this before. So w one of the things I've done where basically it was all around onboarding of employees. And we wanted to automate the process, the build. And so we needed to declare where the master data was going to be for them. No, they never, that conversation had never happened clearly, but we picked no surprises. We pick the HR system and that actually handled the onboarding process. It's the right place to be. And then that data that was put into the HR system was then put onto in this scenario it was Microsoft scenario. So it was active directory. So the Microsoft directory was getting its job description, all those key titles was coming across from the HR system. But before that, it was just coming randomly out of active directory or different, different areas. And I just wanted to know when you're doing your planning and your analysis, is it, do you often move the mastering from one place to another, or is it more of a case of nobody really just understands where data is mastered and that the, and you have to explain that concept or I'm just trying to work out whether you've had to maybe you've had a situation where there's been two HR systems. Yeah. And you have to move from one to the other. What's, how common is that? Is that tricky?

Bret Robinson:

So when we talk about legacy systems, when we move into the new realms, the new SAP or the unit fours and things, there's more in a tight unit. But if we think back to the nineties, when we all started, this we have legacy systems, and it's all in different places, I know when I worked for a racing team I won't name names. I wrote for a racing team and they basically had three HR systems. How okay. You only have 5,000 employees in total or just last, but how do you keep track of which system you're updating, when you put they're different benefits or their deductions are P and D's and all that. How do you know which is which and you get that you get systems where people, will put the documentation the scans of your passport, your right to work and, your marriage, certificate, all these different things. They may need to collect for your job. And they'll store that in one system And then all of your day-to-day stuff's in this system. And then you outsource your payroll and that's in a third system It's great. Okay. But you need to understand where that single listener's point of truth is because you just can't have that scenario. to be successful

Jon:

Yeah w when that scenario exists and there will be a lot of folks listening who either know it exists, where they are, or are blissfully unaware of it, but it's just going on around us is you get the, they call it the swivel chair interface, with people moving between two systems, or why did we deliver the, all their kits to this address? They moved two weeks ago on our system, this is the address we've been given, It's happening all the time. Isn't it. And it's almost it's where, automation is it's got the potential to really do us quite a bit of harm because, it's I suppose this isn't a great analogy, Brett, cause I'm not quite sure about the data oil thing. It sounds a bit too, like a marketing term for me. But if we stuck with that for a minute, it's a bit like putting petrol into a diesel engine, you just, it just, it doesn't work and you've got, you just, you end up with with the wrong or the wrong outcomes.

Malcom:

This Podcast is Sponsored by Fairmont Recruitment- leading the way in technology recruitment across the UK and Europe. Fairmont provide a high quality consultative approach to recruitment, advising and tailoring a campaign to your recruitment needs With a deep understanding of the technology sector. Fairmont can provide an overview of the market, advise on hiring best practice, and provide strategies to attract talent in an extremely competitive environment.

Bret Robinson:

Yeah, that's right. And, you, Your data is also don't forget being updated potentially by many different people this person might work in that system, and update something, but it doesn't coincide with the system over here, or they don't understand that this person over here changed something. When I worked at a big DIY retailer basically they had seven different marketing analysis applications Funny enough, One of them would have done the whole thing, but no, we like this one from that one. this not in front, that one, this one. from that And So he had seven or eight different marketing analysis toes that kinda even though one or two of them would do the whole thing, they still had the seven or eight different ones. It was like, are you mad? That's they had 80 odd interfaces, there there were a few it's like why are you doing this to yourself?

Jon:

Yeah. That's a certainly sounds like a lot of fun.

Bret Robinson:

The architects, they got a lot to answer for because the architects saying, oh yeah, we'll use this. We'll use that We'll Bring it all together and they'll make a solution for you, And it's will that work. And how much is that going to cost me That's all you care about but what you don't look at is that, underlying costs how much does it cost for me to support it? how much is it going to cost me to put listeners on each box to see if there's any issues or security Yes. The more jumps you have the more complex Your whole thing's going to be, and it could fall down quite

Jon:

So where are we now, Brett, on all cleansing journey or the w where are we in the

Bret Robinson:

So we profiled our data. We mapped our day We, started the putting the profiles stuff over, what, results, we found over to the SMEC, crawl all over that. Look at that just tell us what you want to fix this RD Okay. Or do you want road is United Kingdom in caps good, or do you want it, you go and sort that out. We're going to get on now with the mapping. So we're going to map your data and make sure that, this field equals that field. don't care about the cleanliness at this point. We just want to make sure the mappings correct. And then once we have that, and we have now starting getting samples from the SMEs to actually say, this is what cleansing looks like. Cool. So then we'll do, what's called a, standard. cleanse. We're going to move blanks and spaces and things like that. Then we're going to get that to you and you SMEs. are going to analyze it. And then we're going to do, what's called a targeted cleanse. And we're going to say, okay, now they want everything to say road. all these cost centers to be correct all the postcodes. Instead of being in address line two, they want it in the postcode field. And instead of address line one having the full address. they want it jumped up. So then what we start there getting into there is also in the new system might say you've got 10 customer, tables, different, tables over here. Let's use employee. So you've got 10 different tables for an employee that make an employee you've got their name and address you got their email contact details. You've got another table with their next of kin another table with their pension another table where the deductions all that sort of stuff right Now in this one, new shiny says I'm sorry, we only got one table, Ah, okay. So now you got to that tech team has to now, so I make a brown peg fit in a square. hole. So they have to then map that to make that look like they want in the new world. And that requires a lot of back and forth. And I like to run workshops, mapping workshops to where everyone gets involved. So that way we get the single point of truth now, rather than letting it drag on And, take months.

Jon:

If you imagine you've got a business whereby whatever exists inside vest system, it only exists in the short time scale that say it's four months it could be retail some sort of retail sales cycle or something like that. And in the main, it's not repeat business, but where I'm coming from is if you had a legacy system that, that where the work inside, it doesn't last for very long. Do you think there's some cases or an argument to say in those cases, let's just let it run down in that system. We won't even do a migration because the complexity of the mapping and the getting the data quality, and all the rest of it, it does that become a barrier I'm trying to play devil's advocate and say, Brett, is there ever been a time where you've said, do you know what? It's not worth doing a migration here. You're better off just letting that run where it's at, because you see, what do you see where I'm coming from?

Bret Robinson:

I know Exactly where you're coming from and I've seen it many times in an, a mapping organization and in various other places where you have a very old AS 400 or something, server that's, ancient stuff and you just think, hang on a second, it's not worth upgrading that. Okay, cool. No problem. So what we'll do is take the data and get alpha there and put it somewhere else one. or two, we were getting all this bad data from it And something like for instance like the data tool where you can have a transform rule that just runs and says monitor that table. When that table kicks this data, out change it to this and then put it into the new system. So you can, build in little go betweens that, at least manage that. So if you found the root cause, be your legacy system not worth upgrading. Okay. But it's still giving us data, but okay. It's not correct. then you can I've had people go in and even just write standard SQL scripts that just change

Jon:

You giving people license to do a bit of data first link on the basis that is the old system and it's going to run down. It's not, if you went to live with it for a long time, that's not the right approach. Acceptable to do that. And also, I just love the fact that you used the phrase ASMR 408 ancient in the same sentence, because I used to post it back those up. I used to run the T at needs to be part of my overtime gig as a young professional it was changing the tapes that was for a big Dutch based consumer electronics company that would go quiet. And it was about 150 years ago. Interesting.

Bret Robinson:

I mean in good sort of sense because yeah, I've had to do mainframe stuff with some high retailers who used it to process orders to third party suppliers like Flores

Jon:

And Breton don't name, any names, but mainframe still around there are still

Bret Robinson:

Yeah sure. Is Yeah

Jon:

and in government and this mainframe is still going.

Bret Robinson:

alive and kicking and I think that's, and that's where you probably need to look as, Okay. I don't think you're up to standard with your data on that side. of it. You may need to look at, how you sought that out. But yeah, definitely still there. I know one large retail organization in the high street that still uses it to, as I say, to do florists, to do furniture, to do all the third party, what we would class as EDI, sort of stuff, that you get shipped direct from the supplier, rather than them holding the stock. Amazon's a perfect example, EDI.

Jon:

yes. Yeah. So EDI folks we'll get'em we'll get some explanations. Brett, we've got, I've got Malcolm who speaks on the episodes. He's not real. He's he doesn't know he's not real, but he's just an AI. So we generate and we're working on generate a, generating a face for him as well. But what he'll do is he explains some of the terms that we'll use, but electronic data interchange, EDU. I remember working in manufacturing and having the first sort of EDI console where you effectively, it was a mapping exercise, wasn't it? It was, here's the message coming from, I don't know, the chip supplier, and this is how it literally relates to the products that you've got within your ERP system. And you'd map them through and then you'd press a button. And then, as long as the wind didn't change direction, it would work for about a week. But yeah, incredible. Incredible. You've been called in for a kind of an update and it's okay, Brett, we brought you in w we're on what we're trying to improve our data quality. What, where have we got two so far? W how are we over the biggest challenges or are there still big challenges and risks ahead of us in terms of the process you've described?

Bret Robinson:

I think the main thing is, then I suppose if we overlay, what are you going to change So whatever the SMEs have found how the old business processes, fit with the new business processes, And let's face it, right? during the migration transformation now is the time that if you're going to change something. Let's get it changed all at once The ma then minimize the disruption over the longest period of time. So you try and just get it all done So I would say overlaying those new processes is that data still going to work for you. And Are there any other things that you now want to look at and to use and to work with this data and how you want that to be shaped am I going to now, for instance, if you take like Experian experience a great organization, they hold a lot of data a lot of personal data. what we call PII data, which personal data and then You just got All this stuff. And they want to make sure that they're staying GDPR compliant, but they also want to make sure it's serviceable and it's usable, and it's sellable. And and it's up to date. So now we've got to now. And when they change something, they overlaid the new process and say, is that changed? Anything? Do we have to make any new? allowances for data rules or compliance or anything like that So what we're up to now is we're saying, we've got it profiled We've got it plans. We know exactly what data issues we've had we know how to fix them. what we're now up to is here's a list of systems that we need to look at too, as a root cause analysis, that's causing us issues. and those could be third parties supplying data into you, which you don't, like you said, John, you don't necessarily idea, I just get my data from there. I don't know. It just goes in you may want to now put something on your side of the API every time you see this data, it's going to go like that. If They're not willing to change. their API, You need to then make it usable to you. So you need to look at that. So we'd be able to map those out and say, look at these sorts of things. But I think now once we had that in place, the best part about using a tool like iData, for instance, all that stuff, you built up to do the profiling the cleansing the transforming. guess what? It doesn't go away. Okay. The SSI will go away But this now is usable reusable in the live system. to see right now I want to profile my data because I have the CRM team It just doesn't seem to know how to put data into the right field. Or I've got this legacy systems still sending me stuff that I haven't had time to get to in the Bret recommended. I get it fixed I haven't had time. this will then say, it's like a, you mot or your car, you got to get your car checked every year. Okay. To be legally. compliant, to be safe for your you and your family and to save two other users, same thing, data, health check. We'll obviously let you know if my data is going to stray if it's gone left or right. I can correct it. And I will have that running on an automation that would just press a button. Let's look at the data, these scripts, ran overnight. Cool. And then come in the morning. Run these standard cleanse scripts And what's great about using a tool. Like iData is you could change that as your data changes and you never get rid of

Jon:

you're basically using it to keep on top of the investment you've just made. So otherwise things just very gradually go south or sometimes very quickly go south when something else gets added. And Brett's not there to tell us off. I know, I'm not saying you're telling us off bro, but if people just were the best in best intentions, et cetera.

Bret Robinson:

I've just, I just don't like to see people mess up He just put millions on To put in place and now all of a sudden you kinda, make it go south, And then the what do they blame John first state? The same data? That's the problem? Yeah. It is the data And he trying to blame the migration team or the data team No, how you using the system Your

Jon:

it is a bit, like blaming oxygen for not being able to breathe. There is some sort of weird truth in that, but it's not really getting to the essence of the problem. Quick question for you, Brett. Which I wanted to ask if you'd had any experience using sampling because when I've looked at third party data providers, particularly folks who give addresses obviously, you're in a position with your own customers to know a customer address that maybe you've just received, 10 minutes ago. And you can take a sample of. The customer of the third party data to see whether the two are in sync or to see how up-to-date or or not up to date. Some of these data providers are because what I do is I sit down and I think anyone is providing me with address information. It's got a real big task on their hands to keep it up to date with all the different changes that occur. And you can't check every single address. So I've deployed some kind of sampling where you work out what your sample size should be. There is a little bit of technicality listeners because the problem space you're looking at has to be something called normally distributed. Cause that's the sample I'm referring to. They'll definitely be someone commenting on that. And so it's quite interesting that as long as you pick your sample randomly, you don't actually have to get in the whole scheme of things that, that larger sample size to then test against some of the data. To give yourself some confidence about the quality of data. So I don't know, Brett, if you do any sampling as almost like a, maybe on the transactional data afterwards, where you say, we'll take a sample of this and let's compare it to that and see what you know, are we starting to get quality and are we starting to get matches? Does that make sense?

Bret Robinson:

And that's where the sampling really comes to the four is done in the transactional, because like I said, you could get to millions of rows very quickly in a transactional database. And that's where yeah, you're right you might want to take a sample But if you use something like iData, it profiles 100% IL profile or six main

Jon:

okay, so there's no need to sample because the tool just go to the

Bret Robinson:

tool does

Jon:

absolute benefit of automation.

Bret Robinson:

Yeah. And it's a bring it in the sense that not only does it is it. Automate And look at your data. It does every single row every single column. And there is a bit in the new version that will allow you to actually shrink that window down and say only want to look this. So if you had a table for like instance for all, you SAP people out there listening, the new Hana will the AC Doka table the ACD OCA table which has all your purchasing and all your sales in one table. So you have 458 columns by whatever And it's every product, every customer, every supplier, all in there in a transactional sense in the one table. And it's whoa. okay. How am I going to look at all that

Jon:

a lot going on. And I think your healthy warning around Sr. One of the things I've offered when I have been on the SIS side of the table is sampling approaches to the really cynical SSI person, they don't want to do sampling. They want to get someone on a desk going through everything, because Brett, you were talking about, some of the, some of those practices do exist. So I think folks that are listening your sampling will probably appear in more than one episode. It's definitely something to get to, to get into and to, we might do a sampling. I might do. I might do like a quant 1 0 1 episode because that's another area.

Bret Robinson:

that sounds good

Jon:

the folks,

Bret Robinson:

And cause a lot of people come, maybe they don't have the knowledge to get a tool set or to get someone in excuse me talk to someone like you or myself, ask us questions about what do, I do? Which tool set do, I go for what do I need to look at? You need a good quality data architect into help you. Not Part of the, SSI team, but part of your team, because your data and you need to make it sure It's being looked after and treated with the utmost respect and diligence

Jon:

of the paddles in the canoe 100%. Yeah, we got that. So where have we got to, are we almost at a, where are we at coming up to 11 o'clock and it's 12 o'clock is finished or are we still at half past six? Where are we in our process?

Bret Robinson:

So now we're going to start cutting over. And I think for migration projects and things going over into new systems there'll be some data that you can put in You mentioned that pre-prod system, that pre-prod system that's not yet, live but will be your live production system. So you gold client if you like, you'll start building that up And the sooner You can start building that up with signed off quality data. that's not going to change. hugely. And what I always tell people is once you get that data in there, like your product data, and you say, yeah, we update our catalog every three months. Okay, cool. So for this first three months, we're starting this cut-over we got two months left. If you do change anything, it needs to come over, maybe in a Delta, after we go live but now what we're going to start doing is putting that data into that system and building it So we have to worry about during the cut-over weekend or however long your cut-over period is So you need to really kinda be in control of it maybe even doing some dress rehearsals of that. Cut-over just to make sure you've got that timing.

Jon:

I want to share with you one of the, massive anxieties, and the CIO for me is cut-over. Here's the question I always ask and to see what see, whether you say that's interesting, John, you're asking the wrong question, but the question I normally ask is please tell me before we get there which where the process is effectively. Non-reversible, there's a sort of one of the rules I try and run an engineering buyers. If at all possible don't start anything that you can't reverse out of, but there are absolute, the whole point of all this preparation that we've done with the analysis and the cleansing and all the rest of it is ultimately to make a commitment and to start. Yeah, it's cutting over. And then of course you then start to take transit, live transactions in the new system, and then you really are beyond you, you get to a point where you think we have to yeah. That's that phrase that fills you with fear, they call it fixed forward and

Bret Robinson:

yeah Yeah, That's a combination.

Jon:

but what's your what's your kind of view on that? In, in your experience, is there a point of no return or generally, do you have a point where you can, you could stop and reverse back?

Bret Robinson:

Everything's risk-based so your data is really going to be risk-based approach. So risk-based approach you want all your master data in there and working and doing, because what you have to think about is When I opened my doors on day one, can I take in business? Can I make payments? Can I take orders, Can I ship product, so you always have to have that mentality in mind is what can I. And you'll get this, you'll get your program manager saying if you want this new CR change request to go through? it's going to take way too long and we can't do it. that's not day one, That's day two you always hear that as well. The fixed board the

Jon:

And also Brett, we should point out that whenever a program manager tells you it's day two, they mean day 200. Yeah.

Bret Robinson:

Yeah. And, That's the other thing as well. And you as a person, who was employed the SSI, you need to make sure that you're planning that day too And what that looks like and How long that is So you kinda got this? flow, like you stay in the CIO, you got this cut-over in life things happening. and then you've got these questions to say we really need that as business. critical. It's then you got your program manager saying what do

Jon:

Brett another question for your observations. know You were talking about, you've got to go and check the basics. Can you operate the business? Quite a few years ago, I was involved in a retail implementation. I arrived almost like to do a QA, a few weeks before go live. And so it's in retail. I don't know, actually now, whether retail still uses batch operations, I suppose you might do if you've got

Bret Robinson:

Yeah

Jon:

But one of the observations I made very quickly was that the batch window took three days and this is a retail. I was thinking, I'm pretty certain you can't, the client doesn't want to open their business every four days. I'm pretty certain they need to finish on the evening. And then, and they probably need to do stuff in that evening as well to do with stock and moving around. But it's just something as basic as that, Bret, if you've got teams that aren't connected. They might say we mentioned that the bathroom though takes XYZ Z days, th those are the sorts of things. Aren't they, you've got to maybe the non technical folks listening to this, trying to understand, maybe they've got something like this in front of them. And they're trying to think, what are the killer questions I can ask the team just to try and get some comfort, but you definitely want to go around don't you all have your when I be able to the system finish everything it needs to do within our business clock, as it were,

Bret Robinson:

Yeah. And you have to really and that's why the dress rehearsal. is So key John, you had to get your cut-over manager to work with your data migration team. work with your systems team. And, even if you have to practice on what will be your production system and get it rebuilt So these questions as well. You need to ask early on to say when it comes time to cut over can I take this production system, build it up to a certain point, and then have to say, blow it away And now start over again with the real. thing. Some people spin up another AWS environment. nowadays and, use it for just testing the cut-over and then tear it down when they don't need it anymore. So it's a throwaway

Jon:

going to say Brett as well. I'm glad you said, tear it down because that's one of the obvious places you look for as a new in your CIO 100 day plan is to look for all those things have been set up in the cloud that are just still sat there, but nobody's

Bret Robinson:

Yeah

Jon:

It's incredible. Th there must be a fair bit of compute. Don't you think going on right now that isn't really computing, would you say

Bret Robinson:

it and that's right So I know I said to mentioned about profiling UDC, blanks, and multiple spaces and things like that You can say probably up to 30% of your data space on your storage system. And also what you also want to look at is when am I actually using this system? woman Are you using it from eight in the morning Till five? in the evening. Okay. And then there may be some things happening. If it's a test environment, probably not. So shut them down overnight. Shut them down over the weekend. spin them back up in the morning. It's all automated.

Jon:

That was one of the bit, but yeah, it was one of the early sort of use cases. Wasn't it with infrastructure as code that you could rip out everything and then, press the button in the morning and the thing would build,

Bret Robinson:

Yeah Your Jenkins job, you Jenkins almost to Jenkins.

Jon:

right. And that's actually old hat now. Isn't it. I remember when I first saw it, I was like, oh, I was absolutely blown away. I thought this is incredible,

Bret Robinson:

yeah Yeah. And they build the data and they build their server and then what we have are a state of people have what we call the seed data. that's the data that you will then overlay every single time on every single new environment doesn't change because that's your core data

Jon:

Got it. Got it. Got it. Okay. Have we pressed the cut-over button? I know We're doing, it. We're doing a 90 day health check data health check, but we.

Bret Robinson:

we got in the car

Jon:

this big data migration. I'm actually getting nervous. Just thinking about it, which I think member folks fear is a sign of intelligence. So yeah, I'm getting I'm getting worried, but are we going to be successful with this crossover?

Bret Robinson:

Yeah, I think it not maybe not in 90 days but close but I think for a cut-over when you want to cut that data over, it's like anything you don't necessarily, you don't want to update your production system. So whether you're just doing a, cleansing activity in a data, my data, cleaning and data assurance on your system your current system, you're not moving there is that issue to where you want to keep that going. and you want to put that data now into the production system, and there are ways to actually do that, to make sure you don't override anything, and things like that But it's a little bit more technical than this call But I think from a cut-over of point of view, if you now cut to, The one thing you want to do is you want to take your timings. You track timings through your data migrations through your transformations of your data, You want to time, all of those and keep those really close. Give those to your cut-over manager. And then also time how long it takes to get these environments in place. So then you've got you take it to the CTO or the CIO and say here's what we found. This is how long it's going to take. These are the people we're going to need. And this is the running order that's going to happen. in. And once you Have all of that you can then start playing out in real time. We're going to shut the users off on Friday afternoon, no more users. We're going to take the data backups We're going to start bringing everything down and then we're going to start spinning it back up. on the other side. And you're right. There is that point of no return. And you'll get to that usually on a Saturday afternoon or Saturday, mid days, Are we on track Are we on target? Does everything look. pretty good Thumbs up. go. No, go hip. It's a no go you got a day and a half to spin it all back to normal or reapply the backup. If it's a go, you, then just start doing everything. And moving that forward and tracking, I think tracking is the main thing tracking, all the issues you're getting, logging all those And then, like you said, unfortunately, there is always the fixed forward element, but only on the less riskier things or the less you run your month end. You'll do this at the first of the month after the previous. month end. So you've got a whole month to make sure that you've got everything fixed,

Jon:

yeah, absolutely.

Bret Robinson:

That's what you call the hypercare. Then you enter into hypercare, once you're spun up and ready.

Jon:

I want some separated a network of a pretty big one, two big organizations that joined and then they wanted to unjoin and we we basically did like a cut-over every night for six weeks. And we had to do it in the evening. We were lucky it wasn't a 24 hour global. It was just in the UK. And we finished it, but on the fix on fail, there was a satellite office in Europe. And they couldn't connect and I got the phone call and I said how many people are there in the office? This is four of them. I went, okay we can fix forward that one. That's not a problem. And the reason why is it? Nobody told us nobody seemed to know that they had an office at four people. So that I thought was an acceptable element. Okay. Separate where we've we've we've got to the point where we've cut over. We've done this great work. I think this is really be an interesting episode. Wouldn't it? To have a quick listen to, if you are looking. Migration, what, you've, what we've been talking about, the kind of the worries and the professionalism and the points. You've really got to own the points you can give to the SSI. I would also say that as CIO, I always like to get the sense that there's really good comms going on between all the different groups. That's such a key. If you feel like someone's not been talked to that's when you think, oh, goodness, maybe this is going to go, this is, this could be, you're rolling the dice. Now we're in the, we're in the space of chance. Do you get that bright? You get that sort of comms feeling.

Bret Robinson:

Do not be come complacent with yes. Yes, we can do that. Yep. No problem. That's no problem. Prove it to me. Show me, please. So Always seek assurance if you're not sure it's your butt on the line, it's your money always seek assurance when dealing with SIS service, integration partners and things like that. Always get that assurance and that backup And if you not, put someone there who will actually go after that assurance show me the

Jon:

one of the things you could do, bro, it's a practical thing for anyone listening. If they could have a listen to this. And I'm sure Brett, if you want to they can reach out to you if you want to give you a contact details, that sort of thing. But if they had to listen to this, this is the sort of thing to listen, to take some notes and then have that call with the sign, say talk me through your approach. And if there, if it's all a bit if they don't hit on, because we're doing one-on-one aren't we, where we're covering off the sort of the muster, we're not even getting into you. You've I think you've mentioned it a couple of areas where it's just. Really technical. And we're not getting near that because that's not what one-on-ones about, but I think that's key because otherwise the person that's selling to you and the SSI might not get it. And you've got that terrible situation where someone sells something that they don't understand. Someone who buys it, who didn't understand either. That's not a great start. Is it?

Bret Robinson:

I have I had that with a car manufacturer in the UK, large car manufacturer And they were sold a system by a big huge SSI partner in based in, UK as well. And they really didn't understand this HR system fully and they really didn't know. Okay. So what do you want? We want to do this and that, they really didn't know how to articulate it because the business people, know that And the technical people, don't know the business and you're kinda trying to learn. So you always got that battle And me as task manager. always kinda always fitted that sort of mediator. Hang on a minute what are you doing? No That's not what they want. That's not what they said, and you always got to keep checking. You Always have to have that conversation. and that knowledge, and that experience to say, hang on a minute, you're trying to statement where it says time and materials. What does that mean? Oh yeah, If we come across something we'll just, we'll throw one or two people at it to sort it out. It won't take long, nine months later you get this massive bill, of 10 people nine months for your data migration. It's

Jon:

I hadn't really thought of it in the way until you just said it then, but you're really obvious when you do have the two tribes, the really obvious people that sort of integrate between the two of your business analysts, they're back and forth and. And then you've got your senior managers in technology are doing their best to represent the business, et cetera. But testing is that it's a moment of truth, isn't it? So you absolutely have to be the bridge between, and also you get the feedback really quickly. Cause you're at the, this is at the end of the development. This is it's either working or it doesn't. So it's interesting. You must have in your testing profession, quite the mix of skills, including business engagement, as well as technical and I suppose, testing can throw up a problem in any part of the system. Yeah. Because if you're good at testing, you should find problems all over the place. So you've got to have knowledge of the whole stack and also, even better if you've done it in a particular industry, some sort of things that are common in a particular setting, that sort of thing.

Bret Robinson:

Yeah, you got to know a lot of things about, a lot of things really cause you need to know, a BA to know what a requirement is testable or not. You need to know about non-functional requirements, and whether they're testable or not, and how to test them. You need to know about all the different testing elements performance, automation, all those sorts of things. And you need to understand You need to have good comms And I suppose the other thing, one of the most important ones, you need to ask the right bloody questions, right? You need to know the right questions to ask because, and especially if you're hired by the client and not the service integration partner system integration partner if you're not hired by the SSI you're hired by the client, you're in a great place, because now you can start being the devil's advocate and being the voice, and being the lawyer, Who's standing in the dark saying, hang on a second. That's not quite true. I always test static test the statement of work. I like to know what who's on the hook. for what? And I like to have that clearly outlined beat that drum continually until eventually, I've had one of the big one of the biggest SOI clients tried to get me removed from a customer's site because I was stating the obvious and they were trying to pull the wool over their eyes.

Jon:

That's a badge of honor. You should take that as a badge of honor, if that to be as long as you're representing the customer's best interests yeah really interesting. And also you mentioned all those elements that you need to understand, and you didn't say data cause it was pretty obvious we're talking about data. No. I know, but I'm just thinking you've got all of that and data, which we've, which I'm hoping everyone listening to the podcast or watching will know. Th that in itself, it's just a really big, it's a such a big topic and you can, I did a bit of research and I'll put some notes in the on the on the blog, et cetera. But I did I had to look at a couple of data only podcasts, and I was like, can you really do a whole podcast? A whole channel dedicated to data. Crikey, you can, can't you breath. And I was driving back from Ireland white. I did six, six were five hours of data podcasts. And I can say, I will put a link in, and I think the podcast I found a great, but I do think you can have too much of a good thing in one car trip. So I think next time I might just have a few more elements in my playlist, but it is, it's a massive topic. Isn't it?

Bret Robinson:

it? is. And a lot of people starting, who I work with continually and things of don't get him started on data. You'll never shut him up.

Jon:

But that doesn't happen at the pub does that. This isn't a, don't get Brett started on a second point. And he'll be talking about how about his iData tool until you bought a copy of,

Bret Robinson:

I tell ya I absolutely love the tool and I love what it can do and help people. And I think my passion lies in, I don't like to see, people taking advantage of I work with too many clients, with too many SSI partners and it's come on you guys got to get savvy. If you're going to do a project like this you really need to understand your data you really need to understand that because they are going to charge you time and materials And it's going

Jon:

That's I think that's a big recommendation coming out of our conversation is you've got to understand that you've got to own it. You

Bret Robinson:

own your data

Jon:

outsource your data and get someone you really trust who's got a track record and get your head into it.

Bret Robinson:

You can do it. John is so easy They can do it if they had a tool like iData, it can really be done. Very simply. Even if you did get the SSI to do it, it they can be trained they can be taught and they can at least You would have the visual assurance very quickly of what that data looks like without having to scroll through rows and rows of data that you think might be wrong, but you don't know what am I looking for? It's like a needle in a haystack, whereas a tool like that, just boom Does it. There

Jon:

That was

Bret Robinson:

Here's your

Jon:

That was that point. That was a great answer that you gave to my sampling challenge, which was actually you don't need to John. Cause it just does everything. I was like, oh fine. Fair enough. We'll have one of those then. Yeah. Nice one. Okay. Then we'll break.

Bret Robinson:

You need to get into your data. You need to understand it, even if you're CEO and you just have a basic sort of view, but you need to make sure there are people in your organization who are, owning it, who are keeping, you compliant who are keeping You think back to the Enron days and Lehman brothers and all those people didn't have a clue the data was gone south, and you need to, own that because you are responsible for that as the CIO or the CEO so you need to own that. You need to be responsible. or at least have an idea, what, where it's going but also as well, making sure your data science team or your data analysts who are giving you this forecasting and planning information. is correct.

Jon:

Brett, I just want to say, absolute pleasure speaking to you and I really appreciate it cause you've only had one coughing moment, which was much appreciated. And is there anything coming up in the Bret calendar that you'd want listeners to know about

Bret Robinson:

we're going to James briars and I are doing a thing for Embridge We're doing a questions about data quality coming up on Friday. So I'll send you a link to that. That would be a great lesson because James who's the CTO of, IDs and IData, he set out originally with the tool set to actually compare test systems the data sets in those test systems and that's how the product evolved. So James got along knowledge as well. Got scars. Same as you and I, John. If anyone has any questions feel free and you'll have my details, Matt, feel free to ask me I'm quite happy to help out. I do try and, if you've got some data you want me to have a look at a POC, just to see what's in it very small we can, do that. Not a long, drawn out process, just maybe an hour or two. I can

Jon:

I think. Yeah. And what folks should take away from that proof of concept with someone as experienced as Brett looking over it and the topic that we've just covered and all the different areas. There were lots of rabbit holes. We didn't go into that. We could have done the, getting that kind of QA a view at the beginning can save you a lot of time. And a lot of heartache. Yeah. And a huge amount of money. Yeah, absolutely. So

Bret Robinson:

Definitely it's be better best to be prepared. I've got a a load of questions Maybe I'll. find OT. John, to That that you should be asking yourself in the pre and the jury. in this data journey And the pre ones are really good. And it's loaded with the pre because the more pre questions, that you ask and you get answers to the better prepared you are for the actual delivery. And you'll be surprised some of the questions you might think that's not really relevant Trust me. is

Jon:

Yeah. And it's a universal operations principle, which is if you deal with things early on it's a lot cheaper than dealing with them later on, and the, you get to get as much as you can upfront and understood and get experience around you. Like folks like brat.

Bret Robinson:

You might only do this once in your lifetime. You might only do one migration product project while you're at that company you might change from a massive legacy to a brand new shiny tool And that might be it you're then retire So you only do maybe one or two of these in your career, unless you're a contractor and you do this punishment and you love punishment, like you and I, John. And you do this all the time.

Jon:

It's a really good point. And that's a part of the 1 0 1 is that there are things that come along to a company, which is just the ones. I think some of the average age of some of these systems is 10 years, the times change every 10 years and you, and I'm sure you've seen legacy systems way older than 10 years I have. And they're still up and running. So the computer doesn't know how old it is. That's the thing. It just carries on as long as there's electricity coming in. It's happy. Brilliant. I was just a huge, thank you for joining us.

Bret Robinson:

Thanks for having

Jon:

That's about absolute pleasure.

Malcom:

Thank you for listening to Episode 3 Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe. My name is Malcom and I am AI generated I wanted to tell you about something humourous with regards to something Bret said in this episode.

Bret Robinson:

So I started learning. how to fish in the ocean and wind surf and dive off bridges into alligator infested waters.

Malcom:

Before I was compiled, I was often left in fast storage without regular backups! That's living dangerously. Tune in next week for more CTIO one O one. Business Technology. Simplified. and Shared.

Introductions
What is Data?
Day 1
Understand your Schema
If you don't have an architect
Look at the stored procedures
What problems people are experiencing?
Cart before the horse
Garbage in...
Data Profiling
Cleansing Plan
Data Obfuscation
Start Mapping to the new System
Beware of expensive SI T&M Traps
Don't Outsource Your Paddles
Don't start development before you understand your data
Master the art of Data Mastering
Get Mapping
From Standard to Targeted Cleanse
Migrate vs Run off
Space for Pragmatism
Data Fettling
Mainframe is alive and kicking
EDI (Electronic Data Interchange)
Called in to the CIO's Office
A list of issues to focus on
Maintain your quality
The Data Health Check
Sampling Data Quality
A healthy Warning of SI's
Never outsource your paddles
Cutover Prep Build Pre Prod
Fear is a sign of intelligence
Everything is Risk Based
Don't forget the Batch Window
The dress rehearsal is key
Save some money on cloud spend
Track Timings
Is there good comm's?
Mediate between business and technology
Testing is the moment of truth
Testing needs 360 degrees knowledge
Where to source a Test Manager
Data - Understand it and Own It