Public Cloud Workload Repatriation Part 2

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Just to recap, for my last conversation, all roles lead to CIOs needing architects with skill to meet the drivers of work placement. Those drivers could be based on new types of workloads, such as AI, ML, IoT, or business opportunities powered by the cloud. Tim talked about in the last session about the importance of knowing the value of the workload. First off, what are these workloads and how do we scale up to properly identify and place the workloads in our hybrid infrastructure? So question one goes to Joe.

The SolarWinds IT report, I just did a podcast with them going over the results of this survey, mentioned that IT pros, mainly us infrastructure-focused types, are not really paying a lot of attention to AI, ML, and IoT. Joe, what are we missing? Like, what are you seeing out in the field when it comes to AI, ML, and IoT that us IT infrastructure pros kind of don't see? Well, you know, I found the word focus pretty interesting. And I found it interesting because I thought about something silly first.

You know, how when you have a little kid and you're trying to get that little kid to eat veggies, maybe having the veggies on the plate is not the best way to get that kid to eat the veggies. Maybe mixing them into the stew is a better way to get that child partaking the veggies, right? And so what I'm driving at is that all these technologies that you just mentioned, AI, ML, IoT, they are being consumed, but maybe they're not just the star of the plate, right?

And I think we need to separate them out in buckets for a minute because IoT is happening, and it's happening in a number of verticals, and IT is the one implementing it. So if we look at industrial IoT, that's booming. And we look at technologies like manufacturing, transportation, utilities, healthcare, smart cities, they're implementing in a big way. And so if we focus on a smart city application for a minute, we know of a client that integrated their water meter technology with Azure Cloud.

And this made them capable of tracking real time water consumption. It was the IT folks that did this, right? And this project involved 50,000 smart meters. And what they were after was, they were after looking at the consumption and trying to really optimize that water flow and save gallons of water. And they were able to do that. And again, it was the IT team that did this, right? The second thing that I want to talk about is how some of the technologies that you mentioned, while they're not the star of the plate, they are being baked into tools.

So for example, you look at AI and you look at how many security vendors are baking AI into their as a service tools, right? And the IT guys are utilizing AI with maybe not even realizing how much they're utilizing AI. So if we look at a SEM, for example, and a SEM as a service tool, you know, you've got this, you've got AI looking at the log files to determine what is a real threat and what isn't instead of having somebody spend the time to go through the log files.

You're looking at AI in action and IT teams are using that. So I think that focus is a really interesting word. I think we're getting what we need in doses and we're going to learn to expand upon that. That's my answer. You know, I like that answer and the fact that you focused on focus. One of the things that I really want to zero in on your answer is this use of AI in the discipline of IT. We're using it for SEMs, we're using it for a log analysis, et cetera.

To the larger team panel, do you guys think that this is an opportunity for IT infrastructure, IT in general, to take the horns of it and start to create basically infrastructure as a service for AI. AI and ML being like disciplines of IT proper that are kind of sitting at that application layer where I think it sits today. Yeah, I'll jump in there, Keith. I think that's absolutely something that needs to happen. It needs to almost just kind of blend in there and be, you know, like we don't talk about electricity, we talk about what we do with it.

I think artificial intelligence and machine learning are going to be the same way. And so one of the things that we see, our cloud research team tracks something like 400,000 different ways that you can do cloud services today. You can't do that in a spreadsheet anymore. But if you use automation and intelligence, you can find things, for example, like I had a conversation the other day, everybody wants to embrace paths and database as a service and stuff like that. There is a tipping point in almost every cloud provider, Keith, where when you're over a certain amount of memory, right around 64 gigs or so, it's actually cheaper to run that on prem.

And so what you need to understand is help me automate the tipping point where the juice isn't worth the squeeze anymore. So we should absolutely be doing that. That's just baked into how we make good decisions. I think one of the challenges with that approach is when we look at something like AWS, they announced a couple of years at reInvent, these solutions that are generic and consumable, you know, hot dog, not a hot dog. These, I forget the lens solution that they deployed.

Do we have the skill, and this conversation will be focused on the skill, do we have the skill within the enterprise IT scope to even consumerize these solutions so that we're providing it as a service of IT? You actually have to do that though. That I think is one of the questions that I'd ask. I mean, one of the interesting things is IT as a broker for cloud services, right? As a governance layer that kind of connects their internal consumers with the right services and helps them understand how that fits into considerations like where data lives and how the networks connect and things of that nature.

