00:00:07

Hello and welcome everybody to our talk, highlighting the impressive agility story of spar e-commerce. We will explain how their e-commerce program massively improved over the last five years with achievements like 99% reduction of deployment time, a hundred percent compliance across several complex systems, consistent test data, et cetera. Let me introduce max senior architect from spar ICS, and one of the main drivers of sparse technical e-commerce platform from its beginning until now. Hello max.

00:00:38

Hello, David. Thank you for your introduction. And my name is Maxima and I'm working for Bob business services. That's the it company for dish Austria group and established set. I was part of this digital journey. And today I want to share some insights with you, uh, how, uh, our journey was.

00:01:01

Yeah, let me know to quickly introduce myself. I'm David I'm heading the digital advisory practice inside enterprise studio HCL technologies. When we started working with spar, we were still named Automic, the subsequent adventurous mergers and acquisitions, uh, through CA technologies and Broadcom protests where we are today. Still be continuously supported spar Austria with the last years. And, um, yeah, we provided the team for that and that still is a leader for organization by transformation and typically engagements. We accelerate the flow of value from idea to production. We provide support from strategy to actual execution and are backed by 150,000 HDL colleagues, um, who serve more than half of the fortune 500 companies.

00:01:46

Yeah, spot Austria is, uh, quite a traditional, uh, company. We started our business, uh, more or less 65 years ago. And yeah, the, the company itself has, uh, a lot of, uh, outlets and it's more or less a traditional business with many stores, many, uh, employees. And, um, yeah, the, uh, the revenue is growing constantly. Uh, and, uh, we have also a significant, uh, it department with, uh, roughly 500 it professionals. The group itself is, uh, doing pieces in, in seven middle European, uh, countries and its main business is food retail. However, uh, the business is also, uh, doing, uh, sports, fashion, retail, and it's owning and operating a significant amount of malls, uh, across, uh, middle Europe. The pressure for, for our future business is there. And, um, yeah, and we wanted to be part of, of that digital game more, or especially considering that our main, uh, competitor, our main local competitor is investing a lot of money in new business models.

00:03:11

And, um, also we all know that the digital natives are around the corner and stay are more or less disrupting the market. Uh, but it's not only the digital, uh, channel we wanted to serve. It's also more or less, uh, somehow a kind of mixture of offline business and online business. The so-called omni-channel, uh, that you can think of, for example, digital product data, which can be used in the, in the online channel, in the online shop, uh, but also in the, in the offline store. So to say, uh, where you can use that digital data, if you want to know more about, uh, the coats, Europe buying.

00:03:54

So there was actually no option to go digital, but just the disease and how to start.

00:04:00

Yeah. That that's that's right. That's right. And, uh, yeah, when we started, when we started excitement was, uh, quite big. So the decision to go digital was his reason, a lot of excitement and our credo at that time was, uh, we make this happen, whatever it takes. So we had, uh, quite a significant and higher ambitions at the beginning. Uh, we wanted to do it better than everyone else did it before. Uh, we had more or less, no shortcomings with respect to functionality in our minds. We had tons of options, uh, and features. We wanted to do a fully blown omni-channel experience with, uh, with features like home delivery, pickup boxes, app integrations, and many more. And, uh, of course everything should be working from day one. And, uh, on top of that, uh, our intention was also to, to be it somehow a platform that was, uh, should be usable for more than just one country, because we are doing business in more countries. So the idea was to have a platform that could be used, um, in different flavors for our countries like Slovenia, uh, Italy, Hungary, or Austria.

00:05:26

So max, how did it go? Did it turn out well,

00:05:31

Well, uh, to be honest, uh, uh, we quickly figured out, um, doing, uh, this new business is not that simple. As we saw in the beginning, we figured out that the, the business case, the digital business case, uh, is much more different, uh, then maybe, uh, business cases, uh, you know, like selling a book or selling a bottle of wine, it's way more complicated or complex to sell goods or deliver goods to your front door. Um, and the reason therefore is because there are many regulations and laws that need to be considered in advance. Not many of us had experienced such an high dynamic environment where, um, yeah, we're, we're, uh, requirements are changing constantly and very, you have to adapt, uh, that quickly. So it was also a real culture clash.

00:06:34

Okay. In addition to the culture clash, but what is the technical complexity of such a workshop, uh, such a workshop. Um, could you maybe explain for a non retailer retailer audience? Um, yeah. Why does this more complex than setting up some, um, you know, WordPress online shop, whatever, um, which is broadly available,

00:06:55

