We're here at Wicked 2012 in Dubai, the United Arab Emirates, and I'm very pleased to be joined by Mr Nigel Hickson, who is Vice President for Europe for ICANN. Nigel, thank you very much for being with us today. Thank you. Thank you. I'd like to start off by talking about this conference. This conference has been attracting a lot of attention. ICANN is no stranger to controversy. You've got a new leadership. I wanted to find out for you if that's been introducing a new spirit of collaboration. Well, absolutely. I think a new leadership always introduces new opportunities, new ways of doing things. Fadi Jihadi, of course, has got an Arabic background. He's a global player in many ways, and he is very keen to engage ICANN on the global stage, and we're delighted to be at this ITU conference. He came and spoke here. What was the feedback from that? Yeah, very positive. It was a difficult decision to an extent. ICANN is an organisation involved in the internet governance space, and ITU has long traditions in terms of telecommunications. Of course, we have different views on various things, but we recognise each other in the work we do, and therefore we decided on the gracious invitation of Hamid and Tore that we ought to come along and embrace the ITU. There's often been seen as a clash between the internet and the traditional telephone community. Given that cohabitation is pretty much an inevitable outcome, do you see a summit like this as very much bringing together of both sides? Yeah, I don't really see it as two sides. The ITU has got a fundamental responsibility for telecommunications, and the telecommunications layer is absolutely essential to global connectivity, and of course the work that the ITU have done on spectrum and on development and on standards is absolutely crucial. ICANN play in a slightly different field in terms of the domain name system, but we clearly need to cooperate, and this conference is very important. The ITU Secretary General has been making a big push recently for greater multi-stakeholder partnership and involvement in events like these. Do you think that this is a positive development? Yes, absolutely. Clearly the involvement of all players in this space is just crucial. I work for the UK government for 29 years, and we never pretended we had all the answers. No government has all the answers, and therefore it seems absolutely totally sensible to involve other players in your decision making process, and I'm very glad that the ITU is going down that road. Clearly there's some way to go, but I think the involvement of the business community and I know the Secretary General has been very warmly reaching out to civil society. I mean they might not feel they have a full role, but I think this is a trend in the right direction. You've been recently involved in a big project involving top level domain names. How has that been going for you? Yes, this is the new generic top level domain program, so basically at the moment there's 22 generic top level domains, and we're expanding that considerably. There were 1,930 applications for new generic top level domains. At the end of the day, when they start coming into being sometime during next year, there probably won't be that many, but it will be a significant project. I'm glad you asked the question because it's significant being here talking about this, because the new program, especially in that it allows names of Arabic script, names in Russian script, in Cyrillic, in Indian script, Chinese script. It's an ideal way to globalise the internet. Finally, what do you hope will be the outcome of this conference? I hope we reach a result. I think we need to reach a result. The ITR is 1988. Come on, you know, they're out of date. We need to update them. We need to be able to show that the ITU is relevant, that it's fostering broadband access, that it's fostering competitive markets, that it's fostering security. I think there is a positive outcome of this. Nigel Hickson, thank you very much indeed for being here today. Thank you.


Lots of people have become used to tapping, swiping and scrolling to access information and entertainment. But how do these everyday devices work?  We barely bat an eye while scrolling through Instagram or retweeting something on Twitter. But how does putting a finger on your phone's screen to perform these tasks actually work? Let's explore that in this video. Now to begin with, we will look at the structure of a touchscreen display first, and then we will go into the physics of it and understand how does a phone actually recognize where are you touching the screen. It turns out that a touchscreen display is comprised of many layers. At the very top, we have the protective glass, which is chemically toughened. And smartphone glasses are over 5 times stronger than normal glass, and that's why the screen doesn't crack easily when you mistakenly drop it. We have the LCD screen at the bottom that produces the images that you see. And between the LCD screen and the toughened glass are several sheets. One of them, one of them, the top sheet is a sheet containing a grid of hair thin lines of a conductive metal and this conductive metal could be indium tin oxide or copper. And I have shown them as colored but these lines are transparent and of course they are many, many of such conductive lines on the top sheet. Below that there is an insulating layer. This is an insulating layer which separates the conductive lines at the top from this sheet that also has hair thin lines of a conductive metal. But in a direction perpendicular to the first one. Let's look at the structure of the top sheet and the bottom sheet more closely now. Each of the rows of the top sheet, they also have a metal plate attached to them and that is coated with a conductive material like copper or indium tin oxide. And similarly, each of each of the electrode in the bottom, in the bottom plate also has a metal plate attached to it. And there is a current flowing in the top sheet along these blue wires, these blue electrodes. The result of which there is some positive charge that is deposited on all of these plates. And when these two sheets are placed on top of the other, they form a grid like pattern which kind of looks like this. So we have this grid of tiny capacitors. Because there is a positive charge at the top plate, it induces a negative charge at the bottom plate of the capacitor and with no external disturbance whatsoever that charge is maintained constant by the phone's battery. Now over here you see around 35 capacitors but on your phone screen you have around 1500 rows. So you can imagine the number of capacitors that are there on your touch screen display. Now let's pick any one of these capacitors and look at it more closely. So we have the positive plate at the top and the negative plate at the bottom. Since there is charge on both of these plates, there are electrostatic field lines which go from the positive end to the negative end. And these fields aren't getting disturbed because there is nothing that is disturbing them. The phone's battery is maintaining a constant charge on both of the plates and the electric field is also maintained with no disturbance whatsoever. And now comes the interesting part. Let's say we bring a conductive material like a finger, something conductive like a finger close to close to one of these capacitors. While you pause the video at this point and think about will the presence of a conductive material like a finger, will it affect the electric field in any way or will there be no effect? Pause the video and think about it. Alright hopefully you have given this a thought. Now human body is about 60% water and pure water is an insulator but the water that is inside of us is impure. It is loaded with ions, atoms or molecules that have a net electric charge. And the presence of these charges changes or distorts the electrostatic field that was present between the capacitors. And now the field lines look like this. It is as if your finger is stealing away some of the electric field lines from the capacitor. Now the electric field strength has decreased slightly. And we know that electric field strength is just this is equal to V by D, the potential difference between the plates divided by the separation between them. So if the electric field strength decreases even the potential, the potential decreases. This drop in potential is detected by the sensor and then the sensor pinpoints that location that particular location where the voltage has been dropped. And that is how basically a touch screen display works. Now there are a couple of things that you might have experienced something like if there are water droplets on your touch screen, your touch screen starts behaving very randomly as if you have touched at multiple locations on the screen. That is because presence of water distorts electric field at many, many of these capacitors and the sensor detects all of those changes in the electrostatic field sends that signal to the processor. So your phone ends up doing multiple things at once. Maybe opening multiple apps all altogether. And on the other hand, if you're wearing gloves, you might have experienced that you aren't able to operate at a screen. That is because the fabric of the glove is an insulator. So when you bring your finger close to the screen, there is no change in the electrostatic field and there is no voltage drop and nothing is detected by the sensor. Now the touch screen displays that are used these days. They do not really use this grid like pattern that you see on the screen because there are a couple of disadvantages which are associated with this. So one of them is that this pattern starts becoming visible because you have two layers on top of each other compared to one transparent layer which is which might do the job. Now you have another transparent layer beneath that. So the pattern starts becoming visible slightly and that is not the goal. The goal is to make it completely transparent so that the images that are formed on the LCD are clearly visible. And secondly, the electric field is inconsistent. That is because you have these capacitors and the electric field is strongest in between these plates and there are these spaces around and between the capacitors where the electric field is not as strong as it would have been between the plates of the capacitor. So when you bring your finger closer to a capacitor, there is not enough distortion of the electrostatic field and there is not enough drop in the voltage for the sensor to detect it. So there needs to be some change to the design of how the grid is formed. And turns out there is one grid that is followed these days. Let me make some space. That pattern is called a diamond pattern. Now over here, the plates are not on top of each other. They are shifted slightly. You can imagine that the top sheet has been shifted slightly to the right and the bottom sheet is where it is. So as a result of which the plates are not on top of each other, but the plates kind of look like this. And there is an advantage to this because now your electric field lines, which could look like this, your electric field lines are not localized or not concentrated in one particular space. They are more spread out in the space so that when you bring your finger closer to the plates, you get a proper distortion of the electrostatic field which is then detected by the sensor and the location is registered by the processor. So this is the technology that mostly is followed right now on the screen. And the basic principle still remains the same, which is that bringing in a conductive material closer to the capacitor changes the electrostatic field, which then lowers the potential or there is a voltage drop that is detected by the sensor and that particular location is pinpointed and registered.


