David Jungwirth

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, 100% compliance across several complex systems, consistent test data, et cetera.

Let me introduce Max Ehammer, senior architect from SPAR ICS, and one of the main drivers of SPAR's technical e-commerce platform from its beginning until now. Hello, Max.

Max Ehammer

Hello, David. Thank you for your introduction. My name is Max Ehammer, and I'm working for SPAR Business Services. That's the IT company for the SPAR Austria Group. And as David said, I was part of this digital journey, and today I want to share some insights with you, how our journey was.

David Jungwirth

Yeah. Let me also quickly introduce myself. I'm David. I'm heading the digital advisory practice inside Enterprise Studio by HCL Technologies. When we started working with SPAR, we were still named Automic. The subsequent adventurous mergers and acquisitions through CA Technologies and Broadcom brought us where we are today. Still, we continuously supported SPAR Austria over the last years and, yeah, we provided the team for that.

Enterprise Studio is a leader for organization-wide transformation. In typical 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 HCL colleagues who serve more than half of the Fortune 500 companies.

Max Ehammer

Yeah. SPAR Austria is quite a traditional company. We started our business more or less 65 years ago. And yeah, the company itself has a lot of outlets, and it's more or less a traditional business with many stores, many employees, and the revenue is growing constantly. And we have also a significant IT department with roughly 500 IT professionals.

The group itself is doing business in seven middle European countries, and its main business is food retail. However, the business is also doing sports fashion retail, and it's owning and operating a significant amount of malls across middle Europe.

The pressure for our digital business is there, and we wanted to be part of that digital game, more or less, especially considering that our main local competitor is investing a lot of money in new business models. And also, we all know that the digital natives are around the corner, and they are more or less disrupting the market.

But it's not only the digital channel we wanted to serve. It's also more or less somehow a kind of mixture of offline business and online business, the so-called omni-channel, where you can think of, for example, digital product data, which can be used in the online channel, in the online shop, but also in the offline store, so to say, where you can use that digital data if you want to know more about your goods you are buying.

David Jungwirth

So there was actually no option to go digital, but just a decision when and how to start.

Max Ehammer

Yeah. That's right. And when we started, excitement was quite big. So the decision to go digital has risen a lot of excitement, and our credo at that time was, we make this happen whatever it takes.

So we had quite significant and high ambitions at the beginning. We wanted to do it better than everyone else did it before. We had more or less no shortcomings with respect to functionality in our minds. We had tons of options and features. We wanted to do a fully blown omni-channel experience with features like home delivery, pickup boxes, app integrations, and many more. And of course, everything should be working from day one.

And on top of that, our intention was also to build somehow a platform that 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 in different flavors for our countries like Slovenia, Italy, Hungary, or Austria.

David Jungwirth

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

Max Ehammer

Well, to be honest, we quickly figured out doing this new business is not that simple as we thought in the beginning. We figured out that the digital business case is much more different than maybe business cases 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. 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 a high-dynamic environment where requirements are changing constantly and where you have to adapt that quickly. So to say, it was also a real culture clash.

David Jungwirth

Okay. In addition to the culture clash, but what is the technical complexity of such a webshop? Could you maybe explain for a non-retailer audience why this is more complex than setting up some WordPress online shop, whatever, which is broadly available?

Max Ehammer

Here again, it's not just having a simple front end where you can put items into your basket, because a typical food retail use case is that you have at least 50 products in your basket. Most have more than 100. So there are many challenges to cover as well.

On top of that, you need master data, digital master data that needs to be very consistent across many systems. So this was also not easy to achieve right from the beginning.

And the third part that plays a major role in such a business model is the logistics systems. Here, you need to have delivery slots available. You need the tour planning. You need the commissioning tools that need to be harmonized amongst each other. So many items need to collaborate here, and the data that is transferred and required across all those systems needs to be rather consistent and precise.

And the more easy part, so to say, is the cross-channel item where you have fulfillment and stuff like that, and the analytics parts. So these are more or less on top of those three functional items that are necessary to build up an online shop.

As you can see here, a lot of applications cover the different functional items I just explained. And here again, we introduced new applications like SAP Hybris, where we developed the front end, and we used also Adobe Experience Manager, where we had a lot of marketing tools, or we are using marketing tools. And those two new tools and technologies we were using here have been new for us, so we were not very experienced. We had to learn a lot with them.

And on the other side, the existing tools we were already using in the offline channels were developed by other teams. So you can imagine that we had to cover or to circumvent a lot of silos that were in place there. We had different release cycles of the software. We had, as I said, different teams, different departments. So a lot of hurdles to get or to pull everything together into a single webshop experience.

