 hope it will be a good session but just after lunch we are wondering whether you will fall asleep during my part or his part. Yes, you now heard my name, Eldar Björger, she pronounced it very well to be a US citizen. I've come from Stutt Oil, it's a Norwegian oil company as maybe some of you know. We do everything in the oil business value chain from exploration to development and production in Norway, internationally in general and also specifically in North America. We have a very great hub in Houston, about 500 persons. We also do downstream marketing and supply and a lot of technology and also do some business and the strategy work they are based in London. Stutt Oil has been doing data management within the exploration area where I come from originally for about 20 years. It will be strongly struggling with huge amount of data which they now call big data. Someone invented the word big for some reason and we have had petroleum data managers in that area for about 12 years and we have today about 70 professional petroleum data manager in only in this area. So we have a long long experience but we have used internal development methods and some industrial methods worked out in Scandinavia, Northern Europe. But now we are adapting the DAMA framework to be more aligned with other businesses. This is mostly introduction. I will skip that one. I've been doing a lot of presentations for some reason. They asked me to come and present what Stutt Oil is doing. I'm also heading the ASEAN steering group which is quite similar to DAMA within exploration and production area in Norway where we are focusing conferences and education. Stutt Oil as I said is an oil company. It's an international company and it shows the currently ongoing exploration wells for about one month ago. As you see we're all over the world. We are onshore, offshore, about 20,000 employees as I said 500 in Houston. And also as you see the activity in Houston is quite big. We also do a lot in Canada in oil sand area. And as you can see we are quite big company and we are the world's largest operator in waters deeper than 100 meters meaning we are a very technology focused company. Then we are changing. Okay thank you Eldar. So we're doing a kind of a double act on this. So you're all able to read the stuff that's in the bios. Anybody ever been to Bath in the UK? Apart from you I know. Okay so that's where I live and that's where our company is headquartered in Bath. We're the sponsors of Big Rugby Club there. That's the book that was being mentioned. Go and buy a thousand copies. There's quite a few on the Steve Homerman stand right now. And this is my blog. The stuff that I'm very interested in. Information management, life in general and petrol. So when I'm not doing this information management stuff I've got a car that I race in in various circuits around the UK. And I got into a little bit of trouble. It was a data definition issue in the motor world late last year. But before I tell this full story, has anybody here got a Ford F-150 pickup? Okay please don't hit me okay. This comes up. Absolutely true. You can read about some of this on the on my blog. So in anybody follow Formula One motor racing? Okay this year's Ferrari Formula One car is designated the F-151. Year before last the Ferrari's car was designated the F-149. Can you guess what it was designated last year? The Ferrari F-150. So it's not a vehicle to sell. But Ford Motor Company of the US brought out a lawsuit against Ferrari. Do you know the story? No? Okay. You haven't got a check shirt and a kind of baseball cap on back to front so you don't look like a regular F-150 driver. Ford Motor Company brought out this suit against Ferrari saying you're infringing a trademark. Actually it's not true because it's not a vehicle that's for sale. So you know Yabu sucks to them. But they came to this amicable agreement which was basically Ford was stupid and they shouldn't. This is being recorded isn't it? Oh dear. So my name is Alex Sharpe. So I did this blog posting on information management life in petrol about the data definition thing and about a guy, so David Plotkin told me to say it like this, about a guy called Dwayne who rocks up to a Ferrari showroom and looks at this thing and he goes gee you know it's only got one seat and that big flat thing at the front is that where I put my cases of bud on it because you know it's the wing and you know the engine, there's no engine under the hood. There's an engine at the back and where do I put my gun rack whilst he's chewing tobacco and so. I put this up, I put this stuff up on my blog and I actually got a guy from Kentucky going you limey asshole. And it got picked up. Has anybody ever heard of Piston Heads? The site Piston Head? So it went viral on Piston Heads and people started flaming this guy and I got told to take the posting down. But it was fun while it lasted. This is the other stuff that I'm interested in. I've got exotic cats as well. So that's a Savannah cat and that's his brother. Anybody want to talk to me about motor racing or exotic cats? That's what I'm into. So we had the introductions just now. The company I work for is a good bit smaller than Stato. It's IPL. We're independent consulting and software company based in the UK. I'm one of the owners. It's about 300 people and I run the whole consulting division and we really major on information management. So talk to me if you want to know more about the company. So the big question. Data management in particular, master data management. What is master data management? Well you can see here we've got the definition from the DM box. Master data management's control over master data values to enable consistent shared work and textual use across systems, et cetera, et cetera. So that's the DM box definition of master data. We've got to be careful to separate master data. The what is master data? With the how is master data managed? Because how it's managed is methods, tools, mentoring, capabilities and so on. And there's good, you'll see a bunch of the vendors here today in the exhibit hall who have got very good master data management systems. So definitions. There's a world of difference between master data, the what it is, and master data, the how do you manage it. There's another definition there from Wikipedia. When you look at anything in the IT world, you nearly always want to ask the question why do we want to bother this? Bother managing this stuff. So one of the big points here is the very, very first point. It's all about data quality and integration. I've not come here to give you a lecture on the big fundamentals of master data management, but this is all about level setting. So it's about making sure that you've got this 360 degree view. You've got the view across the organization or at an absolute minimum, the view across business functional areas and then later across the whole organization of these key critical shared data resources. Quite often we call it the nouns, the key nouns in the organization. There's a slide on that in the moment. It's also there to make sure we improve data quality, but it's not data quality in its own right. It's improving data quality by making sure there is that consistency of use and of definition and of understanding of those key critical nouns. And the bottom line, which happens to be the bottom line there, it's reducing data inconsistencies so that people aren't saying, oh, well, you call it gender and we call it sex and you call it customer code and we call it client. It's making sure that there's that really clear understanding of what genuinely is the same and what might be called by the same name, but actually is different. So master data helps tremendously on the first case is synonyms and the second case is homonyms. You're familiar with those terms? So homonyms, it's the same word, but it actually means something entirely different. Synonym, you call it a client and he calls it a customer. And actually, when you've drilled under the surface, it means the same thing. So I kind of talked very, very, very briefly about nouns, but one of the easy ways, if you're just coming to a one hour session as opposed to like a one day session on master data management, one of the easy ways of thinking of the stuff that needs to be managed is core nouns of the organization. So if you come along incidentally to mine and Alex session on Thursday afternoon, the thing about process and data, one of the things we talk about there is how to determine what the core nouns of the organization are and some tips and hints how to do that. And it's fun as well. But here's some of the characteristics of the nouns. They're created and updated in multiple places. They are very often long lived. So what that means is that distinctly separates it from the transactional data. It's valuable, complex, et cetera. I'm not going to go through all of that. But by and large, the master data is the stuff that's shared across multiple business units. It has value across those business units. There's some of the attributes, not necessarily all, but there's certainly a major chunk of the attributes that are common across the whole organization. But there may be some attributes that are very specific just to one business functional area. And a good example would would be, you know, if we're looking at a personal customer, as a or just customer person, as a, as a noun as a master data entity that we're looking at, then things like, you know, credit limits, or credit risk, that's not going to be of any value to logistics and picking and packing and the warehousing function. But sure as hell is going to be of real value to people in sales or people in marketing and people in invoicing. But the core attributes, you know, like, you know, the customer identifier and addresses and so on, that is core all the way across the organization. That's probably the quickest that I've ever talked about that. So those are some of the things about kind of master data in general, we're going to have it now kind of look very specifically at some of the stat oil master data challenges. Within the oil and gas area, it's not difficult to find master data areas that fulfill all of these characteristics. Typically, an oil field will live for about 70 years or a plant for 70 to up to 100 years. So it's really long lived. And it has to be maintained all the way through. If you look into the history at start oil, we see as a big, big, big company, we have to manage what has to be managed within the silos we're working in. That's how things has started. So suppose that's the way in all companies. So in the start list, a very process oriented company. And it's not in the most of the processes that have very good master data management. But they do it without within their own process. And that's a hard job in itself. In finance, human resources and exploration, supply chain, they have a lot of master data activities. But until recently, for a couple of years ago, no one had looked beyond the silos. So we started looking into, can we do anything helping start oil to really get value out of looking into master data from enterprise point of view. And it was very easy to find a business case for it. One simple example from the supply chain management. We saw that within the service center, the 85% of the incidents coming in was due to master data errors. And we also saw that almost every IT projects in start oil were asking for master data. Where are the source for licenses, well IDs, tag information, equipment lists and so on. And we did not have anything on enterprise level. So they asked why not. So the business case was very easy to establish. This is an example from the subsurface area showing. And what's typical in the oil business is that you buy applications. The mathematics within the domains are so specific that you make application for almost everything. So you end up with, I think Startle has about 3000 application in total. If you count the master data objects, it's not, we stopped counting when it came to 500. And as you see, from this example, within the subsurface, we have about 10 different domains where the people are working in, highly skilled personnel. We have lot of doing each activity. And we have about, in this case, 70 applications, 300 applications from 70 vendors, which has to be integrated somehow. And then we have to do it through master data. And some of the integration is done manually, some of it done half automatic, some automatic. But this is just show a part of the exploration part, how difficult it is to do master data work. So all of these parts of this picture asks for typically a well master. Where is the well master for Startle? Can we use this well master in feeding all these systems? So the challenge was very, very big. And we saw very soon that we were not able to handle everything. We had to take a top down approach, model the activities, and try to find out what is the most important master data to manage. I come back to some of the models later on. But the information volumes, as I started with, is so enormous that you have to focus and do the most important master data first, and then maybe take on some others later on. And we also have that problem. There is no single truth in this area. I often say that the people you're working with in this area are artists. They are not there for doing a specific job. They do their painting and the paintings do not look like. They typically do interpretations of the seismic data, the well data, and so on. So that personal opinion, and then you have to decide on a project opinion. And then at the end, they have to decide on a corporate understanding of the subsurface. But two years later on, they change their mind and then start over again. And then we need all these versions available all the time. So there's no single truth. You have to keep track of almost every personal truth or opinion all the time and maybe move away some of them during the time. Thank you. One of the point reasons why we've kind of got this point up here about aligning MDM initiatives with business projects and the field of dreams. You're familiar with the field of dreams movie? So what was the tagline? Build it and they will come. Now, who's ever been involved in a big kind of strategic program where the guys in IT have said, build it and they will come. They being the business. Come on and keep your hands up. And how many of those have worked? Yeah, that's my experience as well. So it simply doesn't work period and it certainly doesn't work in the economic climate that we're in these days that you can say this big master data initiative. So you know, it might be wells or geography or other kind of geographic locations, kind of refineries and tank farms and so on. Or kind of thinking your business customer, customer product vendors. We'll just put everything on pause for a couple of years and we'll come build this humongous master data solution into the governance and the data quality and the cleansing and then we'll drop the flag back to my racing analogies will drop the start flag, you know, gentlemen start your engines and you can carry on with your business. It just doesn't doesn't doesn't work. So that's kind of what the field of dreams stuff is about. So we have to make sure that we align MDM initiatives with business projects. Then you then you do have, you know, a Snowballs chance in hell of being able to do something. And that's actually so when we talked, you know, about this being an MDM model driven approach, it's actually slightly tongue in cheek. It's almost like a template. So we're going to talk about data models soon, but it's not just data models, it's model as in a model approach. So like a template based approach. But what this basically says is the stuff and not surprisingly, that's going to explode in a moment, but you have to have some lead business projects that you align this to because you are, you know, you're going to be dead in the water if you try and do this as some infrastructure activity that, you know, you're just doing that is not aligned to specific sets of business projects. I was fortunate enough to have worked in Cooper's and Library and then PWC for many, many years and now in IPL with a lot of our great clients like like stat oil, and it's the only way. I mean, it's the only way that we can actually get stuff to work deliver instead of being kind of five miles ahead of the business and trying to do stuff, you know, way, way ahead and saying we're coming up with all of the requirements. And of course, the world has moved on, just be two inches ahead of the business. That's enough. It might cost more over a 10 year or a five year period, but you're sure as heck, you're going to keep the business sponsors and the stakeholders engaged. And that's way better than any kind of fancy, you know, highfalutin idea that you can get it all perfect, you know, but we just got a pause for two or three years. So please, you know, if anybody wildly disagrees, you know, shout, I'm quite happy to go completely off peace and we'll have a discussion. But that's that's our experience. So when you drill down into the method, you know, into the model approach, this is, you know, these are the fundamental components of the model approach. And again, not surprisingly, there's a lot more detail behind them. And you know, by about the fourth hour, we'll start to, you know, start to have got into some, you know, some more of that detail. But we're going to show a couple of examples from some of the bits over here. But again, it's a, you know, by model, we mean like a template. But there's one other thing. Let me just go back. So number five, this module here that was called select MDM architecture and toolset. The big thing, you know, here to don't forget how many people have ever heard the expression, you know, it's the only way, you know, this is the only way. Yeah. Okay. I've heard that about lots of things. And I suspect over the next few days, you might be told with master data management systems, you'll hear the term a hub. You know, a hub is the way in which you create a master data solution. That's not actually true. So don't believe that is the only way. And this is this is one of the very few things that I could think of that is the only way, you know, nukes things from space. And that really is the only way you can be sure that you're not going to have any opposition. But if we're back to master data, it's not the only way. So we had an advert in Britain for quite a while at Christmas time. People who've got puppies and abandoned them. And they said a dog, a puppy is for life, not for Christmas. Did you guys did the Humane Society here have that? Okay. Yeah. Okay. So, you know, MDM quite often it's for, you know, it's for life. It's not just for Christmas and very, very importantly, get out of this now. Very importantly, a hub absolutely is not the only way. So in the one day version of this that sometimes we do, we go into these in a lot, you know, a lot of detail, but the six that I've got illustrated here and it's a mute point as to whether there's a seventh. So synchronized master, fairly obvious what that is that data that changes in any system, synchronization layer, or as we like to call it, magic, kind of makes these things, you know, you're all in sync. Then you've got the hub base master. Hooray, let's hear it for the hub. So the hub base master, pretty obvious, you know, all of the master data in the hub and then the operational systems publish and subscribe from the hub and again another kind of magic, bit of magic happens in between where it handles all of the, all of the conflicts and the clashes and which one gets precedence if we've both updated customer at the same time. So all of that stuff we're kind of all of the rules put in. There's very common with the big ERP systems, particularly that big three letter German ERP system where you might make your customer master in SAP as your designated master and then that gets synchronized across to other systems. So that's application specific master. Not so common these days, master overlay. So what that is is where you've bought industry specific data, a very easy example. Actually, no, it isn't that easy, but I'll tell you it anyway is country country code. So you can go and buy ISO, which one is it? Prize if you can remember ISO 3166, absolutely right. ISO 3166, two character and three character codes, but you guys of course in the US have to be different. So you've got, you've got the federal standard and then you've got kind of clashes between, there's about 10% of the records in ISO 3166 which now clash with stuff that's in the FIPS federal information processing standard because you've got stuff like occupied territories, Gaza, Western Sahara, which the US government doesn't recognize but is in ISO. So you have to then do your own mapping if you're going to do work in that. Okay, I know we've had to do that for assorted oil companies because of course they operate in those regions. So that's synchronized layer. This real-time data movement or I could have drawn that differently and put in an enterprise service bus, hopefully fairly, fairly obvious. And then kind of the new kid on the block, which is federated master data, so your data virtualization. So it's not a persisted master data solution. It's information that's pulled from the operational systems. Again, a new flavor of magic is put in but it's pulling the information in real time from the operational systems and presenting a virtual master data hub. The great thing about that type of solution is that if you're in a very tightly regulated environment, you don't have to physically move data from one solution to another. So if you've moved the data, quite often you would be subject to new regulation and compliance in multiple locations. Now there aren't multiple locations because it's this federated virtual approach. The mute point is whether some people kind of like to think of this as being almost like a registry approach. I haven't put the seventh one up, which would be registry and kind of pointers. Yes, sir? Yes. And you get an argument till the cows come home as to whether that's virtual or that's a registry service. Actually, I think they're two separate things but this isn't meant to be a five-hour debate on that. So how do these things work? Now, you know, we're not going to go into all of those in, you know, in phenomenal detail. But again, just level setting. Source systems, consuming systems, and the, you know, folks who have been down this path will realize, ooh, the consuming systems could also be source systems as well. Okay, so don't worry, that comes up in a moment. Master Data Environment. You've got some kind of roles and responsibilities such as data owners. You can have some form of metadata catalog, you know, to store models, definitions, enrich it with metadata. Thank you. Some processes to source the data, to put it into the bucket, whether it's a real bucket or a virtual bucket. Okay, so that's what your, you know, your best, or, you know, your least bad version is going to be. There'll be some other operations to standardize, deduplicate, maybe buy in information. So if you're looking at vendor master data, you'd be pulling in information perhaps from, you know, sources like Dunham Bradstreet and enriching that, you know, enriching your own data. Okay, the point about, so data distribution services, so those data distribution services could be, you know, real time, it could be ETL, it could be a virtualized, federated approach, you know, so you can actually virtualize from your data, from your physical or your virtualized warehouse out to the consuming systems. And this is my feeble attempt to kind of show that data distribution doesn't just go to the right to the consuming systems, but it goes back to these because these could be consuming systems as well as systems that source the master data. And a bunch of other roles and responsibilities around stewardship and so on because there may be things that need to be fixed in the data that are fixed outside of the operational systems themselves. So believe me, that was difficult to get in about three minutes. You know, people do kind of half day sessions just on the basic architectures of master data. Oh, yes, I've kind of these two yellow boxes that are going to come up just the examples of sourcing and distribution technologies. But one that I really wanted to show because very few people have actually done this. Has anybody used data virtualization at all for anything, let alone master data? Okay, it was me then. So you know, one of the other approaches is this virtual master data approach. So you could start with life where you have a traditional master data hub and you've got a whole bunch of source sourcing applications. But then a bunch of problems kind of come along, which is more sources are identified down here. Maybe you've acquired another company, there's been some kind of merger, a new set of requirements are going to appear. So you now need this, you know, there's much larger view of the master data. But it takes you a month and a day just to get your kind of new ETLs developed. So here's the new sources, you know, they could even be XML, you know, SOA services that you need to consume. So you can use this concept of a federated data virtualization layer, which picks up from both the existing master data hub, but also from the new sources in this federation layer and presents the data to the system. So you've got it presented to the original systems, and you've got it presented to your new systems as well, incredibly flexible, orders of magnitude quicker in terms of getting the time to the solution. Okay, and the ability for you then to later, if you want to, to put the and build the ETLs to have it persisted in a physical hub, you've got the option of doing that. You've got information out to the business. And certainly in a lot of the big energy companies, the ability to be able to build things very, very rapidly is a key factor. And the icing on the cake is that you can also then have the master data from the federation layer consumed by the source systems themselves. So question. Well, ask the business folks who actually need stuff delivered in the time that the traditional ETL approach can't deliver to them. Absolutely right. It's, it's time to solution is the key thing in this. Very often, you know, a lot of people kind of dis the TV, the data virtualization approach saying, oh, it can't possibly work or whatever it happens to be. It's not either or it's not ETL or change data capture or data virtualization. These are tools in your overall information integration armory. This gives you the ability to get something out quickly. And then you can take a decision as to whether you want to persist that later and put that into your physicalized, think of a better word than that, persisted data hub. Question over here. Okay. You can plug, you can plug a whole lot of business rules into the the TV layer. This isn't meant to be a talk about data virtualization. That was just a, that was a, you know, a kind of powerful, powerful approach. I'm happy to go on forever about that afterwards, but we need to get on to a bit more specific stuff. So we, at the beginning, we were saying, what about data models? And here's, you know, here's some of the stuff that were very specific to stat oil. So what role the data models play in this whole approach? It's time, time to stop Chris. We take the whole time. Because he could talk about data, data months or one hour. There's a list of why making data models here. And there's a lot of reasons. You can see them here. This is an example I will come back to you. It's a location master data at stat oil. And we use models to discuss with the business. What do you really mean about location? As you see here, everything is almost linked to everything. Location seems to be an easy one. But if you go into it, it's very difficult because you have geopolitical way of grouping it and you have geological way of grouping it and so on. So it's a very complex area to go into location. So we need models to discuss with the business. So we really understand what they are meaning with it and be able to agree on what you're going to do. That's one reason for communication purposes. And you may have seen a picture like this. I think the Dharma Diemburg has a similar picture showing the different types of models from enterprise data models on the top down to the physical data models at the bottom. And as I said, the communication focus is in focus when you make enterprise data models. That's why we make them at stat oil. We need something to discuss as a discussion to the business. So they understand what we are talking about and we understand what they need. And the physical data models, that's what we have done for ages at stat oil. That's the IT perspective of it. So we have been very good at this layer at stat oil for 20 to 30 years. But we have never had anything on the top of the pyramid until for two or three years ago. I think it was three years ago. I started looking into this area at stat oil. We need to establish an enterprise model to be able to link together all the processes I've talked about earlier on. Then I came across IPL at a conference in London. So I invited myself to bath. So I've been there. Since then we have been cooperating. They're giving us advice how to go on in this area. Because we saw they had some experience from the oil business from from before. That's important because it's it is a complex area. Take take times to learn how complex it is. You mentioned country codes. It sounds easy. But when we when you drill a well outside Scotland, it's a UK well. When we drill a well outside Greenland. It's not the Denmark well, it's a Greenland well. You need to know the difference between a country and the oil jurisdiction in the world. That's not always easy to understand. And the same if you drill a well outside Faroe Islands. It's not Denmark. It's Faroe Islands. So we I think we used one year to produce this picture of stat oil. We interviewed all processes at stat oil. What are your main information objects made this enterprise model. And these dark gray boxes is the process areas. And in this big green box is the core processes. At the bottom, we have the support processes. And on top, we have the corporate executive committee and the value chain, the capital value process. And when we have established this one, we say to each project at stat oil, be aligned to this model. Tell us where we are in this picture. You need to be aware of what you are doing unless you are not able to continue. And then we took it one step further. We made one model for each process area. This is typically in the exploration part. And as a side effect in the beginning was to identify all the master data objects. All the boxes in green, picture in green color, has some master data behind it. And then based on this information, we made an enterprise master data model on a corporate level like this. Again, used for communication with the business. And to go further on, we decided to do a pilot. And we ended up doing a location pilot. And then the discussions started. What do you mean with location? So you have to pick one specific part called validity area linked to the management system process. Which part of the company does this process document? Is it valid for? It's a very simple, seems to be very simple, but is it difficult? And we also used this one to decide how to proceed in the master data corporate project. And this is more about the pilot. I think this is one of Chris models. We saw very early in this location pilot, we had two big sources of stop oil, which was used very differently. So we decided to make a corporate view of the location object, which was going to be used by all other projects in the stock market. In other cases, we see that the original source is good enough and be used as the corporate hub for that object. But the pilot did not focus on testing tools. We decided to focus on testing roles, responsibilities, workflows, the process part of the activity. And that's hard enough. I think the technology is the easiest part. So how did we proceed? From the master data model, we picked out the most important ones. They are listed here. They are linked to the process areas at stock oil. And we have started, as I said, the location. We have done a lot of work with wells, with fields, the licenses, or I think in the US, it's called leases. And tags, in stock, we have about 6 million tags in our SIP system. And the quality is so and so. Costs us a lot of money because we may have things in the internal stock, but we do not know about it because it's named differently. But as you see, we are not a traditional master data company. It's not about employees, customers. As an oil company, we do not have customers. So, for example, yeah. And it's over to Chris again. Okay, thank you. So just in the last couple of minutes, I think we're going to overshoot by about two or three minutes. So if you can bear with me, that would be fine. This was one of the things we did, which was a master data maturity assessment. So it's kind of like the CMMI, but we've got one of these for each of the information management capabilities. It's in the handout, so I'm not going to go into any detail in that. But the key point is this master data management is just kind of one part of an entire information management framework. And so looking at the maturity model, what we just saw there, that's one bit. And these are all the things that you would expect to see. And the good news is they are in this. And this was the approach that we were following. But you've got all these things, principles and maturity and methodology and tools and templates. I mean here not an MDM toolset, I mean checklists and so on. If you like kind of consulting tools, you know, tools for the guys in the projects to follow. So there's some examples and we've got a few more examples in a moment. We're not going to do justice to it in the time. But the point was when we say a model driven approach, it's following the templated model. And the red bits here, just a couple of examples, you know, coming up of the types of things. So it's, you know, it's something that has, you know, a whole bunch of checkpoints, detailed steps, what the deliverables would be, the toolset, if you like the consulting toolset. Here's another one, you know, determining the master data business requirements. The point with all of this is you don't, you know, we didn't follow every single one of every single step, because, you know, there might have been 293 steps in there. The point is it gave the ability to be able to tailor that right up the front for the geographic master data in this business. So that was the approach there. And you can see, oops, you know, you can see all the things like kind of, you know, prerequisites, deliverables, toolset, et cetera. So this was, you know, a very good jumpstart, which is probably the best way of thinking. You can still do a project without having to have this kind of thing, but it gave a really good jumpstart. And of course, because there was, you know, pre-built business cases and so on, it helps there. And here's the other one, reviewing, you know, technical review options and that's part of the, you know, looking at the MDM tool sets that you might use. So what's the bottom line with the bottom line with all this? You saw in that, you know, the triangle showing the different information architecture framework components that master data was one of those. Up towards the top left was data governance. And at the very, very top was principles. But this stuff, you know, the bottom line, and this is a real key takeaway, all this stuff is only important if the information is really going to be considered as a corporate asset in your organization. If it only gets as far as being a statement on a PowerPoint screen and never gets turned into reality, forget everything that you said, you know, that Eldar and I have just been saying. This is really only important if it genuinely is a corporate business asset. Okay? And all too many organizations don't get it further than the PowerPoint. And please to say, yeah, Stato absolutely get it. They're committed to making sure information is treated as an asset. There's even a thing called the Statoil book, which covers the business processes and how the processes will use the data. There's a lot of art as well, which I don't do art. But, you know, it's one of the real key assets of the organization. So I think this is actually the last slide. Good. So, you know, key points here. Don't believe that you can do the field of dreams thing. Don't believe that you can just build it and they will come. Make sure that any project is aligned to, you know, one or more business projects. It's perfectly okay. In fact, more than okay, it's advisable to be that much ahead of the business, you know, an inch ahead of the business rather than trying to do the world domination, build it and they will come, giant, boil the ocean approach. So please don't go that way. Data models for MDM programs are absolutely essential. Out in the vendor's exhibition area, you're going to see a lot of tool sets. Being able to enrich your models with additional metadata is really valuable. You can put ownership, stewardship, data quality requirements. You can point to systems of record where this entity is. You know, you might have, if I go back to a non-stat oil example, you know, customer information might be in 27 source systems. That's fine. You can have your customer entity and you can point to those source systems. The models are utterly invaluable. So get a good modeling tool and enrich it with additional metadata. Governance is essential. There's a truism here that you cannot, it's this clear, you cannot do successful master data management programs without having done some data governance. You can do data governance and not have to go on to do master data, but you're doomed to failure. It's that clear. If you try and do master data management and you haven't got some of those governance considerations worked out for clashes, for consumers of data, for the business rules, when the data is sourced and consumed by multiple systems, then, you know, you're toast. And lastly, you know, beware the hype. You know, a hub is not the only way. It might be the most appropriate way in a number of circumstances, but for sure it's not the only way. And with that, we're a couple of minutes over. I should take one or two questions and then go. Oh, the final thing here is we were asked to put something up about what we do in our spare time. So Eldar climbs up mountains in the summer and skis down mountains in the winter. And I drive around motor racing circuits in that little toy. So that's it. Any question, to be perfectly honest, I think given that the time is up, come and call us and see us face to face. It's coffee break now. Thank you very much for your time. Thank you.