Can low-code approach help you build better software? Riadh Ziri says yes. In this episode, he shares his knowledge about delivering enterprise applications using low-code for almost two decades. Joining Alexandre Nevski, he explains how to unlock the best-of-both-world impact of low-code approach. He talks about what it means for the progress of business and IT functions, as well as the right way to integrate such innovative tools over long-term traditional strategies. Riadh also discusses why the human aspect must never be removed from this process in order to foster deeper collaboration between teams.
Pega® is a trademark of Pegasystems Inc. Please visit https://www.pega.com to learn more.
—
Listen to the podcast here
Unlocking The High Impact Of Low-Code With Riadh Ziri
Welcome to a new episode of the show. My guest is Riadh Ziri. We’ll be discussing low-code, especially the impact it can have on people in both business and IT functions. No doubt, you have heard of the term. The low-code debate has been raging for over a decade. Whether you believe anyone can build software or you’ve had painful experiences with the approach, you want to hear the inspiring story that my guest was kind enough to share.
He paints a vivid picture of how an actual organization and its people adopted a novel approach, dealt with challenges, and delivered a tremendous amount of value. He also provides practical advice to business and technical leaders. Riadh loves guiding and federating people to deliver the best possible outcome. He has founded and grown his own company, IRIZ Consulting. He is a successful, hands-on CEO. He has been delivering enterprise applications using low-code for eighteen years. Without further ado, here’s my conversation with Riadh Ziri.
Riadh, welcome.
Thanks.
It’s nice of you to have found the time for this. I know that running your own business is never easy, but you managed to do it with a house full of kids. How many kids do you have, and what’s your secret?
I’ve got four kids at the moment. I haven’t done all the work myself. That’s the good thing. Otherwise, it would have been a really big challenge. The secret is we’ve been doing this as a team. It was the two of us.
IRIZ Consulting
Let’s talk about the project. Let’s talk about your business. You’ve created a new company, IRIZ Consulting, for a while already. Can you share with our audience what was your vision for it and how it evolved over the years?
I found it several years ago. Initially, I didn’t have the real intention of starting a new business because, in my experience, I was a consultant. I was an architect working for a software company for many years. I wasn’t really seeing myself as kicking off a business or whatever. After leaving that software company, I started doing some contracts on my own with clients and everything.
There have been different reasons for that. One of the reasons was after doing multiple contracts, I started to get a bit bored probably by working on my own. That was the first reason. The second reason was I was working with big partners who, pretty much all the time, build up teams with very junior people that you have to train. You start training them, invest time in them, and everything. At some point, I was like, “If I have to invest time and train people, why wouldn’t I try to train people who would be part of my own team?” That’s where everything started.
How much progress do you feel you’ve made since those years ago?
It was huge. I was 1 person initially, and now, we are about more than 40 people. Everything is working pretty well. We measure that with customer satisfaction. It seems like all our customers are pretty satisfied. For most of the customers we have been working with, it has been more than 4 or 5 years, which means once we start working with a customer, they pretty much never ask us to leave.
That’s terrific.
That’s, for me, a measurement of success. That’s more than enough for me because if the consultants are happy, that’s it. That was also another reason for me to try to start this business. It was also to create an environment where we can allow consultants to be happy and do what they like in an environment where they can develop themselves and progress in their careers but also be motivated and love what they’re doing. At the same time, it would be for clients to be happy with the work that we’re delivering. If your customers are happy, your consultants are happy. For me, that’s all I was looking for initially. We pretty much made it because everyone seemed happy at the moment.
Understanding Low-Code Approach
I also know that IRIZ Consulting is known for the low-code approach that it promotes and champions on many of its projects. I’d like to start with the basics. Maybe you can, for our audience, define how you would explain low-code to, let’s say, a business leader.
Business leaders are in charge of addressing the needs of their clients. They’re in charge of addressing the needs of their clients as well as the systems, solutions, and applications. Sometimes, with those applications, they can buy them from a software provider and work as it is. You can plug them in, change the logo on the top left of the screen, and there you go. Your project starts, and your application is already up and running. That’s one approach.
The challenge with that approach is that if the software doesn’t work as your users are used to working or want to use it, then the users have to adapt to that software. That’s the flow of it. The other approach, which is open to them, is to go for a much more flexible approach, which is using some classical programming code like Java, maybe .NET platforms, or whatever. That allows you to address the needs of your users precisely. That approach pretty much all the time forces you to reinvent the wheel. That’s where low-code comes as a best of both worlds to provide an approach where you’ve got Lego bricks that are already ready to be used and you can, how do you say it?
Assemble?
Yeah. You can assemble with each other to build whatever you want. That allows you to go much faster than the classical programming approach, which is more flexible than the software approach.
Low-Code: Low-code comes as the best of both worlds. It provides you with easy-to-assemble materials that allow you to go much faster than the classical programming approach.
It’s the best of both worlds.
Exactly.
‐‐‐
In this segment, we use storytelling to bring authentic insights to our audience. I always advise my guests to use discretion with names and specifics in order to uphold the highest standards of privacy and respect for the individuals involved. Bearing that in mind, it would be great if you could identify and share an example of a digital transformation that illustrates the benefits of a low-code approach. If you do have such an example, let’s start with setting the context.
That reminds me of one of our clients, which is probably our biggest client at the moment. We have been working with this client for the past few years. When the story with this client started, initially, they wanted to put in place a CRM application, which is Customer Relationship Management. That’s software that allows my client employees to interact with their own clients. Their client comes, they call, and then they say, “I want to change my address. I want to do this. I want to do that.” That’s why they need it.
They started an RFP to acquire new software to address those requirements. They had been pretty smart and pretty pragmatic. It’s probably one of my best projects and best customers because they had the right mindset when they started it. The mindset is probably the most important ingredient when you want to start a digital transformation program. Even with a small project, it’s always the same.
It always comes to the mindset of how you are approaching it and what your vision is at the end. You need to be ready that you can’t define the rule and say, “I want to do this. I want to do that. I want to do it this way.” You want to probably define your targets, like where you want to be, where you want to go in probably 1, 2, 3, 4, or 5 years, and everything. Give yourself some flexibility on how you are going to get there. This was what we really liked about this client.
Mindset is probably the most important ingredient in starting a digital transformation program. It is all about how you are approaching it and what vision you want to achieve.
Did they have any experience with that kind of approach, the best-of-both-worlds approach, before this project where they had this epiphany? The flexibility that you mentioned, is that something that came from past experiences, or is that an insight they had without knowing anything about low-code?
No. They didn’t know anything about low-code initially. Many companies on the market at the moment have been working with the old approach, which was more of building everything in Java so far. They realized that to be able to build a CRM application and they had about maybe less than a year to build it and put it in production, it wasn’t feasible to address all the needs.
That’s why they said, “We’re going to check what’s on the market, something that is as close as possible to what we want to achieve. That means we would have to address the gap between what the software is providing and how we want it to behave.” That was great because that’s where we started helping them. Initially, honestly, even I didn’t really believe in the success of the project because they were so ambitious. They came to me saying, “We want to do this, and then we want it in production in ten months.”
What were the business drivers for such an ambitious vision?
You had this organization that needed the CRM for itself, but this organization was also in charge of a whole group of other organizations. Each organization, so far, was self-working. Each organization had its own CRM. The purpose of this was to reduce the cost and the scale of the whole group and say, “This one is going to start a CRM which is going to be used as a unique essential CRM for all the organization.” There were about twelve organizations in the group. There were CRM applications by a single 1. That’s why they needed to put it in place as soon as possible. It was so that they could start taking the benefits from it as soon as possible and reducing the cost.
Initial Steps And Challenges
The business drivers were increased in the shared services that the organization was relying on or the set of organizations were relying on. I understand. You mentioned that at the beginning, not everyone was convinced that this was going to be feasible in such a short amount of time. Walk us through the initial steps. They must have been quite inspiring for the mood to have changed over time.
The thing is it’s a matter of commitment. You need to tell yourself, “We can do it.” That’s the thing. Initially, when you start saying, “We need to do this. We need to do that,” and then you start saying, “It’s going to be very difficult and tough, but if we do things this way, then it’s going to work.” That’s where the mindset of the client was important. You need to be able to make this a success. You need to be working with a client who is pragmatic enough and willing to listen to you enough so that you can reach the end line or the finish line as he wants.
That’s the thing. We have experience in that domain. We know how to deliver those kinds of projects. We know what needs to be done and when exactly. That’s the difficulty when some clients want to take too much control of the project and how they want it to happen. That’s when you start advising them, but you end up like, “We should do it this way,” and they’re like, “This is how we want to do it.”
For instance, it’s like, “Which methodology do you want to use? Do you want to go Agile? Do you want to go to Waterfall? Do you want to go somewhere in between?” There are so many constraints that you need to take into account, like whether the customer is ready to work in Agile or not and how much agility we can put in there so that the internal employees of the clients are able to follow what you’re asking them to do. That’s the whole thing.
Is that something that the entire team understood or was there the need to convince people throughout the project, “This is going to work. The low-code is really going to deliver on those benefits.”
The key people understood it. Those key people, for me, were quite good at managing their teams to make them understand the benefits of this approach. That’s the thing. The technical leader and the business leader were in sync and they understood the benefits of it.
I wonder whether it was smooth sailing throughout or was there maybe one moment where some of the stakeholders challenged the approach and were asking more questions to the business and the technical leaders, like, “Why are you doing this? Why are you not doing your own development?” for example, or something else. What would be, in your opinion, the hardest challenge you’ve had to overcome in that initial phase?
It wasn’t smooth sailing. It’s like any project. I don’t know any project that is smooth sailing. Otherwise, there wouldn’t be any projects. There’d be one person coming and doing the job, and that’s it. It wasn’t because, in the end, you are trying to put a very innovative tool, which has its own way of working and has a brand-new way of working, and integrate it into the information system. You integrate that into all the systems and the architecture of the clients with something that has been there for the past couple of years.
You’ve got people in there who have been maintaining all that infrastructure, servers, and everything from deployment, code, or whatever. Those people said, “We used to do it this way. This is not our standard.” We’re like, “I know, but we are going to have to define a new standard because this project and this tool is coming. Let’s work together and identify something that is workable for the software and that is acceptable for you.” That’s how we had to accompany them and assist them in terms of redefining some new standards. Five years later, all that is behind us. We’ve got everything defined on how we deploy our code and, in terms of architecture, how we integrate that application with the other systems and everything.
How did you make that happen?
The thing is it comes down to human interaction at the end. It’s all about human interaction. You need to be able to understand the people on the other side that you need to work with. If you want it to work, you need to understand that these people have been doing the same thing for the past 5 or 10 years, and that’s their job. That’s the only thing they probably know how to do and what to do. You need to understand that you are asking them to go a step, which is very high for them. You need to take them and be patient. It’s all about patience.
Understand them and explain to them. Some of them are going to be like, “That’s fine. I like it. I like learning new stuff ad. I was starting to get bored.” Some others are a bit more reluctant. Those ones, you need to be able to say, “I know you don’t like this. I know it’s not how you used to do it, but let’s go together. It’s going to work. Don’t worry about that. If you need it, that’s fine. Call me.” Initially, they call you up pretty much every five minutes. Even after five years, they still make 1 or 2 comments like, “I don’t like it,” but they still do it. They probably secretly enjoy it.
That’s great. Thank you very much for sharing this very inspiring story. If you found value in the scale of innovation, please like and subscribe to help us share with a wider audience.
‐‐‐
Unpacking Low-Code
In this segment, we focus on the tools that we’ve mentioned in our previous segment. Let’s try and unpack for our audience what low-code is. You can walk us through some of the common characteristics and also mention the major differences in the various implementations and vendors of low-code technology.
Low-code is like Lego bricks. You have pieces of technical components that have been created to allow you to not start from scratch every time you start a new project or every time you have to build a new functionality. You have those components. When I say components, take a software application. You’ve got a screen, a dropdown, a text field, and a connector that allows you to connect to an external system.
Those things exist, which means you’re going to be able to create a screen, for instance, where you’re going to be able to add the different fields that you want. Usually, you do that visually. When you do that visually, you have your screen. You’re starting like, “I want this one on the left, this one on the right, and this one on top. It has to have 1 column or 2 columns. I want one button on the bottom right of the screen. This is my stuff.” I hit Save and it is a happy day. That’s it. The code is automatically created.
Once you have your platform up and running and installed, the way you use them, they all have their own differences in terms of how they do things. Overall, the spirit is pretty much the same. Some have been created a few years ago, which means they are much lighter and then they have less legacy inside. They are probably simpler and less advanced. You can probably address less advanced requirements.
Some others have been there for the past twenty years. They have been accumulating experience over the past twenty years. That means they created things twenty years ago that are still there, like the tools, but they’re maybe not so good. Those things were created twenty years ago. They can still be useful, but they’re probably out of date depending on what we’re talking about.
You’ve got some low-code tools that allow you to create, for instance, a website with simple pages very quickly. You’ve got some other low-code tools that allow you to create real enterprise business applications. What I mean by that is applications that are going to allow employees into an organization to do that job.
That makes sense. You were saying that it’s the best of both worlds, coming back to what you were saying at the beginning. On the one hand, we can purchase an application, probably a Cloud application, that does everything that you need, maybe if your needs are rather standard. On the other hand or on the other extreme, you can build any application or any enterprise software that is going to be exactly tailored to your needs.
This third approach that we are describing here is something in between. It’s important also to differentiate between a low-code tool and a rapid prototyping tool. Sometimes, people will imagine that whatever sales consultant or any other expert is maybe showing is a fancy demo. They expect that when they get the software and start working on it, they are going to be able to write 500-page requirements or documents and say, “What I wanted to do is this.” It’s important to differentiate that a rapid prototyping tool is something else entirely. This is working software.
‐‐‐
Using Low-Code
In this third and last segment, we want to share practical advice with our audience. Let’s try and unpack low-code but from the point of view of a leader starting out on a journey. What can we recommend to them to do in the first phases of them going through a project that they suspect will use low-code?
The first thing is they probably need to have an understanding of the organization. Understanding the organization, understanding the requirements, and understanding the relationship that exists between business and IT is going to be key. What I’ve seen is when you try to bring something which is very innovative and there is a massive gap between IT teams and the business teams, it’s difficult to make it a success no matter which tool, software, or approach you’re going to choose. If we have that gap between the two sides, any project is going to be a challenge. That’s going to be the key thing. He or she needs to find the right approach and do some work in advance to make sure that those teams learn how to work together because that’s going to be the key.
There are some tools out there that allow you to capture the requirements into the tool, for instance, and allow business and IT to collaborate together. Each one provides its set of skills into the tool in terms of business requirements, technical requirements, and everything to build something together. There are tools out there like Pega, for instance. A software provider is Pegasystems. That’s a tool that we have been using for the past few years. That’s probably the biggest challenge.
The biggest challenge is not really the tool. It’s more about how the people are going to work together. You need to provide something to put in place an environment where people are going to be free to provide the expertise, work together, and not have different targets or different interests. It shouldn’t be, “My interest is I can only work two hours a week for you guys. That’s it.” You need to make sure that the interests of one, they’re all working toward a common target.
Low-code approaches are ideally suited to organizations that have a lot of collaboration potential. Whereas if you have an organization where the business people are expected to throw a requirements document over the wall and maybe under normal circumstances are not available to participate in the project, that may not be a good place to do a low-code approach, right?
Yes. That’s the idea. To get the maximum benefit out of a low-code approach is collaboration. Collaboration is important because the tool is very important. It allows you to build things quickly. The purpose of building it quickly is, in a certain way, that you build things faster so the duration is shorter of the project. The key thing for that is to demonstrate things quickly to the client and the business people so that they can validate things as we go. You’ll end up with something that matches not 10% of the initial requirement but 100% of how they will want to use the tool once it’s in production.
That takes care of the business side of things. It’s ensuring that the people will have the bandwidth and willingness. They know that they’re expected to participate throughout the process. What about on the IT side or the technical side? What kind of advice can we give that part of the organization when they’re embarking on a project in digital transformation that involves low-code?
They need to be open to welcoming new technology into their infrastructure. They probably have been doing things in a certain way for the past 10 or 20 years. Some companies don’t have a problem with that because they have been buying software from different software providers and each one has its own specificities. There are others that have been having one way of working for the past 10 or 20 years. Those companies need to prepare themselves for defining new standards and to be open-minded and creative in terms of deploying that software into the infrastructure.
From the perspective of outsourcing or at least relying on external partners, what’s different? What does the organization need to do when they’re doing low-code versus traditional development in terms of procurement or contracting to get the external expertise that they might not have in-house at the beginning?
The key advice here is to find the right partner. You need to find the right partner who’s going to guide you through the darkness of the different steps of every project. You can’t guess by yourself. You’re going to be getting a brand-new tool into your organization and you don’t know how to install it, how to use it, how to deploy it, or how to configure it. That’s where you need a partner who knows how to do things properly, who has probably already made mistakes in the past, and who’s going to tell you, “Don’t do it this way. Do it this way.”
Low-Code: You are getting a brand-new tool into your organization. You need a partner who can help you install it, use it, deploy it, and configure it.
You need a partner who’s going to allow you to put in place a robust foundation at the beginning of the project and is going to allow you to maybe put in place different layers with some generic components that you’re going to be able to reuse across different applications. You build something once and then reuse it multiple times.
That’s really the key thing here. Find the right partner and get trained. Train your resources for the people to be able to understand and follow the pace. If you have a good partner, it can go pretty fast. You don’t want your internal employees to be left on the side. You also want them to follow the pace. Find a partner who has the right attitude and mindset in terms of strategy. You need to find a partner who is willing to consider your resources as part of one team.
This is what we have been doing with all our clients at the moment, which is the co-construction. It’s not just us. We build the applications with our client employees altogether. Everyone is considered the same for me. On my team, there is no internal person, partner team, or partner person. That’s something that is key because that’s the way that these people are going to evolve and then become seniors and experts. They’re going to become ambassadors into their own organization.
Human Aspect
It’s great. We’ve provided really good and practical advice to our audience. Is there any final message or topic that you would want to cover in this segment?
That’s fine. We covered pretty much everything. One of the most important things is the human aspect of things. Technology is one thing. Technology can be very powerful. We have tools that we have been using and we have proven that we are able to deliver robust applications quickly. In big enterprises or big companies, solutions like the Pega Platform have been doing pretty well so far, but the human aspect is probably the most challenging one. You really have to find a way of motivating and engaging every person that is going to participate in the project or the vision. You need to align everyone with the vision. Once you manage to do that, that’s when magic happens.
That’s why it’s so important to have a partner who can help you through that kind of innovation.
That’s what we try to do in every project that we commit to. We start getting some good experience on the technical side and the human side as well. We try to put in place an environment where everyone can be creative, motivated, and happy. Once we have that, you don’t have to worry about them anymore because everyone is going to be committed to going toward the same vision.
Low-Code: Try to create a work environment where everyone can be creative, motivated, and happy. Once you have that, you can expect everyone to be committed to go toward the same vision.
On behalf of the audience, thank you very much for these insights.
Thank you very much for having me. It was a real pleasure.
Likewise.
‐‐‐
Closing Words
Thank you for joining us for this episode of the show. I hope you found Riadh’s insights into low-code as informative as I did. Together, we explored how the secret to success isn’t just about technology, but also managing the human element and especially collaboration. To illustrate, my guest shared an inspiring story about overcoming challenges and achieving remarkable success by focusing on the people.
If you enjoyed this episode and know somebody who would be a great guest for our show, please visit our website and fill out the guest recommendation form. We have more exciting topics and guest appearances lined up, so stay tuned for more tales of innovation that inspire, challenge, and transform. Until next time, peace.
Important Links
About Riadh Ziri
Riadh is an accomplished CEO and a very active Lead System Architect. He founded and grew his own consulting company and spent the last 18 years delivering successful enterprise business applications using Low Code. He loves guiding and federating all the people on his projects in order to deliver the best business outcome.
Enjoy New Shows
More from this show
Explore
© All Copyright 2024 by Glaukos Digital OÜ