Arquitetura

A arquitetura de um produto costuma interessar pouco a quem vai operá-lo. Esta interessa por três perguntas práticas que ela responde: o que para de funcionar quando uma peça cai, o que precisa ser atualizado junto com o quê, e o que dá para deixar para depois.

Quatro componentes

A plataforma é montada em quatro peças, cada uma com um papel:

• O núcleo de rede PON. A planta óptica: a topologia, o estado corrente das ONUs, o sinal, a saúde das OLTs e as operações feitas sobre a cabeceira.
• O ACS de CPE. O lado do assinante: é aqui que o equipamento dentro da casa se anuncia, e é daqui que sai a configuração remota dele.
• O processamento de eventos. O trabalho contínuo sobre o que foi lido: a queda que vira evento de indisponibilidade, as quedas concomitantes que viram massiva.
• A interface do operador. As telas — o que o plantão, o atendimento e o campo têm na frente.

Cada uma sobe, cai e evolui por conta própria.

Independente não quer dizer dispensável, e vale ser explícito sobre isso: com uma peça fora do ar, o trabalho dela não passa a ser feito por outra. O que a independência entrega é contenção. A falha tende a ficar no escopo daquela função em vez de derrubar o resto junto.

A base de dados é o barramento

Nenhum componente chama outro por API. A integração acontece na base de dados, e cada fronteira entre duas peças tem um contrato explícito: o que é escrito, por quem, e com que significado.

Isso soa como detalhe de implementação e não é. Três consequências aparecem na operação e no orçamento.

Não há API interna para versionar. Numa integração por chamadas, a conversa entre duas peças é a parte que envelhece mais rápido: cada mudança de um lado obriga a combinar a mudança do outro, e a incompatibilidade costuma aparecer em produção, na primeira chamada que ninguém testou. O problema de compatibilidade não desaparece aqui — ele muda de lugar. Passa a ser uma questão sobre o que está declarado no contrato, e não sobre uma chamada que só falha quando alguém a faz.

Um componente reiniciando não derruba cadeia de chamadas. Quando A chama B que chama C, a queda de C chega ao operador como um erro em A: uma tela que falha por causa de uma peça de que ele nunca ouviu falar, e um diagnóstico que começa longe de onde está o problema. Sem chamadas entre as peças, não existe essa cadeia. O efeito de uma peça fora do ar tende a ser dado que parou de ser atualizado, e não tela que quebra. Continua sendo um problema — de outra natureza, e que costuma ser mais fácil de localizar.

O estado é um só. Não há uma cópia do estado na interface, outra no processamento de eventos e uma terceira no ACS, cada uma com o seu atraso. Isso ajuda a evitar a discussão que consome uma reunião inteira: por que a tela diz uma coisa e o relatório diz outra. Onde existem duas verdades, alguém precisa decidir qual delas vale, e essa decisão costuma cair no meio de um incidente — o pior momento para tomá-la.

A contrapartida é direta e vale dizer: a base é a peça de que todas as outras dependem. O desenho concentra ali o que estaria espalhado.

Módulos

A interface desenha o que está instalado. Um provedor que não faz gestão de CPE não vê o módulo de CPE — não é uma tela escondida atrás de uma permissão, é módulo ausente.

A distinção entre as duas coisas importa mais do que parece, porque elas produzem telas parecidas e significam coisas diferentes. Permissão é sobre uma função poder ou não fazer algo que a plataforma faz. Módulo é sobre a plataforma fazer ou não aquilo naquela instalação. Quando alguém pergunta “por que não estou vendo isso?”, as duas respostas levam a lugares diferentes: uma é conversa com quem administra o acesso, a outra é conversa sobre o que foi implantado. Ver Controle de acesso.

O ganho para quem opera é que a plataforma não fica maior do que o uso que se faz dela. Área de tela que aquele provedor nunca vai usar cobra atenção de todo mundo que passa por ela, todos os dias, e cobra de novo de cada pessoa nova que precisa aprender o que ignorar.

O que isso significa na prática

Atualizar uma parte sem parar as outras. A versão nova de uma peça não obriga a parar as demais. Quem já precisou marcar janela de manutenção para o sistema inteiro por causa de uma correção num canto dele sabe a distância entre as duas coisas.

Começar pelo núcleo e acrescentar CPE depois. Implantar a gestão da planta óptica é um projeto. Assumir a gestão do equipamento dentro da casa do assinante é outro, com outra conversa sobre o parque instalado e sobre o que o suporte passa a responder — ver CPE e TR-069. Não é preciso resolver os dois ao mesmo tempo para que o primeiro entregue valor.

Não adotar tudo de uma vez. A ordem de adoção acompanha o que a operação consegue absorver, e não o que o produto tem para entregar. Implantação que entrega tudo junto costuma ser implantação em que parte das telas nunca entra na rotina de ninguém.

Nada disso sai de graça. Cada peça é uma peça a mais para instalar, atualizar e acompanhar. A independência entre elas é o que torna esse custo administrável — não o que o faz desaparecer.

Por onde continuar

• Controle de acesso — quem pode fazer o quê dentro dos módulos que estão instalados.
• Visão geral — o produto inteiro em uma página.