>>The Cube Presents Dell Technologies World Brought to You by Dell. >>Hey, everyone, welcome back to the Cubes Coverage of Dell Technologies World 2022. Live from the Venetian in Las Vegas. Lisa Martin With a Volonte. This is Day two of the Cubes coverage. We've had a lot of great focus on talking about multi cloud partner ecosystems, as et cetera, the last day and a half. Now we're going to have a conversation with Dell, and we've got two guests joining us. Please welcome David Linthicum, the chief cloud strategy officer at Deloitte, and Brad Lewis, the senior vice president and GM of the global transformation office at Dell Technologies. Guys, welcome to the Cube. >>Thank you for having us. You guys >>so lots to talk about multi cloud. You can't. It's one of the biggest themes here, David. I want to start with you. One of the things that Michael Dell said in his keynote, and he said it on the Cape today is its multi cloud world by default. What does that mean to you? >>What that means is that if you don't find multi cloud, multi cloud is going to find you. It's a complex distributed system that basically is invasive to what we do within the enterprise. So anybody who's leveraging cloud computing is going to find that there is a need to leverage multiple clouds of multiple kinds of technologies. And therefore we're kind of focused on what's in between the clouds versus the clouds themselves. And I think that's okay. We're leveraging multi cloud by choice. It's driving innovation. It's driving agility. That's why people are adopting it. So whether or not you have it or not within your enterprise chances are you do. Are you going to have it pretty soon, >>right? I think stand I saw yesterday was 75% of organisations have at least 3 to 4 different clouds. What is your take on when you're talking with customers in the field? How are they? How are they managing that approach? What are they doing right? What do they Maybe not doing right. >>I think what they're doing wrong mainly was hit. That one first is that they're managing their clouds within the silos. And so, in other words, are using whatever native tools are in the particular cloud provided to do operations do security, governance, things like that. And the reality is, it's a more holistic approach that needs to be taken. We need to span these solutions across the different cloud providers and also the existing legacy systems thinking holistically about that. It's just something we haven't done ever with an I t. And now we're having to do it. Read. >>What is the global transformation office? Adele, What's your What's your role in your mission? Sure. >>So our mission is working with our customers, who are really focused on driving outcome centric types of relationship with us, so worried less about the just in and of itself and really wanting to figure out how do I take advantage of all of those capabilities that Dell and its partner ecosystem have to drive business value? Ultimately, what does a great experience look like that or a developer for my lines of business? How do I start to improve the type of agility that I've got? How do I office stuff up some of the types of flexible platforms that I'm really reading about or aspiring to be able to offer? So being able to look at that holistic through through the lens of technology, the economics of that. The operational constructs and operating models around it and being able to really take all of those assets and capabilities and map them to the types of outcomes, milestones and timelines that are relevant to that. >>Who is your ideal partner at the customer? Is it uh, C I o the line of business? Somebody in infrastructure? >>It's all of the above, I think, as we get as we get through the conversation, what will become apparent is tech as part of the answer. So it's not. It's important. It has to be considered. It has to be architected. Well, it has to be operated well. But as important as taking an increasingly more so is how to David's point, how are you going to go and build that common model of operational construct around all of these different platforms so you don't end up with a silo based approach? Application owners and driving utilisation and adoption is important and more so than it's ever been. So having those line of business tie ins and the application owners all of those different stakeholders finance and being able to set expectations well and being able to deliver against those consistently and reliably and the impact that has on confidence and investment. All of those things become part of the fabric of a collective that's about mapping to those. So there's no one set of stakeholders that we work with. But what is really important as having somebody who sits across all of those things that has the ability to call the shots and make decisions when hard decisions are having to be made because where things don't typically work well is when we get into stalemates or standoffs, where there's different factional issues or politics comes into it or somebody is not empowered? Having that governance model so that there is a senior stakeholder who can move roadblocks and make sure that we remain aligned is one of the most critical factors. >>David question for you removing those roadblocks the last two years. Obviously, we've seen a lot of organisations massively pivot multiple times right to survive and not to thrive. But we've seen so much investment in the remote workforce and now a lot of businesses facing ageing infrastructure, what do we do? How do you help them remove those roadblocks? Obviously time is of the essence right. So from a competitive perspective, what more do some of those conversations look and sound like >>they're one? Get the obstacles out of the way. In other words, if you think this is about building more data centres to have more VPN, traffic and things like that, that's not what it's all about. This is about finding solutions that provide scalability within the organisation and it's going to maintain scalability. Keep in mind, we're running to work force. People are going to work independently. They're gonna exist on their own infrastructure. They're going to have their own data which is personalised to them. They're gonna basically interact with other employees and other co workers in different, more collaborative ways. Hopefully. So the idea being that we're trying to get everything back centralised again is crazy. We need to figure out ways in which we can diversify the workforce, diversify that kind of technology we're using and leverage things that are really kind of on demand and scalable quick thinking about building data centres. >>Okay, so square the circle for me because I totally agree with what you just said. But it seems like a lot of organisations when it comes to data are taking that approach like Okay, let's centralise all the data so we can make it more manageable and more efficient to manage. Yet we talk about edge. Data is distributed by its very nature. So help me understand that Yin and Yang. >>I think it's partially we get into, obviously, the governance and the data governance and sort of all of the regulator in compliance aspects of that part of it is also emerging technologies. It's the area that's probably the least mature. We spend a lot of time figuring around how to have operational toolsets around multi cloud. Then we figured about how to have applications traverse multi cloud. Now we're moving on to the real crux of the problem and especially as translate edge start to take hold. We're generating large volumes of data is being generated at the edge. It's being generated in the in the core, and that ability to look at things holistically is going to become increasingly important. It's an area of focus for obviously us at Dell Technologies. It's where we're investing heavily and from an R and D standpoint. It's where the marketplace is going to evolve. But it's still in an early stage of maturity and being able to look at that holistically, >>so not necessarily shove it all into a single data store but enable it to be distributed and managed and and governor who should own the data life cycle. Should it be somebody in the business? Should it be somebody in I t. Should it be a data >>group? >>It's >>now. There is a long How long have we got? Well, I mean, you must have these discussions. We absolutely do, but sort of being serious about it. I think the important point is the people who ultimately are the ones who are who are responsible for getting value from that data is where it should resign. So because of the people who have the greatest insight and understanding of how of how to really get value from it, because ultimately we want to pivot from having a data conversation to how do we generate information and actionable information? It's not a data problem in and of itself, it's it's This is a business intelligence. How do we get value from this and that the best place for the data to live is the people who are going to be able to make the most of that. So >>Deloitte's gonna be having these conversations all the time with your customers. But this is, uh, an organisational discussion, isn't it? >>It's also a functional discussion. You have to remember that there's two tiers there. There's the people who own the data tier but don't necessarily want to administer the data so they know what the data is, What it does, they control how it's changed. They control how it's monitored, and we have multiple people that are distributed all over the company that do that. And then there's the people that actually run the control plane, and we get to distribute a data we're having to get to a common control plane that goes across the various databases, which is able to make the changes to the metadata and changes to the technical geeky stuff we have to do to keep data running. And so it's okay to have that. It's okay to have non technical and technical users who still maintain ownership of the data, and they work together in kind of a devops situation to make sure that we're maintaining the data to the needs of the business, and we have the business owners in there to tell us what that is. And we have the data administrators and that would actually make the changes. >>So the technology is, uh, an implementation detail in that model. Um, that's not It's not the tail wagging the dog. It's subservient to the business. Essentially, >>they're working together. And the reality is that the people who have the technical know how and have the business now how are often city in two different organisations that can exist anymore. They need to be maintained. They need to remove the barriers. And I deal with this with my clients all the time. They can't sit in silos. They need to collaborate together to make sure that the systems and the data are going to reflect and to solve the needs of the business. The only way to do that is to have collaboration at that level. >>So Lisa referenced multi cloud by default. You know, Chuck Witton was talking about that on the Cube recently. Uh, so I have often said multi clouds, Really? Multi vendor. It's like, Oh, I woke up. I got all these clouds. Okay, So what are the right strategies for customers? Where are they starting? How are they thinking about it? >>The people who are making the best progress is looking at it holistically. Looking at what does what does God look like? What are the things that are important to us? One of the capabilities were wanting to offer up and going into going into things, worried less about the tech of it. But more about how are we going to do things like accelerate business agility? How are we going to start to empower our lines of business to have first mover advantage? How do we take advantage of all of these disparate capabilities that over time it's going to vary? Who has competitive advantage? You could have one provider comes up with something that's a really compelling use case for what you're looking to do. But so if you've got the ability to be able to consume as a consistent ecosystem, all of those different partners, it's very easy to tap into that quickly and effectively delivering it. If you're trying to build things so that you're only tied into different people in different ways with different operational constructs, that don't really talk very well together. It's going to become very difficult for you to really take the maximum advantage of multi Cloud. So the thing that I would stress is, what are you actually trying to accomplish out of that work from the top down? Think about what good looks like. What are the capabilities that are meaningful and impactful to the business. And then the easiest thing in the world is to figure out which technology choices you have that enable that. But it has to be done through that lens of what is business value look like? And how do we manage that? And maximise that versus making desperate sort of distinct technology choices >>with the focus on business scene, which is absolutely critical. David, What's the GTM like between Dell and Deloitte? How do you when you bring them in? It's >>a perfect relationship. You've got to remember the customers and our clients have to have two things. Number one. They have to have a trusted adviser, and someone can bring to bear risk. Financial financial analysis, the ability to deal with technology, data, security, governance, things like that which are hard problems to solve. But do so in an objective way, making sure we're bringing the right solutions to bear to solve the problems looking after for the client as well as a technology partner that has the breath of everything you see on this floor that we can pick and choose different technologies to bring together to solve their exact needs. So having a partner like Dell is very important because ultimately allows us to pick the right solutions for the customer and bring to bear the exact solutions are going to solve their issues and do so in a way where they're going to be 100% optimised, where the solution that they're running is going to be near 100% optimisation as much as we can, and therefore that's going to value the business. Do you tend >>to these days, uh, to come into an organisation on a more sort of project basis? Or is it more things like we're talking digital transformation or data architecture? And then you figure out okay, where's the priorities? And the spending have to be is a kind of a top down or is it bottom up or a middle out? >>It tends to be a little bit of well, ultimately it ends up being both. So whether the conversation starts at a macro level and it's a more existential, how do we? How do we want to go to market and how do we want to support our business? A lot of conversations start that way. Sometimes it'll be bottom up where it is a specific project. We've got a net new application. We've got to go to market initiative, a new geography, whatever it happens to be. That is sort of what spawns that type of a dialogue. But ultimately, those two things do end up balancing out. Because if you do anything well and the expectation is that we're going to do things well, then it will grow. Or alternatively, if the aspiration is is that you want to do things in the best way possible, it will attract and pull through use cases and projects as and where required anyway. So the two things end up becoming pretty symbiotic, irrespective of whether it started as a top down. Michael meets a customer and sort of starts that way, or it's something from the grassroots up that it's more demand based from a project. >>When you have edged discussions with customers, how much of that is? You know, maybe it's the OT people or the folks out at the edge, and how much is I t involved in those discussions? >>It tends to be so. It's becoming more mainstream that it's a more holistic conversation, so a little bit is always the case. Some of the early conversations tend to be about use cases that are very business century so that you will have conversations with somebody who imagine somebody doing payments of distributed payments in financial services or something like that. And it's all about mobile banking and proximity and things. So you tend to talk to people about well, what are the potential use cases? How do you monetise some of those things? And then you talk to end up in a technology conversation or some could be potentially. Somebody says, Well, look, we've got the Capital Markets group want to do something, or the consumer banks want to go do something that's eccentric. How would we go about doing that from the organisation? We're now getting to a much greater degree of maturity with a lot of customers where it is a collaborative where you've got the person who owns the business problem or the business opportunity, plus the technology group. And it's a collaborative around. Well, what does the technology solution need to be able to offer up and deliver? And if we can do those things, how would we then go and leverage that technology and the most effective way to drive those types of business outcomes? We're talking about seeing >>a similar >>patterns. Yeah, I'm seeing very similar patterns. Ultimately, this is about tactical technology that has a strategic purpose. And you gotta remember we've had edge in one way, shape or form around for the last 30 years. We just haven't done it very well. And the thing is, we're starting to move a lot of these processes and a lot of these data collections, a lot of these analytics and a lot of knowledge engines, you know, out to the edge of the networks. And by doing so, that creates a strategic opportunity for folks in the organisations to figure out how that's going to work for them. And so it isn't necessarily a geeky conversation that we're having it strategically. We're looking to expand the way in which we're doing compute and doing data storage. It has these opportunities within the industry you're in. We're going to build this technology to make it happen. And that goes to both sides, people who do the implementation boards of directors and CEOs. But >>you can kick out if you have to, >>but they've all got to be there. And that collaboration seems like it's absolutely foundational to overall projects being successful. Guys, thank you so much for joining David me on the programme today. Talking about Dylan deployed better together and all the opportunities that there are to unlock the value and multi cloud. We appreciate your insights. >>Thanks for having us our >>pleasure. Thanks for our guests and a volonte. I'm Lisa Martin coming to you live from Las Vegas. Day two of our coverage of Dell Technologies World stick around. We'll be right back with our next guest. >>Thanks. >>Mm. Mhm. Mhm.