Hello everyone, this is Ahmed Abdul-Majid from Egypt and based in Saudi Arabia right now. I had a teaching experience in elementary schools in Egypt and as a project trainer for a multinational company in Gulf. And since teaching has always been my first passion, I wanted to continue my professional development with a well-known and renowned entity. Searching for many entities, universities and institutes, ITTT seemed to be the most accredited and trusted entity. I wanted to study and continue my professional development while I am working right now. So I have chosen the TISL Antifil course provided by ITTT and it was a very successful choice because the content is so rich. They will give you the hands-on expertise and tips, techniques, methodologies that you need to be a successful teacher. Either you're working in a government school, language school or an international school. They will provide you with proper materials, full explanation, real experience from a real class teaching environment and also with videos that will help you to better understand all the content. So the content is so inclusive that you're going to be very comfortable in understanding each topic and with the video support. Second point, we come to the assessment. Assessment is there to assist your understanding. It's not assisting you how much you memorize. It's not about the classical way of learning. It's about a smart way of learning how much you understood out of the content and how much are you able to implement them. So before going into the assessment, I urge you, I advise you to read the content carefully, understand it. If you need any help, just ask the tutor if you have chosen that option. So having said that, that means you are in safe hand. You're going to be supported. You're going to be provided with the proper materials, expertise and also you're going to be very well assessed. That means you are accredited because ITTT is independently accredited. So you need to be sure that you earn the certificate. I'm sure you're going to earn it. I'm sure you're going to enjoy it and all the best to all of you. It's a good choice. It's priceless. Thank you so much for watching.


You. Hello, baby. Miss me? Miss putting my fist in your face. Sonia Blade. Following in her father's footsteps, Sonia joined the United States Marines. Her impulsiveness, combat skills, and loyalty earned her respect and admiration from those she served with. Now, General Blade of Earthrealm Special Forces is a beautiful, stern leader and fiercely agile combatant. Armed with drones, demolition grenades, plus the experience of being married to a movie star and raising a teenager, Sonia strives to defend Earthrealm and her family. Let's call it enhanced training. In the Special Forces variation, Sonia calls down a drone to give her new special attacks. Unlike other special moves, Sonia must finish her combo strings before the drone can be given commands. Look for combo strings with lots of hit advantage for Sonia to call down a strike.  For kamikaze, 4 plus block, to launch your opponent.  I'm going to beat some respect out of you. In the covert ops variation, Sonia exercises her combat prowess with military stance, down back, too. Canceling Sonia's combo strings early into military stance grab will result in a tick throw, a concept we learned about in a previous lesson with Jax. After a double kick juggle, use American Way, 2, 1, up, 4, to help carry your opponent to the corner, or with military stance grab for extra damage. Practice cancelling your stance as well. This will bait out hasty reversals from your opponent that can be punished with a parry. Dead or alive, take your pick. In the demolition variation, Sonia equips three grenades. Using negative edge in the controller options gives Sonia a unique advantage on the battlefield, allowing her to throw, detonate, or reload grenades with a single input. To practice this, open up your opponent and manually detonate the first grenade behind their head. Quickly throw a second grenade. As Sonia recovers, throw the third grenade close to you and hold down one. Then push four, down, down, and release one, causing Sonia to detonate the third grenade and reload at the same time. And your combos would beat down to give ample time to reload. Sonia combines gymnastic mobility with a strong mix of potential. Each variation gives her tools to cover any gaps in her offense. Alternate between a high pressure play style with a strong defense to ensure you have all of your tools at the ready. Show what happens when you mess with Texas with an X-ray parry. Scar your opponent for life with a brutality. Spoiler alert. You lose. Sonia wins.


