The Enterprise Mobility Roundup

Best Practices for Deploying Technology on Existing Infrastructure - with Guest Jeff Brown, Lowry Solutions

BlueFletch Season 3 Episode 260

Unlock the secrets of seamlessly integrating cutting-edge technology into legacy systems with insights from Jeff Brown of Lowry Solutions. Learn the crucial distinctions between Greenfield initiatives and projects that must harmonize with existing infrastructure. Jeff shares his expertise on conducting meticulous surveys, navigating technical debt, and making informed decisions on upgrades, ensuring mission-critical applications remain robust and reliable. Discover practical strategies on balancing innovation while respecting the intricate web of enterprise systems that businesses rely on.

Ready to bring innovation to life through Proof of Concepts (POCs)? Listen to the best practices for running successful POCs and pilot projects. Understand the importance of a solid backhaul infrastructure, setting clear success criteria, and crafting a plan for discontinuing less-than-successful trials. We also dive into the current landscape of unified endpoint management solutions, comparing the enterprise viability of Android versus iOS. Finally, we explore the emerging impact of AI on mobile enterprise technology. Don’t miss this episode packed with expert advice and actionable insights for anyone looking to modernize their tech strategy. https://www.bluefletch.com

Speaker 1:

Hello and welcome to another episode of the Bluefletch Enterprise and Build Around it podcast. Today I'm joined by Jeff Brown from Lowry Solutions. Jeff is a senior sales engineer at Lowry. He's doing a lot of actually making pieces work at their clients and with their clients, and today we're going to be talking about installing applications on existing infrastructure, installing new technology on existing infrastructure. Jeff has a lot of experience doing this. I've worked with him for, I think, almost 15 years now and I know we've worked on a lot of different things. But before we hop into questions and talk about this topic, jeff, do you want to give me a quick overview, maybe background, of yourself, what you've worked on and what you do at Lowry?

Speaker 2:

Sure, my name is Jeff Brown. I'm with the Senior Sales Engineer at Lowry Solutions. I've had the great privilege to be involved in the wireless and mobility spaces for about 20 years now, started out my career as a network engineer and application developer and was able to work implementing some of the first 802.11b wireless infrastructures in retail environments. I had the great opportunity to segue from the wireless space into the mobile device space. Once all the infrastructure was in place, everybody wanted to put their clients on there, so that allowed me to watch the evolution of the industry as we started off with all the pocket PC and Windows CE, windows mobile platforms, an opportunity to see the emergence of Android as a very viable enterprise-based operating system, and I've had the great privilege to be able to implement systems based on mobile devices and Android operating systems for a variety of different customers over my career Awesome.

Speaker 1:

And you know, I guess, just to reframe the topic a little bit, I think one of the through the background on this I know we had a couple of projects recently with the Lowry team. So Bluefudge does single sign-on security for mobile devices and does some application development on Android, and one of the things I noticed is how smoothly Jeff and his team were able to help get new technology onto a customer that already had a large set of existing devices in their facility. So I wanted to talk through some of those topics, but I think the first piece of that topic that comes to mind is actually thinking through or just framing the difference between Greenfield and I call it, existing tech, and maybe you could talk a bit about your experiences, like how do you think about Greenfield technology versus new technology? What are the key differentiators for you?

Speaker 2:

Yeah, you know, everybody dreams of having a greenfield opportunity where there's absolutely no existing infrastructure in place and where you have an opportunity to go in as a solution provider, as an engineer, survey the landscape, get an understanding of what the environment's like and design at least what you believe is going to be an ideal system from the ground up right.

Speaker 2:

It gives you an opportunity to pick the best of breed, the newest technologies that are available, and when you have everything, new problems are expected and there tend to be a lot more tolerance for the types of issues that tend to come along with the greenfield implementation.

Speaker 2:

