Common Base Technology

A scenario we often encounter is companies with the need to develop and deploy a standard set of features between multiple markets, customized for a specific market. Developing those features numerous times from scratch would be a massive waste of resources, so we use common base technology to reduce the time and cost of the development. Developing applications with the common base technology method allows us to build different variations of one app, while using the same codebase.

The first step of such development comes during the system solution design phase, where we identify processes that we can share between the markets. This approach requires a bit more work in the beginning, but that is repaid multiple times later on. The number of the processes that are the same or similar often turns out to be larger than expected, once we start discussing them and breaking them down.

Once the development starts, from the feature flows we identified during the solution design phase, we create “feature silos.” The approach we take is developing the common layers that are shared between all of the features. Those layers include networking, security, standard UI components, shared business logic and others. On top of those layers we then build the feature silos. Each feature silo is an independent unit that encapsulates a specific feature flow. Such an approach allows us to create and chain features per market need, without leaving any gaps in the feature flows.

Since the feature silos are independent of each other, we can turn them on and off, even once the product is in the production. Remember, they are independent of each other, so turning one feature on or off won’t influence the functionality of the other features. To enable this functionality, we use something called feature flags. It’s a mechanism that allows us to control features of the apps, even beyond simply turning the features off and on. Sometimes features need specific configuration options that are different between the markets, and we extract those differences into feature flags as well. Feature flags and configuration options allow us to apply different coloring rules per market, or hide certain information from the UI, if the market has such needs.

The image shows an abstract diagram of the CBT principle. On the lower level, there is a universal code that won’t change per market.

● Networking layer — assumed to be the same for all markets. The networking layer will be built, tested and optimized to communicate with the API on predefined communication contracts (protocol and structure).

● Security layer — all security-related code, which can include user authentication, local data encryption and other secure communication measures.

● Shared business logic — code that defines and executes the shared business logic of the app.

● UI components — reusable UI elements with abstracted API and behavior. These components can be stylized differently, depending on the market.

Common base technology has proven to be an excellent solution for the projects where you want to keep the identity of each specific market, while maintaining a common set of features. When done correctly, it provides the right amount of flexibility and reusability that greatly outruns the small cost of additional analysis and planning at the beginning of the project.

Thanks to Ana Šeler for the design!

Thank you for reading. Please comment, like or share it with your friends and we hope to see you soon.

Would you like to join us? Check out the open positions at our Careers page.