David Jungwirth

Yes, that's what we see on the next slide.

Max Ehammer

Of course, those applications are all necessary to have the business process modeled in the IT systems, and those systems need to interact. So we need a lot of interfaces to exchange the data across the applications, that the data is consistent.

On top of that, we also have some cloud applications that were used, and so we have somehow a hybrid environment. And what makes it really difficult is that some business cases touch a lot of IT systems, so a high degree of dependency between all those IT systems.

David Jungwirth

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?

Max Ehammer

Well, so the next slide is somehow not the way how you should do it, but that's the way how we did it, so to say.

To be honest, in the beginning, we had not really a clue about agile development. We had not really much idea what DevOps is, and we had to learn a lot here. At the beginning, we thought we know what we are doing, but, to be honest, reality showed us something else.

And how did we start? At the beginning, we had a fully blown backlog, so many items that we should cover. As I already mentioned before, our application development teams were spread across the company, so we also built up different work packages where the teams developed more or less in an isolated team, their functionality and their backlog items. So this was split over many teams, no real coordination.

And when then we came together and tested the functionality and checked whether this is working or not, we of course experienced a lot of problems. Because what was the main problem? We integrated way too late, so the testing was also way too late. And also we contracted, in some areas, development partners, and those development partners got, obviously, feedback way too late. So this meant that we had to delay our initially sought go-live date several times because of the reasons that feedback and functionality was tested way too late.

David Jungwirth

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

Max Ehammer

Right. So finally, we got the product that was more or less executable, as David said, it was potentially executable. And then we had a look at the non-functional requirements, because then we realized, now we have to take a look if the performance is good, if customers are able to really select lots of items and to do the checkout in parallel, more or less, or hundreds of clients should do the checkout in parallel.

And yeah, we started to test that, and as you can imagine, also here, we experienced a lot of troubles. And again, we had to shift more or less the release date.

This looks like more like an agile process, and from there on, things became better. We were better at that point of time, so our deployment time improved. But still, we had no automation in place. We were better and more consistent, and we still figured out we have problems. And I think that was the time when we addressed you and your company, David, where we asked for help in process modeling and automation.

David Jungwirth

Yeah. It was the start of our continuing journey, which we want to highlight in our talk today. So you asked us to automate everything, but before we did that, we had a look into all of the areas of the whole software development life cycle. And we found out that actually, also in your organization, with the issues we see there, you 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, analyzing especially those issues and attacking those issues first.

So what did we do? Just right at the beginning, we helped you to stabilize and streamline the full process.

Let's say, what is a value stream? Just very quickly. You see operational value streams. In our case, this would be, for example, search a product, add to a cart, choose a shipment method, choose a 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 development value streams, you also have the full cycle from define, build, test, release, the shortened one. So we analyzed whatever is happening and found out that especially the release and deployment parts need to be first stabilized and then streamlined.

All right, we did this for the first application, first part of the whole e-commerce platform. And how did we do it? With the classic continuous improvement methodology. We planned small initiatives, we coached and implemented them together, analyzed the results, and finally acted on the results.

So also, we all know that the technical change can be exponential. What we did is focusing especially on the culture part, which always just can be improved linear and not exponential.

What did we achieve with fixing process and culture? Could you highlight that, Max, please?

Max Ehammer

Sure. Alone with those improvements related to processes and culture, we were able to get way quicker deployment rates. So roughly to say, 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 with that improvement, we achieved a deployment time of a single day, more or less. So it was already a significant improvement.

And we also said that the reduction time was roughly 91%, and the quality of the deliverable or the deployment was five times better than before. And it was better than before because we had consistent data across the different stages, the testing stages, the development stages, the quality stages, and of course, the production stages. 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, and not testing configuration or data.

David Jungwirth

But that's awesome, Max, no?

Max Ehammer

Yeah, kind of. It was a great achievement at that time. However, to deploy a new package which lasts more than a day is still not sufficient.

David Jungwirth

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 CI/CD tool chain, fully based on what we did before of the standardized and streamlined process. And how did we do it? Could you maybe explain a little bit?

Max Ehammer

Yes. Well, in the first step, we tried to orchestrate the building, the configurating, the packaging of the software itself. So the first step was to have a consistent package of the bundled software across all the different stages, which are development, test acceptance, and production or pre-production as well.