Even if you decide to go cloud native with some sort of AI and ML solution to solve your specific application problem, it doesn't mean that that's an island, right? That your data scientist necessarily goes to the cloud, writes this code, and has no effect on the rest of your IT infrastructure. I mean, hopefully if you're leveraging a SaaS service like that that handles something like image recognition, it is doing a lot of the upload for you. It is meant to get, I think, the IT folks out of the way of having to worry about that from an infrastructure perspective.

But I think that application doesn't live in a vacuum, and so how it connects to all the other things that you're doing is still the domain of IT and super relevant. I think you have to kind of break it down into different layers. To answer your question, Keith, the first thing that I would look at in terms of does IT have the skills, depends on what aspects you're talking about. Are they building an internal public or private cloud type of environment, or are they moving to public cloud?

And those are two very different aspects because you're essentially building a whole service off of an architecture that is somewhat foreign to you, somewhat different from what you're traditionally doing. Whereas consuming that service is a much lower hurdle, relatively speaking. And so I think it's important to understand the differences there because that then leads to some of the issues why people are repatriating workloads. But I do think to Bobby's point, you do get to a point where you realize that the public cloud vendors are really just providing a general purpose service.

I mean, yes, they have different versions of that service, but all of them, all of the major providers, they're all geared to address the broader community of potential customers. When you get to a certain scale, a certain size, or you have very specific requirements to be able to tune your infrastructure for a given application or workload, that's when things start to get problematic for the general public cloud providers, and you start to look at alternative solutions. But that doesn't necessarily mean you're bringing it back into your corporate data center or running it the way you used to run it.

Uh-huh. So, Tim, I think this segues into the second question. Me and you were on a Slack forum the other day, and one of our peers were kind of complaining that as he was talking to a blogger, the blogger said, you know what? I'm dealing with this business with the, I'm dealing with this issue with the business. And he categorized the business as these people that were using the CICD process, which I think both me and you will agree would be IT.

That's not, CICD is a process that the business doesn't care about. That is a IT process. I'm tempted to ask whose fault that is, that that perception persists, but we are here for direction. Yeah, how do we enable, and more importantly, empower our teams to learn more about business drivers so that we can get back to that talent question that we asked before, which was, do we have the talent to deploy AI? Well, what do you mean by AI, and how is that relevant to the business?

We need to get to the core of that answer. So how do we empower our teams to engage the business? Yeah, so first and foremost, stop calling it the business. IT is part of the business, right? And when you start to talk about, there's IT and the business, you start to create this us and them culture where IT is different, or people outside of IT start to believe, start to think that IT thinks they're better than everyone else. It doesn't end well, is the point.

And so it's important to understand that we're all part of the business. And when you create that construct for your vernacular and your conversations, you also start to build relationships with those outside of IT. And that's really important because you need to understand the nature of your business. And that becomes the context in which you build the right skills to determine, okay, here are the business objectives that we're trying to achieve, all of us, those inside of IT as well as outside.

As well as trying to understand what technical skills are gonna be needed as we start to mold which technologies fit in to address which business objectives. But I always confer back to, you have to look at your business, the nature of your business, understand how you spend money, how you make money, how you engage with customers, understand what the board objectives are, the C-suite objectives are, understand each of those tiers. When you do, it starts to become clear where you should be putting your energy and where you should stop putting your energy.

From there, the other pieces can start to fall out in terms of, okay, where do we have gaps? Where do we need to maybe shift resources or shift skills or fill some of those gaps in skillset? But that's where I'd start. So question to the larger panel, where have you guys seen this work and not work, like what are you seeing in the field? No, that's a stopper because I'll tell you why, because this is, I get when I worked for VMware, when I spent a little time working for VMware, I saw acceleration of the number of customers that I met.

Me and my small firm, I can only meet so many customers. I have so much reach. When I went and worked for a vendor, I got to interact with directors of infrastructures, VPs, architects, et cetera. And it was really all very similar that no one really focused on the end product of their organization. It was all about how do I reduce costs? How do I reduce my storage costs? How do I optimize for dedup? How do I lower my VMware bill?

It was nothing about accelerating the business. So I think it's rare to have this conversation, especially within our, and when I say our, because Tim is an exception, Tim and Joe are exceptions, within our infrastructure focused view that we just don't always align to the business. Well, let me say something if I can. Oh, go ahead. Oh, okay. So I have a friend that's a CIO that is super forward thinking. And he went into a new organization and he aligned with the CMO.