When you have existing technology, there's always the challenge of all the variables that are going to be in the environment right. In a greenfield environment, at the very least you can specify a homogenous environment where you have all the same devices, or at least all the same generation of devices. When you've got an existing environment, there's usually some number of devices that have been deployed. As the organization grew and as the organization expanded their use of mobile devices, and because those mobile devices were probably started out as just something along the lines of an add-on, they weren't necessarily treated with the seriousness that an enterprise platform ordinarily would be treated with. So with the pre-existing environment, it's really important to do a very detailed and thorough survey of the current landscape so that you can understand which of the platforms and environments you're going to be able to pull forward into your new world and which ones are unfortunately going to have to be left behind because they just lack the technical capabilities to implement the solution that you're looking for lack of technical capabilities to implement the solution that you're looking for.

Speaker 1:

It's a good segue into my next topic, next question, which is I call it the technical debt and experiences around technical debt and the way I describe technical debt and from the software side, it's you know, you develop something. There's a bunch of code that does things a certain way. It may not be the ideal. There was a guy who decided to do it a certain way and even on the hardware side I've seen things like where people will you know a CIO will come in and be like we're going to roll out iOS devices and doesn't know anything about actually managing devices and as a engineer, you end up having to come in after the person and clean up that mess or deal with that technical data, which most people refer to as cleaning up technical debt, whether it's infrastructure or on the software side. For you, when you think about the pragmatic approaches to cleaning up technical debt, like what to actually touch versus not touch are there any guidance or guiding principles you use with your team?

Speaker 2:

Yeah, I mean you have to understand where that particular product or solution is in its organizational lifecycle. You have to understand where that particular product or solution is in its organizational lifecycle. In some cases you may have a legacy application that no one intends to replace because it's been performing its function for a long time, but it's mission critical. In instances like that, there may be a case for leaving some of that legacy technology in place, with the understanding that it necessarily has to be left behind at some point so that you can move forward into the new generations.

Speaker 2:

I mean, that's one of the things a lot of people really don't consider is what do I do with all this hardware? You got to understand that these are expensive devices for the most part, right? The cost of a mobile device is much more expensive than a typical desktop solution at this point, not to mention it's something that would be lost a lot more readily. So you'd want to make sure that it's definitely a worthwhile investment in your environment. So, yeah, there's always going to be a demand to maintain that legacy equipment the best that you can, but it cannot be a limitation. It has to be identified that these platforms cannot come forward. These are the platforms that are viable to move into our new infrastructure. And then the last part of that is what is the forward strategy, so that we can continue to maintain this environment as we grow and change over time.

Speaker 1:

Do you mainly see technical debts? I know Windows CE was a big technical debt for a long time for a lot of companies. On the mobile side, I feel like there's a lot of green screen or legacy, like AS400. Are there certain areas where you see more technical debt that falls into that category? You described where you need to build that plan and roadmap. Sure.

Speaker 2:

The thing that I've noticed is it depends upon the value of the business operation where the devices are. So when you're dealing with very cost-centric parts of the business, especially in the supply chain, there's always a lot more reluctance to invest heavily there because it's all just cost of doing business right. Most of those kinds of innovations are driven by some sort of efficiency options as opposed to driving new business. So dealing with technical debt in a warehouse-y kind of environment where you've always had basically basic, simple applications, perhaps just a green screen with some sort of ADC, either RFID reading or barcode reading, those processes don't change very much over time. But as you look at other industries retail in particular where the mobile device is much more of a key component of their strategy to drive sales and drive revenue into the business, there are a lot more opportunities to justify replacing those sorts of infrastructures because there is a potential additional revenue stream that goes along with it. So that's the main difference in environments as far as I can see stream that goes along with it.

Speaker 1:

So that's the main difference in environments, as far as I can see. Yes, it's the employees that are actually dealing with the customers, make them as efficient as possible, which is why retail has typically been a leader in that space, exactly On the warehouse side. Do you see that retail model slowly, I guess, coming into the warehouses where it's not just a green screen device, it's also a green screen, it's training, it's communication, it's multi-apps? Do you see more and more of that with some of the clients you work with?

