Memória Técnica — Integração de Sistemas e Redes da Segurança Social do Porto, 1990

Memória Técnica — Integração de Sistemas e Redes da Segurança Social do Porto, 1990
Quando integrar significava realmente construir pontes
Nota de abertura:
Em 1990 desenhei e implementei uma arquitectura de comunicações destinada a interligar sistemas informáticos heterogéneos da Segurança Social, ligando a Caixa Nacional de Pensões a três instalações da Segurança Social no Porto. O velho esquema manuscrito que conservei é mais do que um desenho: é o registo de uma época em que integrar sistemas significava compreender, converter e fazer cooperar arquitecturas que tinham sido concebidas para viver separadas.
Quando integrar significava realmente construir pontes
Em 1990 desenhei e implementei uma arquitectura de comunicações destinada a interligar sistemas informáticos heterogéneos da Segurança Social, ligando a Caixa Nacional de Pensões a três instalações da Segurança Social no Porto.
Vista hoje, a arquitectura cabe confortavelmente num diagrama.
Naquele tempo, porém, cada uma das linhas desse desenho escondia um problema técnico diferente.
Não existia uma rede IP universal sobre a qual pudéssemos simplesmente transportar tudo. Os fabricantes tinham arquitecturas próprias, protocolos próprios, terminais próprios e, frequentemente, maneiras muito particulares de interpretar aquilo a que todos chamávamos, com algum optimismo, «comunicações».
O trabalho consistia precisamente em fazer esses mundos comunicar.
O problema
A necessidade fundamental era permitir a interoperabilidade entre sistemas centrais e periféricos instalados em diferentes localizações físicas.
No desenho técnico que conservei desse projecto aparecem claramente dois universos informáticos distintos.
Do lado da Caixa Nacional de Pensões encontrava-se um ambiente mainframe UNIVAC, integrado numa arquitectura de comunicações SNA, utilizando SDLC no acesso à rede.
No Porto existia, entre outros equipamentos, um mainframe ICL Série 39, além de terminais e redes locais distribuídas por três locais da Segurança Social.
Entre estes sistemas existia aquilo que naquela época constituía uma das grandes infra-estruturas de dados disponíveis: a rede pública X.25.
O desafio era, portanto, fazer atravessar essa rede tráfego proveniente de arquitecturas diferentes e entregá-lo nos sistemas de destino de forma transparente e operacionalmente utilizável.
A arquitectura
A solução foi construída em várias etapas.
Na Caixa Nacional de Pensões, a comunicação proveniente do mainframe seguia através de SNA/SDLC até um equipamento TCL DBS300.
Esse equipamento desempenhava uma função crítica.
Era o gateway entre SDLC e X.25.
A partir desse ponto, as comunicações eram convertidas para o ambiente da rede pública, sendo transportadas através de DRSNET/X.25.
O núcleo da arquitectura era, portanto:
Mainframe → SNA/SDLC → Gateway DBS300 → X.25 → Rede Pública → X.25 → Gateway → Ethernet / redes locais.
Parece simples quando escrito numa única linha.
Em 1990 não era.
A rede pública X.25 como espinha dorsal
A utilização de X.25 permitia transformar a rede pública de dados numa verdadeira infra-estrutura de transporte entre organizações e localizações geograficamente separadas.
A rede não precisava de conhecer a lógica das aplicações.
Transportava os pacotes.
Nos extremos, os gateways tratavam da adaptação aos respectivos ambientes tecnológicos.
Esta separação entre transporte e sistemas finais era particularmente poderosa porque permitia ligar plataformas que, de origem, não tinham sido concebidas para trabalhar umas com as outras.
Era essa uma das grandes virtudes do projecto.
Não procurávamos substituir os sistemas existentes. Fazíamo-los comunicar.
A chegada ao Porto
Na Segurança Social do Porto, outro DBS300 recebia as comunicações provenientes da rede X.25.
Nesse ponto fazia-se nova adaptação tecnológica.
O tráfego X.25 passava a integrar-se na infra-estrutura local e nas redes Ethernet que serviam os vários equipamentos.
A partir daí, a arquitectura distribuía-se pelos três sites.
O primeiro desses locais incluía o mainframe ICL Série 39, além de terminais ligados ao ambiente local.
Os restantes locais possuíam igualmente equipamentos e terminais integrados através das respectivas redes Ethernet.
A interligação entre alguns desses segmentos era realizada através de bridges, utilizando redes privadas digitais a 64 kbps.
Hoje, 64 kbps parece uma velocidade quase arqueológica.
Na altura representava uma ligação digital dedicada, previsível e perfeitamente adequada a muitos dos fluxos transaccionais existentes.
E, sobretudo, cada bit era tratado como um recurso precioso.
Não existia largura de banda para desperdiçar.
Bridges, Ethernet e redes privadas digitais
A arquitectura combinava, portanto, dois tipos de infra-estrutura de telecomunicações.
Por um lado, a rede pública X.25, utilizada como plataforma de transporte de dados entre sistemas remotos.
Por outro, circuitos digitais privados de 64 kbps, utilizados na interligação das instalações no Porto.
As bridges permitiam prolongar segmentos das redes locais entre instalações, possibilitando que equipamentos separados fisicamente funcionassem como partes de uma infra-estrutura logicamente integrada.
Isto colocava no mesmo projecto tecnologias muito diferentes:
ELEMENTOS CENTRAIS
- SNA e SDLC;
- X.25 e gateways de conversão de protocolos;
- Ethernet e bridges;
- rede pública de dados;
- circuitos digitais privados de 64 kbps;
- ambientes mainframe de fabricantes diferentes;
- operação distribuída por três sites no Porto.
O verdadeiro projecto não era qualquer uma destas tecnologias.
Era a combinação de todas elas.
O papel dos gateways
Os DBS300 ocupavam uma posição fundamental na arquitectura.
Não eram simples equipamentos de transmissão.
Eram elementos de fronteira.
De um lado recebiam protocolos ligados aos ambientes mainframe.
Do outro apresentavam interfaces adequadas à rede X.25 ou às infra-estruturas locais.
Em termos modernos poderíamos falar de integração protocolar ou de interworking.
Na prática, tratava-se de permitir que sistemas desenvolvidos segundo filosofias tecnológicas diferentes conseguissem participar numa mesma arquitectura.
Foi exactamente este tipo de problema que marcou grande parte das telecomunicações de dados antes da generalização definitiva do TCP/IP.
Interoperabilidade antes de a palavra se tornar moda
Hoje fala-se abundantemente de interoperabilidade.
Em 1990, nós tínhamos de a construir.
Não existia uma camada IP omnipresente capaz de esconder as diferenças existentes nos níveis inferiores.
Era necessário compreender o comportamento de cada protocolo.
Estados das ligações.
Temporizações.
Estabelecimento e libertação de sessões.
Encapsulamento.
Endereçamento.
Conversões entre interfaces.
Gestão de erros.
E, naturalmente, aquela situação particularmente educativa em que cada fabricante garantia que o problema estava seguramente no equipamento do outro.
Algumas tradições da indústria informática sobreviveram admiravelmente às décadas.
Um projecto desenhado no papel
O esquema original que ainda hoje conservo foi desenhado à mão.
Tem caixas, linhas, nomes de protocolos, equipamentos e anotações.
Não possui a aparência impecável dos actuais programas de desenho de arquitectura.
Mas contém algo talvez mais importante.
É o registo directo do raciocínio técnico que esteve por detrás de uma rede real.
Ali está a arquitectura antes de se transformar em cabos, modems, gateways, circuitos de telecomunicações e sistemas em produção.
Primeiro existiu como problema.
Depois como desenho.
Finalmente como sistema.
Implementar era provar a arquitectura
Uma arquitectura deste género só ficava verdadeiramente demonstrada quando a comunicação atravessava todos os seus componentes.
Uma transacção podia começar num sistema central, atravessar SDLC, sofrer conversão protocolar, entrar na rede X.25, viajar pela rede pública, chegar ao segundo gateway, passar para a infra-estrutura local e finalmente alcançar o sistema ou terminal pretendido.
Cada fronteira tecnológica constituía um possível ponto de falha.
Por isso, o trabalho de implementação não consistia apenas em configurar equipamentos.
Era necessário compreender o percurso completo da informação.
Quando algo falhava, tínhamos de determinar em que camada, equipamento, circuito ou protocolo tinha ocorrido a interrupção.
Era engenharia de sistemas no sentido mais literal da expressão.
Três sites, uma única arquitectura
Um dos aspectos importantes do projecto era precisamente a distribuição por três localizações da Segurança Social no Porto.
Os sistemas estavam fisicamente separados.
A arquitectura de telecomunicações tinha de os transformar numa unidade operacional.
Rede pública X.25, gateways, bridges, Ethernet e circuitos digitais permitiram criar essa continuidade lógica.
Era uma pequena antecipação daquilo que hoje consideramos perfeitamente normal numa organização distribuída.
A localização física começava a deixar de determinar a localização da informação.
1990
Vale a pena recordar o ano.
1990.
Enquanto esta rede era implementada, o projecto WorldWideWeb estava a ser formalizado no CERN. A proposta inicial de Tim Berners-Lee datava de 1989 e a proposta formal com Robert Cailliau seria apresentada em Novembro de 1990.
As organizações dependiam de mainframes.
As redes locais estavam em plena expansão.
X.25 desempenhava um papel fundamental nas comunicações de dados.
Ethernet estava já normalizado e consolidava a sua presença nas redes locais.
Os fabricantes continuavam a possuir ecossistemas tecnológicos fortemente diferenciados.
Foi nesse contexto que esta arquitectura foi construída.
Não para uma demonstração.
Não para uma apresentação comercial.
Para trabalhar.
O que hoje vejo naquele desenho
Mais de três décadas depois, quando observo aquele esquema feito à mão, não vejo apenas protocolos antigos.
Vejo uma maneira de pensar.
Identificar sistemas.
Identificar fronteiras.
Compreender protocolos.
Encontrar os pontos de conversão.
Escolher a infra-estrutura de transporte.
Integrar aquilo que originalmente não tinha sido concebido para funcionar em conjunto.
Essa lógica continua perfeitamente actual.
Mudaram os protocolos.
Mudaram as velocidades.
Mudaram os equipamentos.
Hoje falamos de APIs, VPNs, SD-WAN, containers, cloud, microserviços e sistemas distribuídos.
Mas a pergunta fundamental permanece surpreendentemente semelhante:
como fazemos sistemas diferentes comunicar de forma fiável?
Em 1990, uma das minhas respostas foi aquela rede.
A satisfação de construir o invisível
Há ainda uma característica comum a este género de projectos.
Depois de implementados, tornam-se invisíveis.
Os utilizadores não querem saber se uma transacção atravessou SDLC, X.25, uma bridge ou uma linha digital.
Querem que funcione.
E é precisamente quando uma infra-estrutura funciona tão bem que ninguém pensa nela que a engenharia cumpriu o seu objectivo.
Talvez por isso grande parte deste trabalho tenha desaparecido da memória pública.
Não havia redes sociais para fotografar instalações.
Não havia publicações diárias sobre «transformação digital».
Havia equipas técnicas, equipamentos, diagramas, analisadores, documentação e muitas horas de trabalho.
E havia aquela extraordinária sensação, no final, de verificar que máquinas concebidas por fabricantes diferentes, instaladas em locais diferentes e utilizando protocolos diferentes estavam finalmente a comunicar.
Uma pequena peça de uma transformação muito maior
Este projecto da Segurança Social do Porto é apenas uma pequena parte da minha vida profissional.
Mas representa muito bem uma época.
Foi o período em que Portugal começou a construir uma verdadeira malha digital entre instituições, bancos, empresas, serviços públicos e grandes organizações.
Cada rede era uma peça dessa transformação.
Cada gateway era uma ponte.
Cada circuito estabelecia uma nova possibilidade de cooperação entre sistemas.
E muitos de nós fomos construindo essas pontes antes de alguém lhes chamar transformação digital.
Não sabíamos exactamente até onde aquela revolução nos levaria.
Sabíamos apenas que os computadores já não podiam continuar isolados.
Tinham de comunicar.
E foi isso que fizemos.
Em 1990, naquela rede da Segurança Social do Porto, fizemos sistemas diferentes falar uns com os outros.
Hoje olho para aquele velho desenho e reconheço nele muito mais do que uma arquitectura técnica.
Reconheço uma parte da minha vida.
Uma época em que quase todos os projectos traziam um problema novo.
E em que inovação não era uma palavra escrita numa apresentação.
Era aquilo que tínhamos de fazer para que o sistema funcionasse.
«Hoje olho para aquele velho desenho e reconheço nele muito mais do que uma arquitectura técnica. Reconheço uma parte da minha vida.»
Nota Editorial
Esta crónica é uma memória técnica em primeira pessoa. A topologia do projecto, a identificação dos equipamentos, os protocolos utilizados, a existência dos três sites da Segurança Social do Porto, a utilização da rede pública X.25 e das redes privadas digitais a 64 kbps, bem como o papel do autor no desenho e implementação da solução, assentam no testemunho directo de Francisco Gonçalves e no esquema técnico original de 1990 conservado pelo próprio.
As referências internacionais abaixo não são apresentadas como prova documental independente da execução concreta deste projecto. Servem para enquadrar e documentar as tecnologias e o contexto histórico descritos: X.25, SNA/SDLC, Ethernet, a família ICL Série 39 e o desenvolvimento inicial da World Wide Web.
Esta distinção é deliberada: preservar uma memória profissional com rigor significa não transformar documentação de contexto em falsa confirmação externa de acontecimentos que pertencem ao arquivo e à experiência directa do autor.
Referências credíveis
- ITU-T — Recommendation X.25
A recomendação internacional que definiu a interface entre equipamento terminal e redes públicas de dados em modo pacote; a edição de 1988 estava em vigor no período do projecto. - IBM — SDLC/SNA Protocol
Documentação da IBM sobre Synchronous Data Link Control (SDLC) como protocolo de comunicações utilizado em redes SNA. - IBM — Synchronous Data Link Control Overview
Descrição técnica do SDLC e do seu papel na troca de informação em redes de teleprocessamento e dados. - IEEE Standards Association — Ethernet: 50 Years of Innovation
Contexto histórico da normalização Ethernet e do desenvolvimento do IEEE 802.3 durante os anos 1980. - IEEE Spectrum — Ethernet Is Still Going Strong After 50 Years
Retrospectiva histórica sobre o desenvolvimento do Ethernet e a sua normalização como IEEE 802.3. - Computer Conservation Society — The ICL-Fujitsu Technology Collaboration
Registo histórico da colaboração ICL-Fujitsu e da introdução da família de mainframes ICL Série 39 a partir de 1985. - CERN — A short history of the Web
História institucional do projecto WorldWideWeb: proposta inicial em 1989 e formalização do projecto em Novembro de 1990. - ICL Technical Journal — J. B. Brenner, "IPA Networking Architecture", Vol. 3, n.º 3, Maio de 1983 Descrição técnica da ICL Information Processing Architecture (IPA), concebida como arquitectura para interligação, interfuncionamento e gestão de redes, permitindo integrar sistemas e terminais através de redes públicas e privadas de telecomunicações.
Francisco Gonçalves
Fragmentos do Caos
FC-Chronic-News