And yeah, by aligning with the CMO, he was able to come up with some really great ideas that was gonna not only drive further customer satisfaction, but some of the stuff that they were doing was actually going to decrease time to revenue. And I thought, man, I love this synergy. I wish I saw this more. It was so refreshing. I'll piggyback on what Joe was saying. Keith, I think you and I have talked about this before. We say all the time in corporations, people process technology.

And I think that's actually not great terminology. People process product or people process problem. What is it that we're trying to do for end users or customers? Or what is the problem that we're trying to actually solve? We lose sight of that, fall in love with the tech. And then we're down in the bowels of the data center of the cloud. And we're like, what are we doing again? Who are we doing this for? Who's our customer?

That's to be at the forefront as Tim and Joe were talking about. You know, I'm building the CTO advisor data center and I had to go to the data center today. And one of the things I, literally I was going to the data center to do two things. One, to plug in a USB drive, super low level techy stuff. That's the only thing that they allowed me to do. To do one, plug in the USB drive and two, plug in the cable.

And I had to ask myself, and I tried to ask myself what value is this bringing my targeted customer when this is complete? Like, why am I taking time out of my day because I'm not a tech, I'm not a engineer. Why am I taking time out of my day to go plug in a USB port in a console cable? And I think if you constantly ask yourself that question and go through that exercise, you start to connect the value of what you do to the business.

And more importantly, because Tim talked about this before, if you want to know how much something costs, outsource it. Mm-hmm. You start to recognize the value of the thing that you do and whether or not you should do it or if you should just simply pay someone else to do it because it's not worth your time. So Bobby, you spoke up last, therefore you get the next question. We've talked about the soft skill needed to make these kinds of decisions. However, we have both you and another CTO on the line, Matt, and you deal directly with analytics.

So I'm going to ask you what sounds like a simple question. Who's the customer for workload costs and transformation analytics and what are or should be their use of that data? Okay. I would say it's probably typically most often the CIO or the VP of apps transformation, or sometimes the CDL, that's usually kind of the individual or the team that's the biggest recipient of this. But Keith, if you let me expand the question a little bit, part of what ends up happening is, again, and I've said this before, the technology is the easy part.

Thinking about who we're serving, thinking about what we're ultimately trying to do. And I'll tell you something that I came up with in a past week or so. We are falling in love so much with the technology and the tooling. We're not failing for lack of tooling, we're failing for lack of planning. And the issue that I think we're having is, when you think about tools and technology, those help you with better answers and faster results, not better questions. And the problem that most of us are having is that people are not asking the right questions.

And so ultimately, when we go back to the CIO, again, kind of juxtaposing a lot of the stuff that we're talking about, what is the problem that you're trying to solve for your other peers at the leadership table? It's not just about a data center, it's not just about storage, it's about how we're trying to enable our customers. It's around how we're trying to do things better to transform to be more nimble. We're not connecting it to the why. So in theory, the CIO should be asking why and how they enable the other peers, right?

The CMO, the business units, the line of business executives and stuff like that. Part of my job lately has been engaged, certainly with people who are wrestling with data challenges. The platform that we're running, which both helps people connect data from on-prem into cloud environments, as well as kind of take the same pool of data and attach it to multiple clouds at the same time has given me a chance to engage around some really interesting use cases. And I will say that maybe just because of bias towards what we do, we tend to be solving things maybe that public clouds are inherently not good at, especially if you wanna use multiple clouds, which is these very large data footprints that where data gravity becomes a huge problem because it's so difficult to move from one cloud to another.

And so I've been exposed to a lot of use cases that are much more big data oriented, right? And in that, it's interesting because I've seen this trend with this particular aspect, even though at the end of the day, it's still technology, it's gotten completely away from the traditional IT consumer. So just to have some examples, I've got chief architect at a healthcare company and he's completely oriented around solving problems for healthcare patients. It's not really even an IT discussion, right? A data scientist at an enormous firm doing genomic analysis, right?

Or his whole company is oriented around how do we process genetic data? How do we do it more quickly? And very specifically about different use cases, right? Both, how do we do it cheaply for these things that we have that do not have any sense of urgency, as well as, hey, someone is in an office and needs a genome sequence literally within the hour, how do we deal with that hyper performant version and how do we get those two things to coexist?

