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.

The post Kodiak: The new technology behind the BB app appeared first on Blog do Banco do Brasil.

Uma boa nota nas lojas de aplicativos é reflexo da qualidade do aplicativo e do valor percebido pelos clientes. Isso envolve muitos fatores, além de funcionalidades relevantes para o cliente e de uma boa experiência é importante manter tudo sempre funcionando. Já adianto que não é uma missão fácil.

Com a grande quantidade de coisas novas e ajustes que colocamos todas as semanas no app, algum bug pode acabar passando. São muitos times e desenvolvedores fazendo ajustes. No último levantamento eram mais de 400.

Além disso é importante dizer que o processo de atualização do aplicativo não é algo trivial. O primeiro desafio é juntar todas essas alterações numa versão do app. Depois garantir que todas essas mudanças estejam funcionando direitinho. Que nada do que foi alterado quebre algo que já está funcionando. Aí temos que passar pelo crivo das lojas (App Store e Play Store). E por fim precisamos que o cliente atualize o app em seu dispositivo para que as alterações tenham efeito – existe uma parcela significativa dos clientes que atualiza com pouquíssima frequência.

Buscando sempre oferecer o melhor aplicativo do mercado para os nossos clientes, em 2019, começamos a buscar novas soluções para lidar melhor com esse cenário.

Mas o que é esse tal de Kodiak?

Kodiak é uma solução no-code/ low–code totalmente desenvolvida internamente no BB. Dar velocidade para as entregas do mobile, garantindo segurança e qualidade, era o principal problema que ela buscava resolver.

Para resolver esse problema foi concebida uma arquitetura baseada em templates de tela que pudessem ser parametrizados de forma dinâmica, para organizar o fluxo de navegação e realizar o consumo de APIs.

De quebra, o fato de utilizarmos templates de tela, diminui o esforço de desenvolvimento bem como de padronização das interfaces, aplicação de componentes visuais e acessibilidade.

Mas e na prática, como isso tudo funciona?

Vamos explorar um pouco do Kodiak. E para isso, entender como funciona a mecânica dos templates já é meio caminho andado para entender como funciona essa plataforma.

Entendendo os Templates

Para facilitar a explicação vamos falar um pouco do processo de criação de um template até o seu uso dentro de aplicativo. A imagem a seguir ilustra algumas fases desse processo.

1 – Identificando o caso prático de aplicação

O primeiro passo para termos um template é identificar um cenário prático de uso. Esse passo é o mais importante. Não criamos templates baseados em necessidades hipotéticas. Uma vez que temos o caso em mãos, avaliamos os templates e existentes e exploramos outras abordagens para resolver o mesmo cenário. Identificado que a melhor abordagem é criar um template, buscamos outros casos possíveis de aplicação para deixá-lo o mais flexível possível e partimos para a especificação.

2 – Especificação do template

A especificação ainda é uma etapa de design e por isso conduzida pelo nosso time de UX. Nessa etapa são identificados os componentes da nossa biblioteca de componentes visuais – esse é outro ponto importante, só componentes da nossa biblioteca podem ser utilizados nos templates e telas do app. Também são definidos todos os tamanhos de fonte, espaçamento, cores e aplicação dos componentes na tela conforme o nosso Design Language System e o mais importante, as diretrizes de acessibilidade.

3 – Template disponível

Uma vez especificado o template é construído e disponibilizados na nossa Plataforma para ser utilizado na construção dos fluxos de tela. Recentemente passamos a disponibilizar também um componente do Figma que representa o template, facilitando assim o processo de design de novos serviços que utilizem o Kodiak. Aí é só identificar os templates que melhor se encaixam com a necessidade do produto sendo construído.

4 – Configuração para uso

Na hora de utilizar o template existem um “pulo do gato”. Não é necessário utilizar todos os componentes previstos no template, apenas os que fazem sentido para a tela em questão. Isso traz muita flexibilidade e diversas possibilidades de aplicação de um mesmo template. A imagem acima ilustra exatamente esse cenário em que apenas uma parte dos componentes previstos está sendo utilizada para instanciar a tela.

Chega de conversa fiada, quero saber das tecnologias

