Software Engineering as a Service – Koray Ozcubukcu, Blue.cloud

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Corey. Oskobucho who's CEO for blue cloud, and we're talking about software engineering as a service, which is kind of sort of A New Concept for a lot of folks Corey. Welcome to show.

Thank you very much for having me. So what do we mean by that exactly in this day and age where everything is a service? But how does one actually do software engineering as a service?

Um, yeah good question. So I mean it's it's not necessarily a very New Concept right? Obviously Outsourcing certain functions has been with us for a long time.

But because of the conditions in the market, especially in the last five to ten years this is becoming A more viable option especially after the covid in technology area. Everyone seems to be liking working remotely. Now this is becoming a really valid option.

So what we mean with that is let's talk a little bit about some of the the things that's happening in the marketplace first, right? So every company nowadays regardless of their industry, they have to be a technology company and even if your core business is selling shoes, you gotta have digital presence. You gotta connect with your customers through the digital channel and you got to provide a really good experience for your customers if you want to be a viable business, but at the same time If your core business is not technology, if you're not Google Microsoft attracting tier one engineer software Engineers attracting them bringing them on board building a software engineering function that is really strong.

It's very very difficult in the United States. It's expensive. But even if you are willing to pay a lot of money those Tier 1 Engineers, they don't come work for a non-technology company.

So first you need to attract a leadership, then that leadership needs to pick the right engineers build a function. Um, that is very very difficult. So what is your alternative?

Your alternative is to work with a company like us say, hey. Can I rent my engineering service from you? Can I you know, can I have you be my engineering team?

So that's basically in a nutshell that is what we are offering but then there are a few more things that I think it's important to highlight. It's not just writing code or developing an application and handing it over to our customers, but it is Taking the joint accountability and responsibility for that application. Because any engineer can write an application.

But you got to make sure when you put an application out there in an Apple store or you know on the Google store. It is a like it is a secure application. You take care of your information, right?

So it is also scalable application, right? It may work for three users. But is it going to work for 3,000 users accessing it the same time and also it needs to be cost-effective your application.

You need to make sure that when you write code that could understand the underlying. Capabilities of the the hyperscaler that you're using whether AWS, you know gcp or or Azure so you can minimize the compute time. You can minimize the storage you you can minimize the cost in long term for that application.

So you can bring down your total cost of ownership. All those things goes into writing a valuable application. We take care of all those for our customers as part of the service.

I'll pause here. I'm sure you have some other questions in some regards. It's kind of a managed devops practice for people about how to go build you application that's actually reliable and scales and it seems like we never gonna have enough devops professionals out there.

So there's a whole country of companies out there that need to rely on somebody you can do that as a service. We've had it service providers forever in a day, but do we really need specialists in this space? I mean do a lot of those guys kind of have outdated methodologies for building these types of applications.

What attract somebody to some company like blue cloud. Um, yeah, I think it's it's a loaded question. So I think these are the you know, I mean you you highlighted some of those things.

It's I think it's gonna boil down to you know, I I try to put myself into my customers decision makers shoes. I think what we are gonna see moving forward is you they companies like blue cloud are gonna offer these type of services. And if you're a business and technology is not the core of what you do.

So again, you're a shoe manufacturer or should retailers that your technology is a necessary function, but it's not necessarily core then then you should be able to Outsource that to The Experts who knows the the latest there are latest, you know technology Trends understand how to minimize your total cost of ownership but make this thing as a service so I think again if you're a technology company that's called to you you need to build it. You need to bring your devops specialist you need to build it. But if it's that core to you you need to rely on an expert company.

I think the key that I want to actually highlight here is what is an expert company. I have been in Consulting for 30 years, unfortunately in our industry, so there's so much noise. And and that's something that we have to solve as an industry moving forward when we say we are an expert.

How do I make sure that I have this joint responsibility with my customer? I put my skin in the game and that one is something that all of the the businesses needs to be asking. To their partners are you in it with me or you're just I'm gonna pay you money and then you're gonna give me something.

So that's the thing that I think next 10 years are in this Journeys to figure it out. How do you build this longer-term partnership that your you know, both both companies have skin in the game customers and the vendor that is missing in our industry. Unfortunately last 30 years.

I saw that actually went into that that joint responsible to rent down hopefully next 10 20 years. We're gonna see a different type of relationship there. I don't know.

