Business Architecture “Moderno”: Um guia para startups

Uma série sobre Business Architecture

Desde a publicação desses textos, toda semana várias pessoas me procuram no Linkedin com perguntas, pedindo mais conteúdos e referências. Diante dessa grande busca, decidi fazer desses conteúdos uma série sobre Business Architecture.

• O que faz um Business Architect (No Medium);
• 5 características de um ótimo Business Architect (No Medium);
• Esse texto é a terceira parte;
• 25 livros que valem um MBA;

As primeiras partes foram escritas no meu perfil do Medium, mas os meus conteúdos mudaram definitivamente para cá: https://www.coletividad.org/blog

A série vai trazer essas reflexões e dúvidas, junto da minha experiência, e os desafios extraídos de dezenas de conversas com Business Architects de Startups de todos os tamanhos e segmentos.

5 principais erros das startups

Existe um enorme confusão sobre Business Architecture, ainda que seja um campo relativamente em crescimento no universo das Startups de Tecnologia.

A confusão permanece devido, em parte, por conta do:

1. Tempo de existência;
2. Imaturidade da própria profissão para considerar diferentes estágios das empresas as quais ela se aplica;
3. Ausência de bom conteúdo e referências;
4. Ausência de aplicações práticas de sucesso e métricas;
5. Aderência com os contextos das startups tentando adotar Business Architecture — perpetuado por práticas ultrapassadas e incoerentes com o universo atual ou contextos específicos. Mais sobre isso à frente!

Os 5 principais erros das startups, em ordem de frequência, segundo o que vejo nas startups de todos os níveis e escalas é:

1. Imitar empresas de “sucesso” que tem Business Architecture na sua teoria operaiconal, sistema e organograma. Se você não sabe contratar um Business Architecture, então antes é preciso definir as capacidades, informações e organização de RH/People, além de Estratégicas, porque Business Architecture não se trata de “pedigree”, mas de uma sintonia precisa. Ironicamente esse é exatamente o tipo de problema que Business Architecture deveria resolver. Tentar replicar a estrutura de outra empresa provavelmente levará ao fracasso da área/atuação, porque Business Architecture é extremamente específico do negócio e deve ser sobre a visão de longo prazo nas suas atividades de planejamento, análise de impacto, entrega operacional e implantação de soluções.
2. Business Architect específico por Produto, Time ou Unidade de Negócios — raramente aplicado à Empresa como um todo, como deveria. Para facilitar a adoção, as empresas estão tentando extrair valor de Business Architecture restringindo à condições/estruturas menores. Porém, quanto mais restrita a atuação, menos valor a pessoa Business Architect oferece. O que nos leva ao erro 3.
3. Redundância e desvio de função para Analista de Negócio, Product Manager, Project Manager. Esse é um dos pontos mais comuns e que escrevo no primeiro texto. Novamente, o tipo de problema que a profissão deveria resolver.
4. Separação entre Processos de Negócios e Business Architecture (a História explica). Dividir a realização do seu modelo de negócios, conduzido por Business Architecture, da realização do seu modelo operacional pelos Processo de Negócio só cria mais complexidade, fricção — exatamete o que Business Architecture deveria evitar.
5. Menos comum, mas acontece, é o Business Architect atuando como uma disciplina de TI, fazendo um papel (ruim) de Solutions Architect, olhando para dados, a solução, o aplicativo ou as arquiteturas técnicas. 

Breve História e contexto de Business Architecture

O primeiro trabalho em um conceito mais moderno de arquitetura de negócios provavelmente foi iniciado pelo Supply Chain Council (SCC) — uma associação de organizações que se uniram para desenvolver padrões para o desenvolvimento da cadeia de suprimentos — em meados da década de 1990.

Os gerentes da cadeia de suprimentos acabaram desenvolvendo uma arquitetura padrão para uma cadeia de suprimentos que as empresas poderiam usar para definir suas próprias cadeias de suprimentos e como suas cadeias de suprimentos se conectavam com outras cadeias de suprimentos. Uma Supply Chainception (hehe).

Eles subdividiram uma cadeia de suprimentos em quatro subprocessos principais: origem, fabricação, entrega e devolução.