If there's a need for a very rapid scale-up of genomic analysis, I think the COVID situation probably made us all sensitive to even a use case like that. How do we deal with those? Even the people dealing with self-driving cars, right? How do we process hundreds of petabytes of data so that we can retrain a model about how a car can drive itself? These questions are both fascinating and they also get completely away from traditional IT, both in kind of the way that they approach it because it's so completely business-driven, as well as the way that they approach the technology because the requirements look so different that I think that sort of, air quotes traditional IT workload that you see in the enterprise.

And I think the other side of the coin there, when you think about traditional enterprise, where I see a lot of interest and a lot of engagement on these, really is about, I think IT folks need to have just a little bit more of a mindset around developers. So a lot of this stuff that we're doing today is so oriented around software productivity. Tim, on the last time we got together, made such an incredibly cogent point, it still sticks out in my head, really about how these giant, kind of grown in the cloud companies typically have managed one or two apps at enormous cloud scale, but typical enterprise actually ends up managing hundreds or thousands of apps, often at very small scale, to do very specific tasks.

And that whole sprawling line of business thing is a huge concern. And I think at the end of the day, the value you get out of those applications as a business is totally derived from what your developers can do with them, right? How fast can they iterate on it? How fast can they deliver new value to the business with those apps? And so I think having that super developer-oriented mindset in IT about how you empower them to make quick progress is absolutely critical to how you deliver value to the enterprise.

That was a mouthful. So let's spend a little bit of time bringing that last part of the question up. I think it's obvious that, I love the genomics example because I have a farmer background and that was one of the most challenging parts of providing infrastructure to them is getting the data where they needed the data. And where they need data is not always where the data was produced. So, you know, you get the, if you get it in the clinic and then you need to move it from a clinic to an HPC cluster, how does that functionally happen?

And how do you design a system that allows it? And then secondly, how do you get to the right person to have those conversations? We talked a lot about the enterprise architect in the last session. Let's talk about the role of enterprise architect in all of this that we just talked about. Is the enterprise architect the right function to be able to stitch all of these conversations across workload types, business outcomes, and the point at which we're actually talking to, Tim, forgive me, the business about the value of these systems.

Is it the EAs? That just seems like a lot of responsibility. I'll jump in on that, Keith. I think that's a lot to expect any one person to be able to do, but the enterprise architects probably have unfair expectations on their plate. Now, what a lot of EAs are doing is they're fighting the wrong battle. They're fighting about IaaS and PaaS and SaaS and CaaS. We had a discussion on social media about that the other day. In my opinion, I'm gonna introduce a new term here to remix.

I think all the public providers to a certain extent are pushing CaaS, but not containers confusion as a service. There's too much stuff to figure out what in the world I'm supposed to be doing. And the reality is I need to come back to what is the problem I'm trying to solve. So I'll simplify it. I wanna piggyback on something that Matt said. If I'm an enterprise architect, I should be able to solve this question. What are the three Ds of data?

Talk about data storage, data transport and data organization, right? Databases, data lakes and data warehouses, because we know data is the lifeblood of the enterprise. That's really where the rubber meets the road. So if an EA can at least start to think about data, then I think it expands their mind beyond tooling and technology to think about how that's gonna be used throughout the entire enterprise. But most can't do it. There's also a simple question though, Bobby, that they have to be asking first, and that's how and why.

And so this is the part that I think gets lost in translation and where we kind of get wrapped around the axle as we get so caught up and we've seen this, gosh, I can't tell you how many times I've been in conversations about data warehouses that went on for months, trying to architect the right schema and the right architecture for that data warehouse. And guess what happens a month after it goes into production? It needs a change. And so my point to this is that I think we put too much structure in, I'll just say the broader IT organization.

We really don't encourage nor give people license to think. And so I think this is where we've kind of lost creativity in IT as well to step back and say, okay, I'm an enterprise architect. Am I the right person to do all these pieces? Well, probably not. So who do I need to bring into that circle to be able to have that fruitful conversation so that we are working cohesively as a team rather than this just coming down to one person or one given team.

Usually, at least in the organizations that I've led and been part of, it's not typically one person, it's usually the EA is a function that's a team of people, so larger organizations. But I do think to your point, you have to step back and ask yourself, so what data, where's it coming from? How's it going to be used? How could this be changing down the road? How do we ensure that we're creating the right degree of flexibility? Because we know that in the last 120 days are a perfect example of this.