I answer your question, but that's it important topic for me as a person who has been in this industry for a long long time. That's something that our customers should be very careful about it's a challenge because not everybody knows exactly to what degree they pieces software might drive revenue for them. So they're not quite clear if I want to share Revenue forever in a day or if they want to have a limited time window on that or and then how do you decide that when the application itself may not be Revenue driving itself, but it's That somebody wants you to do or build.

So how do you put skin in the game for something that for them is a cost per se. It's not really Revenue drivers. So do you have to be choosy about what projects you pick based on the business model that goes with it, right?

I mean, I think there as long as there is the spirit of sharing the the benefits and risks. There's always risks, even if it's not a revenue generating application. There is always a risk when you put a piece of technology out there.

There's always a risk and at minimum everyone needs to agree on the the objectives of the of the application either on the cost side risk side or Revenue side. There's always a way to have that joint responsibility. Do you have enough people to scale your operations or do you have to be choosy about what customers you pick because there's only so many engineers in the world that you can get.

So how do you go about scaling your operations to support multiple customers? Yeah, very good question. And this is yeah, there is a limit how quickly you can scale equality operations.

So we want to make sure that our application development have high quality High Velocity in order to achieve that you've got to have certain you got to be selective a little bit selective when you're bringing engineers. And obviously selective when you're bringing the customers so so far we haven't run into that that issue, but I'm sure at some point if if we are successful which I 100% believe we will be very successful scaling this there is gonna be a limit what you can do. So there are a couple of things that we are doing in that case first you need to build the right team structure.

So what that means is there's always a pyramid that you build you have you have senior engineers and you have Junior in you pick them hand-pick them. So they are really like the right attitude right aptitude type of people. If you build that type of pyramid, then you have the ability to Leverage The you know handful of extremely experience Engineers to make sure that they provide the oversight for quality for security for for scalability.

So that's one way of doing it and then secondly is we're tapping into and this is more important than maybe the first one we're tapping into some markets that is untapped. So that's kind of funny nowadays because it feels like the entire Globe is tapped in but so we are in Eastern Europe right now on certain Camp company or countries that has signific Sequence a software engineering talent and because of the the economic conditions the cost actually is very attractive as well. And we're able to actual provide opportunities to those people to work on really exciting projects for us customers.

And that is that is becoming a secret source for us. Do you think also part of the way you guys think about customers a little bit and yeah, not everybody's a good fit. So if they don't have an appreciation for software engineering, maybe they're not your customer in the first place because they're just going to be looking for the cheapest outcome.

There is rather than the quality gate per se. Yeah, it's a you're right on and that's is not just for software engineering. But any kind of Consulting engagement, my preference is to work with the customers that really values USA.

As a partner. And in this case in the software engineering is the same thing if they're coming to us and saying I know how to do software engineering. So don't tell me anything.

Just give me some bodies to write code. We evaluate that I I walk into that situation with a big question mark and say you may be right and maybe we learn things from you and that's that's okay, but I want to make sure our customers are also open for a dialogue so we can build that partnership. But if they are saying my way or Highway then it is it is kind of like, okay.

Well, then you're really not looking for a company to partner. You're just looking for the cheapest way of accessing resources, and that's not really a A an exciting story for our Engineers if you think about it. Do you care what devops platforms people are using?

I mean, do you have a preference or you know much care with the cicd is underneath it and you're willing to work with just about anything? Well is it is a consulting company we want to respect with what our customer has been using. So we don't have necessarily preference to say don't use that use this now.

Obviously this only applies if our customers already have a platform. if we don't then certainly, you know, we can recommend certain platforms, but it all depends on a the circumstances again, if you know if we use pretty much everything. And you know, but again if if particular skill set exists.

in our companies environment then we prefer to actually go with that instead of trying to be religious about a one technology versus another or one platform versus another, you know again I have I have used certain platforms and I you know, we all have all have favorite platforms and then things that we like we don't like but again that that becomes a kind of religious conversation. So we try to go in and it says the situation if we see a gap between what our customer wants to do and the platform that they have then there's a problem. We raise our hands say we see these things as risks.

Let's do that thing or if they do not have the best practices. So again, I'm kind of generic here. The reason for that is sometimes we have to work within an establishment.