Além disso, eles identificaram um processo que chamaram de plano, que era necessário para todos os outros processos. Em essência, eles estavam dizendo que cada cadeia de suprimentos e cada processo específico de fabricação e devolução exigia um processo de gerenciamento — que eles chamavam de plano — para controlá-lo.

Atenção para:

1. Essa noção primária de Business Architecture foi desenvolvida por pessoas de negócios — pelos gerentes da cadeia de suprimentos — e não por pessoas de processo e nem por pessoas de arquitetura de TI;
2. Mostra por que os empresários podem querer uma arquitetura de negócios. Sua primeira preocupação não era alinhar os aplicativos de software com os objetivos de negócios. A primeira preocupação deles era entender como os processos que eles tinham estavam funcionando, identificando como os processos de uma empresa se relacionavam com os de outras empresas e, em seguida, identificando quais processos seriam os mais econômicos para considerar a correção.

Essa é a grande lição histórica sobre Business Architecture. Na medida em que esse modelo cresceu, ele passou a incluir informações também sobre as melhores práticas dos funcionários, e não as melhores práticas de tecnologia, dados ou outras áreas, hoje mais predominantes no universo de negócio.

No tipo de empresa em que isso ocorria, e/ou Business Architecture é ou era historicamente adotado (Microsoft, Amazon, Oracle) uma área, time, domínio, projeto (ou lucro) é tão grande que a estrutura parece uma empresa por si só, então micro-operações e gerenciamento são justificáveis. Muito diferente da sua startup com 50, 100 ou 2000 colaboradores.

O efeito ou uma possibilidade nesse “inchaço corporativo” era a frequente adição de mais sistemas, mais pessoas, mais cargos, mais um banco de dados, mais servidores, mais uma “solução rápida” que só criava mais redundância. Executivos que continuam jogando recursos para problemas de negócios mal definidos e mal articulados — principalmente porque não precisavam, já que não existem tantas ameaças, há abundância de capital, e não há necessidade de agilidade.

Exatamente o oposto de tudo que Business Architecture se vende como a solução. Há uma clara inconsistência.

Por isso Business Architecture precisa de uma atuação “Moderna”, coerente com o modelo (teórico) das Startups. Digo teórico por que muita “startup” replica essa prática do “inchaço corporativo”, com executivos e líderes jogando recursos para problemas de negócios mal definidos e mal articulados.

Business Architecture ontem vs hoje

Nessa ideia clássica, a descrição de Business Architecture é:

“A arquitetura de negócios é um componente essencial de uma arquitetura corporativa para fornecer visões holísticas e multidimensionais de capacidades, entrega de valor de ponta a ponta, informações e perspectivas de negócios de estrutura organizacional e seus relacionamentos entre estratégias, produtos, políticas, iniciativas e partes interessadas.”

Mas até aqui já vimos que:

1. A definição é contraditória e muito abrangente. Considerando que qualquer domínio “ponta a ponta” só pode realmente ocorrer em níveis elevados de poder decisório e por uma quantidade reduzida de pessoas;
2. A ideia de pertencer ao domínio de “Business Enterprise” já sugere o tipo de corporação em que ela costuma e/ou costumava existir;
3. A origem e contexto do pensamento vem da premissa de que solidificar e padronizar os processos “mecânicos” de forma (100%) previsível e mais realista onde surgiu (cadeia de suprimentos);
4. É insustentável e ineficiente manter mapas de Stakeholders, Estratégias, Ambientes, Iniciativas, Capacidades, Políticas, entre outros, todos atualizados em um ambiente realmente dinâmico, enquanto você tenta manter sua atuação realmente estratégica;
5. Ao contrário da ideia original de Business Architecture, em startups a Tecnologia vem primeiro, depois Business (ao menos nos estágios iniciais e pré-IPO) onde o escopo e os impactos das estratégias, planos de produtos, iniciativas e investimentos são claramente definidos a partir de uma perspectiva primeiramente de Tecnologia em busca de escalabilidade.
6. Startup = Velocidade. Velocidade = fragmentação. Determinada por grandes nomes e histórias de sucesso, velocidade em Startups é sobre execução. A capacidade de encontrar e resolver poucos, porém grandes e reais problemas de maneira escalável e repetível, não unicamente sobre a velocidade com que você contrata mais gente por que tem capital. Velocidade e crescimento vem com uma inconstância e variedade enorme nos vocabulários de negócios, modelos mentais e operacionais de todas as partes — o que é um desafio e incoerente com Business Architecture.