Speaker 2:

You know, it depends upon the size of the organization themselves and what their ability is to do innovation right.

Speaker 2:

If you're talking about a large enterprise customer that has their own internal IT shops, you're always going to see a lot more innovation there because they have internal resources or they can acquire the resources that are needed to be able to innovate along those lines right. When you get down to the small to mid-sized businesses that don't have the resources either capital or internal technical resources they're the ones that are a lot more challenging just because they literally don't have the resources to innovate and change. Nor is there really a strong driver because the business hasn't changed a whole lot. That being said, right, everyone's looking for ways to make those green screen picking opportunities more effective as applications that do more of a product identification, where not only are you getting a description of the thing that you're looking for but you also see a picture of the actual item that you're looking for. That can help a lot in facilitating complex pick operations that you might have in some sort of a retail distribution warehouse.

Speaker 1:

Yeah, I think. The other thing that made me think of when you were saying that is, the actual types of end users in those facilities are probably different than retail.

Speaker 2:

Retail typically has a little bit longer employment term than a lot of the warehouses I've worked with and their end users Absolutely Most of the associates in my experience in a warehouse or logistics operation, they're very much task oriented, where they're going to perform a specific task for their entire shift. In a retail environment, if you're not a cashier, if you're a reseller, there's a lot more variability in the roles that they perform during the day, which is why it's a lot more important for them to have a device that can allow them to accomplish those different roles without having to switch devices right. In a warehouse, you scan barcodes all day long and you have a barcode scanner that is designed to scan barcodes all day long. But in a retail environment, you're interacting with customers, you're scanning product, you're looking up information, you're using it as a voice communication device, you're sending text messages back and forth to other associates in stores. So the retail environment is definitely a lot more complicated.

Speaker 1:

So you touched on mobile devices, you touched on software and some of the backend pieces. What's your read on the state of I'm going to call it networking and Wi-Fi infrastructure in facilities? Do you feel like it has gotten into the 21st century yet A lot of the customers you work with, or is there still a mixed bag on the infrastructure side for networking.

Speaker 2:

Yeah, it's kind of like it depends on when your house was built, what kind of windows are put in it right.

Speaker 2:

There's a lot of costs that goes along with wireless infrastructure and when you look at deploying wireless infrastructure in large facilities that there are a lot of, that's a tremendous capital cost and the cost of ripping it out and replacing it is also extremely high.

Speaker 2:

So there's an incredibly mixed environment of infrastructures that are capable of supporting the new Wi-Fi 6 and all of the newer wireless LAN technology that has been built for high density client environments. There's still a lot of infrastructure out there that was built for low density client environments. There's still a lot of infrastructure out there that was built for low density client environments and then we've had to adapt them into higher density right and those are always going to be challenges, especially when you're talking about a noisy environment like a warehouse or a retail environment where Wi-Fi is problematic. That's the great benefit of going with a greenfield solution, especially if you're going into an environment where you're wanting to do telephony and voice kinds of applications that are really really sensitive to latency and the customer experience and the end user experience in assuring that when you do go into production you're going to have the kind of success that you're looking for right. The older the infrastructure is, just the more challenging it is likely to be to get the performance that you're looking for.

Speaker 1:

There's also the one thing I'm not sure you mentioned it the backhaul pipe. I've seen people that rolled out Wi-Fi 6 and still have like a crappy 1.5 T1 on the back end.

Speaker 2:

Oh, I'm sure it's still slow. I didn't even consider that. You know, once upon a time all of our infrastructures were local, and so if you did have some sort of mobile device, most likely it was doing a lot of its communication applications that were on servers that were hosted on the same local network or most often even co-located in the same physical environment. But that's not the case anymore. Everything is hosted somewhere else, and the chain of communication is so much more complex that not being able to understand where things are breaking when it does break makes troubleshooting much, much more challenging. So, yes, that's a big component. You've got to consider your backhaul. It's not just your local LAN environment any longer, it's the carrier, it's all the points in between, it's the kind of infrastructure that, it's the hosting environment. Yeah, those are all key considerations.

