While the technology landscape is flooded with new stuff, many organizations are too entrenched in their current tech stacks and have a hard time bringing the new stuff in-house (while preserving productivity).
Mihai Popa: Hello and welcome to this episode of the Cegeka Webinar! Thank you for joining us, I am Mihai Popa, your host today.
Our goal is to look into the new technology landscape, which keeps on mushrooming these days, and at how top companies with major previous investments in software are going about bringing these technologies into their stack or not.
Whether we may talk about low-code cross-platform mobile development, game-changing artificial intelligence, or simply evolving from legacy code to newer and faster development platforms, all organizations need to make technology decisions.
And today we’d like to understand how these decisions are made and what the implications are for both companies in the product area and in the service area and today I think we’ll be able to talk to people involved in both ends of the spectrum.
Now in the right part of the screen you will see the questions and answers window and there you can write your questions and we will address them throughout the webinar and at the end of it, trying to make this session as interactive as possible.
Now to meet our speakers, first of all thank you for being here and I suggest we have a table-round and let our speakers introduce themselves. Gentlemen.
Robert Mircea: I will start, my name is Robert Mircea, I am working as Head of Digital Platforms in Orange, Romania.
We are one of the departments in IT in Orange, actually we are the ones which provide software for our end-customers, what we published currently on our public website, mobile apps, all the necessary integrations with our backend systems and necessary integrations with telecom platforms.
I’m here because I find this very challenging and we are also in the position where we make this technology choices fairly often, because of the dynamicity of the industry and our competition on the Romanian market.
Radu Apostoae: Hello, my name is Radu Apostoae, I am a Director of Software Engineer for GoPro and also the leader of the GoPro Bucharest office.
Andrei Pavel: And I’m Andrei Pavel, and I’m working for Cegeka Romania which is a service company, and I think there’s a different way of approach between a product and a service company, but I think there are also a lot of things that are common.
I’m also here to share a bit of my view or our view, but also learn from both Mircea and Radu, so I’m very interested to get this going.
Mihai Popa: Now to start off, I think that the sources that all of us learn about new technologies are quite important, so where do you hear about new technologies and how can you tell if an emerging technology can actually bring a benefit? Is it by you reading or getting informed from various blog articles or whether it is because a competitor has recently started an initiative in the area, how do you learn about it and how do you discern what’s relevant and what’s not?
Radu Apostoae: I can pick it up. For GoPro, this is a rather easy question to answer, because GoPro has innovation baked within our company culture.
For us it’s important to always come out with the best product for our customers, so we’re always interested in technologies that would allow this to happen, so we take information from any source possible and all our employees are welcome to suggest ideas for improvement.
We actually have quite a number of programs to suggest improvements and actually bring them to life, we’re actively looking even for POCs and poor results and when deciding what to choose we’re going to take all those results into account.
So it’s either web information, posts, conferences that our employees attend, also what the market does, also what the market needs, so we’re always paying attention to what would bring benefits to our customers. We know pretty well what the desires of our customers are and we’re actively working on addressing those problems and bringing those opportunities to life, so that’s where we’re focused, in looking for tech that addresses those items. So, it’s both internal & external, and sources of information are welcome to us.
Mihai Popa: But you could not say that every single technology that pops up is also going to bring value to your table.
Radu Apostoae: No, for sure.
Mihai Popa : So the process for evaluation is probably as important.
Radu Apostoae: That is for sure. There is obviously a process to evaluate but then again if you want to innovate, you can’t put a lid on ideas. It’s important to let all the idea surface and look at all the potential opportunities and I have a process to actually select what makes more sense. But otherwise, everybody’s welcome to come up with ideas.
Robert Mircea: For my case, actually Orange’s case, things are pretty much the same, but we also have a particular landscape here due to the fact that we are also a service company which is using also the technology delivered by our partners. Although the IT in Orange is purely development, it’s not something that we look into buying platforms, there are occasionally cases where our partners came with some innovative technology to propose to us, in order to adopt it in their products and so on.
But coming from most of the inspiration, the case is pretty much the same. We are not looking actively necessarily in selecting a technology just out of the blue, we put all the decisions in the context of the business requirement that we need to address. Actually, whatever fits the bill for accomplishing that.
As sources, the technology stacks we are following very closely, the technology radars, maybe you are familiar for example with ThoughtWorks Technology Radar, which is published by the consulting company ThoughtWorks almost twice a year. This is a great source of inspiration because it allows us toa actually assess the technology based on maturity and generally we are looking for trends here.
Although we are not in the innovators so often, we are usually in the early-adopters phase where we take the technology, we play with it. We go to conferences, mostly the ones which are industry-setters, for example one of the best in my opinion is QCon which is held in London, and we are going there for quite some time, maybe 15 years or so, and it’s a great source of inspiration usually. There are others as well, but people come to us saying that they try to learn new stuff from articles, Twitter, webinars like this, we saw a lot during this pandemic situation, that most of them move to online, and after developers trying some new things. They like, I don’t know, a new cool frontend, a new cool language for backend, and so on. Based on this, usually we have a pattern here where we try to extract something that we can use for a longer period of time and not necessarily for only POC.
Mihai Popa: Roger that, thanks a lot! Also, I think many companies would only embrace new technology once it’s been validated by Gartner and so on. That happens especially with the big guys…
Robert Mircea: Gartner is a source of inspiration but it’s not necessarily… usually we go to Gartner when we are looking for platforms, because we are not building everything. Of course, I assume that you are not building the accounting software in your company, you are just buying it.
So we are in the same position in telecom, we take some big platforms and we integrate it with our software built in-house, and Gartner is for sure an inspiration for a short list of partners that have the potential to be selected.
Andrei Pavel: Yes. So I think for a service company there is the situation where you have customer requests that also request the technology stack and that makes sense of course because it should be aligned to the product strategy, to the company strategy, and to be coherent in your technology choices makes a lot of sense. One of the input is from that: “know thy customer” should be a golden rule, also from a technology perspective.
Other than that, of course there’s the scenario where there’s a certain flexibility in choosing the technology stack and then there’s the question of “what do you propose to a certain customer that is not keen on selecting a certain stack or not?”.
As Robert mentioned, I think there are lot of resource and sources on the web starting from ThoughtWorks, but even maybe looking at surveys like the one that was for example release by StackOverflow for 2020 last month - there are always interesting things that make the context more complete.
Competition is always an inspiring source of course, but also what is important is if you have, and I think that’s a purpose in itself, dedicated and passionate colleagues, then that’s a very valuable resource, and as a company, I think you need to sponsor and encourage that. Any colleague can come with a proposal. Of course, that doesn’t mean that every proposal will be a part of your offering, but still, having this culture of proactive proposal, even from a technology perspective, from developers, I think it’s a very valuable resource. There are different ways to encourage that, in our company we use for example guilds, the .NET guild or the Java guild, or the people management guild, and then there’ a good occasion for the colleagues to discuss about that, and if something interesting pops up, like a framework or a new version of a framework, it’s always worth considering, definitely.
Of course, I think the small things like Twitter I think also Robert mentioned, there are a lot of guru guys, excellent guys, like Bob Martin or, Martin Fowler, or Scott Hanselman, or Jeff Atwood, etcetera, that are always keeping in touch with what happens, and as in fashion, they are also trend-setters, in a different way of course, but it’s very interesting to follow those guys, and learn from them and then apply to your own scenario, situation.
Mihai Popa: At least as a proof of concept, if not more.
Andrei Pavel: Yes, of course.
Mihai Popa: Ok, so let’s say that we have decided on a new technology to bring in-house and we’re convinced of its benefits, of its potential benefits. What do you do, do you train your in-house people, or do you bring talent from the market which already have a little bit of experience, or both?
Radu Apostoae: I would start again, because I just realized I didn’t give any insight into how we choose the actual technologies, we were only talking about sources.
So once we do have a lot of information about potential ideas, we definitely need to take into account the most important thing, which is the whole product lifecycle, because we’re working on a product and our product will be on the market for several years, so we need to take into account the fact that this technology will need to support the entire lifecycle of the product.
Once we launch a product it’s not a tech stack that we can change anymore, or affect in any way, so it needs to be something that we’re sure enough will support the entire lifecycle.
Mihai Popa: Futureproof, as it were.
Radu Apostoae: Futureproof, and stable enough and mature enough.
So there’s definitely a lot of criteria we take into account when selecting new tech, but this is the most important to look into.
Coming back to your question, we do POCs for any new ideas, because we do need to understand how well they would fit our existing environment and our existing portfolio and technologies we use, and once we get the results we push forward with an implementation project or with another deep dive. It depends on the scale of the change. Small changes which we probably apply monthly or frequently anyway, and where the decision to actually move forward with the implementation lies within the implementation team, because it’s a small change.
If we’re talking about bigger frameworks or tech stacks, then it’s a longer process and we do need to take into account our product lifecycle as well and how often we release new products.
Mihai Popa: So, in the case of a small POC, already existing people would do self-training, self-study, and just try their hand at the respective technology.
Radu Apostoae: Yeah, in most cases the ideas come from them, the engineering teams, it’s a technology they’ve been investigating, they’ve been looking into, and they’re eager to work with, and if it proves that it’s something that would actually bring a lot of value, then we just take the decision and go ahead and implement it.
So usually, yes, it’s our engineering team who train on the technologies and start implementing them. But then if we’re talking about a large-scale change, where it makes a lot of sense to hire people who already have the know-how, we can also take that decision, to hire people to jumpstart a new technology.
That’s not something that happens very often, to jump into something wildly different from whatever you have in-house.
Robert Mircea: In our case, things are somehow the same.
The idea here is that compared to a product company we are more diverse in the type of systems that we have here because in our case we have different technology stacks supporting different business functions and so on.
Usually, when we decide on a new stack, we don’t go to market necessarily from the beginning, as a rule of thumb, we are trying to give the engineers the time to try the new technology, to actually do some small experiments or throw away projects that they want to do. Afterwards, if we decide that it’s something that we’d like to follow up more, we go to train them, we have different resources here, maybe online, maybe classroom in previous times, not now, but usually this type of training and at some point, if the domain that we are trying to get into is really, really new, novel for us, we go first and find in the market several key people that are already familiar with the technology that we tried for the stack that we want, and they will actually have the purpose of sparking and igniting the fire of that technology in a certain area.
As an example that happened last year, was the adoption of RPA, Robotic Process Automation frameworks. This was the approach that we took and at the end we now have developers who are certified in this by themselves, but everything started like a plug in a certain area and then expanded to cross-functional teams and so on, depending on the case.
Also, the people that usually go and start this kind of fire, we have the role of growing the others. We do a lot of internal presentations around technology, we are trying to foster a culture of sharing here and this is a good way to actually make the others aware of the new technology and the fact that they can use it in some purpose, and this is the way that we usually go and adopt something.
Mihai Popa: Okay, a little bit related to what you were just saying, Robert, and everybody, have you ever experienced resistance to change on the part of your teams, who sometimes maybe like being in their comfort zones?
Robert Mircea: Front-facing [refusal], like “ok, I don’t want to use this”, is not very often. We also have some kind of debates here around technology because people comparing frameworks and so on, maybe Oracle-provided vs. community and so on, something like this usually takes place and there are people who do not actually adopt it from the start, and there are different cycles of adopting this, and I interpret this based on either the right moment when it should happen, because maybe it’s not the right moment for that team or that developer to jump into this, but usually the majority opinion wins, and the others are convinced on the way.
We are afraid usually when we don’t understand or when we are not comfortable with a new technology, and a large portion of my time and some other technical leads’ is directed into discussions and clarifications, and answering questions, and showing what we can do with that technology. This is about giving assurance that failing is safe and this usually helps with actually adopting something new.
Radu Apostoae: For GoPro resistance to change is not such a big problem actually because people are involved in the decision-making process, so engineering is always part of the decision in terms of new technologies and frameworks, therefore it’s our decision and it’s a lot easier to adopt it. Obviously a lot of people are not comfortable with change, but when you are part of the decision and you understand or you contribute to making the best decision, then it’s a lot easier to emotionally accept the change.
Mihai Popa: Resistance is futile! 😊
Radu Apostoae: No, resistance is useful actually, because it has some information in it which you need to take into account.
Mihai Popa: Understood.
Andrei Pavel: So maybe, Mihai, just to link a bit the two questions, also regarding the “do we hire, or do we train,” I think of course the obvious answer is both, it really depends on situations.
As my colleagues also mentioned before, it really depends on whether it’s small or big, the context related to it, what are the timeframes to deliver on it, probably if it’s very close you don’t really have the time to train at least at a level to be able to deliver high quality. It also depends on what we understand by new; is it new for us as a company, but it has been on the market for some time, or is it just new?
If it’s just new, then you probably can’t really hire people with a high degree of expertise. But I think it’s both, and it really depends on the situation, and having the flexibility to consider both is always good. Looking to the other questions of pros and cons, because it relates a bit to the third question, if you need to train on something, do you also have resistance?
And of course there is always resistance, as long as it is a constructive resistance - as Radu mentioned - because there are some good reasons, you don’t want a “yes-man” type of team, but just bring up all the pros and cons, but it’s good to understand that as with most things, there’s the Gauss distribution, where you have the innovators, the early-adopters, the majority, and the laggers.
For a good adoption I think also as Radu mentioned, you need to involve the teams, the engineers. After that of course you need to communicate very well, you need to identify some champions that will promote that in the teams, start a training session, then of course extend it to all teams also while doing internal marketing, if you will.
Resistance is in our nature and a good way to approach it is to try and make it constructive, involve the people that will execute on it, for the right reasons and try to expand it to the entire team or the entire population.
Mihai Popa: Ok, thank you so much! We have a question from Cliff; he asks us to what degree do the participants take technology innovations from domains other than their own?
Radu Apostoae: To the degree to which they are relevant to the product we are trying to develop. We are not strictly focused on what we’ve done before, but obviously we’re open to other ideas before, they can come from different domains, indeed, but it’s important that they apply to what we’re trying to build. I’m trying to think of an example, but I don’t think something comes to mind right now, but we’re not focused on a single domain.
Mihai Popa: So it may be that you may hire someone coming from a completely different vertical which has to do with software development, and then they would bring a certain methodology or a certain way of looking at things, or a technology stack, and suggest it to you, and it would be something that you were not previously thinking of.
Andrei Pavel: That’s a very good question Cliff, thank you! I think for a service company it’s in our nature to try to use different technologies of different processes across projects, but still I think it’s important to look at it from what perspective do we see innovation, is it from a product perspective, is it also from a technical perspective, optimal is both, of course.
From a technical perspective it’s definitely something that I think can be applied in different verticals, but also from a function perspective, I think it can be applied to verticals.
We had a quite recent example of doing an online onboarding journey that was quite applicable also in a mobile application, fintech related - think Revolut - how you do it with a selfie and an identity card, that was also applicable in an insurance vertical but also in fintech, Revolut-type of application.
We also proposed to the customer some of the innovations that we did cross-project, and it’s always interesting and rewarding to see that you can get better products by cross-innovation, or applying innovation to different projects. From a technical perspective I think it’s a little bit easier to do, that you can use some sort of techniques in different projects, where the vertical doesn’t necessarily matter…
Robert Mircea: I can also give two examples of cases where we borrowed ideas, not necessarily the full package from other domains rather than telecom or software development.
For example, several years ago, we entered the fintech market, with Orange Money, and at that moment we didn’t know anything about financial services and so on, we had no idea what they meant and so on. That was a classic example of jumpstarting with several experts in that area. But once we got those experts, we found out valuable information on how they build systems and so on, what technologies they use, and we actually took this and of course we did not copy it, we already had some things in the telecom area, but we built over the ideas that we found out and we took from the banking industry for example, in our case.
And the other part related to borrowing ideas from other domains, is not necessarily technology-related, but more culture-related in the organizational development area. We are doing here some kind of cross-inspiration from psychology, or social sciences and so on, we have several people in our HR which are having lots of preparation in this human interaction and organizational awareness and development and so on, who help us toa actually find the best way to communicate or organize things, taking into account humans, not necessarily the technology in this case.
So yes, we can say that we go for example to the social sciences to bring some valuable information to the tech world.
Radu Apostoae: Maybe just to give an example, what comes to mind for GoPro would be maybe collaborating, working with a linguistic expert, because our products use voice recognition, for us it’s important that we make sure that the cameras interact as naturally as possible with the customers, so there would be I guess a domain that’s non-technical but brings a lot of value.
Mihai Popa: Yes, that’s a very good example, indeed.
So coming back to let’s say mapping the new technologies onto what you already have into your application array, would you rather say you replace what exists, you adjusts what exists, or you integrate with that exists?
Robert Mircea: I can give some insights on how we do it actually: we use everything, all the options - replace, adjust, integrate and so on. In a complex technology landscape, where you are usually having similar systems, we don’t make decisions where we change everything, we never took this approach up to now.
Usually you go to subsystems or several platforms and you say what do I want to achieve there, and usually as I said before, we are very strongly linked with the business needs, what we need to do next, what we want to do with that platform, and so on. We assess something very clearly, for example will this current technology that we are using in that product continue to solve my business needs or features that I have to implement let’s say in the next 2-3 years, maybe more.
Other systems may become obsolete, due to technology, support, or anything like this, and we always ask here for example if it’s the moment to actually replace everything, or change it, and so on. Usually we go in the place of slowly replacing and we take the approach where we place modules generally and put side by side the old technology with the new technology and slowly moving to that new technology. We don’t stop and say ok, we need to do a big rewrite, or do something like this in order to be compliant with the new technology just because of this.
Mihai Popa: Actually, this may have led a little bit into my next question: because so many companies want to preserve the investments they previously made, we have the whole array of low-code and no-code platforms, which basically help people integrate existing systems with each other, without a deep know-how of development, and which would bring non-developers into the software engineering process, and I wanted to ask you:
How are you looking at that moving forward and whether there are any risks you foresee into having people with other expertise, backgrounds, stepping in the software development process?
Andrei Pavel: I think it’s an opportunity, Mihai. Usually because I think these profiles are also very business-oriented, so they would bring directly their expertise to the table, I think now, at least for the foreseeable future, these will run in parallel also with complex coding platforms, or let’s say traditional coding languages.
There are different use cases, I think, for both, also depending on the requirements, starting from usage to of course business requirements, I see them both. Of course, it’s also an opportunity for the people and the developers that have been doing maybe traditional coding to look into this as time progresses. I see this as an opportunity myself.
Radu Apostoae: This could be an opportunity indeed, but we need to be aware that is has some risks involved as well because it kind of reduces the complexity of the tasks you can do or the customization you can do afterwards, so it depends on the organization running the product development.
For us it’s a matter of return on investment, whenever we select a new technology we need to look at how difficult it would be to implement a new technology, how expensive, how long it would take vs the benefits it could bring, benefits plus additional risks or limitations, because for instance, platforms that could allow non-developers to create functionality are useful is you’re trying to bring some frequently new stuff, frequently provide, but then again there are limitations you need to understand or take into account, because you won’t be able to do whatever you want.
Andrei Pavel: Indeed, indeed. So the choice I think has to be done with an open mind, but very cautiously, because one of the risks that I also saw is that a lot of these local platforms also offer the possibility to do some actual coding, so if at some point what they offer from a component perspective is not enough, you can also do some coding.
If the choice is not right, you might find yourself in a situation where you do a lot of coding, but then you have the restrictions of the platform. You might be doing a better job if you start with a traditional programming language.
You need to be cautious and do it smartly, and analyze very well what needs to be built now, what needs to be built in the future, as much as you can, and base your decision on that, not necessarily go directly, because maybe the first things that you need to build look cheaper.
Radu Apostoae: You also need to look into the risk of becoming captive on a platform, because if you build an entire set of use cases and potentially part of the organization on that platform, and afterwards you no longer have the flexibility further grow your business, it’s going to be a very expensive decision and implementation to change that platform.
It’s an opportunity with a double blade.
Robert Mircea: We actually passed through, at least two as I remember, two cases of empowering mostly tech-savvy, because we did not go to actually give them everything.
One of them was in the domain of BI reporting, for example, we have here platforms which allow the power user to actually do that kind of integration with different data sources, data lakes and so on, and rather than letting the IT do the reports and just publishing them to the business users, we had a feedback that they always want a new field, a new kind of customization that they want, and we were in a situation where we, for example, offered them, kind of data lakes, or universes with data that they can query as they want, for example. We found out that this was actually a successful experiment, because we were willing to also write code for this, for example how to script, or how to bind all kinds of reports, or process them automatically, but I can also give you a less successful example where let’s say we had a not optimal approach.
For example, I was mentioning the robotic process automation and usually when you’re looking at the RPA framework from the developer perspective, you’re looking at it like… I don’t know how to say it politely, “how am I supposed to integrate the UI or some kind of other means with the RPA?”
We found out that giving this access to the business users, to this kind of tools, actually they did some kind of integrations between apps which could easily be done by IT speaking with that system via web services and so on, and in this case I think this is not the right approach, linking the applications or platforms at the UI level, and this is a technology choice that is very fragile on the long-term and somehow limits your possibility of changing things as they want.
This is a way where I don’t think these kind of integrations are good to be let at the mercy of power users from the business, because they create a coupling in the long-term and this is very hard to break afterwards.
Mihai Popa: Ok, thank you so much! Now we have some questions from our kind audience and Cliff is asking “are you using system on a chip or embedded systems development and do you find that development demands on these platforms, are standards higher than PC architecture information processing type environments?
Robert Mircea: For me it’s easy, we don’t.
Radu Apostoae: Sorry, I couldn’t hear the last part of the question, Mihai, could you please repeat it?
Mihai Popa: So the question was whether you use embedded software development or system on a chip and if you find the standards of developing for embedded being higher than those of traditional PC architecture.
Radu Apostoae: We do use embedded development of course, the standards are higher because the stakes are higher, there is a lot less room for mistakes and the languages themselves are a lot more unforgiving, so I think the limitations of the standards are natural given what you’re trying to do in an embedded ecosystem.
You can easily play with memory and you can easily mess it up, so it’s important to know exactly what you’re doing, programming in C, embedded, it’s not as forgiving as Java, there is no garbage collector, you really need to know what you’re doing, so I don’t think the standards are an issue, they are important.
Mihai Popa: Yes, and Cliff has one more question for you, Radu: “what’s the reasons for dropping drone production – was it due to the technical challenges, or due to commercial competition issues, as in they were not profitable enough? What were the unique demands of drone technologies?”
Radu Apostoae: I don’t think it was a matter of technical issues, I think it was a matter of how we drove the business decision. I think it’s something would not venture into answering necessarily, I wasn’t part of the company back then, so I don’t know exactly the background.
Mihai Popa: Ok, thank you very much! Vasilica asks us “how much time do you allocate to your teams to learn or explore new technologies until you take a go/no-go adoption decision?”
Robert Mircea: I can answer this, how we proceed actually. It’s not a fixed time here, we’re not taking like recipes, like pharmaceutical recipes or so on.
We usually have two approaches here, depending on how we want to do it. If the technology is something with a big impact, let’s say it has a bigger blast radius, we usually dedicate a lot of time.
We do POC for weeks, maybe several months for this, we dedicate people and so on. I can give you an example, adopting Kubernetes management platform, which is something like a lot of impact here in Orange, when adopting it, due to operational issues and so on. And here we have followed with a dedicated team.
We did a POC, the POC is actually several months old, we are doing a selection process, we are doing architecture and so on, all this stuff, and it takes a while, because after we took this, it’s a jump where other teams need to go, because it’s very hard to just do all this only for the need of a certain team.
With smaller technology stacks, like for example trying out a new language, we want to try GoLang, for example, we find out that for us it works a bit differently, for example we try to find projects which are either temporarily used in production, for example we do a lot of offers, online offers and so on in this area, and these are usually backed up by systems which can be developed in a few weeks, or months, it can be done with the new language, it will stay in production for 3-4-5 months, and afterwards it will fade out.
In this case, we jump straight away, go prototype and do all this stuff in the new language, it doesn’t matter for us if it’s the cleanest code and so on, because it’s a tryout period.
Between these two approaches, this is the way that we find that it works.
Radu Apostoae: We don’t have a standard duration as well in GoPro, a time that we allow our team members to learn a new technology.
It also depends on how that new technology came up, it’s part of the career development plan, it’s something that our engineers want to learn and grow on, we definitely reserve a part of their time to look into the new technology and we give them this opportunity, but it’s important that it’s something, or it’s technology that is relevant to what we are doing, that is connected to the product we are trying to build.
At the same time if it’s an idea as we mentioned earlier for a new function to be implemented using a new tech, than we definitely do POC, and we timebox is and try to do something in a certain amount of time to get an outcome that can be evaluated. It could be from allocating 10% of somebody’s time to working on new tech, to full-time for a short period of time in a POC.
Mihai Popa: Right. Ok, now we have a question from Alexandru Unța, I’m not sure if this was not actually covered from your previous responses, but I’ll read it. He asks us “what do you consider an appropriate metric for judging if a technology is a good fit or not?”
Radu Apostoae: I think it’s a matrix, not a metric, that we need to look into. It’s going to be a set of criteria that we have to take into account.
For GoPro, at least, the maturity of a technology is important, because as I mentioned earlier, we need to take into account the entire product lifecycle.
Then we need to look into the flexibility it brings us, what it allows us to do, there are many criteria, but I think maturity is one of the most important ones, and security is again an important constraint.
I just wanted to mention that it’s a set of criteria.
Andrei Pavel: Indeed, I agree with the statement that especially in the enterprise world, I think maturity is a key factor in making a decision, usually you don’t see a high level of adoption regarding technologies that have been out for a couple of months or even a year, you want to have a time where that technology matures, where all the things that need to be ironed out are fixed, and then you can start using it, because you don’t want, besides the thing that you need to implement in your product, you don’t want to go into the actual framework and start fitting there.
And then you have an unstable product, that’s really a no-go, so I think maturity is very important. I see also the security part of maturity, and scalability, and all those things.
Robert Mircea: What we usually do here is adopt a more like evaluation grill, or matrix of features and so on.
Several people are invited to actually score their choices there, we try to find the best criteria, like for example even apart from security, scalability, we also look into community for example, because we are usually adopting open-source technology as a first choice, rather than going commercial in other cases, and we look a lot at how mature it is, how vivid the discussions are on groups, and so on, which are the tools that we can use to troubleshoot that technology, we are also looking if we need at some point commercial support from a company that can provide us commercial support, but it’s not necessarily taken into account from the start.
We are also looking at how we train, if we can find talent on the market to operate that technology or to work that technology as well.
This is very important because you cannot adopt a new technology without the right people and without giving them time to actually learn it, get familiar and so on.
Apart from the technical evaluation, like what it supports, all this kind of tick boxes that developers usually look at, we also look at this kind of criteria in order to be comfortable when we adopt it.
Mihai Popa: Right, ok, thank you so much! Now we’re getting close to our time limit.
We have one more question which comes also from Alexandru Unța, actually it was on my original list as well, but I’ll read his, which is in a slightly different wording, but Alexandru is asking “can you give us an example where you chose a technology and that turned out to be a bad decision?”
Robert Mircea: Bad decision…
Mihai Popa: I can think of several proof of concepts that didn’t go beyond proof of concepts in Cegeka.
Radu Apostoae: I can also think about proof of concepts, but unfortunately, or fortunately, the answer is no. I can’t think of something that made it to production, which was a bad decision in terms of a tech stack. We definitely tried a lot of things, but they didn’t make it to production.
Robert Mircea: Maybe not necessarily a bad decision, more like we often find out after a while that it’s not a fit for us, or that it does not solve all the stuff. We were in a position where we built software and after one year of production we found out that it would kind of limit us at that moment, or I don’t know, we want to go in the frontend development with single page application frameworks rather than server-side, and we invested some time and resources to build this kind of server-side rendering technology for our use cases here and at some point we found out that it became too complex to actually develop something over the top and at some point we said ok, is it worth continuing to invest in that area, or should we stop and say ok, let’s go find an alternative which allows us to move faster?
This happens, but not very often actually, and it’s not something that I can say is the case.
Mihai Popa: Andrei, anything comes to mind?
Andrei Pavel: I think from a service company perspective, sometimes you also need to take some leaps of faith and to invest in training some teams or resources in a specific technology expecting that it will come to fruition, or it will have a big impact, also from a commercial perspective.
Relating to the actual question, I don’t think there were some decisions or bad decisions that we regretted in a product, but what did happen indeed was that maybe some areas didn’t grow as fast or strong as we thought, maybe RPA could be an example, maybe the artificial intelligence, which are still I think hot topics, but maybe they didn’t have the traction that we expected in the first place. Does that mean that the decision was bad? Maybe we reconvene in a year or two and check then, but for now I think it’s an investment and like I said I think these are hot topics that we still expect to grow.
Mihai Popa: Ok, thank you very much, I think we’re just on time, so Robert, Andrei, and Radu, thank you so much for your participation and very interesting input, also everyone in the audience who have been bearing with us for this hour, hope to see you again at our next webinar. Until then, thank you!
Andrei Pavel: Thank you, Mihai, for having us and thank you to all the participants! If there’s any feedback or other questions, I think we are all open to pick them up as a follow-up, so thanks again!
Radu Apostoae: Gladly, that’s for sure. Thank you!
Mihai Popa: Ok, bye for now!
Andrei Pavel: Bye!
Robert Mircea: Bye!
Radu Apostoae: Bye!