Uh, here again, uh, it's not just, um, yeah, having a simple front-end where you can put, uh, items into your basket because a typical, uh, food retail, um, use cases that you have, uh, at least 50 products in your basket most have more than hundreds. So there are many challenges to cover as well. Uh, on top of that, you need master data, uh, digital master data that needs to be very consistent, uh, across many systems. So this was also not easy to achieve right from the beginning. Uh, and the, the, the third part that is, uh, plays a major role in, in such a, um, a business model is the logistics systems. Uh, here you need to have deliveries, lots away level. You need the tour planning, uh, you need, uh, the commissioning tools that, that, uh, need to be harmonized amongst each other. So many, uh, items need to, uh, collaborate here.

00:07:55

And the, uh, the data that is, uh, transferred and required across all those systems needs to be, uh, very, uh, consistent and precise. Um, and the more easy part, so to say is, is the cross channel, uh, item bear you have, um, yeah. Fulfillment and stuff like that, and the analytics parts. So these are more or less, uh, on, on top of those three, uh, functional, uh, items that are necessary to build up, uh, online shop. As you can see here, a lot of applications that covered the different functional, uh, items I just explained. And here, uh, again, uh, uh, we had, we introduced new, uh, new applications, like, uh, SAP Hybris, where we developed the front-end. And, uh, we use also the Adobe experience manager, where we had a lot of marketing tools, uh, or we used, or we are using marketing tools and those two to, um, new tools and technologies where we're using here, um, have been new for us.

00:09:02

So we were not very experienced. You had to learn a lot with them. And, uh, on the other side that the existing tools we were already already using in the offline channels, uh, both developed by other teams. So you can imagine, uh, that we had, uh, to Carver or to circumvent a lot of silos that were, uh, in place there. Uh, we had, uh, different release cycles of the, of the software. Uh, we had, uh, SRC, different teams, uh, different departments. So a lot of hurdles to, um, to get, or to pull everything together into a single, uh, backdrop experience. Yes, that's what we see on, on the next slide. Um, of course those, those applications, uh, are all necessary to, um, uh, to, uh, have the business process modeled in the it systems and those systems need to interact. So, uh, we need a lot of interfaces, uh, to exchange the data across the applications that the data is consistent. Uh, on top of that, we also have, uh, some cloud applications that were used. Uh, and so we have somehow a hybrid environment. And, um, what makes it really difficult is that, uh, some business cases, um, touch a lot of, uh, it systems. So, uh, a high degree of dependency, uh, between all those it systems.

00:10:36

Thanks max. Now we have a clear understanding about the business case, the need, and also the architecture of the system, but could you maybe also explain how you started developing and building these kind of integrations and functions?

00:10:48

Well, so the next slide, uh, is, uh, somehow not, uh, um, the way how you should do it, but that's the way how we did it. So to say, um, uh, to be honest in the beginning, uh, we, we, uh, we had not really a clue about HIV development. We had not really much idea of what dev ops is. And, uh, we had to learn a lot here, uh, at the beginning, we thought we know what we are doing, but, uh, to be honest, reality showed us something else. Uh, and how did we start, uh, at the beginning? And we hit a fully lone backlog, so many items that we should cover. S as I already mentioned before, uh, our application development teams were spread across the company. So we also built up different work packages where, uh, the teams develop more or less in an isolated, uh, team, their, uh, their functionality and their backlog items.

00:11:51

So this was split over, uh, many teams, no real coordination. And when, when then we came together and, uh, and tested the, uh, uh, the functionality and check whether this is working or not, you of course experienced, uh, a lot of, uh, of problems because, uh, what, what was the main problem we integrated way too late? Uh, so the testing was also way too late. Uh, and, uh, also we, we contracted in some areas, um, uh, development partners and those development partners got obviously feedback way too late. So this means that we had to delay our, uh, initially sought a go live date, um, several times, because all, uh, because of the reasons that feedback and functionality was tested way too late.

00:12:50

So after one and a half years, you had a potentially executable product, not cheaper, but at this time.

00:12:56

Right. Right. So, so finally we, we, we got the product that was more or less yeah. Executable, as David said, it was potential truly executable. And then we had a look at the non-functional requirements, uh, because then we realized now we have to take a look if, if the performance is good, if, uh, if customers are able to really select, uh, lots of items and to do the check out in parallel, more or less, or hundreds of clients should do the checkout in parallel. And yeah, we started to test it. And as you can imagine, uh, also here we experienced, uh, a lot of travelers, uh, and again, we had to shift more or less the release date. Uh, this looks like more, uh, like an HR process. And from there on things became better. We were, uh, we were better at that point of time. So, um, our deployment time improved, um, but still we had, uh, we had no automation in place. Uh, we, we were better and more consistent. Uh, and, uh, yeah, we, we still figured out we have, we have problems. And I think that was the time when we, uh, addressed, uh, you and your company, David, uh, where we asked for help in, uh, process modeling and automation.

00:14:25