Speaker 1:

On that note of like thinking of putting new software and I know one of the things you and I have worked on a couple of different organizations around pilots and POCs Do you have any like hard and fast rules for here's like the three things that Jeff recommends If you're going to POC you know a new piece of hardware or software, make sure you do it this way, like what's your, what's your playbook or runbook for that.

Speaker 2:

You know, a lot of it involves semantics. Right, In my world, a proof of concept and a pilot are two very different things, but people use those terms interchangeably and I think that's a big mistake and the way I differentiate the two is. A proof of concept is you have an idea for some technology solution you think is going to help your business operation, but you're not sure you know how to build it. You know what it looks like and you're going to go ahead and build it and put it out there with measured goals. Right, I'm going to prove this. Concept either works or it does not. If the concept works, it may go to pilot. A pilot is something that you have decided is going to go into production. It is going to go into deployment and this is the first one of them. That's what a pilot installation is.

Speaker 2:

So if your organization is looking to validate some new technology or some new business process, that should always be handled with the proof of concept. It should have very clearly defined success criteria so that you know if it's achieved the goal that you set out to achieve with, and it absolutely must have a defined duration. One of the biggest challenges for organization are proof of concepts that never go further than a proof of concept. And the next thing you know, you have seven or eight different specialty solutions that are out there and the organizations that spun them up are no longer around to support them and they become zombies of a sort. They provide some function but they're not going anywhere. And proof of concepts if they're unsuccessful, they must be ripped out, and that way you're prepared to go for the next one. Maybe there's going to be another iteration, but that's a separate proof of concept with different measures of success and a different timeline to achieve.

Speaker 1:

I love that articulation the zombie projects, and I think it's it's. It's so important to think through that difference between a POC, a pilot. A POC and I talk to people all the time it has to have an end date and you have to commit to turn it off.

Speaker 2:

If it's a pilot, there has to be a day two plan.

Speaker 1:

Yeah.

Speaker 2:

Right, there has to be a day two plan before you go to pilot, and proof of concept never has a day two plan.

Speaker 1:

Day two in your book. I call it run, but can you articulate how you think about day two and what that looks like? And you're thinking operationalization of a product or technology.

Speaker 2:

Yeah, it's the ongoing care and feeding right.

Speaker 2:

Day one everyone is focused on getting that feature functionality out the door, up and running, and everybody knows it's not going to be right the very first time, right, and so, before you go to day one, there has to be a plan for day two in place.

Speaker 2:

And the day two things are okay. When it doesn't work as expected, what are we going to do tactically to address the issues that are affecting our user right now? And then, what are we going to do strategically to remove this particular problem from our application and make sure that it doesn't recur anymore? Right and so, yes, that is all your operational concerns, but a lot of people, I think operational is commonly it's built, we're going to run it as built, but systems aren't like that anymore. There's not only the how are we going to run it, but how are we going to enhance it and keep it going and what is the planned lifecycle for this system? On day two, I know that I expect this program to live for two or three years. I believe it may live five, and if those are the things that are going to happen, how am I going to plan accordingly, right? Yeah, over the that are going to happen.

Speaker 1:

How am I going to plan accordingly Over the next five years from your standpoint? Just to go back to the POC pieces, how do you think about cost justification? I know one of the things a lot of clients we work with have a heartburn around is I don't want to POC something, spend a bunch of money on it and then not have it go to production, which I think is a completely wrong attitude to have. But how do you frame that for people? How do you think about the cost justification of a POC that may or may not actually?

Speaker 2:

go to production. All businesses have to continue innovating and because the mobile space is such an innovative space, there are a lot of opportunities for you to find help in developing a proof of concept, right yeah.