The world has changed on a dime. And guess what? Six months ago, you could have said the same thing that the world is changing. We're working very differently. Our customers are looking for something very differently. The technology that we have access to is very different. And so we have all of these opportunities, but we really need to encourage our staff to that license to think and be creative and help them be kind of more involved in the process than they have been in the past.

So I want to wrap this up in the next five minutes. And if anyone in the chat wants to chime in, let me know. This is a lot. Just, I mean, we've covered a lot over the past two panels. And obviously not every organization is going to have all the skills they need to even start. So they're going to need to go out and get help from folks like Tim, from folks like Joe, even from our vendor friends, Bobby and Matt, added greatly to the overall conversation.

What types of questions should we be using or asking to filter out if the advisor or the vendor has done their homework and they really know how to do the hard work? Because, you know, we see the marketing material, but once we pull back that layer, we're like, oh, you know what, my team could have provided, you know, much better commentary than what I've gotten from these advisors. Boy, a great thought about that. There's been this consistent advice from this group, right?

Which is understand the thing that you were trying to do at the business level before you go and embark on these projects. The fantastic litmus test for your vendor is get engaged, articulate that business problem. What are you trying to solve for? You know, what are the parameters? And then get to a position where you can ask them to kind of give that back to you. What do you think you're solving with, you know, whatever it is that you're proposing?

And don't listen to the speeds and feeds part of that conversation. Don't pay attention to it's the flash hotness this, or it's the cloud agile that. Listen to if they can articulate the business challenge back to you and they understand what you're solving for. That's a great first step at the very least. I'm going to answer different. That was good. But because the driver is important. So we always say to them, okay, what's the driver for this project?

And we get like this various set of answers sometimes, right? They're not able to clearly, customer isn't able to clearly articulate what the driver is. Well, because you know, we think we should go to the cloud or we think we should do this. Well, no, why are you doing this thing here? The other thing that I want to share with you guys, it's super fun and super interesting is we put together a scorecard for the IT team. We're agnostic. We don't really care who they pick and we put together a scorecard for them.

And we send it out to the decision makers in the group and we ask them to just answer the scorecard and send it back to us. And how they pick a vendor and what they think is important is so telling, right? To us, because think about for a minute how vendors get picked. How do they get picked from an IT team? Is it a consensus to somebody just raise their hand and say, I like this guy, I like that guy, I like this other guy, right?

Bobby shaking his head. Bobby, what would you say? Honestly, who went to golf or who went to dinner with somebody? Yeah. Yeah. I would, I wanna also add to what Joe was saying. A lot of times folks, and also what Bobby was just commenting on, a lot of times it's who you know, right? But, or who do you know that someone else, it's that one degree of separation or two degrees of separation. But I think that the piece you have to be careful about is you need someone that understands your business because at the end of the day, and I'll harp on this again and I'll sound like a broken record, but you've gotta understand your business foremost.

Otherwise, it's just tech for tech's sake. Once, but the same thing should be true for your vendors. They should understand kind of at a fundamental level. And I don't mean the motherhood and apple pie version of healthcare or financial service. Great, you do a bank. So people go into the bank and they get money from the ATM. They need to know a deeper level than that if you're talking about working with a bank. But the other piece you have to be cautious against is don't create a requirement that they have worked with your industry before.

So I've run across a number of cases and I'll just use myself as an example of this. The very first time that I worked with a healthcare client and the very first time that I worked with a financial services client, these are both highly regulated industries. I personally didn't have experience in either of those industries at the time other than just being a consumer of each of those different functions. But the reason why they brought me in was because they didn't want someone that was jaded to that industry.

They didn't want someone that just said, hey, this is the way other healthcare providers do it or this is the way that other financial services in that particular niche do things. They really wanted to bring advice and expertise from other industries to bear. So for example, I could bring a major airline into healthcare or healthcare into financial services. And so it's important to understand what they've done but don't create a requirement around it. How flexible are they in terms of really kind of doing their homework and understanding?

For example, if you wanna ask them and this is a great test, ask them what they think, ask the vendor what they think your top five objectives are, your top five core issues are and see if you get two to three of those that match up with what your business objectives are. If the answer is yes, great. If the answer is no, move along. Yeah, and some advice to vendors because I've been there as a vendor for a very short period of time.

And even in my role now advising folks, I don't wait until I have that meeting with the person who cares about that. Everyone should care about that question but the person who's gonna make the decision based on that answer, I should already know the answer to that question. Great question, but the part of doing the homework and not just vendors. If you're looking for a job and you want to work in one of these four thinking organizations, do your homework. Homework isn't, oh, iSCSI versus NFS versus FAO.