Yeah. It was the start of a continuing journey, which we want to highlight in our talk today. So you asked us to automate everything, but before we did that, um, we had a look into, um, all of the areas, um, of the whole software development life cycle. And we found out that actually, um, also in your organization, um, brief the issues, um, the see there, um, yeah, you'll also find in other organizations, there's a study from Gartner highlighting that only 8% of the issues are in the tech area, which means automating that 50% and 42% are located in cultural and process issues. And that's what we did with you together then, um, analyzing, especially those issues and attacking those issues first. So what did we do just right at the beginning, we stayed, we helped you to stabilize and streamline, um, the full process. Um, what let's say, what is the value stream just very quickly?

00:15:22

You see operational value streams in, in our case, this would be, for example, search product adds to cart, choose the shipment method, choose payment, submit the order and ship the goods finally. And all of those, we have plenty of software development, value streams, as you showed us before in the architecture diagram and for all of these, um, uh, development value streams. Um, you also have the full cycle from, uh, define build test release, uh, the shortened one. So we analyzed whatever's happening and found out that especially the release and deployment parts, uh, need to be, uh, first stabilized and then streamlined. Alright, we did this for the first, um, application of first part of, um, the whole, um, e-commerce platform. And how did we do it with the classic? Um, yeah, continuous continuous improvement methodology. We plan small initiatives. Um, we coached and implemented them together, analyze the results and finally exited on the results. So, um, also we all know that, um, the technical change can be exponential. What we did is, um, focusing, especially on the culture part, which is always just, um, can be approved, uh, linear and not exponential. Yeah. What did we achieve with, um, fixing process and culture? Could you highlight that max please?

00:16:41

Sure, sure. Uh, along with, with those improvements, uh, related to processes and culture, we were able to get, uh, way quicker deployment, uh, rates. So roughly to say, we, we, we, we needed before that we needed more than a week or roughly a week to deploy a new package and to be consistent across the systems. And, uh, with that improvement, we achieved, uh, a deployment time of a single day, more or less. So it was already a significant improvement. And, uh, we also said, uh, that, uh, yeah, uh, the reduction time was roughly 91% and the quality of the deliverable or the deployment was, uh, like five times better than before. Uh, and it was better than before because, uh, we had consistent data across, uh, the different stages, uh, the testing stages, the development stages, uh, the quality stages, and of course the production stages. And, um, and we had also consistent configuration across those systems. So the product owners were able to concentrate on the new features that were being delivered, uh, and not, uh, testing configuration or data,

00:17:57

But that's awesome.

00:17:59

Yeah. Kind off. It, it was, uh, it was great, a great achievement at that time, however, um, uh, to deploy a new package, uh, and, uh, uh, yeah, which lasts more than a day is still not sufficient.

00:18:15

Okay. Then now we can start automating, we have a streamlined process. That's what we did in the next two to three months. We fully automated the CICT tool chain, um, fully based on what we did before, after standardized and streamlined process. And, um, yeah. How do we do, how did we do it? Could you maybe explain a little bit,

00:18:37

Yes. Uh, in a first step, uh, we, we tried to orchestrate, uh, the building, the configuration, uh, configurating, uh, the packaging, uh, off the software itself. So the first step was to have a consistent package of the bandit software across, uh, all the different stages, uh, which are development test acceptance and, uh, production or pre-production as well. Uh, and in, uh, in a second step, um, uh, we also, uh, made, uh, so-called system copy or also back copy of production data to pre-production stages. This was, uh, necessary for us, uh, because of the many different systems involved in the, um, in the business model itself. Uh, and it, uh, systems involved in the, in the business processes. It was, it was really necessary to have a consistent data set across those different stages and this improved quality a lot, because we could test and evolve on new features on, uh, more or less production, um, data. On top of that, we also introduced, um, automated testing and this reduced, uh, the feed picks equal to the developers significantly, uh, which was a very important, uh, step for what is well I'm here to say is that, uh, the orchestration was done, uh, by, uh, the application release automation tool of atomic at that time. And, um, this, uh, helped us, uh, a lot to improve our situation.

00:20:22

Yeah. But automating our orchestrating, the continuous delivery pipeline was just the first step. If you look at the big picture, um, we call it the DevOps orchestration platform. There are several capabilities in there from HL execution, continuous testing, continuous integration, security monitoring, continuous delivery. There are plenty of, um, yeah. Capabilities you need to build up in your organization, and then you technically need to orchestrate whatever's flowing through such a default, so frustration platform.

00:20:56

