Digitizing a complex transportation business into a massive scalable ecosystem that supports all web and mobile platforms and attracts 23% more orders.
Our client’s delivery and logistics company facilitates international trade, providing transportation services for individuals and businesses locally and globally. Our client asked us to:
Digitalize his well-established transportation business that had a diverse fleet. Our client was new to the online world and had only a basic concept of what his platform should do and how it should look.
Build a scalable system that would be easy to modify.This would let our client enter new markets, engage more transportation service providers, and supply new delivery types.
Reduce the number of failed orders.
Over 10% of orders were missed or behind schedule as a result of using multiple spreadsheets and handwritten notes.
Develop the whole product in four months.
This is the amount of time our client had before his potential competitors stepped into the online delivery market and got a big cut of the target audience.
Develop a user app for the web, Android, and iOS, a courier app for Android, a web dispatch center, and a web admin panel to transform the client’s complex business into an online system. We decided to conduct an on-site investigation of our client’s business to get a complete list of vital requirements and user stories.
Implement a dispatch panel with automated order logging and an effective UI and UX to decrease the percentage of failed orders. The dispatch panel helps dispatchers sort and process delivery requests and is meant to get the number of failed orders down to zero.
Build a microservice architecture and use cloud computing services to make the platform scalable. This should supply our client with the flexibility for future updates without having to modify the whole system.
Apply time-saving tools and project management techniques along with a new planning framework to complete the project in four months. See the details of how we achieved these goals in that timeframe below.
COLLABORATION IN NUMBERS
$500,000 – $999,999
May 2019 – present
Ruby on Rails
Room (DB Cclient)
Retrofit (API Cclient)
Clean Architecture MVP
DIVING DEEP INTO THE BUSINESS SPECIFICS TO DEVELOP AN OPTIMAL PLATFORM CONCEPT
To ensure that platform functionality would satisfy our client’s business needs, we went on-site and spent some time watching how the business operates. As a result, we built an ecosystem consisting of:
A web dispatch panel and a web support center to automatically distribute orders and clarify delivery details
An Android courier app with order management, navigation, and a minimalist design so as not to distract couriers from driving
User apps for the web, iOS, and Android with delivery listings, parcel management, payments, and real-time order tracking
A web admin panel for platform analytics and employee management
MANAGING STAKEHOLDERS FOR AN ENTERPRISE COMPANY
Every enterprise has a number of departments including marketing, sales, finance, customer support, and operations. Each requires specific features from a delivery and logistics platform. For instance, the finance department needs an integration for creating invoices, the operations department needs to be able to implement process automation, and the marketing department requires a promo code generation tool.
To ensure that all essential features in the final product were compatible with each other, we used a stakeholder management framework. It helped us prioritize requirements, remove uncertainties and contradictions, and provide updates on the results.
To properly collect and arrange requirements, we adopted several practices:
Rolling-wave planning to state a well-defined feature set for the platform. In addition, we regularly validated the requirements with our client to properly interpret and implement them.
RACI matrix for role distribution. A RACI matrix helped us understand who would be responsible for each feature, who to consult to properly implement it, and who to inform about adding new functionality.
War room practice to remove uncertainties and contradictions. We invited all stakeholders to the sprint planning meeting once there were a certain number of change requests from multiple sides.
Together with all stakeholders, we balanced the incoming requirements and delivered a product that reflects the goals of different business units. For example, the operations department required a registration form with certain fields.
And at the validation session, the marketing department realized they hadn’t supplied their own requirements for gender and other fields. With the help of our framework, we developed a registration form that was informative for both departments and remained short enough so as not to scare away users at registration.
PROVIDING REQUIREMENT TRACEABILITY AND TIMELY PROJECT UPDATES
We regularly informed our client about the current state of the project during calls and meetings as well as by email. Additionally, we invited the client to our grooming meetings, where we searched for ways to improve the development process. When the client needed to check something or to present information to other stakeholders, we provided a dashboard with documentation available 24/7. This is a regular practice for us, though the form of documentation may vary from detailed Jira task descriptions to PDF presentations.
THE MICROSERVICE ARCHITECTURE
Such a massive platform could have been created as a monolithic server, but future developers would have had to reassemble and redeploy the whole monolith with every little change made to the project modules. This is why we decided to apply a microservice approach that could be scaled and deployed independently.
SELECTING THE TOOLING
For an ecosystem that has six components and runs on three platforms, we had to choose the tooling that would supply correct modularization. Though Rails is not widely known as a platform for microservices, Rails Engines, which is a part of the Rails ecosystem, is a great tool to achieve these goals. With good planning, documentation, and in-team agreements, it became our choice for the project.
BETWEEN THE MICROSERVICES
Communication between microservices is a separate topic. We would normally use the message bus, but in certain circumstances, it’s overhead. That’s why we chose the Apache Thrift protocol, a battle-tested technology that we’ve used before. It offers the huge advantage of making it easy to describe the communication interface API for languages other than Ruby. We were able to use Apache Thrift for a variety of technologies on the backend and frontend.
DECREASING THE NUMBER OF FAILED ORDERS
To help dispatchers easily discover new orders and process them as soon as possible, we implemented a dispatch panel. It automatically receives and assigns orders from the web, Android, and iOS apps. Next, the panel automatically distributes orders based on the time they were made and visualizes them on a dashboard. All unprocessed orders are red. Orders in progress are yellow, and completed orders are green.
Orders that lack some details are also added to the dashboard, but are white and highlighted with a red line. This way, dispatchers can see that they need to contact people to get more information. For this purpose, they can use the support center calling feature.
SPEEDING UP THE DEVELOPMENT
Due to the tight deadlines, we needed to gear up the platform development by engaging a team of the top specialists at our company, adopting the best collaboration practices, and using time-saving task management technologies.
ENGAGING A DESIGN TEAM
We formed a design team of lead developers, a designer, a business analyst, and a solution architect to select the primary solution and conduct development planning. The team chose optimal frameworks and tools and built development plans for each part of the project so that other developers could stick to these plans and tools during app development. Once the sets of solutions and plans were ready for one part of the project, the design team proceeded to the next part, working simultaneously with all other teams on the project.
STREAMLINING THE COOPERATION OF DESIGNERS
For this project, we adopted a shared library of reusable components. Some of the designers working on the project built new UI and UX components. Once created, these components were put into the shared component library. Then the other designers could use these UI and UX elements for other parts of the platform, implementing a consistent design and saving time for other tasks.
VISUALIZING TASKS WITH THE WORK BREAKDOWN STRUCTURE (WBS)
We needed all 30 members of the development team to fully understand the bigger picture of the project and see their contribution to its development as well as how their particular work influenced the work of other team members. This is why we used our integral work breakdown structure (WBS) to visualize all tasks for every team member and to demonstrate the relationships between tasks. This way, team members could see if they were blocking someone else’s work.
USING AUTOMATICALLY GENERATED DOCUMENTATION
Proper documentation can help developers that maintain the project. However, thorough documentation takes hours to complete, and we were really pressed for time. That’s why we decided to use the Autogenerated Swagger API. This tool allowed us to pull documentation from our integration tests instead of writing it manually.
We helped our client turn his complex offline delivery business into an ecosystem of six apps for the web, iOS, and Android.
The platform’s microservice architecture will save our client time on updates and provide a broad space for business scalability.
We decreased the number of failed orders, bringing our client 23% more orders as soon as the business went online.
We completed the project without exceeding the time and budget constraints thanks to flexible project management techniques and time-saving tools.
Our client chose to continue our collaboration, and now we’re working on the next version of the platform.