Kodiak: The new technology behind the BB app

Augusto César Gonçalves de Azevedo, father of Catarina, with almost 15 years in BB Technology, worked with Security specifying and building solutions, has been working with Digital Channels since the beginning of his career, technological platforms for channel development teams, in recent years he led the integration with GiftCards, the mobile Components team and the Kodiak team where he worked as a PO, today he is leading the BB Mobile Platform team.

A good rating in the app stores reflects the quality of the application and the value perceived by customers. This involves many factors, beyond relevant functionalities for the customer and a good experience, it is important to keep everything always working. I must say that it is not an easy mission.

With the large number of new things and adjustments that we put into the app every week; some bug will end up passing. There are many teams and developers making adjustments. In the last survey, there were more than 400.

In addition, it is important to know that the application update process is not trivial. The first challenge is to put all these changes together in one build of the app. Then make sure that all these changes are working properly. That nothing that has been changed breaks something that is already working. Then we must pass through the scrutiny of the stores (App Store and Play Store). And finally, we need the customer to update the app on their device so that the changes take effect – there is a significant portion of customers who do not update very frequently (it’s worth a dedicated article just to talk about our Mobile Deployment Process, note).

Always seeking to offer the best application on the market to our customers, in 2019 we began to seek new solutions to better deal with this scenario.

After a brilliant idea from Paula Moura, we started building Kodiak, which was named much later.

But what is this Kodiak?

Kodiak is a no-code/low-code solution fully developed internally at BB (patent pending). The main problem it sought to solve was to speed up mobile deliveries while ensuring security and quality.
To solve this problem, an architecture based on screen templates that could be dynamically parameterized to organize navigation flow and perform API consumption was conceived.

As a bonus, the fact that we use screen templates reduces development effort as well as standardization of interfaces, application of visual components, and accessibility.

But how does all this work?

Let’s explore Kodiak a bit. And for that, understanding how the template mechanics work is already halfway to understanding how this platform works.

Understanding the Templates

To facilitate the explanation, let’s talk a little about the process of creating a template until its use within the application. The following image illustrates some phases of this process.

1. Identifying a practical application case

The first step in having a template is to identify a practical use scenario. This step is the most important. We do not create templates based on hypothetical needs. Once we have the case in hand, we evaluate the existing templates and explore other approaches to solve the same scenario. Once identified that the best approach is to create a new template, we look for other possible application cases to make it as flexible as possible and move on to specification.

2. Template specification

The specification is still a design stage and therefore conducted by our UX team. In this stage, the components of our visual component library are identified – this is another important point, only components from our library can be used in templates and app screens. All font sizes, spacing, colors, and component application on the screen are also defined according to our Design Language System and, most importantly, accessibility guidelines.

3. Template available

Once specified, the template is built and made available on our Platform to be used in building screen flows. Recently we also started making available a Figma component that represents the template, thus facilitating the design process of new services that use Kodiak. Then it is just a matter of identifying the templates that best fit the needs of the product being built.

4. Configuration process

When using the template there is a “trick”. It is not necessary to use all components provided in the template, only those that make sense for the screen in question. This brings a lot of flexibility and several possibilities for applying the same template. The image above illustrates exactly this scenario where only part of the components provided are being used to instantiate the screen.

Enough with the small talk, I want to know about the technologies.

Let’s take a look under the hood. To make it easier, let’s use this diagram below, a simplified version of the system architecture.

We talked a little about the logic of how templates work, now let’s look at some of the technology that makes it work.

Kodiak SDK

Our app is built in React Native and naturally our templates are too, mainly because of the ease of integration and mastery we have of the technology. These templates along with the module that controls screen instantiation and communication with the Engine (our backend) are packaged into a library we call Kodiak SDK – using poetic license since Kodiak doesn’t produce code, but we’ll get there. This SDK is embedded in the apps we’re integrated with.

Engine, our orchestrator

With each screen navigation in the app, the SDK communicates with the Engine to find out which screen to display next. The Engine – which is built in JavaScript and runs on NodeJS – in turn retrieves the screen configuration, identifies which APIs to consume, consumes them and returns to the App a JSON containing the identification of the template to be instantiated and the data that will be shown to the client. The Engine is our screen and API orchestrator.

This architecture has some interesting gains:

• our APIs no longer need to be directly exposed on the internet.
• the fact that the App does not interact directly with the APIs makes them difficult to reverse engineer.
• only the data that will be used on the screen is returned, reducing unnecessary data traffic.
• it is possible to monitor more easily and clearly what is happening in the customer’s journey.
• the app becomes lighter.
• and most importantly, changes in flows do not depend on updating the app, they occur instantly.