Vamos dar uma espiada embaixo do capô. Para facilitar, vamos usar esse diagrama abaixo, uma versão simplificada da arquitetura do sistema.

Falamos um pouco sobre a lógica de funcionamento dos templates, agora vamos ver um pouco da tecnologia que faz isso funcionar.

SDK do Kodiak

Nosso app é construído em React Native e naturalmente nossos templates também, principalmente pela facilidade de integração e domínio que temos da tecnologia. Esses templates, juntamente com o módulo que controla a instanciação das telas e a comunicação com o Engine (nosso backend), são empacotados em uma biblioteca que chamamos de SKD do Kodiak – usando de licença poética uma vez que o Kodiak não produz código, mas vamos chegar lá. Essa SKD é embarcada nos apps com os quais estamos integrados.

Engine, o nosso orquestrador

A cada navegação de tela no aplicativo o SDK se comunica com o Engine para descobrir qual a próxima tela a ser exibida. O Engine – que construído em JavaScript e roda em NodeJS – por sua vez recupera a configuração da tela, identifica as APIs a serem consumidas, realiza o consumo das APIs e retorna para o App um JSON contendo a identificação do template a ser instanciado e os dados que serão mostrados para o cliente. O Engine é o nosso orquestrador de telas e APIs.

Essa modelo de execução tem alguns ganhos interessantes:

– nossas APIs não precisam mais ficar diretamente expostas na internet;

– o fato de o App não interagir diretamente com as APIs dificulta a engenharia reversa;

– são retornados apenas os dados que serão utilizados na tela reduzindo o tráfego de desnecessário de dados;

– é possível monitorar de forma mais fácil e clara o que está acontecendo na jornada do cliente;

– o app fica mais leve;

– o mais importante de todos, a alteração nos fluxos não depende de carga do app e ocorre de forma instantânea.

Monitor, foco na disponibilidade e performance

Um dos pontos de ganho citados foi a monitoração. Esse é um tópico que vale a pena explorar um pouco mais.

“Todos Serviços” (a forma como chamamos os fluxos de tela que representam uma funcionalidade no app) implantado no Kodiak nasce monitorado por padrão. Como toda navegação de tela acaba gerando uma chamada para o nosso backend conseguimos observar essas interações.

Optamos por utilizar a stack Prometheus e Grafana para fornecer aos nossos desenvolvedores um painel em que ele consegue acompanhar seus fluxos de tela. Nesse painel são mostradas informações como:

– quantidade de exibições de tela;

– tempo de carregamento das telas (média e percentil 99, que é importante para evidenciar possíveis problemas que afetam apenas parte dos usuários);

– taxa de sucesso nos carregamentos das telas (hoje afetado principalmente por erros na interação com as APIs);

– quantidade de erros;

Todos esses dados são coletados por tela e por API consumida, o que possibilita um acompanhamento muito rico do ambiente como um todo.

Ok, entendi como funciona o runtime. Mas e o desenvolvimento?

Todo usuário que está chegando no Kodiak pela primeira vez vai passar pelo nosso Hotsite que contém algumas informações básicas e direciona para o nosso “Get Started”.

O Get Started é um tutorial com o passo a passo em que o objetivo é configurar o ambiente de desenvolvimento e sair com um pequeno fluxo de telas executando no App (nosso Hello World).

Launcher, gerente do ambiente de desenvolvimento

Mas não pense que a configuração do ambiente é um monte de instruções de instalação de diversas ferramentas. Aqui entra o Launcher na história, nosso instalador que deixa tudo prontinho e é compatível com Windows, Linux e Mac. Além de instalar o emulador Android e todas as ferramentas necessárias para executá-lo, ele também mantém um processo no computador do usuário. Esse processo é quem faz toda a comunicação da nossa interface web de desenvolvimento e gerenciamento com as ferramentas instaladas no computador do usuário. Também é o responsável por abrir o emulador, instalar e atualizar as versões do App para os desenvolvedores e automatizar/abstrair o que for possível para facilitar a vida do pessoal – #dx.

