Solution Highlights
- Reduced the time spent on development and regression testing by 3 times
- Significantly improved time to market and optimized the delivery process
- Optimized costs by reducing the amount of effort required from 14 to 8 teammates
- Resolved management and synchronization issues caused by big engineering teams
About the Project
Customer:
Compete (ceased operations in 2016) was a US-based media measurement and analytics company, which provided marketers with digital intelligence to help them create more effective websites and marketing campaigns.
At different times, the company delivered a range of products and services, yet the core of their business was:
- A SaaS digital marketing platform, which provided subscribers with unique online measurement tools for consumer and competitor behavior
- A benchmarking survey tool — having a unique multi-source panel of its kind, the company helped businesses conduct online surveys quickly and efficiently
- A data analytics service, where a dedicated team of data scientists worked with raw clickstream data to build custom reports for specific reporting needs
Our collaboration with Compete started from a dedicated team model back in 2008 and lasted until their acquisition by Comscore in 2016. As years passed, Intelliarts as a company gained more understanding of the Compete’s domain, product, and business model, as well as obtained more experience in technology consulting. In 2012, the company came to us for a technology consultation to discuss ways to optimize the delivery process.
Challenges & Project Goals:
A large part of the project involved building a data collection agent (DCA) allowing the company to collect, organize, and interpret clickstream data through web browsers for further use in analytics. Two teams of engineers worked on developing three browser extensions (Google Chrome, Mozilla Firefox, and Internet Explorer).
At some moment, Compete met the difficulty that every time they needed to add a new feature to the DCA, the engineering team had to make changes in three different code bases. This expectedly complicated and prolonged the development process and regression testing, as well as delayed delivery.
To optimize the team performance, Compete wanted to make it possible to engineer the features with a single business logic only once.
Solution:
After brainstorming possible technology solutions, we advised the customer to isolate the business logic into a separate module in order to make it platform-independent and then develop containers for each browser to give access to the browser APIs directly. With this approach, whenever Compete needed a change in business logic, engineers wrote the code and tested it once, but then placed it in three different containers.
Business Value Delivered:
- Improved time to market owing to less time spent on development and regression testing of DCA — we reduced the time spent by 3 times for this particular part of the project as compared to days when we started our cooperation with Compete.
- Cutting indirect costs since the required engineering team structure was reduced to 8 people instead of 14 to work on Compete’s project. At the same time, the team was able to preserve the former pace of development.
Big Data, SaaS Development
Technology Solution
At the technology consulting phase, we offered the customer an advanced solution to close their needs for process optimization. As mentioned, our technology specialists recommended separating a business logic into the JavaScript (JS) code common for all three browsers and then creating sort of platform adapters for Chrome, Firefox, and Internet Explorer.
We then provided Compete with a detailed roadmap for technology implementation, estimated the amount of effort needed and team requirements.
When we agreed upon all the details, the Intelliarts team continued with the implementation:
- Our engineers completed a rather complex code refactoring to isolate the business logic into a separate JS module and make it browser-independent. We added the interface so when a new feature was going to be developed, the engineers would make adjustments in the code and test it once instead of three times.
- Our next step was to engineer three containers for Chrome, Firefox, and Internet Explorer. Used as platform adapters, these would create a bundle and add the instance of the business logic to the browser-dependent part. Since three browsers had three different APIs, we could treat these adapters as independent translators. In other words, they should convert function calls into the business logic in a way so they were understood by each browser API.
- In the cases of Chrome and Firefox, extensions were written in JS by default. So here we only needed to develop two platform adapters that should call a particular browser function and intercept an HTTP request to extract the data from there.
- With Internet Explorer, the implementation was more challenging. Its extension was written in C++ so Internet Explorer couldn’t read our JS code there. To solve this problem, we used Google V8 JavaScript Engine, a software component capable of executing JS code. With its help, we created a pseudo extension, where we uploaded the business logic written in JS, common to all three browsers. Working as a very simplified virtual machine, this solution allowed us to run a JS code specifically for Internet Explorer.
- Before we came up with V8, we also thought about using other engines like Rhino by Mozilla, but they didn’t fit our requirements. Besides, to be able to use V8, we had to pull up its source code since it’s an open-source engine and reassemble it.
Business Outcomes
The project brought real value to the customer:
- The company spent 3 times less time on the development and regression testing of DCA after we implemented the solution. As a result, this significantly improved the company’s time-to-market.
- There were also noticeable results in cost optimization when it came to staff augmentation for the whole project. We needed only 8 people to do the same amount of work as completed by 14 teammates earlier. At the same time, no change was noticeable in the team performance — Compete was able to introduce new features with the same pace as before.
- Finally, some management issues were resolved after the project was completed. At some moment, the team (21 teammates) became so big that it was difficult to manage. But after we reduced the amount of effort required, the team started to work more efficiently, communication became smoother, and there was higher engagement. Fewer people in the team also needed less time for synchronization, and there was less overhead.
