Blog post
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 is during the system solution design phase, where we identify processes that we can share between markets. This approach requires a bit more work in the beginning, but that is repaid multiple times later on. Often the number of processes that are the same or similar 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 to develop 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 feature silos. Each feature silo is an independent unit that encapsulates specific feature flow. Such an approach allows us to create and chain features per market need without leaving gaps in the feature flows.
Since 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 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 features off and on. Sometimes features need specific configuration options that are different between 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 to hide certain information from the UI if the market has such needs, for example.
The image is showing an abstract diagram of the CBT principle. On the lower level, there is a universal code that won’t change per market.
● Networking layer - which is 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 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 outrun the small cost of additional analysis and planning at the beginning of the project.