Não que isso seja certo ou bom, mas esse é o cenário na maioria das estartups sem uma liderança (CEO e/ou Liderança) com Operação estratégica.

Como Business Architect é importante entendê-lo para você exercer a sua função da melhor forma.

Arquiteturas Acidentais

Quando unimos a inaptidão para perceber e resolver os reais problemas, com a falta de investimento, com políticas exclusivas, com uma governança ruim, sem capacidade de reconhecer e incorporar todas as pontas, desejos e necessidades no planejamento e na execução do sistema, nós temos crescimentos adjacentes — as Arquiteturas Acidentais.

Algumas infinitamente mais tristes que outras.

Em uma consequência infinitamente menos importante (e triste) do que a da foto acima, esse é paralelo entre ação vs efeito dos pontos trazidos até aqui e que devem ser considerados no seu sistema.

Arquiteturas Acidentais é o equivalente a dívida técnica ou débito técnico (technical debt) na tecnologia. Essa “dívida” acontece quando uma estrutura técnica, Ex.: um código ruim, vulnerável, com erros, é lançado para agilizar a entrega de uma funcionalidade ou projeto que atenda a demanda do momento, mas que no futuro precisará ser refeito.

É o famoso “melhor feito que perfeito”

Isso tem seu lugar e relevância, e deve ser planejado e considerado desde o início nos seus mapas e fluxos.

Business Architecture “Moderno” nas Startups

Na minha visão, para Startups implementarem um modelo próprio real, seguindo o escopo tradicional, é imprescindível que a pessoa Business Architect seja de uma posição Senior, em Operações e/ou outro setor da empresa, com poder decisório e responsável por coordenar estratégica, tática e operacionalmente multiplas áreas.

Com isso ela realmente possa: 

• Articular o que a empresa faz (capacidades);
• Definir como alcançar e entregar valor aos stakeholders internos e externos (fluxos de valor);
• Definir o vocabulário de negócio e os relacionamentos (informações);
• Definir e organizar a estrutura do negócio (organização);

Caso esse não seja o caso, o caminho adjacente (como em Arquiteturas Acidentais):

• Dê oportunidade e treine as pessoas;
• Tudo bem você não ser Business Architect (hoje), e sua empresa te limitar a um Consultor/Assessor/Manager. Mas caso você queria, é fundamental que tenha um mapa de como consttruir isso para sua carreira e/ou na sua empresa. A área é muito recente e essa é uma oportundiade de você contribuir com o mercado e criar a área da maneira certa na sua empresa (se a Cultura real dela permitir);
• Defina Business Architect como como parte das funções de várias pessoas em outras funções à medida que utilizam e refinam a arquitetura de negócios como parte da organização. Essa estrutura permite o dimensionamento, adoção (como vimos nos 5 erros) e permeie toda a organização, embora, novamente, possa ser difícil garantir a coesão e a consistência da função. É por exemplo um Product Manager ou Business Analyst usando também o chapéu de Business Architect, similar ao papel de um Product Owner em um time. Diferente de um Business Architect desviado para atuação de Product Manager;
• Adeque e foque na especificidade do seu negócio, nos profissionais disponíveis e suas habilidades, experiências, interesses e personalidades, assim como novos modelos de negócios. Isso permitirá que a estrutura e o escopo da(s) função(ões) sejam adaptáveis ​​e flexíveis para realmente atender às necessidades da empresa;
• Pense nisso como um quebra-cabeça onde Business Architecture preenche as peças que faltam para completar a liderança e influenciar partes estratégicas de acordo com as necessidades específicas do negócio;
• Entenda a fronteira dos sistemas e o ambiente de negócios no qual ele pretende operar;
• Simplifique e elimine tudo que não for realmente essencial;
• Sempre considere a “métrica oposta” — Ato vs efeito nos seus eventuais mapas e fluxos;
• Crie um mapa e sistema que foque as pessoas em grandes e reais problemas;
• Reduza o risco do maior risco;