Yeah, that's right. That's right. Uh, and, uh, yeah, here, you can see, um, the, the orchestration of the different tools. So we had, uh, a significant amount of tools in place. Uh, automating them alone, as David said, is, is still not enough. Uh, the key value here is the orchestration so that the processes, uh, the it processes can flow, uh, and the, uh, the orchestration of the Amala Simi automated parts of each tool, uh, get together. And this is really what helps to, to improve significantly. We achieved really a lot at the end of all those, um, yeah, those, uh, steps we, we have done, uh, we reduced the deployment time, uh, down to roughly half an hour from one week to half an hour. So we, we say we, uh, improve that, uh, that time by 99%. So a really an awesome achievement. And this was not only the time, but also the consistency and quality of, of that deployment was, was great.

00:22:12

So, uh, we say we have a hundred percent compliance of test data and consistency across, uh, the systems, uh, which helps you focusing on doing the real work, uh, which is very, very important. And, uh, of course that the next fear is, which is, uh, popping up right now is that, um, we reduced, uh, also the deployment related arrows. So we say we have almost no arrows anymore that are related to a deployment. Uh, and this is just great because you, as I already said before, you, you just concentrate on the real work. Uh, in earlier days when we started up, uh, we had so much time, uh, uh, to figure out what's going wrong again. And now, uh, we just, uh, uh, deploy the packages and concentrate on the new features that are being developed.

00:23:15

So, uh, an additional, uh, item where we are really proud on is that we have, uh, more or less, a hundred percent stream, like in-house dev ops team available right now, because in the beginning, we started with many partners, many different partners that help us out. Uh, but in the meantime, we figured out that, uh, doing such a work or such an online channel, uh, development, that's not work if you have the partners spread across the, the country more or less. So we decided to in-house that, and, uh, we achieved to, to build up and complete in-house, uh, dev ops team, uh, that is doing a great job. And, uh, yeah, what helped us also is that, uh, not only our developers doing a great job, but also our C-SAT means, so to say, and we are able to build up, uh, more or less a full production, like environment in less than a day.

00:24:19

So what, uh, what did this bring to the business?

00:24:23

Um, the business figures, of course, uh, also, uh, good, uh, compared to our patches that we have available, uh, we calculated more or less that we have a saving of, of roughly a hundred thousand euros per release, which is for us a significant amount because our budget is not that higher comparable to others, maybe, but for us, it was a significant saving. And also the introduction of, um, of the tool or the orchestration tool, uh, gave us a feeling that the return on that, uh, on that tool, uh, and that return on investment, uh, was significant because it helped us so much saving a lot of money and a lot of time with respect to, uh, men, uh, or labor. And, uh, of course these numbers are, um, I have to be considered in such a way if we would have not improved in any case, but at that time, and if we, uh, calculate it into, to the future, uh, these are the numbers, uh, that are well, our next steps are more or less, uh, to yeah.

00:25:38

To move, uh, from a project thinking, uh, to a product thinking because we're still, uh, heavily thinking in projects, not really in product development. So this is one of our key, uh, endeavors for the next time. We also want to, um, yeah, make real CICT instead of weekly deploys. Uh, we also experimenting with, uh, feature talkers and, uh, also, uh, experiencing with, with, uh, dockerized applications that developers can, uh, release or deploy their development and test it on their own. Uh, we also want to confirm what the model is, web front-end platform to make it more, uh, flexible, uh, and, uh, easier to develop in the future. And, uh, one thing, uh, we still do not have in place is, uh, non-functional testing like performance testing. So we also need to take care of that. Um, and yeah, last but not, uh, the feature teams thinking is, is something we want to address in the future so that, uh, microservice-based, uh, development teams can be established.

00:26:56

All right, is that, that would like to handle it to the last slide with the final learnings from this whole project over the last years

00:27:05

From my personal learning is that you have to experience, this is very, very important. Uh, you cannot, uh, learn it by reading a book. You have to experiences experience this. And, um, for me, the, one of the major parts is the shift left continuously, uh, topic. So it means that you have to, to, uh, test very early integrate very, very early and, uh, yeah, create some, some kind of continuous test automation. So that's, that's very, very, very important aspect from my point of view. Uh, but this is not alone. Uh, the second part is, uh, to, uh, to start automating as early as possible, because this, this helps a lot, especially with, with respect to configuration, you need it to make sure that all your configuration data is automated across all your stages and systems. Otherwise you never get to a real CICT. And, uh, you also have to, uh, to take care of that your software components, our packages right away from the beginning.

00:28:15

And, uh, of course, uh, it's, it's good if you can orchestrate that, um, uh, as much as possible. Uh, what I was wanted to add is, uh, feedback loops, uh, with the teams, uh, not only from a technical point of view, but also from a business point of view. So you need to know if the features that you are developing are, uh, addressing the customers. Uh, but also from a technical point of view, the development, uh, development teams need to know if the features they are developing are working or not. And the earlier they get the feedback, the better you can, uh, develop and drive your tool or application.

00:28:58

All right. Thank you, max. And thank you, the audience for participating. Thanks for your attention for listening to the story of spar commerce. Thanks.