And in a second step, we also made a so-called system copy or also back copy of production data to pre-production stages. This was necessary for us because of the many different systems involved in the business model itself, and IT systems involved in the business processes. 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 our new features on more or less production data.

On top of that, we also introduced automated testing, and this reduced the feedback cycle to the developers significantly, which was a very important step forward as well.

Here to say is that the orchestration was done by ARA, the Application Release Automation tool of Automic at that time, and this helped us a lot to improve our situation.

David Jungwirth

Yeah, but automating or orchestrating the continuous delivery pipeline was just the first step. If we look at the big picture, we call it the DevOps orchestration platform. There are several capabilities in there from agile execution, continuous testing, continuous integration, security monitoring, continuous delivery. There are plenty of capabilities you need to build up in your organization, and then you also technically need to orchestrate whatever is flowing through such a DevOps orchestration platform.

Max Ehammer

Yeah. That's right. And here you can see the orchestration of the different tools. So we had a significant amount of tools in place. Automating them alone, as David said, is still not enough. The key value here is the orchestration so that the IT processes can flow, and the orchestration of the more or less semi-automated parts of each tool get together. And this is really what helps to improve significantly.

We achieved really a lot at the end of all those steps we have done. We reduced the deployment time down to roughly half an hour, from one week to half an hour. So we say we improved that time by 99%. So really an awesome achievement, and this was not only the time, but also the consistency and quality of that deployment was great. So we say we have 100% compliance of test data and consistency across the systems, which helps you focusing on doing the real work, which is very important.

And of course, the next figure which is popping up right now is that we reduced also the deployment-related errors. So we say we have almost no errors anymore that are related to a deployment. And this is just great because, as I already said before, you just concentrate on the real work. In earlier days when we started up, we had so much time to figure out what's going wrong again. And now these days we just deploy the packages and concentrate on the new features that are being developed.

So an additional item where we are really proud on is that we have more or less 100% streamlined in-house DevOps team available right now, because in the beginning, we started with many different partners that helped us out. But in the meantime, we figured out that doing such a work or such an online channel development does not work if you have the partners spread across the country, more or less. So we decided to in-house that, and we achieved to build up a complete in-house DevOps team that is doing a great job.

And what helped us also is that not only our developers doing a great job, but also our sysadmins, so to say, and we are able to build up more or less a full production-like environment in less than a day.

David Jungwirth

So what did this bring to the business?

Max Ehammer

The business figures, of course, are also good compared to our budget that we have available. We calculated more or less that we have a saving of roughly EUR100,000 per release, which is, for us, a significant amount because our budget is not that high comparable to others, maybe, but for us it was a significant saving.

And also the introduction of the tool, ARA, or the orchestration tool, gave us a feeling that the return on that tool and the return on investment was significant because it helped us so much, saving a lot of money and a lot of time with respect to man or labor. And of course these numbers have to be considered in such a way if we would have not improved in any case, but at that time and if we calculate it into the future, these are the numbers that are valid.

Our next steps are more or less to move from a project thinking to a product thinking because we're still heavily thinking in projects, not really in product development. So this is one of our key endeavors for the next time. We also want to make real CI/CD instead of weekly deploys. We're also experimenting with feature toggles and also experimenting with dockerized applications that developers can release or deploy their development and test it on their own.

We also want to conquer the monolith web front-end platform to make it more flexible and easier to develop in the future. And one thing we still do not have in place is non-functional testing like performance testing, so we also need to take care of that. And last but not least, the feature team thinking is something we want to address in the future so that microservice-based development teams can be established.

David Jungwirth

All right. With that, I would like to hand over to the last slide with the final learnings from this whole project over the last years.

Max Ehammer

From my personal learning is that you have to experience. This is very important. You cannot learn it by reading a book. You have to experience this.

And for me, one of the major parts is the shift-left continuously topic. So it means that you have to test very early, integrate very early, and create some kind of continuous test automation. So that's a very important aspect from my point of view.

But this is not alone. The second part is to start automating as early as possible because this helps a lot, especially with respect to configuration. You need to make sure that all your configuration data is automated across all your stages and systems. Otherwise, you never get to a real CI/CD. And you also have to take care that your software components are packaged right away from the beginning. And of course, it's good if you can orchestrate that as much as possible.

What I also wanted to add is feedback loops with the teams, 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 addressing the customers, but also from a technical point of view, the 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 develop and drive your tool or application.

David Jungwirth

All right. Thank you, Max. And thank you, the audience, for participating. Thanks for your attention, for listening to the story of SPAR Commerce.

Max Ehammer

Thanks.