Speaker 1:

Maybe another way to frame this is like how do you convince the guide to say we're going to put money into this even though we may turn it off?

Speaker 2:

Fundamentally, I don't believe you can. That's why I'm having a hard time answering this question. Fundamentally, I don't believe you can. Either they are willing to invest what's required to do a proof of concept successfully because they think it has value as a business process right, we need to try new things and see if they work or not. If that company isn't willing to innovate, I would say that they're probably going to have some struggles.

Speaker 2:

Otherwise, right, I mean, a desire to innovate in your business has to be part of the DNA of that business. So you have to be willing to take some sorts of risks, and that's why it's important to have a champion internally and have those internal stakeholders and make sure that your business is aligned. If the business is aligned behind the concept of the proof of concept, it's not a difficult thing to achieve. But that's where it becomes. It's an internal thing for the sponsor of the initiative. Nobody's ever, no one was ever able to sell me a project when I was in a position to do those things. It had to be something that we needed to do or wanted to do, or it wasn't going to happen at all.

Speaker 1:

Yeah, like that's a good point. It makes me think of the. When you're going and asking somebody for something, the best answer is yes, the second best answer is no, the worst answer is maybe, maybe, yeah, for sure. I feel like something that gets stuck where it's like we want to innovate but we don't want to spend the money and have stuff fail. I think that's not going to happen.

Speaker 2:

It's spot on and a lot of those things. I mean, they're really organizationally dependent, right no-transcript.

Speaker 1:

Lowry has been leveraging Bluefletch for single sign-on and some of the tools. We have Android devices for a couple of different clients, but are there certain areas where you're seeing clients outside of what we do? Are there certain other areas you're seeing clients outside of what we do? Are there certain other areas you're seeing clients go run POCs and go test and try new things out that you think everybody should be putting their hat in the ring and trying different things out, whether it's mobile devices or certain areas of software communication tools? Is there anything that stands out to you as people should be doing more innovation and POCing?

Speaker 2:

people should be doing more innovation and POCing. I had the great opportunity to work with some customers many years ago that were the first ones to sort of embrace the enabling communications amongst your associates inside of your own building and using the mobile devices to do that. It's taking a while, but I have seen more of the large customers starting to embrace. The best way I can describe it is the mobile device is no longer a point solution but it's become a general purpose tool, kind of like a PC was. And so, as they're realizing, hey, I can do more with this mobile device. I can enable them to communicate with customers, they can communicate with one another, I can use them for task allocations. There's so many different things that can be done with a mobile device.

Speaker 2:

As the infrastructures have matured and as the organizations have matured, you're starting to see a lot more uptake of those things, right? You know, the whole idea of carrying around a mobile device in a retail environment and talking to customers and talking to other associates was a really new idea, like 10 years ago, I mean, no one was doing that yet. And all of the other components from the mobile device platforms have become more capable. We've had major advances in wireless technologies that have allowed us to put more clients in the same space with higher bandwidth requirements. It's taken a while for all of these different technology pieces to mature enough to be stable to see the organizations willing to take a risk on their business, on them. So I think we're definitely going to see a lot more of those.

Speaker 2:

We've seen some of them in the grocery environment. We see a lot of it in soft goods as well. So it's an evolutionary process, right, the early adopters got out there a long time ago, and now mobility and wireless is mature enough that everyone realizes it's an essential business component. And so everyone's coming to the table, not just the rich companies with lots of resources right, with lots of resources. Right, yeah, and the ecosystem's fleshed out a lot better tool. There's a lot better tools that are suitable for different size businesses. Right, you don't have to run SAP to do your business. There might be a smaller application that can help you achieve those goals, right?

Speaker 1:

Without having to build your own right.

Speaker 2:

Exactly. I mean, there's a vast ecosystem in the mobile space of software integrators and companies like yourself who can do custom development of applications, who can provide mobile device management services, can provide launcher features, things that a customer might have had to go to a big MDM solution before. Well, now there's a much smaller, medium-sized solution that doesn't require as much overhead. There's a much smaller, medium size solution that doesn't doesn't require as much over.

Speaker 1:

Yeah, I think what you talked about earlier with thing everything's moving to the cloud definitely makes it easier to try out those solutions, test it out and get it and the single sign on piece the single sign on piece that you were talking about earlier.

Speaker 2:

You know the mobile device was a point solution. You came in at the beginning of your shift, you badged into it, you signed on, you ran it for the whole shift and then you put it away at the end of your shift. But now you know you may hand that device off to someone else. They may need to log in it. Now. It's just not a single application. You may have five, six, seven, eight, ten different applications. Well, you can't be signing into eight or ten different applications every time you want to switch back and forth. That's why it's so essential for the single sign-on piece to be there. It took time for the applications to become rich and complex enough on the mobile devices to demand that solution, just in time for BlueFlesh to come along with the solution.

Speaker 1:

Yeah, you mentioned the MDM side. I know you've seen a lot of evolutions in MDM over the last 15, 20 years. What's your readout on the current state of the MDM marketplace? Is it Intune's eating sodium AirWatch? How do you feel about that when you look at clients and the folks you work with?

Speaker 2:

It's very much size of the organization and culture of the organization. Microsoft is so dominant at the desktop and server world that a lot of businesses that are already doing Microsoft tools will prefer to stay with something like an Intune, because they already have resources available that know how to operate it. That being said, you know there's a few major players in the industry. They all operate in similar functions. Some of them have better exposure of APIs so that you can automate some of its functions. Sodi and Workspace ONE in particular, allow for external tooling to manage the clients that are inside their unified endpoint management solution, but not everyone requires something like that. But not everyone requires something like that. You know what you need to manage a fleet of 10 or even 500 devices is very different from what you need to manage a fleet of 100 or 200,000 devices. So there are tools once again that are available for every layer of that stack. It just depends on which is going to be a best suit for your organization.

Speaker 2:

So true, so true they're all very capable at this point.

Speaker 1:

Yeah, another just question on that. Like the devices themselves, I know Android has supplanted Windows CE. What's your thoughts on Android versus iOS in the enterprise? Do you have any beliefs, one way or the other, as to which works better in different scenarios?

Speaker 2:

Once again, it depends on your clientele. What your end user wants is really important. I have worked with clients who used exclusively iOS devices because that's what their end users demanded and it fit into the business that they were doing right. There's a tool set that's available for iOS devices for you to deploy configurations. They have Jamf, I mean. There's a whole suite of tools available.

Speaker 2:

That being said, apple iOS has and always will be designed for a single end user type of use case. That device is designed to be tied to a person, a single individual. Android, at least, still has the concept of a shared device and has that functionality where I can enable all the functionality of this device without having to tie it to Brett Cooper at bluefletchcom, which is something that's still really challenging in the iOS world. Not to mention, ios is iOS. You get what you take. They release a new version every month.

Speaker 2:

There's an extraordinary amount of churn that goes along with those new iOS releases if you're running at an enterprise level and having to go back through and validate all of your applications and revised configurations that have changed with new features. Android, to my notion, is designed for the enterprise user. It was designed for a multi-user environment Originally, a lot of the device management kinds of features weren't necessarily built into the operating system itself, but that created a vibrant ecosystem of third-party vendors who were building tools that allowed you to manage an Android platform the way it needed to be managed in enterprise controlling the user interface, controlling the configuration of the wireless LAN, making sure that certificates were deployed and all those things. So I that's probably the biggest difference there.

Speaker 1:

Yeah, definitely be interesting to see how it plays out. I feel like Google is starting to get a little bit too much like iOS, with some of their really focusing on the consumer and not thinking as much about the enterprise as they have in the past.

Speaker 2:

