Consolidação técnica da Fase 4 do Tech Challenge, onde assumimos o papel de Tech Manager para fortalecer o alicerce técnico do nosso produto: um aplicativo móvel focado em promover autonomia e independência para idosos através da gestão de suas atividades diárias.
Contexto: Nas fases anteriores, validamos a dor do usuário (Fase 1), estruturamos a equipe e o planejamento financeiro (Fase 2), e definimos a arquitetura inicial e conformidade regulatória (Fase 3). Agora, evoluímos essas bases para garantir robustez, segurança, escalabilidade e integração com o ecossistema digital.
Proposta de evolução arquitetural para equilibrar simplicidade operacional com flexibilidade estratégica de longo prazo.
A arquitetura definida na Fase 3 estabeleceu uma base sólida utilizando microsserviços, com um frontend multiplataforma em Flutter, backend hospedado na AWS, e uma combinação de bancos de dados NoSQL (MongoDB) e SQL (PostgreSQL). Esta abordagem, embora robusta, apresenta desafios em termos de complexidade operacional, especialmente para uma equipe em crescimento e um produto em estágio inicial de mercado.
Desafio Principal: O custo de coordenação entre múltiplos microsserviços para funcionalidades que atravessam diferentes domínios. Para o MVP e as fases iniciais de crescimento, essa granularidade pode introduzir uma sobrecarga de desenvolvimento e manutenção que não se traduz diretamente em valor para o usuário.
Propomos uma evolução para um modelo de Arquitetura Híbrida, adotando um Monólito Modular (Modular Monolith) como o núcleo do sistema, enquanto mantemos a possibilidade de extrair serviços para microsserviços independentes conforme a necessidade de escala e complexidade de domínios específicos.
Neste modelo, os domínios de negócio definidos na Fase 3 (Gestão de Usuários, Lembretes, Agendamentos, etc.) seriam implementados como módulos internos e bem definidos dentro de uma única aplicação (o monólito). A comunicação entre esses módulos ocorreria primariamente através de chamadas de função em memória, o que reduz drasticamente a latência e a complexidade em comparação com a comunicação via rede dos microsserviços.
Uma única base de código e um único artefato para deploy simplificam o processo de CI/CD e reduzem a carga cognitiva da equipe.
A comunicação em memória entre os módulos é muito mais rápida do que a comunicação HTTP/RPC entre microsserviços.
Transações que abrangem múltiplos módulos podem ser gerenciadas com a consistência de um banco de dados relacional único.
A arquitetura é projetada para a extração evolutiva, permitindo que quando um módulo específico (ex: Notificações) se tornar um gargalo de performance ou exigir uma equipe dedicada, ele possa ser extraído para um microsserviço independente sem reescrever o resto do sistema.
Dentro de cada módulo do monólito, aplicaremos os princípios da Clean Architecture. Esta escolha garante uma separação clara de responsabilidades e um baixo acoplamento entre a lógica de negócio e os detalhes de infraestrutura (frameworks, bancos de dados, UI).
A arquitetura será organizada em camadas concêntricas:
Regra de Dependência: As dependências só podem apontar para dentro. Isso garante que a lógica de negócio não dependa de detalhes de implementação, tornando o sistema mais testável, manutenível e adaptável a mudanças tecnológicas.
A evolução da arquitetura está diretamente alinhada com o roadmap do produto em três horizontes temporais:
O Monólito Modular permite uma entrega rápida de valor, com um ciclo de desenvolvimento ágil e focado nas funcionalidades principais.
Conforme a base de usuários cresce, o monitoramento (utilizando Prometheus/Grafana) identificará os módulos que mais consomem recursos. O primeiro candidato à extração para um microsserviço seria o de Notificações, devido ao seu volume e natureza assíncrona.
A arquitetura modular, com suas fronteiras bem definidas, facilita a exposição de funcionalidades via APIs públicas para parceiros, transformando o produto em uma plataforma. Módulos como Agendamentos e Gestão de Saúde poderão ter suas APIs expostas para integração com clínicas e farmácias.
Conclusão: Esta abordagem arquitetural oferece o equilíbrio ideal entre velocidade de desenvolvimento no curto prazo e a flexibilidade estratégica necessária para a sustentabilidade e o crescimento do produto no longo prazo.
Framework de governança baseado em COBIT 2019 para alinhar tecnologia com objetivos de negócio.
Adotaremos o framework COBIT 2019 como base para a nossa governança de tecnologia, por sua abordagem abrangente que alinha os objetivos de TI com os objetivos de negócio. O COBIT nos ajudará a garantir que a tecnologia não apenas suporte, mas também impulsione a estratégia do nosso aplicativo, criando valor de forma segura e confiável.
Nosso modelo de governança se concentrará em três domínios principais do COBIT:
Para garantir clareza e agilidade nos processos de decisão, implementaremos uma Matriz de Responsabilidades (RACI).
| Atividade / Decisão | Product Owner | Tech Lead | Arquiteto de Software | Squad de Desenvolvimento |
|---|---|---|---|---|
| Definição do Roadmap do Produto | A | R | C | I |
| Priorização de Features | A | R | I | I |
| Decisões de Arquitetura de Software | I | A | R | C |
| Seleção de Novas Tecnologias | I | R | A | C |
| Gestão do Orçamento de TI | A | R | I | I |
| Gestão de Riscos Técnicos | C | A | R | I |
| Plano de Resposta a Incidentes | I | A | R | R |
| Conformidade com LGPD/GDPR | A | R | C | I |
Legenda:
Nossa estratégia de gestão de riscos será proativa e contínua, integrada ao ciclo de vida do desenvolvimento de software.
| Categoria de Risco | Risco Específico | Probabilidade | Impacto | Estratégia de Mitigação |
|---|---|---|---|---|
| Tecnologia | Vulnerabilidade de Segurança em Dependência de Terceiros | Média | Alto | Análise de Composição de Software (SCA) contínua com ferramentas como Snyk ou Dependabot. Atualizações de segurança automatizadas no pipeline de CI/CD. Política de uso de bibliotecas de código aberto. |
| Pessoas | Perda de Conhecimento Chave (saída de um membro sênior) | Baixa | Alto | Documentação contínua da arquitetura e decisões (ADRs). Pair programming e code reviews para disseminar conhecimento. Plano de sucessão para posições críticas. |
| Processos | Aumento do Débito Técnico devido a Prazos Agressivos | Alta | Médio | Gestão de Débito Técnico explícita no backlog. "Sprints de Qualidade" periódicos para refatoração. Métricas de qualidade de código (complexidade ciclomática, code coverage). |
| Regulatório | Não conformidade com novas regulações de privacidade de dados | Média | Alto | Monitoramento regulatório contínuo. Privacy by Design como princípio fundamental. Consultoria jurídica especializada para revisões periódicas. |
| Mercado | Adoção da tecnologia por concorrente de maior porte | Média | Médio | Foco na experiência do usuário e nicho (idosos). Ciclo de feedback rápido para inovação contínua. Construção de uma comunidade de usuários engajada. |
Revisão Contínua: Este plano de governança e gestão de riscos será um documento vivo, revisado e adaptado trimestralmente pelo Steering Committee para garantir sua relevância e eficácia contínuas.
Arquitetura de dados escalável e estratégia de IA ética para personalização e insights de negócio.
Nossa arquitetura de dados foi projetada para ser escalável, segura e flexível, suportando desde análises de negócio até a implementação de modelos de Inteligência Artificial. Adotaremos uma abordagem de Modern Data Stack, utilizando as melhores ferramentas para cada etapa do ciclo de vida dos dados.
Coleta e Ingestão:
Armazenamento:
Processamento e Transformação:
Análise e Inteligência Artificial:
Nossa estratégia de dados está intrinsecamente ligada aos objetivos de negócio do produto. A governança de dados garantirá a qualidade, segurança e o uso ético dessas informações.
| Objetivo de Negócio | Métrica de Sucesso (KPI) | Fonte de Dados | Dimensões de Análise |
|---|---|---|---|
| Melhorar a adesão ao tratamento médico | Taxa de conclusão de lembretes de medicação (> 90%) | Eventos do App (Kinesis) | Por tipo de medicamento, perfil do usuário, horário |
| Reduzir o isolamento social | Nº de interações sociais por usuário/semana | Dados do App (PostgreSQL) | Por faixa etária, localização, tipo de evento |
| Aumentar o engajamento do produto | Relação DAU/MAU (Usuários Ativos Diários/Mensais) > 40% | Eventos do App (Kinesis) | Por funcionalidade, versão do app, sistema operacional |
| Personalizar a experiência do usuário | Taxa de cliques (CTR) em conteúdo recomendado > 15% | Logs de Interação (S3) | Por tipo de conteúdo, perfil de usuário |
A confiança dos nossos usuários é o nosso ativo mais importante. Portanto, estabelecemos diretrizes rigorosas para o uso ético de IA e a segurança dos dados, em total conformidade com a LGPD e os princípios de Privacy by Design.
Os usuários serão informados de forma clara e acessível sobre como seus dados são utilizados para personalizar a experiência no aplicativo. Para modelos de IA que impactam o usuário (ex: recomendação de atividades), forneceremos explicações simples sobre o porquê de uma determinada sugestão ter sido feita.
Nossos modelos de IA serão continuamente auditados para detectar e mitigar vieses que possam prejudicar ou discriminar grupos de usuários. Ferramentas como o SageMaker Clarify serão utilizadas para medir e monitorar o viés dos modelos.
Todos os dados utilizados para fins analíticos e de treinamento de modelos serão previamente anonimizados ou pseudonimizados para proteger a identidade dos usuários. Coletaremos apenas os dados estritamente necessários para a funcionalidade do aplicativo e para os objetivos de negócio declarados (minimização de dados). Implementaremos um controle de acesso rigoroso (RBAC) no nosso Data Warehouse e Data Lake, garantindo que os dados só possam ser acessados por pessoal autorizado e para finalidades legítimas. Todos os dados serão criptografados em trânsito (TLS) e em repouso (AWS KMS).
Criaremos um Comitê de Ética em Dados e IA, composto por membros das áreas de produto, tecnologia e jurídica, para revisar e aprovar todos os novos casos de uso de dados e modelos de IA antes de sua implementação. Os sistemas de IA terão mecanismos de supervisão humana, garantindo que decisões críticas não sejam totalmente automatizadas.
Pipeline de CI/CD robusto com segurança integrada em cada fase do desenvolvimento.
Nosso pipeline de CI/CD será o coração da nossa estratégia de entrega de software, garantindo que possamos construir, testar e liberar novas versões do nosso aplicativo de forma rápida, segura e confiável. Utilizaremos o GitHub Actions como nossa ferramenta de automação, por sua integração nativa com nosso repositório de código e sua vasta gama de ações customizáveis.
O pipeline será acionado a cada push para a branch main ou na criação de um pull request para main.
O código-fonte é compilado e os testes unitários são executados. Se qualquer teste falhar, o pipeline é interrompido. Também realizamos análise estática com SonarCloud para verificar code smells, complexidade e duplicação.
O CodeQL (integrado ao GitHub) analisa o código em busca de vulnerabilidades de segurança conhecidas (e.g., SQL Injection, XSS), enquanto o Dependabot e o Snyk escaneiam as dependências do projeto em busca de vulnerabilidades conhecidas.
Se os passos anteriores forem bem-sucedidos, uma imagem Docker da aplicação é construída e enviada para o nosso registro de contêineres, o Amazon ECR (Elastic Container Registry), com uma tag única da versão.
A nova imagem Docker é automaticamente implantada em um ambiente de homologação, que é uma réplica do ambiente de produção. Utilizaremos AWS Fargate para orquestrar nossos contêineres, abstraindo a complexidade de gerenciamento de servidores.
Testes de integração automatizados são executados contra o ambiente de homologação. Ferramentas como o OWASP ZAP são executadas para testar a aplicação em tempo de execução, simulando ataques externos.
Após a conclusão bem-sucedida de todos os testes, o pipeline pausa e exige uma aprovação manual do Tech Lead ou Product Owner para prosseguir com o deploy em produção.
Implementaremos uma estratégia de deploy Blue/Green. A nova versão (Green) é implantada ao lado da versão atual (Blue). O tráfego é gradualmente redirecionado para a versão Green. Se nenhum erro for detectado, a versão Blue é desativada. Isso permite um rollback quase instantâneo em caso de problemas.
Nossa filosofia é que a segurança é responsabilidade de todos e deve ser integrada em cada fase do ciclo de vida de desenvolvimento de software (Shift-Left Security).
Realizamos Threat Modeling (Modelagem de Ameaças) para identificar potenciais riscos de segurança na arquitetura da nova funcionalidade.
Fornecemos treinamento contínuo para os desenvolvedores sobre práticas de codificação segura (e.g., OWASP Top 10). O uso de SAST no pipeline fornece feedback rápido sobre vulnerabilidades introduzidas.
Além dos testes de segurança automatizados (SAST, DAST, SCA), realizamos testes de penetração (pentests) anuais com uma empresa externa especializada para validar a segurança da nossa aplicação.
Utilizamos o AWS GuardDuty para monitoramento contínuo de ameaças e atividades maliciosas em nossa infraestrutura AWS. Logs de aplicação e infraestrutura são centralizados no Amazon CloudWatch e analisados em busca de anomalias.
Para testar e fortalecer continuamente nossa postura de segurança, adotaremos uma abordagem colaborativa entre equipes de ataque e defesa.
Red Team (Ataque): Tem a função de simular ataques de adversários reais para identificar vulnerabilidades e pontos fracos em nossas defesas. Periodicamente (a cada trimestre), um subgrupo da equipe (ou um consultor externo) atuará como Red Team, tentando explorar a aplicação e a infraestrutura sem conhecimento prévio da equipe de defesa. O objetivo é testar a eficácia dos nossos controles de segurança e da nossa capacidade de detecção e resposta.
Blue Team (Defesa): Tem a função de manter e operar as defesas de segurança da organização, detectar e responder a incidentes. O Blue Team é a equipe de operações do dia-a-dia, responsável por configurar firewalls, monitorar logs, aplicar patches de segurança e responder a alertas gerados pelas nossas ferramentas de segurança.
Purple Team (Colaboração): Facilita a colaboração e o compartilhamento de conhecimento entre o Red Team e o Blue Team. Após cada exercício do Red Team, realizamos uma sessão de Purple Team onde atacantes e defensores se reúnem. O Red Team compartilha suas táticas, técnicas e procedimentos (TTPs), e o Blue Team discute como as defesas se comportaram e como podem ser aprimoradas. O objetivo não é "ganhar" ou "perder", mas sim melhorar a segurança geral da organização de forma colaborativa e transparente.
Estratégia de integração para transformar o produto em uma plataforma de bem-estar para idosos.
Para que nosso aplicativo transcenda sua função como uma ferramenta isolada e se torne uma plataforma de bem-estar para idosos, a integração com ecossistemas digitais é fundamental. Nossa arquitetura de integração será baseada em APIs (Application Programming Interfaces), projetada para ser segura, escalável e fácil de consumir por parceiros estratégicos.
Adotaremos o Amazon API Gateway como o ponto central de entrada para todas as integrações externas. Ele nos fornecerá uma camada de gerenciamento robusta para:
Identificamos três categorias principais de parceiros estratégicos:
Caso de Uso: Compra recorrente de medicamentos diretamente pelo aplicativo.
Integração: Quando um lembrete de medicação indicar que o estoque está baixo, o usuário poderá, com um clique, autorizar a compra e a entrega pela sua farmácia de preferência.
Benefício: Conveniência para o usuário e aumento de vendas para a farmácia.
Caso de Uso: Sincronização de consultas e exames.
Integração: Integração com sistemas de agendamento (HIS/EMR) para sincronizar consultas e exames. O usuário poderá visualizar seus agendamentos feitos na clínica diretamente no nosso aplicativo, e vice-versa.
Benefício: Redução de faltas e melhor gestão da agenda para a clínica.
Caso de Uso: Conexão de cuidadores a idosos.
Integração: Prestadores de serviços que conectam cuidadores a idosos poderão se integrar para sincronizar agendas e facilitar a comunicação, garantindo que o cuidador esteja ciente dos compromissos e medicações do idoso.
Benefício: Melhor coordenação do cuidado e tranquilidade para familiares.
Avaliamos continuamente tecnologias emergentes para identificar oportunidades de inovação que possam agregar valor ao nosso produto e aos nossos usuários, utilizando o framework Hype Cycle do Gartner para avaliar a maturidade e o potencial de cada tecnologia.
| Tecnologia | Análise de Viabilidade e Aplicabilidade | Framework Hype Cycle (Posição) |
|---|---|---|
| APIs Abertas (Open APIs) | Alta Viabilidade. Essencial para nossa estratégia de plataforma. Permitirá que parceiros construam novos serviços sobre nossos dados (com consentimento do usuário), fomentando um ecossistema de inovação. | Platô da Produtividade |
| Open Data | Viabilidade Média. Poderíamos consumir dados abertos de saúde pública (e.g., calendários de vacinação, dados epidemiológicos) para fornecer informações relevantes aos usuários. A geração de Open Data a partir dos nossos próprios dados anonimizados é uma possibilidade futura para pesquisa acadêmica. | Pico das Expectativas Infladas |
| Blockchain | Baixa Viabilidade (no momento). Embora o Blockchain possa oferecer um registro imutável de dados de saúde, a complexidade de implementação, os desafios de escalabilidade e a falta de uma necessidade clara de descentralização para o nosso caso de uso atual tornam o custo-benefício desfavorável. Reavaliaremos se a necessidade de portabilidade de dados entre múltiplos provedores de forma totalmente descentralizada se tornar crítica. | Vale da Desilusão |
| IA Generativa | Alta Viabilidade (para casos de uso específicos). Estamos explorando o uso de IA Generativa para criar um assistente de conversação (chatbot) mais humano e empático para o suporte ao usuário. Ele poderia ajudar os idosos a navegar no aplicativo, tirar dúvidas sobre suas medicações e até mesmo oferecer companhia, combatendo a solidão. A tecnologia já está madura o suficiente para prototipação. | Pico das Expectativas Infladas |
Nosso objetivo é posicionar o aplicativo não apenas como um produto, mas como o hub central da vida digital do idoso. A estratégia de integração é o caminho para alcançar essa visão em três horizontes temporais:
Construiremos a melhor experiência para o usuário final, resolvendo suas dores principais de organização e lembretes. A confiança e o engajamento gerados aqui são a base para o ecossistema.
Lançaremos nosso programa de parcerias e as primeiras APIs abertas (e.g., para farmácias). O objetivo é demonstrar o valor da integração e criar os primeiros casos de sucesso.
Expandiremos o leque de APIs e incentivaremos desenvolvedores terceiros a criar suas próprias soluções integradas ao nosso aplicativo. Imaginamos um "app store" de serviços para idosos, onde nosso produto atua como o sistema operacional, garantindo segurança, identidade e consentimento.
Efeito de Rede: Ao nos tornarmos a plataforma de escolha para o ecossistema de "Age Tech", criamos um forte efeito de rede: mais usuários atraem mais parceiros, e mais parceiros criam mais valor para os usuários, solidificando nossa liderança e criando uma barreira de entrada robusta contra a concorrência.
Consolidação técnica e estratégica da Fase 4 do Tech Challenge
As decisões técnicas e estratégicas da Fase 4 do Tech Challenge demonstram como a evolução da arquitetura, a governança estruturada, a estratégia de dados e IA, a implementação de DevSecOps e a integração com ecossistemas digitais trabalham de forma integrada para fortalecer o alicerce técnico do nosso produto.
As escolhas realizadas refletem uma visão de longo prazo, garantindo que o aplicativo possa crescer de forma sustentável, segura e alinhada com as necessidades dos nossos usuários idosos e do mercado de Age Tech.
Grupo 28 (84) - Tech Challenge Fase 4: IT Product Development