Monitor, focus on availability and performance

One of the gain points mentioned was monitoring. This is a topic worth exploring a little further.
Every Service (the way we call screen flows that represent a functionality in the app) implemented in Kodiak is born monitored by default. Since every screen navigation ends up generating a call to our backend, we can observe these interactions.

We chose to use the Prometheus and Grafana stack to provide our developers with a panel where they can monitor their screen flows. This panel shows information such as:

• number of screen views.
• screen loading time (average and 99th percentile, which is important to highlight possible problems that affect only part of users).
• success rate in loading screens (today mainly affected by errors in interaction with APIs).
• number of errors.

All this data is collected per screen and per consumed API, which allows for a very rich monitoring of the whole environment.

OK, I understood how the runtime works. But what about development?

Every user interacting with Kodiak for the first time will go through our Hotsite that contains some basic information and will be directed to our “Get Started”.

The Get Started is a step-by-step tutorial in which the goal is to set up the development environment and finish the process with a small flow of screens running on the App (our Hello World).

Launcher, manager of the development environment

But don’t think that setting up the environment is a bunch of installation instructions for various tools. Here the Launcher comes into play. It is our installer that makes everything ready to use and is compatible with Windows, Linux and Mac. In addition to installing the Android emulator and all the necessary tools to run it, it keeps a process on the user’s computer. This process is what manages all the communication between our web interface of development and management and other tools installed on the user`s computer. It is also responsible for opening the emulator, installing and updating the versions of the App for developers and automating/abstracting whatever possible to make life easier for people – #dx.

Once everything is installed and the dev is minimally familiar with our systems we offer a self-instructional material in video lesson format, the “Kodiak 101: From zero to production”. In this training, which consists of about 20 topics with approximately 3.5 hours of video, we build a real product flow, from start to finish. The goal is to enable our devs to make their deliveries as soon as possible using the Platform.

Launchpad, the Godfather

In the previous paragraphs, when I mentioned our “web interface of development and management”, I didn’t call it by name. Many of you should have guessed that I was referring to Launchpad (React) and its backend, Launchpad API (JavaScript + NodeJS).

This is the guy who controls everything. He provides the interface for development and parameterization of flows, version control, deployment and rollback management, processes of approval, management of apps and development, testing and production environments.

Developing on Kodiak

Let’s look at the development process to see if it helps us understand the mechanics behind the scenes.
To develop something on Kodiak the first step is to have the Service created (which represents a product flow). Next, you need to select an SDK version (the newer the more features and templates available).
Now it’s time to add the screen template. After selecting the template, the dev assigns an identifier for the screen and can continue performing the parameterization of the APIs and components provided in the template. All this is done in a web form and the result, which is the screen configuration, is saved in a JSON document in our database.

Build and Deploy, making changes effective

Once all screens have been configured (their APIs, components and links from one to another), a package (our build) containing all the flow settings is generated. A version number is assigned to this package, which will be used to identify the package and to promote it to the testing and production environments.
In the end, the screen flow is a set of JSON documents (configurations) saved in a database. Promoting changes from one environment to another consists of copying this set of configurations from one database to another.

And here’s an important point that I haven’t talked about yet. The Engine is not a single element. For each application and processing environment (development, testing and production) there is an instance of the Engine running. This is very important so that there is no interference from one environment to another and so that the runtime environment is independent of the management/development environment.
In general, this is how Kodiak works.

Generating value for our customers and for the business

Imagine identifying an opportunity for improvement in a transactional flow and having this adjustment distributed to 100% of customers in less than 2 hours? I’m talking about the time between identifying the opportunity for improvement, making the adjustment and deploying it to all customers in this 2-hour window.

This is a real example that happened recently in our Prepaid Cell Phone Recharge service. An improvement in the screen flow doubled the conversion rate of one of the payment methods instantly.
More important than delivering new features is not breaking what is working, especially if it’s PIX =) (our primary money transferring method in Brazil). As much as we have all the care and various processes implemented to minimize the risk of bugs, it will happen sooner or later. With Kodiak, besides making adjustments very quickly we can undo changes instantly.

This is the kind of potential we are unlocking. To allow product teams to deliver solutions to customers very quickly. Evaluate the results and decide how to proceed.

We have cases where the complete flow was built and deployed in less than 10 days. This would not be feasible in a traditional mobile development process, counting all the quality steps we follow.

In addition, being a no-code/low-code solution, Kodiak allows developers without mobile experience to make deliveries on the app, greatly increasing the autonomy of product teams.

This is how we are transforming BB’s app.