Yeah, in a previous life I did have an opportunity to meet with some of the Google engineering team where we had an opportunity to express the direction that everything seemed to be headed was more of an Apple IOS-y kind of environment where the Google Play Store would be the end-all, be-all for distributing applications, be they internally developed applications or third-party applications.

Speaker 2:

And while that kind of a model works really well for smaller medium businesses, there was a concern that they were going to engineer out all of the third party unified endpoint management, mdm kind of functionality, and so I think I would like to think that maybe we were influential in helping them understand that while, yes, android is largely a consumer operating system that's most of you know the vast majority of the installed base is consumer phones there is a massive installed base of enterprise users who have a slightly different usage model than a typical end user would, and so I'm optimistic that the fact that we do still have this feature functionality, that the device owner versus device admin, that they've been continuing to build bridge solutions right, are going to keep us from being all forced into an Apple Play Store in the Android world in the future, and that's one of the reasons why I prefer Android today is because it is open that way.

Speaker 1:

Yeah, same here, and I don't know the idea of a vendor automatically pushing something to me without me being able to control. It is terrifying. And it's even more terrifying after the Microsoft CrowdStrike issues in the last couple of weeks. So it's yeah.

Speaker 2:

And you have some customers who want. I mean, once I have an operating system particular version, I am locking it on this. I do not want it to change to avoid all of those kinds of things, and that's a lot more difficult to do. You can put off iOS updates for a short time in the Apple world, but eventually it's going to create challenges for you.

Speaker 1:

Yeah, you got to take those, got to make them happen. And then just a bit further out or further afield, do you have any thoughts around some of the newer technologies, like some of the AI pieces? I feel like it's pretty nascent on the mobile enterprise device side, but are you seeing anything with AI at all in the next six to 12 months that you're looking at or you're playing with?

Speaker 2:

I know a lot of people that use it to write marketing literature and do things along those lines my kids writing their homework with it. Yeah, I mean, I remember when nanotech was the big thing. I remember when blockchain was the new thing. I remember when RFID was the new thing, right and so a new thing being a new thing, and the period in time when it becomes viable as a technology and the industry and everything else. Sometimes there's a really long period of time there.

Speaker 2:

So I think a lot of the AI is going to be much more on the data analysis on the back end side, at least early on that, and creative spaces, because I think it's going to allow people to take shortcuts at doing things like writing papers and doing copy and even writing codes. That's doing things like writing papers and doing copy and even writing codes, but, specific to the mobile space, I think the compute limitations are going to keep all that stuff in the cloud and that's probably going to keep it at least somewhat out of the business space for a while. I don't know. It's going to be kind of interesting to watch.

Speaker 1:

Yeah, we'll see where it goes. See where it goes, awesome. So, just in summary, a couple of key points. I had goes, see where it goes, awesome. So, um, just in summary, a couple of key points. I I had a number one um, you think about innovation and poc is definitely something that that if you want to be an innovative company, you have to have the pocs. If you'll write those off, um, I think, on the technology side, understanding that changes in infrastructure, as uh seems important. I think some areas talk about the wi-fi, the backhaulhaul, those pieces, and then, from a standpoint of technical debt, understanding when to clean it up, when to leave it, how to build roadmaps around it definitely key and very, very important. So, jeff, thanks for covering those with us today.

Speaker 1:

If people want to find out more about Lowry, where would they go? What's your website? Or where are you guys on LinkedIn? Sure, we're on lowrysolutionscom. Um, that's where you can find everything about w lo w r y, no e, no e, okay, correct, yeah, lowry solutionscom. And then, uh, you guys are on linkedin or any, any other good, good spot to see you. We're in all those places, all those social media places. Well, jeff, thank you for joining us today. We'll include a link to Lowry with the correct spelling, because I'm bad at spelling. We'll include that in show notes and, as always, if you have any questions, feel free to reach out to myself or Jeff Brown. Appreciate it and have a good one. Thank you, brett.