Rob Koplowitz (00:09)
Hi, everybody, and welcome to this week's Lowdown on Low-code. This is actually a really cool episode, and it's a little bit of a departure from where we normally go. So we are on with a vendor, but we're actually on with a vendor who's going to talk to us about what I personally think is the most critical topic in lowcode. And it's very closely tied to the topic of adoption. And it's around best practices for setting up a COE, a center of excellence.
I'm really excited about today's episode. you're excited as well, do me a favor, hit the subscribe button, hit the like button, hit the share button, help us get the word out to some like -minded folks out there. Hopefully by now you've figured out who I am. I'm Rob Koplowitz. I'm one of your hosts for Lowdown on Low-code. And I'm with one of the regular co -hosts here, John Rymer How are you, John? You're looking dapper today.
John (01:04)
Thanks, Rob. I'm John Rymer, also an analyst at analysis .tech, former Forrester analyst, and one of the coiners of the term Low-Code. And I certainly did eight, nine years of research on the topic with Rob. I am thrilled today to have Raveesh Dewan with us.
CEO of Joget. You may not have heard of Joget. They've been quietly building a really good platform and conducting business, you know, sort of off of a lot of people's radar.
we're very happy to have you to tell us about Joget, but also to help us understand how to set up and run a center of excellence critical management strategy. So welcome back over to you Rob.
Rob Koplowitz (01:58)
Thanks, John. So Raveesh, we have this thing we start every podcast with. we love for our guests to tell us about yourself and how you got into this, because the stories are just fascinating how people came to this world of enterprise software and Low-Code in particular. Tell us how you got here, Raveesh.
Raveesh Dewan (02:18)
Yeah, Rob, thank you so much. And John, thank you so much for this opportunity. I hope I'll be able to share some insights that I've learned from a lot of other folks who I interacted with and some were from you guys as well. So how I got into this, let me just take step back. I was spending a lot of time in corporate America dealing with technology, licensing various technology, deploying various technologies.
And in fact, my last run was with, you running the Centers of Excellence for Technology and some of the large ones, BPM Center of Excellence, Web Center of Excellence and whatnot. while I was working in corporate America, it always used to think the technology is getting expensive and expensive. And
especially being in healthcare where I spent my last decade in corporate America, I found out that it is significantly expensive when we are dealing with these tech deployments. And I got curious, wanted to figure out how we can make it cheaper, faster and better for the organization. And I have a very strong affinity with open source, so started...
know, exploring and saw the small Joget open source that was budding at the time and started interacting with the team. Got more and more engaged and one thing led to another. And here I am, you know, leading Joget, trying to take it to the next level every single day. But in this journey, what was important to me was just sharing a perspective there.
Healthcare is becoming expensive, as you know, every seven years the cost is doubling. And how can we reduce the cost was coming down to how can we be more efficient with the technology so that we can spend more dollars on care. And that was the kind of my view of the world. How can we reduce the cost? And together as a team with Joget and some of my friends, we got together and thought, you know what, let's take it to the next level.
And here we are taking this journey across the globe now. And I just want to share one more story, Rob, and I think I shared this with John. John was the first industry analyst ever who I literally did a demo in like 10 minutes on an iPad in a Forrester conference. And I am not kidding. If you remember John, he was back in Chicago.
John (05:11)
We had about 20 minute slots Raveesh of course I'm going, that looks really interesting. by the way, I got somebody else coming in. So I said to Raveesh, I want to learn more. Let's connect afterwards. well, many years later, here we are.
Raveesh Dewan (05:15)
Yeah.
Hahaha
Hahaha
Rob Koplowitz (05:33)
It's a great story. always love hearing people's backgrounds. I mean, so John, think what's fascinating about Raveesh's background is how similar it is to some of the other founders and CEOs that we've had who just needed to solve a big problem. So let's go over to you, John.
John (05:53)
So Raveesh, I would suspect that a lot of the listeners don't know much about Joget if they know Joget at all. You guys have been beavering away, but kind of quiet. us a little bit about Joget just to help people understand the company and the product, and then we'll pivot.
Raveesh Dewan (06:16)
Yeah, let me talk about the company. it's been, this is the 10th year, if you will. know we, know, a platform journey is a long journey as simple as that. And I say 10th year, but I still say we are very, very young at this point in time. We have had very, very good product growth initially.
Because we were more focused on building the product and customer came to us. Now we understand the customer better. We understand what kind of partners work better with our product. And we are on a really good growth path right now. Some very large deployments have already happened. One of the things that we struggled initially was, can it only do simple applications?
And the reason for that was more drag and drop, more visual. Our guiding principle has been very simple. We want to keep it simple. We want to keep it visual, more and more visual, and to help with the adoption. Very simple. But that does not mean it can only do simple things. here we are. Now we have customers who are doing all sorts of applications on Joget. One of the customer
is running Joget on humongous infrastructure with more than 22 million transactions a month. So that's the scale we are running now. The product is super focused on how it can make it visual from build perspective and give the ability to go from no code to Low-Code to pro code because it's not possible not to customize and
and build something complex that is highly aligned with the customer environment. So we give that flexibility, but we also keep in focus that when we are doing that, that should also become a new drag and drop feature within the platform. So that's the core focus. Just sharing how we came up with the Joget name. It's very interesting. The Joget is a name of folk dance, Malaysian folk dance.
And in folk dance, there are a lot of things that have to come together in harmony to make it look beautiful. Just like any enterprise, you're building an enterprise application and lot of teams have to work in harmony and get the things aligned and going. That's equivalent to, know, like good dance that requires a lot of coordination.
John (08:55)
That's awesome. Hey, you mentioned open source. Open source licensing is another aspect of the business, correct?
Raveesh Dewan (09:03)
That's correct.
John (09:05)
Okay, great, thanks for that. Folks, if you really wanna have a closer look at Joget, Joget .com, go have a look. And now, Rob, over to you and let's pivot to COEs.
Raveesh Dewan (09:05)
Please.
Rob Koplowitz (09:18)
Yeah, I mean, after I sort of expressed my embarrassment that I've think we've both known Raveesh for a very long time and I actually never thought to ask where the name Joget came from. So it's actually a cool story. Hey, Raveesh, you've told us some stories over that's archived together. And some of them are actually, I think, really interesting and perhaps might be a little bit enlightening to our audience. I'm going to share a couple of those really quickly and then.
and then talk about why a COE might be a really good thing to start thinking about investing in. So one of the stories you told us that I love is that you did the demo and it's like, this is so easy to use. Look at this.
And somebody in the room, the CIO or somebody very high ranking said, this is awesome. We're going to have 3000 spreadsheets replaced in the next six weeks. it's like, well, hang on, hang on. And then another story was, was a particularly large project of yours that was being run by, a systems integrator who was doing all the requirements gathering the old fashioned way, right? Waterfall type requirements gathering, not taking full advantage of that. These are the types of things we'd love our listeners to get around and really believe.
John (10:09)
you
Rob Koplowitz (10:27)
that the role of a COE is critical in this. And, you know, I love the fact that you have the experience of a COE as a practitioner, but also the experience of talking to people about COEs around adopting Joget. Could you help us out with that a little bit? How do you think about setting it up? What type of investment are we really talking about? How should people be thinking about this in order to get to that transformational value of Low-Code that we're all looking for?
Raveesh Dewan (10:58)
Yeah. Let me share my thought. First of all, I want to acknowledge running a COE and establishing a COE is no simple job. It is as if you are working against current. You are talking about delivery teams who have a delivery pressure every day to deliver and you're going to go tell them, you should not do this. You should not do that.
you know, this is to be done this way, you are going to be going against them, conveying them, you are not doing it the right way, and they have the delivery pressure on their back to deliver. This is no simple job. And a lot of times,
People think that, we'll create the COE, they will come and do the governance and everything will start falling in place. Everything starts falling apart if it is not done right. It creates a lot of stress within the organization and contention within the organization if this is not done right. So there are some key fundamental principles that are to be thought through.
just like any new technology adoption that happens within the organization, there is a life cycle. There is a learning life cycle, there is an educating life cycle, and then there is an adoption life cycle, which is the toughest piece of nut to crack. With COEs, are creating the, or facilitating the process within the organization without forgetting.
It's not the COE who is on the hook to deliver. It's the delivery team who is on hook to deliver. And sometimes when we get into the COE role, because we established COE as an authority within the organization, the role of the people in those shoes assume everyone has to listen to me. It is actually counter -intuitive. They have to listen to everyone in order to get the right things going.
they have to focus on things that the teams are not able to pay attention and help them and facilitate how they can pay attention, not telling them what they should do or what they should not do. Right. And the most important thing that I see a lot of times happening in the COE is, obviously from the COE perspective, you have to have that skill. So you will naturally be skilled in the technology being in COE and others may not. A lot of times,
Teams should come to COE to help solve those tech problems or key problems that they are running into. And COE by nature are there to serve them to help them solve the problem. But the key element of this is not taking the credit as a COE. That credit should go to that team that is going to deliver. If COE goes in and
tries to expect that I'm solving these problems and I should get the credit for this, which naturally humans as humans, people in COE, they would want that. It goes against the delivery team. It is very difficult to do that. And I always say if you are in a COE role, think about you are coaching a basketball team, you are never going to be that MVP.
You should strive for a best coach award, not an MVP award. That MVP award has to be one of those basketball players who took your coaching and implemented and took that to the finish line. That's a key element of, or I would say attribute that people should look at when they're creating the COE. What the leader and the team, are they willing to do this?
Because their success is going to be driven by that team's success or multiple team's success. And if they try to take that credit for every single problem they are solving, it's going to take away the win from the team that is delivering that is, you know, it's just like, you know, order a pizza, who gets the tip? The delivery guy, not the cook who really cooked the pizza. Right. But if delivery guy is not there, there's no pizza reaching the customers.
Rob Koplowitz (15:22)
Yeah.
Yeah. That's great. That's great. Thank you, Raveesh. Hey, guys, I want to take just a quick minute and do a little commercial for our sponsors, analysis .tech. Low Down on Low-Code is brought to you by analysis .tech. If you want to interact with John Rymer like Raveesh did 10 years ago, give him that demo or ask us any questions for myself.
John (15:28)
That's great.
Rob Koplowitz (15:56)
actually give myself enough credit for being the coining the term digital process automation was jump into the Low-Code thing. Dave Marcus, fantastic background in RPA and as well as the digital process automation. Francis Carden the godfather of RPA but has now become a full devotee of Low-Code and just a brilliant mind.
Ryan Duguid who has tremendous experience on the product development side architected two of the more prominent.
products in the DPA and low -code space and Andy Bartels, our chief economist who can help you with the financial issues associated with setting up these programs and determining ROI's. Hit us up on analysis .tech. Super easy, analysis .tech. There's a feedback form. If you want to get a half hour of anybody's time, who I just mentioned, the feedback form will be happy to get back to you at no charge. So John, I'm going to pass it back over to you.
John (17:03)
Thank you, Rob. Raveesh, I'm going to go off script a little bit. The setup that you describe is, you know, you're talking about, think very, that culture is very important and understanding you're the coach, not the player. You're the coach, not the producer. I wonder,
if there is a certain level of investment that you've seen that is required really to have success. I've seen, mean, Rob and I have encountered a lot of COEs over our time. Honestly, oftentimes I've seen a CEO, it's just a development team and it's got a fancy title. It's like they're not doing it all with your, but that's something we understand how to fund.
But what you're talking about is a different beast entirely. Tell us about the level of investment and sort of what should people expect to bring to the party.
Raveesh Dewan (18:08)
think John, there are three different levels of investment when you're talking about COE. First of all, the senior management commitment is significantly important because what will happen is different organizations, the messages will flow differently, you'll come to a leader always resolving a problem and if the senior management commitment is not there together, very challenging to do this. It will become a political nightmare within the organization to deal with.
Second is commitment from resources standpoint. The people who you bring in cannot be for a short term perspective because the COE is a mix of knowing the technology and knowing the organization also. How this merges together is the key from COE perspective to understand.
So you cannot bring in a new technology guy within the organization without understanding the mechanics of delivery, how delivery happens within the organization. It's very hard to leverage them in COE. Even though the mindset would be, they know technology. I'll pick up an example from Joget's standpoint. Somebody who knows Joget and I'm building a Joget COE, I may get an excellent Joget developer.
bring in, but can they be a good fit for COE? Maybe not. They need to also learn organizational reality. And the third most important thing is their relationships with these development leaders within the organization. I know technology, I understand the organization, I also need to build that relationship with these leaders within the organization whose delivery teams I'm working with day in, day out. That is...
what is required to build that trust with the COE. That they are not an obstruction, but they are the path that will help us accelerate the delivery. That creation of that image will come from these three fundamental principles. Everyone sees there is an organizational commitment. Everyone sees they are a partner, not a governance or police on top of me.
And third is do you have the way to understand the organizational realities, the delivery realities within the organization. It varies. It absolutely varies from organization to organization. Without these fundamental blocks, there is no COA.
John (20:36)
And it takes time, doesn't it? You talked about learning. I love that. It's a COE as a learning organization.
takes time. It doesn't happen in a week or a month. It takes time for you to build up trust and to really understand things, doesn't it?
Raveesh Dewan (20:57)
Absolutely, absolutely. And I would also recommend if we are thinking about, your organization is thinking about COE, there has to be an assumption you are going to leverage this technology at scale. If you are not doing that, there is no need for the COE. You are going to be wasting time and energy to do this.
If there is a clear vision of I'm going to take this technology and deploy it at scale and I need a lot of people working on this because that's how we get the value. That's a good checkpoint to say, you know what, we need a COE. If that is not there, building an application in two or three and you want a COE, it's a waste of time.
John (21:43)
Back over to you, Rob.
Rob Koplowitz (21:45)
So Raveesh, I want to dive a little bit more into some of the roles and how they might be associated with the COE. So I think, you know, when we really think about the promise, the transformational promise of Low-Code, we think about busting out of those barriers, building a lot more software, building it a lot faster, having a lot more people involved, right? And not necessarily people who have the
depth of programming experience that we might think of in a traditional world. So we have to make sure that design standards are followed. We have to make sure that we have ways of accessing data. People own data. We want to get to that data in the background. We have to make sure that we have things around application lifecycle management, privacy, governance, risk compliance. When I think about the RACI chart, I think about that first day you're putting the COE together.
Can you give us like a hundred thousand foot level of who do I need to have in that room? Who's going to be ongoing participants in this COE and how are they going to participate?
Raveesh Dewan (22:55)
have an excellent question. The reason why I say this is because everything that we just talked about may give an impression that COE is an organization within an organization wherein there are a of people who are going to do this governance. It's actually the role of COE that RACI also has to include other teams in the mix.
is not done alone. COE cannot exist alone. It has to exist in context of those teams, if you will. obviously there has to be a COE leader who is passionate about, you know, increasing the adoption of the technology within the organization for the right use of technology, meaning I don't want to use Joget for what it is not meant and be cognizant about that.
It's just like, you you have a hammer and you have a nail, you have a big hammer, everything looks like a nail and that's not the intent. It should be very clear. Here are these five things that we leverage this technology for. Even though I might be able to leverage for other things, which is not the right use of technology, but plugs the problem, we're very cognizant of doing that. That is the one that derails COE very, very quickly.
So that leader who can quickly understand and filter this and provide the guidance that this is the right thing to do with this technology, what it is meant for, is one thing. With that, leaders are various, I would say, COE roles. You can talk about tech leaders or more of contributors within the COE, which will be within COE who are more focused on technology.
and trying to map the capabilities with the organizational needs and creating that wave of communication with the delivery teams that these are your deliverables, these are the capabilities that map to your needs. And this is how we adopt that. And that's very valuable for the delivery teams because they don't have time to go research these things. That's where the COE will add value.
Second thing is the set of people who can review and get engaged at a project level to know at a high level, we set this strategy, we gave the direction, is it being followed correctly or not? And this is where really the rubber meets the road. Are you using it the way it was intended to? We agreed on this, everyone agreed on this, this is still happening. The governance check is required.
for various reasons. One, it helps team from delivery standpoint. Second, also to validate by COE that is recommendations being followed correctly. And they will get into these scenarios wherein it is not being followed the way it was supposed to be. That is not the blaming time for the team.
John (26:15)
It's a teaching moment.
Raveesh Dewan (26:17)
Exactly the point. That's the teaching moment. You don't teach by blaming, you teach by showing. And sometimes you will have to take on that expertise saying that, us put that effort for you to make it right. And this is where, you know, I was talking about the credit. This is where the credit goes. You know, it feels like I have done it as a COE. I should be, you know, in the limelight. Absolutely not. You help them teach.
You try to take that away from that. They don't want you to come back.
And the third, the fourth piece which is for these roles is, you know, engagement with the other teams. This is where different team members should form that COE group of governance, wherein some of the delivery folks are also included in. You cannot create an ivory tower because they should, when you give a lesson to them, it's hard for them to listen. But when they're sitting, giving them the others the same lesson,
They internalize that and that's what keeps the COE intact for a longer time. Otherwise, these organizations will be momentarily created, technology came in, who cares about COE, we know the technology and off you go. If you want it from a longer term perspective, it's not just you get any COE, these elements are very essential to keep in front of you while you create the COE.
Rob Koplowitz (27:53)
It's a big job. It's a big job. And I think maybe we kind of started off this research, John, all these numbers years ago and definitely did not take it seriously enough that you have a big job in front of you, right? You have a big job in front of you and it's going to result ugly. You're just going to get transformational changes. Well, you know what? Transformational changes are well worth an investment. So back to you, John.
John (28:18)
Yeah, what, Raveesh, what's the best relationship between the CO, COE and IT? Should the COE report to IT?
Raveesh Dewan (28:33)
John, it depends upon the organization type. There are organizations that have centralized IT. There are organizations that have federated IT. COE usually in federated IT will have to report to some central body. In the scenario where everything is consolidated within one IT organization, it will remain within the IT organization.
Especially some of the COEs like BPM, if you will, which is more process engineering heavy, there can be slight difference in how that gets, where that should be reported. But if you're talking about a technology focused COE, that will be more suitable within the IT organization, reporting to the same leader, if you will, and that leader has to first commit, I'm going to create the COE.
is going to create this small wave of uncomfort within the organization and I'm ready to commit myself to handle that. If I don't do that, I'm really not... Then the person who is going to be signing up is not really sure what they're signing up for. SEO is no easy job.
John (29:47)
I think what you're saying, Raveesh, and correct me if I'm not getting this right, is that the principles that you outlined are what's important, not the reporting structure.
Okay, that's great. Rob, I have one more question. One of the controversial things about, I think about COEs is how long should they live? And should they just be kind of one thing and not evolve? Because it just, as Rob was laying out, I mean, our belief is that the real transformational power of Low-Code.
drives expertise and involvement in software and automation deep into the organization away from a central organization. And that's not easy to do and everybody's on a journey towards that. But it does say that over time, the COE may fulfill its educational function and teach the organization and business people and IT and
Raveesh Dewan (30:37)
Mm -hmm.
John (30:56)
gradually begin to wind down because there's not as much need for it. Is that a good way to think about it?
Raveesh Dewan (31:03)
I think John, that is an excellent scenario when the people don't change within the organization. You will have in reality, practically speaking, I look at this, if ideally I look at this, yes, it grows, then it should wind down and there should be a steady state. The problem is people change organization every single day.
leaders change. you want to leverage the if there is a longer term use of technology, you have to establish some bare minimum to exist to continue that path. I'm not saying that it will be at that scale that you know when you were trying to grow when the technology is deployed and there is a regular cadence going on. Yeah, the engagement will come down but
It will never go to zero for very simple reasons. People change, things change, goals change, and technology may have started on the path one. The goal of the organization change, it has to adjust and COE has to participate in that. It will never be zero. That's my recommendation. Until as you decide this sunset, this technology is on a sunset path, we want to contain what it is doing, we don't want to grow.
As long as you want to grow, want to have some piece of it alive.
John (32:34)
That's a great perspective. Thank you for that. Rob, back over to you.
Rob Koplowitz (32:38)
So first, I just want to thank Raveesh. I want to thank my co -host John. I do have a few specific takeaways for the listeners today. If you liked what you were listening to, you liked what you heard about COEs, I think this is great. We were really excited to have Raveesh come in and share this information. Button this up with the two episodes that we had recently with Paul Kobulanski of Shell, who's on the practitioner side for Low-Code.
great information there about setting up programs and COEs as well. And then here's a big one, guys. So upcoming, John and Raveesh have been working on some really, really good research around maturity models,
you can find this through Joget, you can find it through LinkedIn with John Rymer. Tune into that and then get a hold of that research because I had the opportunity to be involved in that and it's really, really good research. I really think you should take a look at that. Hit that subscribe button before you go, hit the share button. Raveesh, thank you so much for coming on today. This was so informative. Yes.
Raveesh Dewan (33:51)
My pleasure.
John (33:53)
Thank you so much, Raveesh Really, really good, practical advice that I'm sure will help a lot of people, and we're grateful you're willing to share it. Thank you.
Raveesh Dewan (34:01)
Thank you John.
Rob Koplowitz (34:02)
And thank you again to our audience. We so appreciate you taking the time to tune in and listen to us. We're still amazed that you spend your time with us. So thank you all. We'll see you on the next episode of Lowdown on Low-code.