From theCUBE Studios in Palo Alto in Boston, bringing you data-driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vellante. Data Mesh is a new way of thinking about how to use data to create organizational value. Leading edge practitioners are beginning to implement Data Mesh in earnest. And importantly, Data Mesh is not a single tool or rigid reference architecture, if you will rather. It's an architectural and organizational model that's really designed to address the shortcomings of decades of data challenges and failures, many of which we've talked about in theCUBE. As important by the way, it's a new way to think about how to leverage data at scale across an organization and across ecosystems. Data Mesh in our view will become the defining paradigm for the next generation of data excellence. Hello and welcome to this week's Wikibon Cube Insights, powered by ETR. In this Breaking Analysis, we welcome the founder and creator of Data Mesh author, thought leader, technologist, Jamak Deghani. Jamak, thank you for joining us today. Good to see you. Hi, Dave, it's great to be here. All right, real quick, let's talk about what we're going to cover. I'll introduce or reintroduce you to Jamak. She joined us earlier this year in our Cube on Cloud program. She's the director of emerging tech at ThoughtWorks North America and the thought leader, practitioner, software engineer, architect and a passionate advocate for decentralized technology solutions and data architectures. And Jamak, since we last had you on as a guest, which was less than a year ago, I think you've written two books in your spare time, one on Data Mesh and another called Software Architecture, the hard parts, both published by O'Reilly. So how are you? You've been busy? I've been busy, yes. Good, it's been a great year. It's been a busy year. I'm looking forward to the end of the year and the end of these two books. But it's great to be back and speaking with you. Well, you got to be pleased with the momentum that Data Mesh has. And let's just jump back to the agenda for a bit and get that out of the way. We're going to set the stage by sharing some ETR data, our partner, our data partner on the spending profile and some of the key data sectors. And then we're going to review the four key principles of Data Mesh. Just it's always worthwhile to sort of set that framework. We'll talk a little bit about some of the dependencies and the data flows, and we're really going to dig today into principle number three and to bid around the self-service data platforms. And to that end, we're going to talk about some of the learnings that Shamak has captured since she embarked on the Data Mesh journey with her colleagues and her clients. And we specifically want to talk about some of the successful models for building the Data Mesh experience. And then we're going to hit on some practical advice and we'll wrap with some thought exercises, maybe a little tongue in cheek, some of the community questions that we get. So the first thing I want to do, we'll just get this out of the way, is introduce the spending climate. We use this XY chart to do this. We do this all the time. It shows the spending profiles in the ETR dataset for some of the more data related sectors of the ETR taxonomy. They dropped their October data last Friday. So I'm using the July survey here. We'll get into the October survey in future weeks, but about 1500 respondents. I don't see a dramatic change coming in the October survey, the Y axis is net score or spending momentum. The horizontal axis is market share or presence in the dataset and that red line, that 40%. Anything over that we consider elevated. So for the past eight quarters or so, we've seen machine learning slash AI, RPA containers and cloud is the four areas where CIOs and technology buyers have shown the highest net scores. And as we've said, what's so impressive for cloud, this is both pervasive and it shows high velocity from a spending standpoint. And we plotted the three other data related areas, database, EDW, analytics, BI and big data and storage. The first two well under the red line are still elevated. The storage market continues to kind of plot along and we've plotted the outsourced IT just to balance it out for context. That's an area that's not so hot right now. So I just want to point out that these areas AI automation containers and cloud, they're all relevant to data and their fundamental building blocks of data architectures as are the two that are directly related to database and analytics and of course storage. So it just gives you a picture of the spending sector. So I wanted to share this slide, Jamak, that you presented in your webinar, I love this. It's a taxonomy put together by Matt Turk, who's a VC and he called this the mad landscape machine learning and AI and data. And Jamak, the key point here is there's no lack of tooling. You've made the data mesh concept sort of tools agnostic. It's not like we need more tools to succeed in data mesh, right? Absolutely agree, I think we have plenty of tools. I think what's missing is a meta architecture that defines a landscape in a way that it's in step with organizational growth and then defines that meta architecture in a way that these tools can actually interoperable, interoperate and integrate really well. The clients right now have a lot of challenges in terms of picking the right tool. Regardless of the technology, they go down the path. Either they have to go in and bite into a big data solution and then try to fit the other integrated solutions around it or as you see, go to that menu of large list of applications and spend a lot of time trying to kind of integrate and stitch this tooling together. So I'm hoping that data mesh creates that kind of meta architecture for tools to interoperate and plug in. And I think our conversation today around self-serve data platform hopefully illuminate that. Yeah, we'll definitely circle back because that's one of the questions we get all the time from the community. Okay, let's review the four main principles of data mesh for those who might not be familiar with it and those who are, it's worth reviewing. Jamak, allow me to introduce them and then we can discuss a bit. So a big frustration I hear constantly from practitioners is that the data teams don't have domain context. The data team is separated from the lines of business and as a result, they have to constantly context switch and as such, there's a lack of alignment. So principle number one is focused on putting end-to-end data ownership in the hands of the domain or what I would call the business lines. The second principle is data as a product which does cause people's brains to hurt sometimes but it's a key component. And if you start sort of thinking about it and talking to people who have done it it actually makes a lot of sense. And this leads to principle number three which is a self-serve data infrastructure which we're going to drill into quite a bit today. And then the question we always get is when we introduce data mesh is how to enforce governance in a federated model. So let me bring up a more detailed slide, Jamak, with the dependencies and ask you to comment, please. Sure, as you said, really the root cause we're trying to address is the siloing of the data external to where the action happens, where the data gets produced, where the data needs to be shared, where the data gets used, right? In the context of the business. So it's about the really the root cause of the centralization gets addressed by distribution of the accountability end-to-end back to the domains. And these domains, distribution of accountability, technical accountability to the domains have already happened. In the last decade or so, we saw the transition from one general IT addressing all of the needs of the organization to technology groups within the IT or even outside of the IT, aligning themselves to build the applications and services that the different business units need. So what data mesh does, it just extends that model and say, okay, we're aligning business with the tech and data now, right? So both application of the data in ML or inside generation in the domains related to the domains needs, as well as sharing the data that the domains are generating with the rest of the organization. But the moment you do that, then you have to solve other problems that may arise. And that gives birth to the second principle, which is about data as a product, as a way of preventing data siloing happening within the domain. So changing the focus of the domains that are now producing data from, I'm just going to create that data I collect for myself and that's satisfying my needs to, in fact, the responsibility of domain is to share the data as a product with all of the wonderful characteristics that a product has. And I think that leads to really interesting architectural and technical implications of what actually constitutes data as a product and we can have a separate conversation. But once you do that, then that's the point in the conversation that CIO says, well, how do I even manage the cost of operation if I decentralize building and sharing data to my technical teams, to my application teams, do I need to go and hire another hundred data engineers? And I think that's the role of a self-serve data platform in a way that it enables and empowers generalist technologies that we already have in the technical domains. The majority population of our developers these days, right? So the data platform attempts to mobilize the generalist technologies to become data producers, to become data consumers and really rethink what tools these people need. And the last principle, so the data platform is really to giving autonomy to domain teams and empowering them and reducing the cost of ownership of the data products. And finally, as you mentioned, the question around, how do I still assure that these different data products are interoperable, are secure, respecting privacy? Now, in a decentralized fashion, right? When we are respecting the sovereignty or the domain ownership of each domain, and that leads to this idea of both from operational model, applying some sort of a federation where the domain owners are accountable for interoperability of their data product. They have incentives that are aligned with global harmony of the data mesh, as well as from the technology perspective, thinking about this data as a product with a new lens, with a lens that all of those policies that need to be respected by these data products, such as privacy, such as confidentiality, can we encode these policies as computational executable units and encode them in every data product so that we get automation, we get governance through automation. So that's the relationship, the complex relationship between the four principles. Yeah, thank you for that. I mean, it's just a couple of points. There's so many important points in there, but the idea of the silos and the data as a product, sort of breaking down those cells, because if you have a product and you want to sell more of it, you make it discoverable. And as a P&L manager, you put it out there. You want to share it as opposed to hide it. And then this idea of managing the cost, number three, where people say, well, it's centralized and you can be more efficient, but that essentially was the failure. And your other point, related point, is generalist versus specialist. This is kind of one of the failures of Hadoop, was you had these hyper-specialist roles emerge, and so you couldn't scale. And so let's talk about the goals of Datamesh for a moment. You've said that the objective is to exchange, you call it a new unit of value between data producers and data consumers. And that unit of value is a data product. And you've stated that a goal is to lower the cognitive load on our brains. I love this and simplify the way in which data are presented to both producers and consumers. And doing so in a self-serve manner, that eliminates the tapping on the shoulders or emails or raising tickets. So I'm trying to understand how data should be used, et cetera. So please explain why this is so important and how you've seen organizations reduce the friction across the data flows and the interconnectedness of things like data products across the company. Yeah, I mean, this is important. As you mentioned, initially when this whole idea of a data-driven innovation came to exist and we needed all sorts of technology stacks, we centralized creation of the data and usage of the data. And that's okay when you first get started where the expertise and knowledge is not yet diffused and it's only the privilege of a very few people in the organization. But as we move to a data-driven innovation cycle in the organization, as we learn how data can unlock new programs, new models of experience, new products, then it's really, really important, as you mentioned, to get the consumers and producers talk to each other directly without the broker in the middle. Because even though that having that centralized broker could be a cost-effective model, but if we include the cost of missed opportunity for something that we could have innovated, but we missed that opportunity because of months of looking for the right data, then that cost-benefit parameters and formula changes. So to have that innovation really embedded, data-driven innovation embedded into every domain, every team, we need to enable a model where the producer can directly peer-to-peer discover the data, use it, understand it, and use it. So the litmus test for that would be going from a hypothesis that as a data scientist, I think there is a pattern and there is an insight in the customer behavior that even though if I have access to all of the different informations about the customer, all of the different touch points, I might be able to discover that pattern and personalize the experience of my customer. The litmus test is going from that hypothesis to finding all of the different sources, be able to understand them, be able to connect them, and then turn them into training of my machine learning and the rest is known as an intelligent product. Got it, thank you. So a lot of what we do here in Breaking It Houses is we try to curate and then point people to new resources. So we will have some additional resources because this is not superficial what you and your colleagues in the community are creating. But so I do want to curate some of the other material that you had. So if I bring up this next chart, the left-hand side is a curated description both sides of your observations of most of the monolithic data platforms. They're optimized for control, they serve a centralized team that has hyper-specialized roles as we talked about. The operational stacks are running enterprise software, they're on Kubernetes and the microservices are isolated from let's say the Spark clusters, which are managing the analytical data, et cetera. Whereas the data mesh proposes much greater autonomy and the management of code and data pipelines and policy as independent entities versus a single unit. And you've made the point we have to enable generalists to borrow from so many other examples in the industry. So it's an architecture based on decentralized thinking that can really be applied to any domain, really domain agnostic in a way. Yes, and I think if I pick one key point from that diagram is really or that comparison is the data platforms or the platform capabilities need to present a continuous experience from an application developer building an application that generates some data. Let's say I have an e-commerce application that generates some data to the data product that now presents and shares that data as temporal immutable facts that can be used for analytics to the data scientist that uses that data to personalize the experience to the deployment of that ML model now back to that e-commerce application. So if you really look at this continuous journey, the walls between these separate platforms that we have built needs to come down. The platforms underneath that generate, that support the operational systems versus support the data platforms versus supporting the ML models, they need to kind of play really nice together because as a user, I'll probably fall off the cliff every time I go through these stages of this value stream. So then the interoperability of our data solutions and operational solutions need to increase drastically because so far we've got away with running operational systems and application on one end of the organization, running and data analytics in another and build a spaghetti pipeline to connect them together. Neither of the end are happy. I hear from data scientist, data analyst pointing finger at the application developer saying, you're not developing your database the right way and application point dipping you're saying, my database is for running my application. It wasn't designed for sharing analytical data. So we've got to really, what data mesh as a mesh tries to do is bring these two world together closer because and then the platform itself has to come closer and turn into a continuous set of services and capabilities as opposed to this disjointed big isolated stacks. Very powerful observations there. So we want to dig a little bit deeper into the platform, Jamak and have you explain your thinking here because it's everybody always goes to the platform. What do I do with the infrastructure? So you've stressed the importance of interfaces, the entries to and the exits from the platform. And you've said, you use a particular parlance to describe it. And in this chart, you kind of shows what you call the planes, not layers, the planes of the platform. It's complicated with a lot of connection points. So please explain these planes and how they fit together. Sure. I mean, there was a really good point that you started Dave with that when we think about capabilities that enables build of our application, builds of our data products, build that analytical solutions, usually we jump too quickly to the deep end of the actual implementation of these technologies. Do I need to go buy a data catalog or do I need some sort of a warehouse storage? And what I'm trying to kind of elevate us up and out is to force us to think about interfaces and APIs, the experiences that the platform needs to provide to run this secure safe trustworthy, performant mesh of data products. And if you focus on then the interfaces, the implementation underneath can swap out, right? So you can swap one for the other over time. So that's the purpose of like having those lollipops and focusing and emphasizing what is the interface that provides us such a capability like the storage, like the data product lifecycle management and so on. The purpose of the planes, the mesh experience plane data product experience to the plane is really giving us a language to classify different set of interfaces and dedicated capabilities that play nicely together to provide that cohesive journey of a data product developer, data consumer. So then the three planes are really around, okay, at the bottom layer, we have a lot of utilities. We have that Mac Terps, you know, kind of Mac data tooling chart. So we have a lot of utilities right now, they manage workflow management, you know, they do data processing, you know, you've got your spark link, you've got your storage, you've got your late storage, you've got your time series of storage, you've got a lot of tooling at that level. But the layer that we kind of need to imagine and build today we don't buy yet as long as I know is this layer that allows us to exchange that unit of value, right? To build and manage these data products. So the language and the API is an interface of this product, this product experience plane is not, oh, I need this storage or I need that, you know, workflow processing, is that I have a data product, it needs to deliver certain types of data. So I need to be able to model my data. It needs to, as part of this data product, I need to write some processing code that keeps this data constantly alive because it's receiving, you know, upstream, let's say user interactions with the websites and generating the profile of my users. So I need to be able to write that, I need to serve the data, I need to keep the data alive and I need to provide a set of SLOs and guarantees for my data so that good documentation, so that someone who comes to the data product knows what's the cadence of refresh, what's the retention of the data and a lot of other SLOs that I need to provide. And finally, I need to be able to enforce and guarantee certain policies in terms of access control, privacy, encryption and so on. So as a data product developer, I just work with this unit, a complete autonomous self-contained unit and the platform should give me ways of provisioning this unit and testing this unit and so on. That's why kind of I emphasize on the experience. And of course, we're not dealing with one or two data product, we're dealing with a mesh of data products. So at the kind of mesh level experience, we need a set of capabilities and interfaces to be able to search the mesh for the right data, to be able to explore the knowledge graph that emerges from this interconnection of data products and need to be able to observe the mesh for any anomalies. Did we create one of these giant master data products that all the data goes into and all the data comes out of? Have we found ourselves a bottleneck? So be able to kind of do those level mesh level capabilities we need to have access in level of APIs and interfaces. And once we decide what constitutes that to satisfy this mesh experience, then we can step back and say, okay, now what sort of a tool do I need to be able to buy to satisfy them? And that's, that is not what the data community or data part of our organizations used to. I think traditionally we're very comfortable with buying a tool and then changing the way we work to serve the tool. And this is slightly inverse to that model that we might be comfortable with. Right, and pragmatists will tell you people who've implemented data mesh, they'll tell you they spent a lot of time figuring out data as a product and the definitions there, the organizational, the getting domain experts to actually own the data and they will tell you, look, technology will come and go. And so to your point, if you have those lollipops and those interfaces, you'll be able to evolve because we know one thing's for sure in this business technology is going to change. So you had some practical advice and I wanted to discuss that for those that are thinking about data mesh. I scraped this slide from your presentation that you made. And by the way, we'll put links in there. Your colleague Emily, who I believe is a data scientist, had some really great points there as well that practitioners should dig into. But you made a couple of points that I'd like you to summarize. And to me, the big takeaway was, it's not a one and done. This is not a 60 day project, it's a journey. And I know that's kind of cliche, but it's so very true here. Yes. This was a few starting points for people who are embarking on building or buying the platform that enables the mesh creation. So it was a bit of a focus on kind of the platform angle. And I think the first one is what we just discussed. Instead of thinking about mechanisms that you're building, think about the experiences that you're enabling, identify who are the people. What is the persona of data scientist? I mean, data scientist has a wide range of personas or data product developer the same. What is the persona I need to develop today or enable and empower today? What skills do they have? And so thinking about experiences with mechanisms, I think we are at this really magical point.  So let's take that opportunity and use a bit of a creativity while being pragmatic. Of course, we need solutions today or yesterday, but to still think about the experiences, not mechanisms that you need to buy. So that was kind of the first step. And the nice thing about that is that there is an evolutionary, there's an iterative path to maturity of your data mesh. I mean, if you start with thinking about, okay, which are the initial use cases I need to enable? What are the data products that those use cases depend on that we need to unlock? And what is the persona of my general skill set of my data product developer? What are the interfaces I need to enable? You can start with the simplest possible platform for your first two use cases. And then think about, okay, the next set of data developers, they have a different set of needs. Maybe today I just enable the SQL-like querying of the data. Tomorrow I enable the data scientist, file-based access of the data. The day after I enable the streaming aspect. So have this evolutionary kind of path ahead of you. And don't think that you have to start with building out everything. I mean, one of the things we've done is taking this harvesting approach that you work collaboratively with those technical cross-functional domains that are building the data products and see how they are using those utilities and harvesting what they are building as the solutions for themselves back into the platform. But at the end of the day, we have to think about mobilization of the largest population of technologies we have. We have to think about diffusing the technology and making it available and accessible by the generous technologies. And we've come a long way. Like we've gone through these sort of paradigm shifts in terms of mobile development, in terms of functional programming, in terms of cloud operation. It's not that we are struggling with learning something new, but we have to learn something that works nicely with the rest of the tooling that we have in our toolbox right now. So again, put that generalist as one of your center personas, not the only person. Of course, we will have specialists. Of course, we will always have data scientist specialists, but any problem that can be solved as a general kind of engineering problem. And I think there's a lot of aspects of data mesh that can be just a simple engineering problem. Let's approach it that way and then create the tooling to empower those generalists. Great, thank you. So listen, I've been around a long time. And so as an analyst, I've seen many waves. And we often say language matters. And so I mean, I've seen it with the mainframe language. It was different than the PC language. It was different than internet, different than cloud, different than big data, et cetera, et cetera. So we have to evolve our language. So I was going to throw a couple of things out here. I often say data is not the new oil because data doesn't live by the laws of scarcity. We're not running out of data. But I get the analogy, it's powerful, it powered the industrial economy, but it's bigger than that. What do you feel? What do you think when you hear the data is the new oil? Yeah, I don't respond to those data as the gold or oil or whatever scarce resource because as you said, it evokes a very different emotion. It doesn't evoke the emotion of, I want to use this, I want to utilize it. It feels like I need to kind of hide it and collect it and keep it to myself and not share it with anyone. It doesn't evoke that emotion of sharing. I really do think that data, and I, with a little asterisk, and I think the definition of data changes. And that's why I keep using the language of data product or data quantum. Data becomes the most important essential element of existence of computation. What do I mean by that? I mean that a lot of applications that we have written so far are based on logic, imperative logic. If this happens, do that and else do the other. And we're moving to a world where those applications generating data that we then look at and the data that's generated becomes the source, the patterns that we can exploit to build our applications. I mean, curate the weekly playlist for Dave every Monday based on what he has listened to and other people has listened to based on his profile. So we're moving to the world that it's not so much about applications using the data necessarily to run their businesses that data is really truly, is the foundation of building block for the applications of the future. And then I think in that, we need to rethink the definition of the data. And maybe that's for a different conversation, but that's, I really think we have to converge the processing that the data together, the substance and the processing together to have a unit that is a composable reusable trustworthy. And that's the idea behind that kind of data product as an atomic units of what we build for future solutions. Got it. Now, something else that I heard you say or read that really struck me because it's another sort of often stated phrase which is data is our most valuable asset. And you push back a little bit on that when you hear people call data an asset, people said, often have said they think data should be or will eventually be listed as an asset on the balance sheet. And in hearing what you said, I thought about that and said, well, you know, maybe data as a product, that's an income statement thing. That's generating revenue or it's cutting costs. It's not necessarily, because I don't share my assets with people. I don't make them discoverable. That's a color to this discussion. So I think it's actually interesting you mentioned that because I read there a new policy in China that see it was actually have a line item around the data that they capture. We don't have to go to the political conversation around authoritarian of collecting data and the power that creates and the society that leads to, but that aside, that big conversation, little conversation aside, I think you're right. I mean, the data as an asset generates a different behavior. It creates different performance metrics that we would measure. I mean, before conversation around data mesh came to, you know, kind of exist, we were measuring the success of our data teams by the terabytes of data that we're collecting by the thousands of tables that they had, you know, stamped as golden data. None of that leads to necessarily, there's no direct line I can see between that and actually the value that data generated. But if we invert that, so that's why I think it's rather harmful because it leads to the wrong measures, metrics to measure for success. So if you invert that to a bit of a product thinking or something that you share to delight the experience of users, your measures are very different. Your measures are the happiness of the user, they decrease lead time for them to actually use and get value out of it. They're, you know, the growth of the population of the users. So it works a very different kind of behavior and success metrics. I do say, if I may, that I probably come back and regret the choice of word around product one day because of the monetization aspect of it, but maybe there is a better word to use, but that's the best I think we can use at this point in time. Why do you say that, Jamak? Because it's too directly related to monetization. That has a negative connotation or it might not apply in things like healthcare or? I think because if we want to take a short cut and I remember this conversation years back that people think that the reason to, you know, kind of collect data or have data so that we can sell it. You know, it's just the monetization of the data and then we have this idea of the data market places and so on. And I think that is actually the least valuable, you know, outcome that we can get from thinking about data as a product that directs sell an exchange of data as a monetary exchange of value. So I think that might redirect our attention to something that really matters, which is enabling using data for generating ultimately value for people, for the customers, for the organizations, for the partners as opposed to thinking about it as a unit of exchange for money. I love data as a product. I think your instinct was right on. And I think I'm glad you brought that up because I think people misunderstood, you know, in the last decade, data, selling data directly. But really what you're talking about is using data as an ingredient to actually build a product that has value. And value either is generate revenue, cut cost or help with a mission like this could be saving lives but in some way for a commercial company, it's about the bottom line. And that's just the way it is. So I love data as a product. So I think it's going to stick. So one of the other things that struck me in one of your webinars was one of the Q and A, one of the questions was, can I finally get rid of my data warehouse? So I want to talk about the data warehouse, the data lake, JPMC use that term, the data lake, which some people don't like. I know John Furrier, my business partner doesn't like that term, but the data hub. And one of the things I've learned from sort of observing your work is that whether it's a data lake, a data warehouse, data hub, data, whatever, it should be a discoverable node on the mesh. It really doesn't matter the technology. What are your thoughts on that? Yeah, I think that the really shift is from a centralized data warehouse to data warehouse where it fits. So I think if you just cross that centralized piece, we are all in agreement that data warehousing provides, interesting capabilities that are still required, perhaps as an edge node of the mesh that is optimizing for certain queries, I say financial reporting, and we still want to direct a fair bit of data into a node that is just for those financial reportings and it requires the precision and the speed of operation that the warehouse technology provides. So I think definitely that technology has a place where it falls apart is when you want to have a warehouse to rule all of your data and model, canonically model your data, because you have to put so much energy into kind of try to harness this model and create this very complex, the complex and fragile snowflake schemas and so on that that's all you do, you spend energy against the entropy of your organization to try to get your arms around this model and the model is constantly out of step with what's happening in reality because reality of the business is moving faster than our ability to model everything into one canonical representation. And I think that's the one we need to challenge not necessarily application of data warehouse on a node. I want to close by coming back to the issues of standards. You've specifically envisioned data mesh to be technology agnostic as I said before and of course everyone myself included we're going to run a vendors technology platform through a data mesh filter. The reality is per the Matt Turk chart we showed earlier there are lots of technologies that can be nodes within the data mesh or facilitate data sharing or governance, et cetera but there's clearly a lack of standardization I'm sometimes skeptical that the vendor community will drive this but maybe like Kubernetes, Google or some other internet giant is going to contribute something to open source that addresses this problem but talk a little bit more about your thoughts on standardization, what kinds of standards are needed and where do you think they'll come from? Sure, I mean, you're right that the vendors are not today incentivized to create those open standards because majority of the, not all of them but some vendors operational model is about bring your data to my platform and then bring your computation to me and all will be great. And that will be great for a portion of the clients and portion of environments where that complexity we're talking about doesn't exist. So we need, yes, other players perhaps maybe some of the cloud providers or people that are more incentivized to open their platform in a way for data sharing. So as a starting point, I think standardization around data sharing. So if you look at the spectrum right now we have a de facto standard it's not even a standard for something like SQL I mean, everybody's bastardized SQL and extended it with so many things that I don't even know what the standard SQL is anymore but we have that for some form of a querying but beyond that I know for example folks at Databricks to start to create some standards around the Delta sharing and sharing the data in different models. So I think data sharing as a concept the same way that APIs were about capability sharing. So we need to have the data APIs or analytical data APIs and data sharing extended to go beyond simply SQL or languages like that. I think we need standards around computational policies. So this is again something that is formulating in the operational world. We have a few standards around how do you articulate access control? How do you identify the agents who are trying to access with different authentication mechanism? We need to bring some of those our data specific articulation of policies something as simple as identity management across different technologies is nonexistent. So if you want to secure your data across three different technologies there is no common way of saying who's the agent that is acting to access the data? Can I authenticate and authorize them? So those are some of the very basic building blocks and then the gravy on top would be new standards around enriched kind of semantic modeling of the data. So we have a common language to describe the semantic of the data in different nodes and then relationship between them. We have prior work with RDF and folks that we're focused on I guess linking data across the web with the kind of the data web I guess worked out we had in the past we need to revisit those and see their practicality in the enterprise context. So data modeling and rich language for data semantic modeling and data connectivity most importantly I think those are some of the items on my wish list. That's good. Well, we'll do our part to try to keep the standards push that movement. Jamak we're going to leave it there. So grateful to have you come on to theCUBE really appreciate your time. It's just always a pleasure. You're such a clear thinker. So thanks again. Thank you Dave. It's wonderful to be here. Now we're going to post the number of links to some of the great work that Jamak and her team and her books. And so you can check that out because remember we publish each week on siliconangle.com and wikibon.com and these episodes are all available as podcasts wherever you listen to just search breaking analysis podcasts. Don't forget to check out etr.plus for all the survey data. Do keep in touch. I'm at D. Volante. Follow Jamak D Z-H-A-M-A-K-D. Or you can email me at david.volante at siliconangle.com comment on the LinkedIn post. This is Dave Volante for theCUBE Insights powered by ETRB. Well, and we'll see you next time.