And I hate to go in there. So everything that you have been doing is is bad. So I rather to go in there say okay, you have some gaps here, right and you can run these things on your ci/cd pipeline that's gonna actually increase your your quality and maybe streamline some of your continuous deployment processes.

We provide those things if there are platforms specific gaps, then we say you may want to consider maybe switching but frankly, I don't remember lately us providing that type of response and most of the platforms are good. As long as you you use them properly. It's a political correct answer I guess but that is also true.

Are you seeing more organizations struggling with the transition the cloud native they're building microservices kubernetes is a factor and these things are more complex than Legacy environments. So have we reached some sort of deep marcation point where organizations are saying? Yeah.

Maybe we should rethink how we go about this whole software engineering thing from top to bottom. Um, very good question. Yeah.

I mean we're seeing significant. Problems actually when our customers moving to the cloud. The reason for that is that they are not refactoring.

Their application infrastructure at their application architecture. There was a lot of and you know, there's no one party to blame for this or the last 10 years. There's a lot of migration towards the cloud while you are doing that the hyper scalars and Cloud vendors they kind of say yeah, you have to go there and that's really easy you do lift and shift.

Not really. I mean it's you can do that. But then you find yourself in a A complicated environment.

There is moved. In fact complicated more by that migration into cloud and you end up with paying significant consumption fees. Because you really did not refactor.

You did not understand the underlying platform and refactor your applications and re-architect your applications. You just move them. You just move your data databases into the cloud.

Now your questioning why you're spending you're paying so much consumption fees. So, you know again that's we're seeing it every customer like it is every large Enterprise customer. We're running into that problem.

Now, most of our customers are coming to us say what do I need to do? And we're helping them actually in different layers, right data layer is one that that needs to be refactored. Then you need to go to integration layer with the microservices.

You know, how are you going to build them? How are you going to refactor them? to scale better in the cloud environment and also think about the consumption.

Right don't assume that. Every time that you need bandwidth because that's expensive what other techniques that you can use. So what are the other patterns that you can apply in order to reduce your total cost of ownership in the long long run all those things requires Cloud native thinking Cloud native architecture.

So now that most of the applications are moved to the cloud now, they are kind of doing the re-architecting and refactoring. How often is that news to them versus how often are you providing them a little therapy and just holding their hand through this process and helping them get through something that they kind of previously kind of ignored. But you know now it's all coming home.

There's I love the question. I don't know. I I think it's 80% off the time it's surprised.

and then then you need to help the customer to to position that properly with their upper management because there's a lot of you know selling the cloud. And rightfully, I mean, that's our future. But it's not the the magic pill.

Oh all of a sudden we're gonna be able to my, you know retire our you know, on-prem data centers on Prem systems and we're gonna go to the cloud cloud is going to give us all these things and that you know, There's truth to that. But now they need to say yes. Yes, we move to the cloud, but we need to spend all this money to refactor and rewrite some of these applications it requires some therapy like you said.

All right. So what's your best advice to folks ultimately as we kind of given the moment in time that we're in, you know, what's the one thing you wish people would kind of come to terms with their understand as they begin their next software engineering Adventure. Yeah, I think that the biggest advice is be purposeful.

Yeah, and this is this is true for cloud. This is true for anything that you do in it. But also I think it applies everywhere just be purposeful if you are bringing any architecture or if you are doing a migration you're retiring one of your applications platforms, you really need to ask yourself the right questions.

Why are you doing this? Are you doing this thing? Because sometimes I hear things like oh, yeah, our license expires there.

We don't want to renew it. So we want to go but that alone is not necessarily. Good answer because so what?

I mean tell me what you are doing. Are you increasing your customer experience? Right.

Are you bringing new channels that's going to actually allow you to compete better. Are you reducing your maintenance cost? Right are you you know again, are you bringing more visibility more scalability thinking that that's gonna support your business that needs to be very clear.

That's one once you have that then I think you need to really have the right architects. Either you need to hire them or you need to bring a company who can bring that architecture. And really do an assessment of what you need to do.

So it's more of a planning. I mean again good old do your planning understand your business objectives understand your roadmap, then start that Journey don't jump into the journey thinking that you're gonna end up in a nice spot you 80% of the time. That's not what happens.

As always it's about deciding where you want to go and then figuring out how to get there and everything else is kind of a distraction from there, Corey. Thanks for being on the show. Hey, thank you for having me.

It was a great conversation. Thanks. All right back to you guys in the studio.