Everyone knows that digital transformation poses numerous challenges and pitfalls, but does it really have to be this arduous?
In the latest episode of the Impulso Podcast, Jianggan, Yorlin and I are joined by special guest, Jing Li, founder and CEO of Sirius Technologies and co-author of our report “Transforming Digital Transformation,” as we unravel the complexities and triumphs of digital transformation.
Digital transformation isn’t just about technology; it’s also a mindset shift towards innovation and agility – “Agility is the outcome, not the approach”.
Join us as we explore the challenges of digital transformation in the financial sector, the concept of fusion teams and the role of the enterprise architect in bridging the gap between business and tech. We also explore WeBank’s Success, highlighting how their pioneering approach to embedded finance propelled it to become the world’s best digital bank.
You can tune into the full episode here:
Also available on Apple Podcasts.
Featured materials:
Transforming Digital Transformation, Momentum Works
[AI-generated transcript]
[00:00:00] Sabrina
So hello everyone and welcome to episode 74 of the Impulso podcast by Momentum Works. So on today’s episode, we have a special guest with us, Jing Li, founder and CEO of Sirius Technologies. So before Sirius in Bangkok, Thailand, Jing had actually been a lead architect at WeBank, the world’s largest and some would argue the most successful digital bank.
At WeBank, he assisted in the development of the world’s first banking architecture built on off the shelf hardware and open source technology. And he was brave enough to take his expertise as well as learnings, and more importantly, his team, to create Sirius Technologies in a different country, enabling digital transformation for banks and financial institutions.
So, hi Jing, and thanks for joining us today.
[00:00:45] Jing
Hi, Sabrina. Thank you for having me.
[00:00:48] Sabrina
So recently, Momentum Works and Sirius Technologies have actually joined, launched a joint report called transforming Digital Transformation. So this report will be linked in the show notes below.
And of course, joining us today, besides me and Jianggan, we also have Yorlin. who before MomentumWorks actually had some experience of digital transformation, right?
[00:01:07] Yorlin
Yeah, I did and had fun with working on this report with Jing, together with Nanette and Daniel.
[00:01:12] Jianggan
I thought we had fun doing digital transformation before.
[00:01:15] Sabrina
No, we will talk about it later today. So, maybe to set the scene, we can talk about how did the idea for this report even come about? Why did we want to launch this report on digital transformation?
[00:01:25] Jianggan
I have no recollection, so I think you and Jing, okay?
[00:01:29] Yorlin
I think from what I understood, it happened over drinks.
So I think, yeah, So I think, I think Jing , you were in Singapore, right? And then I think you met up with Jianggan. And then I think over drinks, you guys were talking. And then I think this idea came about.
[00:01:47] Jing
So I think the main reason for us to Launched this report. I think it came from the question like, Hey, Jing, exactly what does Sirius do?
So why you build Sirius? So, and then we, I start talk about the challenges that enterprises facing in their digital transformation journey and all the, all the problems and all the failures. And then start to share a little bit about how the way that Sirius does a digital transformation can help the enterprises to approach their digital transformation differently.
And of course, the amazing title of a transforming digital transformation. Came from Momentum’s work. And I mean, engineers like us can never come up with some creative captions about the ideas. So yeah, so it came from a very honest sharing from my side, about why I built Sirius, and what I want Sirius to do.
So that’s where it started.
[00:02:43] Jianggan
So actually one question here. Why did you build Sirius ? So Sabrina mentioned in introduction that you were brave enough to actually your team who have been working with you for years and to build this company outside your comfort zone, which is Shenzhen wh ere Tencent and WeBank, were based, and you’re now in Bangkok and obviously different culture.
, I presume your Thai has improved. Since then,
[00:03:09] Jing
( Thai here). . . A little bit. .
[00:03:11] Jianggan
Okay.
[00:03:11] Jing
Yeah. So why? Yeah. Actually having a company at Sirius is not just my idea. We tried in WeBank and then we actually started forming this idea in date 2016. And then unfortunately, because of the changes in the regulations in China, banks were not allowed to build to spin off any fintech company since 2017.
So our initiative was killed by the regulator in China. Then for other participants back then to them oh, fine. They decided to just you know, stayed in WeBank. But for me, I truly believe that what we built in WeBank is something for a much bigger stage , and then we believe that such a good know how shouldn’t be limited in serving just one bank.
And then I’m maybe the craziest among the few. So , I struggled with the idea for a while. And then I decided that this one thing that will never come back. It’s time. So then I discussed with my core team and they all decided to follow me. So we start to, and then we left WeBank and then to keep pursuing this vision about, you know, bringing these know hows to
[00:04:24] Jianggan
So obviously now you’re in Bangkok and you work a lot with banks in Southeast Asia and to a certain extent some banks in Latin America as well. So your previous experience with WeBank in China and obviously WeBank was a beautiful scratch. We interact with lots of banks and people tell us that that WeBank is amazing.
I don’t know exactly how they did it, but it’s amazing. So maybe if you ask to summarize, how did WeBank become successful? And how do you see the banks in this region are different from WeBank or the banks in China? And what are the lessons that are applicable to this region, to the financial institutions in this region, before Yorlin start talking about how painful it is to do digital transformation?
[00:05:07] Jing
So everyone sees WeBank as a largest digital bank. So, because it’s easier to see that they have almost 400 million users. But the actual success factor for WeBank to grow so fast is the strong belief in today we call it Embedded Finance back in 2014. So nobody is talking about Embedded Finance in 2014, Embedded Finance was not even a thing back then.
So, but from day one. Probably because of the Tencent DNA, probably because of all the, you know, amazing bosses we had back then. WeBank from day one, never positioned ourselves as a bank. We positioned ourselves as a tech company with banking license. So from day one, we knew that we couldn’t compete with the incumbent banks if we built ourselves in the same way.
So we decided to be the connector between the banking sector in China. The industry, the internet companies, okay, so we want to be the bridge that brings all the capitals and all the licenses and all the risk capabilities from the banking sector and that inject them into the real use case, especially in the internet industries.
On the internet platforms. So because why we do that because internet platform in china is the easiest way To reach out to the mass market. So we become the connector So we then from day one we are not launching like a mobile banking app or typical banking products from day one we start to embed our Abilities into mass platforms.
The most popular product in WeBank is microloan and microloan is not even available on WeBank’s banking app. It is available on WeChat. It is available on QQ. Okay. And then we built some crazy business solutions for McDonald’s. We were the platform behind McDonald’s digital membership, pre all the vouchers, coupons, and their prepaid wallet.
So. And this kind of use cases is how WeBank been able to grow so fast. Hence, nowadays, when we talk to all the banks in Southeast Asia, other than talking about the distributor architecture, about using low cost technology to achieve premium grade outcome, we also talks a lot about better finance, about invisible banking, about.
the necessity for you to modernize your idea, not just to lower the cost, but also to make yourself composable. So you can become as flexible as WeBank to launch a more appropriate product for your partner to fall in love with you and then forming a win win. Partnership to embark on a new journey. So to summarize, WeBank’s success is two sides.
One, of course, is the one that I’m more familiar with. I’m part of the core team, which is the tech. And the other side is the business growth strategy and very simple. Two words, invisible banking, and in the modern term is embedded finance.
[00:08:30] Yorlin
I think based on my discussions with various people in the ecosystem, right WeBank is actually one of the poster child for how banks can innovate today. So every time we get a request it’s usually is WeBank available for a visit and I would love to see what’s happening there.
So I was actually quite Impressed. The first time I spoke with you Jane, it was in Bangkok in your office right now, right? And you were sharing with us how the fundamentals were, the infrastructure and what you had in mind coming from an ex banker background, the kind of challenges that I saw, and I think this is why I, Really like working with you on the report, the transforming digital transformation is that existing banks nowadays, they’re catering to a different target audience.
And especially in Southeast Asia, they don’t have this competitive need that this kind of competitiveness that China banks have. And so they can afford to move slower. And usually for quite a number of banks and bigger compliance play a very big role. And so, usually we see that they’re quite concerned about data leakage, about fraud, about cybersecurity and risk nowadays, right?
So, hence, I think that’s where the Sirius solution comes in the middle. And I think I remember when you visited us in Shenzhen to give a sharing to one of the kind of visits we did, you said that I remember your words very clearly, a bank is like a jumbo jet is very powerful, but it must move a bit slower.
Whereas tech companies nowadays, like the e commerce players are like speed boats, speed boats, right? So they can move much faster, but their power is very limited. So imagine you have the speed boat on the. Jumbo jet. That was,
[00:10:13] Jianggan
it doesn’t jet more faster than boat,
[00:10:15] Jing
the legacy bank are the aircraft carrier.
[00:10:17] Yorlin
Yeah.
[00:10:18] Jianggan
Aircraft carrier so it carries the jet.
[00:10:20] Yorlin
Yes. Yeah. Aircraft carrier. So that actually stuck with a lot of like people since then.
[00:10:24] Jianggan
But it’s kind of true, right? Aircraft carrier needs to be protected from all its flags by sort of or it’s like a different, I mean, now you can make an analogy, right? Anti submarine, anti air, whatever. So these are the compliance and
what else is it?
[00:10:39] Yorlin
Legal compliance.
[00:10:39] Jianggan
Legal compliance, et cetera,
that we’re talking about, right?
[00:10:41] Yorlin
And it becomes more important, especially in today’s environment, right?
Trust is so important and people go to a bank and they’re putting all their money there, right? So I think, of course legacy banks will want to find ways to protect the trust, right? And at the same time, I also know that they want to grab hold of new opportunities in e commerce and I think on the online channels.
Right. So I think hence, this is where the the, the solutions come in.
[00:11:05] Jianggan
Was that comment?
[00:11:08] Yorlin
That was a comment. Yeah.
[00:11:12] Jianggan
you experienced some transformation projects. I mean, and I think back then your role was pushing for it and you were leading some of the projects and you said it was very, very challenging. What was the challenge you see? Having to deal with different stakeholders or?
[00:11:29] Yorlin
Okay, I’ll share my experience from more of and I think then I think Jing you can add on. I think you’ve seen a lot as well. I think the key challenge is when you’re pushing for innovation in an established organization, the key question that organization will ask is number one, why should we do it?
And what is the immediate like return that I’ll get in three years time and five years time. Right. So that’s the first thing. The second thing is that these organizations have a lot of like existing processes and a system that they’re using. And they’re actually usually you have to create a new system, which is cut and slash.
Whatever is being used now for all the other products and just use a new system for this new product, or you had to find a very complicated way to merge the new product into the existing system systems, actually not system, systems, and this actually creates a lot of like discussions, and the discussion will go into, oh, when you make this change A, For this new product, which is going to be online.
How will this impact my existing products that are not sold online? How will it impact , my reporting? How will it impact my customer service? And I think there was one incident when we did transformation. They wanted to do away with actually getting customers to pay with cash, which makes a lot of sense in the digital world, but then for customers that want to pick, make payments subsequently, how they can’t do that.
And then of course that cause a big change request to be escalated halfway through making that, that project as saying that, no, we need to be fair to all customers. Cash is still King. I also want to accept, let my customers pay in cash. And then actually the entire project was delayed for a bit longer just so that these elements could go in.
So these are just some of the kind of examples that we are seeing in for all established company to launch a new products. How about you, Jing? What have you seen?
[00:13:10] Jing
Yep. So I, I saw things mostly from the tech perspective. So so there are many, many different reasons for. Not very successful transformation projects typically is because of the complexity of doing such a thing in a bank, it doesn’t matter which system you’re changing.
You can easily have a huge dependency across multiple upstream and downstream systems. So doing such a change is typically like I share with you guys earlier is it’s like doing a transplant operation. You are removing an organ and replace it with a new one. And then, so doing such a project such a operation, you need to create a bypass if it’s a heart transplant or there’s a lot of preparation need to be done.
And imagine if you are doing multiple transplant project at the same time, I mean, in medical world, it will never happen. But in digital transformation, somehow we believe that we can do that. So that’s why you typically see, like, the bigger the organization, the more ambitious they are. They typically tell you, like, it’s a 5+10+N.
So 5 core systems being changed, 10 major upgrades. And the end dependent project, you can see these kind of cap captions a lot in the past people underestimated the complexity of making too many changes in too many different places. There is typically a number 1 reason of failure. And number 2 is typically because of how currently organizations are organized.
So they typically have a 2 side of the coin business and tech. They don’t see each other, just like your coin, the head will never say see the tail, that’s kind of like the business and tech in most of the organization, they are on opposite side. So another very interesting factor in Webank is that in WeBank business and IT, they’re on the same side.
So basically IT team has its own business people. And business can have its own IT team to do their own initiative. It’s pretty hybrid infusion model that created a lot less gaps between the understanding of why are we doing these and exactly what we want to achieve in this case.
So that makes the communication between IT and tech in a lot smaller and more effective. Okay. And then, so I think that is why in our reports, , we mostly focusing on these two parts , when we were talking about a solution, how to reduce the gap between IT and business has the idea of fusion team and all the elaborations, but also how to minimize The cost of change and minimize the cost of failure, , how to still achieve all the digital objectives without doing all these transplant operations at the same time.
[00:16:03] Yorlin
I really like the term fusion teams. I think I used to think that is only something that happens in startups. Right. Because one person will be doing multiple roles. And during the creation of this report, I learned a lot from talking to you, Jing, as well as the kind of like insights that you shared.
And what I enjoyed about the fusion team concept is more like getting existing people in organization to now unlearn a bit about what they have learned in the last 10 years. 20 years of their work experience, meaning that I’m no longer just like managing finance. I’m no longer just managing product, but I also need to know how it works in the IT part.
And I need to also be able to do certain tasks that in the past I would just pass on to Jing. This is your role. Don’t come near me. And you would say this is a customer complaint. It’s not my problem. But we’re in a fusion team. We’re all gunning towards the same goal. And we all need to work on different tasks in order to achieve that goal.
Right.
[00:17:01] Jianggan
Isn’t a fusion team what a product team is supposed to be doing?
[00:17:03] Yorlin
It’s a
[00:17:04] Jianggan
Linkedin business idea, because I remember when I was running multiple like, you know, Internet companies, I mean, the product team always serves as the bridge between development as well as operations. Right. But of course. It’s a tough job because everyone wants to strangle them.
[00:17:19] Yorlin
And I think in the finance world, we, I think in my experience, it was called something like a change management team or transformation team.
And this would be a bridge between the product people as well as the business people. What I think, and in the report, we also mentioned a term called enterprise architect, which is going to be taking on more role. Change management is actually more role is more for more like the processes, the people, the business strategy, et cetera, et cetera.
Enterprise architect is a new role that I’m getting used to more meaning that this person needs to know both the business side as well as product side. He or she needs to speak. And I think that role currently is missing. So we see in many organizations where we are discussing a problem, right?
It’s usually led by the product team because they face the customers, right? And say, I want to make this change. I want to be able to allow my customer to buy to this product on less than e commerce platform. And I, usually the change manager will say yes. Okay, sure. And then he will take this request to the IT folks and IT folks will come back with a hundred questions.
How is it going to be done? Why do you need this and that? And so then the change manager will take this back to the product person and try to distill it, analyze it and product person will then say, why do you need to know so much information? I just need it today. Just get it done today.
So we’re seeing this kind of dynamics and it’s not wrong because both parts have different KPIs to hit, right? Business needs to get more customers. IT needs to make sure that the reliability and the system is safe. So the fusion team comes , to gel this. And I think the enterprise architect is important to work together with the change management team to talk the same language, have the same framework and infrastructure.
And align the business goals and IT goals,
[00:18:57] Jianggan
All will be the KPI for entreprise update then?.
[00:19:00] Yorlin
Do you have any idea, Jing?
[00:19:01] Jing
So just happened that we are serving as a enterprise architect consultant for one of the lead bank in Thailand.
It is very difficult to set a KPI for enterprise architect because one way you can say that enterprise architect is the most all rounded experts, because if you look at TOGAF, which is like the holy grail of defining what enterprise architecture is it covers business, technology, application, data, and more. Okay. But on the other side, if you look at it from a different angle, we are also the ones that need to learn to compromise in the right way, because you can never have a perfect solution that please everybody.
So what to trade off for what, so there’s a lot of decision to make. So ultimately, I think the the goal for enterprise architect is to define the standard and set the framework, set the process to allow enterprise to move forward in the most effective way. What is the most effective way?
Typically it is measured from ROI’s perspective. And then also time to market and also success rate. So I do believe that we need to measure even the tech team from the business perspective. That’s the whole idea of fusion, right? So if you measure tech team about like a number of bugs, availability of your systems, you’re basically saying that primary school students should do one plus one equal to two.
Yeah, but if you really want to measure the effectiveness, the performance of tech team, they should also share the business KPIs, ROI, time to market. If, for example, right, this project, you say you need a hundred men a day. Can you do it with 80? Can you do it with 60? Right. Why not? What do you need to make yourself more efficient, more effective?
So I think the tech team should own a business oriented kpi as well ROI to tech team is not about how much revenue you make because tech team is not very responsible , for the revenue, but you are responsible for the cost. Can you reduce the cost to improve the ROI?
Can you be more efficient to improve the ROI? And then time to market. can you complete faster? And then finally, success rate. Can you not to fail your technical build? Okay, so these are the kind of things that typically I use to measure my own senior tech guys, because we are a tech company.
So we have to create a slightly different culture among ourselves. So engineers are also having the concept of a gross profit. So I think if we apply the similar mindset to enterprise architecture, who is, who’s literally become the right hand person for the business leader.
So then this person need to think like a business guy. And not just think like a tech guy talking about line, how many lines of code, how many bucks per hundred lines that is just doesn’t make sense.
[00:21:55] Yorlin
So and that’s not right. And then I want to link this to another point that we also wrote in our report is the new way of actually looking at innovation.
As well as the cost, right? So to your point Jing if a IT guy is supposed to reduce the time needed from 100 days to 80 days, and the cost, reduce the cost, on business side, they also need to build innovation in bite size, in composable size, right? So instead of spending six months to build everything, To make this a gigantic launch how do we do that in a composable size and iterate and see what’s the result before moving on to the next part?
[00:22:29] Jing
Yeah, so I think the key approach here is called domain driven design. Okay, Domain Driven Design is a highly abstract skill that is very, very confusing. If you go and buy books to try to read and understand what Domain Driven Design is, you probably will not even want to finish the first chapter.
So, but in the layman’s term, domain Driven Design is basically very simple. It just helps you how to dissect complex things. Okay. So if you say that, for example, right, you can just think that I have a requirement. I want to launch a digital bank. That can be a business requirement. And then it will take a very, very long time to.
analyze and then to build. But if you start applying domain domain design into just this phrase, I want to build a digital bank. Then you will start dissecting digital bank. What is the digital bank? And then you’ll start do applying all the approaches divide this one big muddy board into smaller chunks and then smaller chunks within the small chunks.
So it is a top down approach about breaking down a complex things into well bounded, smaller domains. We’ve clearly defined boundary entity behavior and characteristics. So basically it is a drill down. It is a process of dissecting complex things. Then you have a clear understanding of what is going on, and then you can pick and choose a much smaller problem space to solve.
And then you start aggregating the solution of smaller problems, become the final solution to your big problems. So that’s exactly what you said, in order to go to market faster. Your problem has to be simpler. Otherwise, there’s no magic here that some technology can help you solve a complex problem in the simpler way.
You can only solve a simpler problem in the simpler way.
[00:24:33] Jianggan
I just asked ChatGPT while we were talking explain domain driven design to me. It gave me about 60, 70 word explanation. I said, this is too long, too difficult to understand. Gave me something below 10 words, and then gave me something which I completely couldn’t understand.
But anyway,
[00:24:47] Yorlin
Read our report.
[00:24:48] Jianggan
Yes, or ask ChatGPT yourself if you have a paid version. One question about domain driven design. It is obviously a software development approach, right? And and of course, you only, you, you remember when you were doing transformation, people kept talking about this keyword called agile.
And you remember that in some of your projects that you actually if I may say like hired agencies to explain to you what is the difference between agile and waterfall and help sort of teams sort of make things agile, but in lots of cases where we see a lot of thinking and a lot of sort of effort went into agile, but in the end, it doesn’t really make the whole transformation more agile.
And of course there could be specific cases, but Jing, I mean, how do you see that in general? I mean, how was Agile used or sort of not used properly?
[00:25:37] Jing
Yeah, so I think agility is something that people has a big misunderstanding. I think agility is the outcome. Agility is not the approach. So you want to be agile, actually, if you look at the core of agile project management style, it is again, quick iterations, basically dissecting the big issue into smaller ones so you can iterate faster.
Okay. And people sometimes tend to get lost in this in this journey and thinking that Agile means no governance. No, no, no. Actually, that will start a disaster. Actually, I think Agile needs domain driven design because at the end of the day, it is about dissecting a complex issue into smaller problems so that you can iterate faster.
Like I said, you can’t iterate faster if your scope is big, okay? So I think that they are related. So agility can be achieved with a few key characteristics in your technical design. Number one is domain driven. If you can do domain driven design, properly dissecting your problem space, has a clearly organized problem space, then you can easily define a very clearly matching solution space to your problem space.
And then when you are building your solution, if you apply a very old concept in software engineering, which is called modular design, and then make sure you’re abstracting your systems in the right way with enough reusability in the modules. then You can be agile because you are solving a smaller problem with 40 to 60% reused components, and you’re only building the remaining.
That’s how you can speed up.
Just to share 1 story the record in WeBank from forming the product idea to launch the first MVP in production. It’s 11 days.
[00:27:37] Yorlin
Wow.
[00:27:37] Jianggan
How many days? 11.
[00:27:40] Jing
[00:27:41] Jianggan
Okay.
How big was the project?
[00:27:45] Jing
I think it’s a retail e commerce retail kind of online, offline financial service. Yeah.
[00:27:52] Jianggan
So, still requires products, still requires integration and all this testing and stuff, right?
[00:27:57] Jing
Exactly. So it is still compliant to all the standards, but 11 days because in there’s 6,000 plus 7,000 events that is becoming the glue for defining the business world.
And
[00:28:12] Yorlin
I think to add on, right you also something that you can usually tell us is that when you can be agile, you can run fast. That’s great. But if you’re running in the wrong direction, then the entire project , it’s going to end up, you know, failing.
So I the kind of issue that I think businesses also need to have is also making sure when you do modular and agile design, composable is running in the right direction.
[00:28:35] Jing
Exactly. So, , I think domain driven design is the starting point. And then, it comes to the digital twin of domain driven design. Domain driven design is talking about human. Human need to exercise domain driven design to better define the problem, but on the system side, on the digital side, it is event driven.
So that to make sure that whatever you built can easily be composed, are not closely coupled, and together. So these are the two exactly, exactly. And you, you, you, you typically can’t do event driven if you don’t do domain driven because you don’t understand how many entities in the, in the problem space, their behavior, their characteristics, then you can’t plan the events and then they become super messy there.
Yeah. So the technical version of domain driven design is that it’s event driven, using event driven to support.
[00:29:30] Jianggan
So if, let’s say that, I mean, I remember that we put in a report that compostable innovation equals mentoring design class event driven, right? Yep. So the question is if this brings, obviously benefits why are organizations already adopting it?
[00:29:48] Jing
This is a great question.
To achieve that there’s a lot of technical challenges. Okay. First of all, I mean, I remember Yorlin, Nanette, both try to learn domain driven design. And then you ask ChatGPT and you get a very abstracted answer. So that’s how difficult practicing domain driven design is.
So it is, everyone knows the value, everyone knows the power, but to actually do it, it takes a lot of effort. Okay, it takes a lot of effort. So that’s why the learning curve for domain driven design is very steep. It takes years of exercise to perfect it. Our domain driven design journey started in 2010.
So when we were designing the core banking systems on AS400, we took a deep look at one of the very famous framework coming from IBM called FW Okay. An FW , is a very comprehensive financial framework coming out from the Dublin lab of IBM. So IBM was the creator of this thing.
And then inside of this whole thing, under the data model section, there is a domain driven, there’s a domain design they did for banking sector. So we start, we learned that, and we start applying that in all the projects that we did from 2010 until today. So through years of exercise, the core members of my team learned to think in a domain driven way.
So this is not something that you can take a 10 days lesson or 15 days training course then you’re a master already. No, you can learn how, but it takes time to perfect. That is why the adoption of domain driven design is not very, very high, it’s because it is difficult. Without domain driven design, then event driven architecture becomes quite difficult, because it depends a lot on the clear dissect of the problem, but also because Event Driven itself, we always say that things are loosely coupled.
They are not like command based, but they are fact based. That also means you don’t know what’s going on in the plain term. Okay. You don’t know what’s going on and you don’t know what exactly what’s going on. It’s very scary. It’s very scary. For most of the banks, most of the banks, they want to know exactly what’s going on.
So that’s why they are still doing the SOA API based A core, B core, C core, D. So, and then in order to get your loosely coupled system design to function and perform as well as the closely coupled design, this is a technical barrier need to break through. So many reasons adding together, making composable application a bit more difficult to achieve at the same time.
Nowadays, it’s a lot better because we already have microservice. 10 years ago, 15 years ago, it’s even more difficult because it was monolithic running on mainframe. Big chunks of codes packaged together to run. That’s even more difficult. Today, we already have the technical foundation for doing composable application.
That’s why we are talking about it. You have microservice, you have container, you have even mesh. All these technologies are there to facilitate you to drive a domain driven design on a event driven architecture. Then the remaining is how can our human being adopt into these mindsets and then start practicing it and implementing it.
[00:33:24] Jianggan
When you say that, it takes more than 10 years to have a very good time, at least that comes from your experience. Then you know, market so realistically, I mean, how should organizations go about it? And I think the usual approach that many organizations do is that the. They will have consultants, right, because consultants have seen a lot of different use cases and they should be able to advise that but what do you think , is the most right approach to, to, to actually achieve composable innovation in a fast way, aside from engaging in Sirius, I mean.
[00:33:57] Jing
Okay. The primary approach is to engage Sirius. I’m kidding. Yeah. So I think that the fundamental way to address this is to pay attention to build your enterprise architecting. You might not be able to find a ready to deploy team in the market, but just, Support them just endorse them and power them.
When I say 10 years, it was as we did it for 10 years already. But it probably would take like a couple of years or five to six projects that you can already quite, you know, familiar and proficient , with such approach. So just be patient with them. Keep the, keep, let them try.
So self create a strategy, enable the team. And then and it’s also like right talent and when you want to have a jumpstart, then you can consider some external helps for, for a program to enable you or a partner to you know, babysit you for the beginning.
[00:34:59] Yorlin
Maybe this is a good time to slide in.
This is why Momentum Works and Sirius. We’ve created this program called the Chief Digital Officer Program, where we’ll embed organizations as selected leaders into this innovation lab where we can actually try out design thinking and event led innovation and composable innovation. So that led by both of us.
Yeah,
[00:35:21] Jianggan
this is quite interesting because I came from a background. I mean, running Internet companies from operations and business side. And I had, I mean, over the years, I’ve learned to be more patient. If you talk to me to, like, 10 years ago, I was very impatient for everything.
Everything needs to be done yesterday. And now I’ve learned to be patient and my understanding about large corporates, large organizations were always that they are too patient. And over the years, as I have discussed with many of them, I mean, you guys have done lots of projects. I started to learn that maybe that’s not the case.
People are actually impatient in a way because people want to see successes. I mean, people want to drive things forward. But the reality is that whatever you’re dealing with, which is actually quite complicated with lots of pieces. Sometimes it’s just not that easy , to achieve agility.
Hmm.
Well, one more question. Since you mentioned about AS400 legacy systems. I remember that doing the works for the report, and you kept telling the team that legacy is beautiful, AS400 is beautiful, IBM is beautiful. I mean, not IBM as a company, I mean, you didn’t say that, but IBM products are beautiful because this were simple.
And then it was written, I mean, with actually proper design and stuff. Now, I mean, we go to usual like talk shops, conferences, and people talk about legacy as if it’s something that there’s a plague, right? They want to get rid of it. They want to sort of move on to the new world, but they complain about it being stuck with legacy.
In your opinion, what’s the right attitude here and how should people make the best out of it? I mean, we know that tens of thousands of institutions still run as 400 and and it shows that it’s still critical. But increasingly, I mean, you see young people will learn to become, I mean, technologists that they don’t want to, I mean, be around this kind of systems.
[00:37:10] Jing
So when I first started learning coding in early 1990 something, I think I started learning coding in 1993. Yeah. So at that time you can learn Fortran, COBOL, and all these programming languages in university. Yeah. And today university only teach Java. They don’t even teach C anymore. So they teach Java, Python.
So there’s a shift in education focus for you know, computer science. That created a lot of problems for carry on the legacy of the older design older systems. So when I say they’re beautiful is, it is the same kind of feeling when you look at a 1960s classic Mercedes, or Porsche, or Ferrari.
They are good. The problem now is that if you’re expecting them to carry tons of goods, they are not designed for it. Okay, so, it’s a mismatch between the purpose of the system and then the needs of your business. You need to ask yourself, right? Are all your businesses needs to run with a new technology?
Is the old technology really running out of value? There’s no residue value in there at all. Recently, we are talking to one of the digital bank applicants about how we should approach between they have what we call the Gen 2 core system and Gen 3 core systems, how to position the products between these two.
So again, like I said, ROI, time to market, success rate is the key. Then you should really launch the simple and the early, the first batch of product on your Gen 2 legacy core. Because it is already there. It is already up and running instead of hoping that you can config and customize it, the simple ones on the on the new generation of core systems.
It’s very simple. It is the first principle. You apply the first principle. What do you want? If you are a stubborn and a rich person, I really, really don’t like legacy. I don’t care. I just want it to be out of my company. Then go for it because that is your purpose.
That’s your purpose But if your purpose is to launch a product and ask yourself, can I launch it on the on the stack that I already invested if can Why not?
[00:39:45] Jianggan
Because it’s not cool.
[00:39:48] Jing
Then you are the stubborn rich guy, right? Who just want to be cool, then I wish you good luck.
[00:39:54] Jianggan
Then you always have to buy the latest and every time there’s a new version you buy, you have a collection for your garage.
[00:40:00] Jing
I think
the fundamental reason for any company to really consider sunsetting any legacy technology one of The inevitable reason is the, when the companies, IBM sunsetting these this product, but typically they will give you a couple of, they will give you years ahead of notice for you to get ready for it.
Yep. So, but other than that, it should be business driven. It should be first principle driven that you just find the best path for you to get from where you are to where you want to be. And you don’t really care about whether you look cool in due process or not.
[00:40:44] Jianggan
But how about the talent issue here, right?
I mean, young people are not learning the systems and old old guys, eventually they will retire , and have easier life. So eventually this shift will happen with, with or without IBM, like shifting, right?
[00:40:57] Jing
Exactly, exactly, it will happen, it will happen, but it just doesn’t deserve the kind of like rip and replace style of approach at the moment.
We still have time, we still have time, we still can do this in a way more progressive, practical and efficient way.
[00:41:13] Jianggan
I think we do have a lot to discuss. And and now I have the reflection. Actually, yes, it happened over drinks. And so I don’t remember what happened over drinks until people remind me. Yes, go ahead.
[00:41:24] Yorlin
The only shoutout I want to , give is to Nanette and Sabrina. You re download the report we love it so much. There’s this image about spaghetti. I think the closing word from Jing , and Jianggan over drinks, is that transformation is like spaghetti. It’s like a tangled part of spaghetti.
And the solution is not to untangle it. The solution is to composable innovation. So putting all these together was just, I think this is actually just a masterpiece in the making spaghetti to composable innovation.
[00:41:52] Jianggan
And remember we threw this image into our community and then people started saying that, Hey, we should call it Mixian and we should call it I don’t know,
[00:41:59] Yorlin
Mirebals..
[00:42:00] Jianggan
Yeah. Different kinds of noodles. And it seems that people are passionate about this analogy. And of course there’s different variants, but essentially, if you look at the, the stack that many people are facing in a financial industry, we’re facing the same problem, right? We’re trying to address the same issue.
And of course with a bit of cultural variant, et cetera, et cetera, but at the end of the day Yeah, I think what you mentioned, I mean, what’s composable innovation was the component of that, et cetera. And that is universal with the financial institutes we’re dealing with today.
Right? Yep.
[00:42:31] Yorlin
Yeah. So on this note Sirius and Momentum works. We do have this chief digital officer program that we’re running for organizations. So we’ll be talking a lot more about it over the next few months and we’ll be coming up with more case studies and how fun it will be to innovate Composable in a safe sandbox,
using a Sirius multiverse platform.
[00:42:51] Jing
Thank you. Thank you Yorlin. Yes. Hopefully we can bring these to more organizations
[00:43:00] Sabrina
Thank you Jing for joining today’s episode of the Impulso podcast if you guys are interested in Digital transformation, like we mentioned, Momentum Works and Sirius Technologies did launch a report called transforming digital transformation, which will be linked in the show notes below.
I do recommend that you check it out because I think it has very good visualizations and breaks down the complex terms and ideas that we’ve spoke about in this podcast in a simpler visual. So it might help you better understand
[00:43:26] Jianggan
and explain to your colleagues.
[00:43:27] Sabrina
Yes. So thank you guys for tuning in to another episode of the impulso podcast.
We hope that you guys enjoyed today’s episode. And if you did do like our podcast and follow us on Spotify, Apple podcast, or your preferred podcast platform to stay up to date on the latest happenings and trends in tech, new retail, and a broader, digital economy.