That really doesn't matter in the long run. That stuff will work itself out. What works itself out is if you can describe why iSCSI, if at all, makes a difference to reducing the wait time for someone sitting on a bus stop, then that absolutely matters. If it doesn't, you know what? Let the vendors figure that part out. This is where IT is moving, in my opinion. Any last comments, questions from the audience? Bobby, I see you kind of have something percolating, burning that you want to get out.

Anybody have anything they want to get out before we wrap up? You know, you talked about vendors, Keith, and I think when it comes to the enterprise, if I was sitting in the seat of an executive making a decision, I don't want to know your success. I want to know where you failed. I want to know where there was a dumpster fire when you were done. Now you pulled it out of the trash can and you're a savior, but like something crashed and burned and it was hideous because the challenge that we have, Keith, in any sort of cloud projects is that our time horizon is too short.

And I'll tell you what I mean by that. The definition of success is too short-sighted. Does success mean you got to the cloud or does success mean that you can get out if you need to? Does success mean that you didn't have to retrain or fire all your staff? Like how many dead bodies were there when this thing was all done? Too many of us are kind of in the first generation, maybe second generation of this, and we're redefining and figuring out what success looks like.

So from a vendor, I want to know where stuff has not gone well before so that I can learn from that and not hit all of those landmines. If you're not willing to be honest with me about that, I've been married 20 years, Keith. I'm not going to buy a book from someone who just got married yesterday. Love your thoughts, but it's on paper that hasn't been proven yet. But the reality is, Bobby, I mean, let me counterbalance that. The reality is from a customer standpoint, I'm not going to tell you where my problems are or where I've had issues.

And the reason why is because most vendors have burned that torch profusely. So that's just open shooting field, right? It's like, just open up the wallet and it's just shooting fish in a barrel, right? I can't iterate. I was so surprised from my role at PwC versus my role at VMware. Like at PwC, it was open to the kimono. I know that's overused, but it was like, here's our problem, help us fix our problem versus from a vendor perspective, yeah, I'm not going to tell you what our problem is because you're trying to sell me.

Yes. Yeah. But Keith, this comes back to the reasons why that does work in certain situations and not others. And it goes back to relationships and trust. If I have trust with you, if I trust Bobby, yes, absolutely. Bobby, come on in, close the door. I'll tell you exactly what's going on. Here's my list of issues. Any of those you can help me with? Great, pick and choose. But if I'm going in and I just met Keith off the street and Keith comes in, I'm not going to share it with you until we build that trust, we have that relationship.

And then it's just like Bobby, I'm going to share what's going on. I think that just again, Tim, and I agree with everything you're saying, the challenge that most of us have is that people are asking the wrong questions. Yes. And so trust comes in because there are a lot of consultants that said, okay, you asked me how much computer is going to cost me in Amazon. Here's your answer for that. What I didn't tell you is all the other stuff like egress and shoddiness.

And so I need to be able to tell you, this is what you didn't ask me, Tim, that you should have. And if I can't earn that right, then it's again, it's not the tech, it's can I steer you or lead the witness so that you don't come up short just because you didn't know to ask the right question. A lot of us have soldiers pointed in the wrong direction. We brought firepower to the fight, but they're fighting the wrong people. That's right.

I come for the conversation for the Bobby's analogies. Joey, did you want one last comment? Yeah, I was going to say like, guys, let's talk about a metric driven approach to a decision. Let's have some quantifiable reasons, both hard and soft, meaning cost-based features, functionality that we utilize to make that decision and take that up to the CIO instead of just picking somebody. How about that? So we're close out there. We have had two really great conversations. We've all sent this to our network of folks.

You'll be able to see the replay of this on YouTube. It'll come out as another CTO Advisor podcast next week. Share it with your fans. If you guys have any questions, hit the folks up here on either Twitter, because we're all very active on Twitter or at our respective portals. We'll end out with everyone saying where people can reach them if you're listening to this in podcast format. Let's start out with Bobby. com. Thanks for having me, Keith.

Thank you. Bobby, tell them. com. Matt? Yeah, Twitter, it's just at Matt Wallace. So that's pretty easy to remember. com if you want to email me. And finally, but not least, Joe. I'm digitalcloudgal on Twitter. And you can find me on Twitter at CTO Advisor. And obviously you found me somehow because you're listening to this, talk to you next, CTO Advisor, CTO Dose.