>>Well, thank you, everyone. And welcome to winning the roadmap race. How? Toe work with tech vendors to get the features that you need. We're here today with representatives or RBC Capital Markets. We will share some of their best practices for collaborating with technology vendors. I am Ada Mancini, solution architect here at Mirant us. And we're joined by Tina Bustamante, senior production manager, RBC Capital Markets and Minnows Agarwal, head of capital markets. Compute and data fabric. Um, RBC has been using docker since about 2016 and you've been closely involved with that effort. What moved you to begin, contain arising applications. >>Okay, uh, higher that. Thank you for having us. Um, back in 2016 when we started our journey one off our major focus, Syria was measuring develops capabilities And what we, uh what we found was it was challenging. Toe adopt develops across applications with different shapes and sizes, different text tax. And as the financial industry, we do have, um, a large presence of rental applications. So making it making that work was challenging. This is where containers were appealing. Tow us. In those early days, we started looking at containers as a possible solution to create a standardization across across different applications to have a consistent format. Other than that, we also saw containers as a potential technology that could be adopted across across enterprise, not just a small subset of applications. Uh, so that that was very interesting. Interesting. Tow us. In addition to that, uh, containers came with schedulers like kubernetes or swarm, which were, uh, which we're doing a lot more than all, which would do a lot more than the traditional traditional schedulers. As an example, resource management fell over management or scaling up and down, depending on a application or business requirements. So all those things were very appealing. It looked like a solutions to a number of problems that are number of challenges that we're facing. So that's when we got started with containers. >>So what subsequently motivated you to start utilizing swarm and then kubernetes? >>Yeah, other than resource management, the follower Management Aziz, you can imagine managing followers. D are Those are never difficult, Never easy on with containers. We saw that, as the container schedule is, we saw that it's a kind of becomes a manage manage service for us. Um, other aspect We are heavily regulated industry in capital markets, especially so creating an audit trail off events. Who did what? When? Uh, that's important. And containers seem to provide all those all those aspects tow us out of the box. Um, the another thing that we saw with containers under the schedulers, we could simplify our risk management. We could control what, what application on which container gets deployed, where, how they run on when they run. So all all those aspects of schedule er they simplify are seen to simplify at that time a lot off a lot off the traditional challenges, and that that's what was very appealing to us. >>Eso what kind of changes were required in the development culture and in operations in order to enable these new this new platform in this new delivery method? >>Yeah, that that's a good question, and any change obviously requires a lot of education. And this was not just a change across our developers or operations, but it was the change across throughout the change, starting with project managers, business analyst developers, Q A, uh, Cuba and our support personal. In addition, I talked about the risk and security Management so it it is. It is a change across the organization. It's, uh it's a cultural change. So the collaboration other than education collaboration was extremely, extremely important. So across those two, we started first with internal education, using something like internal lunch and learns. We did some external workshops or some hands on workshops. So a lot of those exercises were done in collaboration across all those all those things. The next item that we focused on is how do we get our high end developers the awareness of this technology on, uh, make sure they can. They can see, uh, the use cases. Or they can identify the use cases that can benefit from this technology. So we picked high end developers, noticed application and kind of try before you buy type of scenarios. So we ran through some applications to make sure they get their hands study. They feel comfortable with it on. Then they can broadcast that message. The broader organization, the next thing we did it waas getting the management buying. So obviously any change is going to require investment on uh, making sure there's a value proposition that's clear to our management as well as our business was critical very early on in in container option face. So that that that was that was another item that we focused heavily on. And the last thing I would say is a clearly defining strategy benefits so defining a roadmap off how we will proceed, How do we go from our low risk to high risk application or low risk medium risk applications? And what other strategy benefits are these purely operational? Are these purely cause best benefit? Or it's a modernization of the underlying technical facts. So if the containers do check all those three boxes So that that was that was our fourth item on the left that, uh, that, I would say, changed, um, in a container adoption journey. >>So as as people are getting onto the container ization process and as this is starting to gain traction, what things did your developers embrace as the real tangible benefits, um, of moving the containers of container platforms? >>It's interesting. The benefits are not just for developers. And the way I will answer this question is not from development operations. But let me answer it from the operations to developers. So operationally the moment developers saw that application can be deployed with containers relatively quickly without without having them on the collar without them writing a long release notes. They started seeing that benefit right away, but I don't need to be there late in the evening. I don't need to be there on call to create the environment or deploying, uh, deploying Q A versus production versus the are to them because, like do it right one on then repeat that success factor of different environments. So that was that. That was a big eye opening, um, eye opening for them. And they started realizing that Say, Look, I can free up my time now I can focus. I can focus on my core development, and I don't need to deal with the traditional traditional operational operational issues. So that's what that what? That was quite eye opening for all of us, not just for developers. And we started seeing those, uh, that are very early on. Another thing, I would say the developers talked about waas. Hey, I can validate this application on my laptop. I don't need to be I don't need to be on, uh, on on servers. I don't need all these servers. I don't need to share my service. I don't need to depend on infrastructure teams or other teams to get their check is done. Before I kept start my work, I can validate on my on my laptop. That was that was another very powerful feature. Um, that that empowered them. The last thing I would say is that the software defined aspect, uh, aspect off, um, off technology as an example, Network or storage. Although a lot of these traditional things that something Democrats have to call someone they have to wait on, then they have to deal with tickets. Now, they can do a lot of these things themselves. They can define it themselves, and that's very empowering. So they are perspective. Our move towards left, Um, s o the more control developers have, the better the product is. The better the quality of the product. The time to market improves on just the overall experience on the business benefits. They also start to They all start toe, um improved last part. One extra point. I would like to make here the success success of this waas so interesting, uh, to the development community even our developers from business. They they came along and they have shown interest in adopting containers. Whether it's, uh, the development developers from the quartz are the data science developers. They all started realizing the value value proposition of containers. So it was It was quite eye opening, I would have to say. >>And so while this while this process is happening while you're moving to container platforms, um, you started looking for new ways to try and deliver some of the benefits of containers and distributed systems orchestration more widely across the organization. And I think you identified a couple areas where, um, the doctor Enterprise kubernetes service wasn't meeting the features that you anticipated or it hadn't planned on integrating the features that you required. Um, can you tell us about that situation? >>Certainly. Haida. Thanks for having us again. Um, from the product management perspective, I would say products are always evolving and the capabilities can We have different stages of maturity. So when we reviewed what our application teams what are businesses looking to dio? One area that stood out was definitely the state of science space. Um, are quantum data science is really wanted to expand our risk analysis models. Um, they were looking for larger scales, uh, to compute like a lot more computing power. And we tried to see, um, come up with a way to be ableto facilitate their needs. Um, one thing, and it really, really came from like an early concept was the idea of being able to leverage GPU. Um, we stood up like a small R and D team, trying to see if there was something that would be feasible for our on our end. Um, but based on different factors and considerations and, you know, technical thinking involved in this we just realized that the complexity that it would bring to our you know, our overall technical back is not something, um that we would be, um, best suitable, I would say to do it on our own. So we reached out Thio Tim Aransas and brought forth, like, the concept of being able to scale the kubernetes pods on GPS. We relied on there authorities on their engineers Thio, you know, think about being able to expand, uh, kubernetes there kubernetes offering to be able to scale and potentially support running the pods and GPS um, definitely was not something that came from one day to the next that it did involve a number of conversations. Um, but, you know, I'm happy to say I was saying the recent months it has become part of the KUBERNETES product offering. >>Yeah, I believe that that effort, um, did take ah, while took a ah lot of engineering effort. Um, and I think initially all had done some internal r and D to try to work on those features, but ultimately, you decided to go with a different strategy and rely on the vendor to produce those assed part of the vendors product. Um, can you elaborate on the things that you found in that internal R and D? >>Well, we definitely saw the potential for there was definitely potential there. But, you know, the longevity of actually maintaining that GPU, uh, scaling using communities on our own was just not 100% like, in our expertise, expertise of something that we wanted to collaborate more closely with the vendor. Um, you know, technology is always evolving, So it's just the longevity of keeping up with, like, the the up to date features or capabilities testing que involved was just not something that we thought it would be. Something that we should be taking on on our own. >>Okay, So, like spending the time and engineering effort, focusing on the data science, the quantity of analysis parts I see. Um, and then ultimately, um, working with the vendor produced a release and where these features are now available. Um, how what did that engagement look like? Um, with RBC s involvement, >>I would say the engagement started off with, you know, discussing bringing it forth, being very open, you know, having transparency. So that delivery was always a little bit was the focus. Um, but it definitely, um, started office, you know, discussing what it would be like the business case. Why we would require the feature. Definitely the representative. Those and others engaged from them. A ransom side had their own, Um, you know, thoughts and opinions. Um, it had to be being able to run the work clothes, um, on GPU would be something that they would ultimately, as I mentioned, have to support on their end. Um, so we did work with them very closely. There was a very much a willingness collaborate we held a number of meetings. We discuss how the CPU support would would actually evolved. So it wasn't something that came about within like one sprint. No, that was never like our expectation. It did take a couple weeks to be able to see, like a beta product opine on it, see a demo, review it, discuss it further. Um, as you know, sometimes there might be a relief where this capability maybe offered, but there are delays. It's just, you know, part of off of our industry in a cent. Um, we're very much risk versus the nose mentioned, you know, >>when >>you are a financial institution. So we just wanted to make sure it was a viable product, that it was definitely available off the shelf, and then we would be able to leverage it. Um, but yeah, the key point, I would say, in terms of being able to bring the feature forward with definitely constant communication with Miranda, >>that's excellent. I'm glad that were ableto help bring that feature forward. I think that it's something that a lot of people have been asking for and like you said, it enables ah, whole new class of uh, problem solving. Okay. Uh, Meno je Tina, Thank you for your time today. It's been wonderful talking to you again. Uh, that is our session on working with your vendors. I want to thank everyone who's watching this for taking the time Thio contribute to our conference. Uh, awesome. Thank you, kitty.