Collaboration context

LKQ is a leading distributor of automotive aftermarket parts. We started our cooperation at the time of LKQ’s expansion into the markets of Central and Eastern Europe. The work we have done so far can be divided into 4 stages.

Client information

LKQ Europe GmbH is a subsidiary of LKQ Corporation. It is a leading European distributor of spare parts for passenger cars, trucks and industrial vehicles. 

In 2011, the group focused on trading spare parts to a highly diversified customer base. LKQ wanted to reach garages, workshop chains, independent car parts distributors, and fleet management companies.

LKQ Europe currently employs approximately 26,000 people in 1,000 locations in more than 20 European countries. Its revenue in 2020 exceeded $5.49 billion. The organization supplies approximately 100,000 independent companies in more than 20 countries.

Stage 1: DataMatrix API + demo app

Time: Q4’2019 – Q1’2020

Team setup: small cross functional team + Product Owner (client)

The high-level goal of the project was to create a web API to enable the company to manage its product range. During the first stage, we defined some basic rules such as: who may and may not trade particular parts, rules of sorting and promoting a given brand, complex business cases where assortment is displayed depending on a car brand and its mileage. 

The biggest challenge at this stage was to ensure data unification. The client wanted the system to be scalable and used throughout Europe. 

In the past we have worked on rule engines for dynamic pricing and the knowledge we gained then came in handy when creating and applying the rules.The design process was quite problematic. Even if we knew the rules system from previous projects, we had to define input parameters. Therefore, we designed norms for classifying products and services that our engine will always be able to interpret. DataMatrix enables instant synchronization of all the data the user needs. If a potential customer searches for a specific car model using the application, they will receive information such as price or availability of that vehicle.

Regarding unification, we analyzed the output data from different catalogs and the most frequently used fields in various systems, such as B2B and B2C stores. Then, using this data, we prepared a section that contains the most frequently used fields. The rest of the fields are stored in the same format as the attributes.

The final result of this stage was a tested web API that enables communication and is very clear for programmers, but not so much for business people. Therefore, we decided to develop a simple front-end application, which we use to this day as a tool for presenting the capabilities of the web API. 

Stage 2: Vehicle Core Service

Time: 2020

Team setup: small cross functional team + external Product Owner (client)

As with Data Matrix, the biggest challenge was the unification and globalization of the product. We started our work with one EMDM catalog. As the project developed, the number of systems interpreting data (such as registration numbers, etc.) grew – usually one per country for each way of seraching. Our task was to adjust the requests and responses to unify the data for a customer. 

The next challenge was determining which requests should be sent to particular systems. 

Requests are usually part of the system documentation, so by reviewing the documentation of different systems we were able to determine which system is used for vehicle identification and what aspects need to be standardized. For instance, in each country there may be a different supplier for VIN and VRM numbers, and another supplier for the general specification of the car. Our task is to control to whom the request will go. For this purpose, we have created a configuration that allows business people to set which suppliers are to be used in a given country for a given search. 

Stage 3.1: Product Core Service

Time: 2020

Team setup: medium size cross functional team + external Product Owner (client)

In 2020, our main task was to solve the problem of importing CSV files in a unified form. 

Not every company keeps its product data in standard systems such as EMDM or TecDoc to which we already know how to connect. Many small companies create their own catalogs, either in the form of software or simple Excel tables. To enable selling goods using our system, we had to provide the possibility of importing such data into our structure.

To make import easy for customers, the input format takes the form of a simple CSV file, where the headers indicate particular product groups. CSV is a commonly used format, and regardless of the solution used by a customer, it is always possible to generate such files from the database. Finally, after processing the file, the data is stored in our database and is accessible through our product API.

Stage 3.2: Infrastructure as a code

Time: 2020

Team setup: cross functional team extended with DevOps skills + external Product Owner (client)

Since 2020, our DevOps team has been in charge of the entire infrastructure. The DevOps team’s job is to provide a secure environment. They make sure that the application is hosted on the right server or cloud.

The entire infrastructure of the application is coded in repository so if any change has a negative impact on the entire application, it can be easily redeployed.

For example, after the security audit, the IP addresses had to be  changed. Without infrastructure as a code, we would have had to change IP addresses manually in all application layers. Fortunately, it was enough to change the code in certain places and the change was implemented automatically in the whole infrastructure.

An additional benefit of this solution is a shared code repository, which allows maintaining order in the test versions.

Stage 4: Order Management Core Service

Time: 2021

Team setup: further growth of the team + new Product Owner (client)

At this stage, our task was to create a web API that provides ERP data about products across Europe. The biggest challenge at this stage was to ensure data unification. Our goal was to develop an application that would be useful to all of the client’s teams, as each team worked with different technology.  We didn’t have one main data source but many distributed solutions supporting diffrent technology – file exchange on SFTP, SOAP, JSON RPC, REST API or even emails. 

With good user experience in mind, we have set the goal that the application loading speed should be a benchmark for others. To achieve this, we used the GRPC protocol.  

After establishing a contract with every team member, we could divide the work on different plugins between teams and only requirement for development were supporting GRPC. This approach allow us to develope plugins in more them one team and more them one language – at the moment, our team uses C#, and the external team uses GO Lang. 

Plugin approach have one more benefit that is very useful – it allows us to upload versions of different plugins independently of each other. At this point, we support 15 different ordering systems. 

Summary

It is a complex, long-term process that involves cooperation of our team and flexible adjustments of the needed skills and the Product Owner of LKQ. It is a common configuration, and we are comfortable working this way. You can see the commitment on both sides, and the flow of information is unobstructed. 

Our application is in continuous development according to agile methodology, and some modules are already on production servers. These modules allow over three hundred customers in the CEEU region to check prices and place orders. Day by day, we are adding more solutions and integrating more customers.

Read more case studies.