Uma vez que tudo esteja instalado e o dev esteja minimamente familiarizado com os nossos sistemas, oferecemos um material autoinstrucional em formato de vídeo aula, o “Kodiak 101: Do zero a produção”. Nesse treinamento, que consiste em cerca de 20 tópicos com aproximadamente 3,5h de vídeo, construímos um fluxo real de um produto, do início ao fim. O objetivo é habilitar nossos devs a fazerem suas entregas o quanto antes utilizando a Plataforma.

Launchpad, o poderoso chefão

Nos parágrafos anteriores, quando citei nossa “interface web de desenvolvimento e gerenciamento”, não chamei ela pelo nome. Muitos de vocês dever ter sacado que eu estava me referindo ao Launchpad (React) e seu backend, Launchpad API (JavaScript + NodeJS).

Esse é o cara que controla tudo. Ele prova a interface de desenvolvimento e parametrização dos fluxos, controle de versão, gestão de implantações e rollbacks, fluxos de aprovação, gestão dos aplicativos e ambientes de desenvolvimento, homologação e produção.

Desenvolvendo no Kodiak

Vamos olhar um pouco para o processo de desenvolvimento para ver se nos ajuda a entender a mecânica por baixo dos panos.

Para desenvolver algo no Kodiak o primeiro passo é ter o Serviço criado (que representa um fluxo de um produto). Na sequência é preciso selecionar uma versão de SDK (quanto mais novo mais funcionalidades e templates disponíveis).

Agora chegou a hora de adicionar o template de tela. Após selecionar o template o dev atribui um identificador para a tela e já pode seguir realizando a parametrização das APIs e componentes previstos no template. Tudo isso é feito em um formulário web e o resultado é a configuração da tela, salvo em um documento JSON na nossa base de dados.

Build e Deploy, implantando as alterações

Uma vez que todas as telas tenham sido configuradas (suas APIs, componentes e links de uma para a outra), é gerado um pacote (nosso build) contendo todas as configurações do fluxo. A esse pacote é atribuído um número de versão que será utilizado para identificar o pacote e para promovê-lo para os ambientes de homologação e produção.

No final das contas o fluxo de telas é um conjunto de documentos JSON (configurações) salvo em um banco de dados. Promover as alterações de um ambiente para o outro consistem em copiar esse conjunto de configurações de uma base de dados para outra.

E aqui tem um ponto importante que não falei ainda. O Engine não é um elemento único. Para cada aplicativo e ambiente de processamento (desenvolvimento, homologação e produção) existe uma instância do Engine rodando. Isso é muito importante para que não haja interferência de um ambiente no outro e para que o ambiente de runtime seja independente do ambiente de gerenciamento/ desenvolvimento.

De modo geral é assim que o Kodiak funciona.

Gerando valor para os clientes e para o negócio

Imagine identificar uma oportunidade de melhoria em um fluxo transacional e ter esse ajuste distribuído para 100% dos clientes em menos de duas horas? Estou falando do tempo entre a identificação da oportunidade de melhoria, a realização do ajuste e a implantação para todos os clientes nessa janela de tempo de duas horas.

Esse é um exemplo real que aconteceu recentemente no serviço de Recarga de Celular. Uma melhoria no fluxo de telas dobrou a taxa de conversão de um dos meios de pagamento instantaneamente.

Mais importante que entregar novidades é não quebrar o que está funcionando, principalmente se for o PIX. Por mais que tenhamos todo o cuidado e diversos processos implantados para minimizar o risco de bugs, uma hora vai acontecer. Com o Kodiak, além de fazer ajustes de forma muito rápida conseguimos desfazer as alterações de forma instantânea.

Esse é o tipo potencial que estamos destravando. Permitir que os times de produto entreguem soluções para os clientes de forma muito rápida. Avaliem os resultados e decidam como prosseguir.

Temos casos em que o fluxo completo foi entregue em menos de 10 dias. O que não seria viável em um processo tradicional de desenvolvimento mobile, contanto todas as etapas de qualidade que seguimos.

Além disso, por ser uma solução no-code/low-code, o Kodiak permite que desenvolvedores sem experiência em mobile realizem entregas no app, aumentando muito a autonomia dos times de produto.

É dessa forma com que estamos transformando o aplicativo do BB.

The post Kodiak: a nova tecnologia por trás do aplicativo do BB appeared first on Blog do Banco do Brasil.