A new addition was dedicated tonight at the Confidence Learning Center in Cass County in the Brainerd Lakes area. The new Joe and Kay Gustafson Memorial Field, which includes Frisbee Gulf and human foosball areas, is the first recreation field at the camp, which provides educational and recreational opportunities for people of all ages with developmental and cognitive disabilities. Camp staff members say they're thankful for what the new field will bring. Today we are opening the Joe and Kay Gustafson Memorial Field and what it is, you can see behind us, it's a one and a half acre flat field that has tar around it for our campers to use throughout the year and we're so thrilled to have it. This has been a need at Confidence Learning Center for many, many years. The new field cost $25,000 which was provided by the Gustafson's Endowment Fund. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.


Oop-Arts, the anachronym for out-of-place artifacts. Objects often found in extraordinary places, inexplicable in nature, and repeatedly dismissed by any who conform to mainstream institutional timelines for Homo sapiens. According to these, apparently already laid out chronologies specifically for man, the immense age of some of the out-of-place artifacts make their existences simply impossible to explain. The Nampa Da, for example, a favorite oop-art of a number of antiquarians and alternative historians alike. Found deep within the Earth's sediment, pumped to the surface, amongst the sediment which had been resting there for at least two million years, this small clay figurine even adorned with surviving details of the fashion at the time of its creation. And although fascinating, this video does not focus upon zinc vases dynamited out of stone quarries or iron pots found in 500 million-year-old coal seams, or even the imprints of chariot wheels found deep in mines in Russia. It pertains to a modest artifact, a simple mortar and pestle once found by a J.H. Neal, and although today mortar and pestles are not the most interesting of utensils, it is their extreme ages which make them remarkable finds. Confirmed as being of immense age, this mortar and pestle was found left in situ, discovered by a Mr. J.H. Neal in tertiary deposits dating back almost 33 to 55 million years. And just like that of the iron pot, found in the foundry, dated at 500 million years, felt compelled to create their own personal affidavits regarding the events and the legitimacy they're in, no matter how hard it was to explain. These men felt compelled to do all they could to prove the legitimacy of said discoveries. On August 2, 1890, J.H. Neal signed an affidavit swearing his discovery to have been 100% legitimate. Mr. Neal declared that it is utterly impossible that these relics could have reached the position in which they once lay, unless it was at the time the gravel was deposited and present yet before the lava cap formed, giving a dating of around 33 million years old. How old is our species? Where do our origins lay? Within this vast, ancient, and seemingly infinite universe. Have we, as earthlings, experienced ancient cataclysm? An amnesiac event as so many ancient texts write of? If yes, then to what level of sophistication did these now lost ancient ancestors once reach? Sophistications far to advanced for any mainstream publication to ever publish. It is a reality that the continual discovery of such artifacts are slowly proving was indeed a reality, no matter how difficult it is for any institute or individual historian to accept as a reality. It is an upart which we find highly compelling. The Necromantheon, once used as a Greek temple of Necromanthe devoted by the Greeks to their god of the underworld Hades and his female consort Persephone. This site was believed by the Greek devotees to be the door of Hades, allowing entry to the realm of the dead. Located at the meeting point of the Acheron, Pyroflegathon, and Kokitis rivers, which were believed to have also flowed through the kingdom of Hades. With names given to the rivers, presumably by the Greeks, interpreted to be joyless, burning coals, and lament. Wilt's other temples, such as the temple of Poseidon at Teneron, the temples at Hermione and Cumae in Italy, and Heraclea within Pontos, were known to have been used for the practice of Necromanthe. It was the Necromantheon that was the most famous of them all. According to ancient Greek beliefs, while the bodies of the dead decayed in the earth, their souls would be released, traveling to this purported underworld via fissures within the earth. These spirits of the dead, according to the ancient Greeks, were said to possess abilities that the living did not have, including the power of precognition, the power to foretell the future. They therefore claim that these temples were erected by them in locations that were entrances to this mysterious underworld, used as altars for the believers of such to practice Necromanthe, a belief form of communication with the dead. This practice was attempted in order to receive prophecy. However, if one explores the architecture of such site, not only does this ancient Greek claim of construction become a clear, dubiously attested claim, but the evidence for highly advanced precision block building, now known as polygonal masonry, is discovered throughout the site. This existence of such sophisticated block building, which is not only found within and upon nearly every as yet unexplained ancient site upon the earth, but is incredibly similar in form to that of many other ancient sites within Italy, specifically the ancient wall which can still be found surrounding the Acropolis of Alitri and at other sites, including within the ancient ruins of Delphi. This astonishing feat of ancient engineering is as yet unexplained by modern academics, strongly indicating that this ancient site was originally built by a civilization now lost to history. Furthermore, like the enigmatic metal clamps, whose remnants are to be found within a number of these same ancient sites that were originally used by this highly intelligent group, these once utilized to keep the stones in their fitted positions as they shifted and settled over the millennia. These clamps design vary from continent to continent. Our reason for mentioning this curiosity is that although the sophisticated methods of creating these ruins often remain similar or the same, depending upon the continent they are found, is dependent on the style and material these methods are made from. This, to us, strongly suggests that these ancient structures may have indeed been built by the different races found within these differing countries. The commanding force, the leading power of these groups, was the same worldwide power and font of this knowledge, who, with their clearly incredible technological prowess, successfully created such structures, and indeed the Necromantheon, which, regardless of their tremendous age, has successfully survived a vast amount of millennia, successfully making it into our own modern ancestors' lives, predictably adapted due to their wondrous nature into their historical belief systems, often being adopted surrounding spirituality, either for a theistic worship, burial, or in the case of the Necromantheon, for the use of contacting the dead through the mystic teachings of Necromantheon. It is, undoubtedly, highly compelling. We recently covered the astonishing discovery made deep within a coal mine under Rostov in Russia. Fortunately photographed by Mr. Kasatkin, an experienced safety engineer, who discovered the prints of what clearly appears to have been left by chariots' wheels, these seemingly impossible prints are, thankfully, not the only unexplained artifacts to have been found deep within the mines of Earth. In 1912, workers shoveling coal in the municipal electric plant in Thomas, Oklahoma, would make an equally important discovery. As they were breaking up the large lumps of coal in preparation for the furnaces, to their surprise, a small iron pot would be ejected from one of the chunks. Several experts would examine the iron pot over the following few days, all declaring it to be genuine. Apparently, the imprint of the pot could also still be clearly seen in the broken chunks of coal that had encased it for, in all possibility, millions of years. According to Robert O'Faye of the Oklahoma Geological Survey, the Wilburton Mines Coal in which the pot was found is an incredible 312 million years old. The cup is now displayed at a private museum in southern Missouri. It was fortunately photographed by Robert Nordling, who sent a copy to Frank Lewis Marsh, emeritus professor of biology at Andrews University in Berrien Springs, on 10 January 1949. He forwarded the images to Wilbert H. Rush in 1971. Rush was a professor of biology at Concordia College. This means that we now have several artifacts we know to be in existence, which, according to modern understanding as to the age of coal, are over 300 million years old. The pot is still within a private collection of an unknown collector. In perusing the amazing archaeological sites within ancient Mexico, one will inevitably be confronted with a site called Cuequilco, just south of Mexico City's urban sprawl, a four-step round pyramid that, like all ancient structures, has secrets to tell, a secret like the Great Sphinx, which can reveal to us, all through overwhelmingly physical evidence, a true understanding of its true antiquity. The academic world, with its papers and books abundant, funded, researched, and massed published, supported by an institute of individuals who seek to destroy all things which disagree with them. These people would have you believe that Cuequilco was constructed at the earliest in 300 BC. However, nature would tend to disagree. Cuequilco was hardly more than a small mound with some scraggly trees growing upon it back in 1922, before Brian Cummings received permission from the Mexican government to begin an excavation at the site. During initial excavations, Brian noted that the well-known Pedegral lava flow had partially engulfed this ancient structure. He became increasingly interested in the site after learning that geologist George E. Hyde dated the Pedegral lava flow at over 7,000 years ago. Additionally, when Brian's workers successfully cut deep trenches down into this ancient lava in an effort to locate the base of the pyramid, they not only passed through the bottom of this layer, but continued through several other areas of sediment before finally reaching the high-quality paving at the original level of the structure. In fact, over 18 feet of ancient sediment lay below this 7,000-year-old volcanic activity, including two other previous lava flows, each separated by layers containing artifacts from no less than two other separate inhabitations of the area by civilizations of varying advancement. Also, evidence of a past submersion in no less than 6 feet of seawater, another ancient structure lending credence to the Great Flood. The pyramid itself once masterfully constructed using uncut chunks of lava. Amongst the first layer of erosion and decay resting just above the original foundations of the structure, it seems we're remnants of a primitive civilization that moved into the area shortly after apparent catastrophe. Is this proof of our civilization once being destroyed? Along with this initial primitive civilization is an extremely ancient lava flow, which is followed by a dramatically far more advanced civilization. Amazingly, Cummings successfully produced dates of over 10,000 years for the original sediments, more than 2,000 years before ancient Egypt was said to have been built, though we feel this was most probably just a re-inhabitation of these powerful pyramidal structures. And although he also found dates far older than 10,000 years, he reluctantly put them down to anomalies and did not record them. After the details of this excruciating and highly efficient research was understood, Brian Cummings predictably experienced the cold shoulder of conspiracy. It seems mainstream archaeology, along with the well-known overpaid figures who partake in this limited public discussion, have successfully avoided the subject altogether. Indeed, it would require a dramatic rethinking of the largely accepted chronological development of man. It would also require an extremely tricky maneuver in verbal acrobatics to get away with explaining the presence of a highly complex, highly capable, highly advanced ancient civilization, building impossible structures well over 10,000 years ago. And although it seems that mainstream archaeology has successfully avoided having to make such a spectacle of their belief systems in their attempted denials of such evidence, it will continue to be something we would like to see.