3.8 Interoperabilidade e padrões abertos

Visão geral e motivação

A interoperabilidade é a capacidade de dois ou mais sistemas trocarem informações e usarem as informações trocadas, sem que nenhum dos lados precise conhecer o funcionamento interno do outro. Um padrão aberto é uma especificação publicamente disponível, desenvolvida e mantida por um processo transparente e baseado em consenso e livre (ou justa, razoável e não discriminatória) de implementar, de modo que qualquer pessoa possa construir um sistema conforme sem a permissão de um único fornecedor. Projetar para a interoperabilidade significa construir sistemas que se conectam por especificações compartilhadas e publicadas, e não por integrações sob medida: conectores personalizados e pontuais que ligam exatamente dois sistemas e precisam ser refeitos toda vez que um dos lados muda.

Para uma grande organização, a interoperabilidade não é um luxo. É o substrato sobre o qual tudo o mais roda. As empresas adquirem outras empresas, trocam de fornecedores e costuram dezenas de sistemas internos e de terceiros, e os padrões abertos são o que permite a um novo componente se encaixar sem reescrita. Para o governo as apostas são ainda maiores. Os serviços públicos são prestados por muitas agências, esferas de governo e fornecedores privados, e nenhum órgão controla todo o parque. Um cidadão que pede um benefício pode tocar sistemas de identidade, de impostos, de saúde e de assistência social pertencentes a departamentos diferentes. Esses sistemas precisam interoperar, ou o serviço falha. Os órgãos públicos também trocam de fornecedor em ciclos de contratação medidos em anos, então qualquer dependência das interfaces proprietárias de um único fornecedor se torna uma armadilha longa e cara.

O modo de falha recorrente é o oposto da interoperabilidade: o aprisionamento proprietário, em que os dados e processos de uma organização ficam tão emaranhados nos formatos e interfaces não padronizados de um fornecedor que trocar, integrar ou até ler os dados depois se torna proibitivamente caro. Os padrões abertos são a defesa principal. Este capítulo cobre os níveis em que os sistemas precisam interoperar, os padrões que o tornam possível e como projetar, contratar e certificar para isso. Ele se conecta de perto a APIs e design de interfaces (capítulo 2.3), sistemas distribuídos (capítulo 3.3), estratégia e governança de dados (capítulo 7.1), contratação e código aberto (capítulo 10.3) e conformidade e governança (capítulo 4.6).

Princípios fundamentais

A interoperabilidade é projetada desde o início, não remendada depois. Decida os padrões antes da construção, porque adaptá-los depois significa reescrever interfaces e migrar dados.
Prefira padrões abertos a integrações sob medida. Uma interface conforme serve a todo parceiro atual e futuro. Um conector personalizado serve exatamente a um.
A interoperabilidade tem níveis. Fazer os bytes atravessarem o fio (técnico) é inútil se os dois lados discordam sobre o que os bytes significam (semântico).
O significado vive em vocabulários compartilhados. Identificadores, sistemas de códigos e terminologias são o que torna os dados trocados utilizáveis, e não apenas transmissíveis.
Os padrões só são reais se você os cumpre. Uma afirmação de “suporta FHIR” sem teste de conformidade é marketing, não interoperabilidade.
O aprisionamento é uma decisão de custo total de propriedade. A opção proprietária barata de hoje costuma ser o parque preso e caro de amanhã.
O governo multiplica a necessidade. Os serviços públicos atravessam fronteiras organizacionais que ninguém controla, então os padrões abertos são frequentemente um mandato, não uma preferência.

Recomendações

Projete para os quatro níveis de interoperabilidade

O European Interoperability Framework e modelos relacionados descrevem quatro níveis, e um sistema precisa satisfazer todos eles para realmente interoperar. A interoperabilidade técnica é a tubulação: redes, protocolos e transporte (por exemplo HTTPS) que movem bytes entre sistemas. A interoperabilidade sintática é o acordo sobre estrutura e formato, a gramática da mensagem, como JSON (JavaScript Object Notation, um formato leve de dados em texto) ou XML (eXtensible Markup Language). A interoperabilidade semântica é o acordo sobre o significado: que um campo rotulado gender ou um código 250.00 significa a mesma coisa para as duas partes. A interoperabilidade organizacional é o alinhamento de processos, governança, papéis e acordos legais: quem pode enviar o quê a quem, sob qual acordo de compartilhamento de dados e para qual finalidade. A maioria dos projetos de integração acerta os dois primeiros níveis e fracassa no terceiro e no quarto. Trate a interoperabilidade semântica e a organizacional como trabalho de design de primeira classe, não como reflexão tardia.

Padronize a camada de troca de dados e de API

Adote padrões abertos e amplamente implementados para como os sistemas descrevem e expõem suas interfaces. Para APIs web (Application Programming Interfaces, o contrato definido pelo qual um sistema chama outro), use a OpenAPI Specification, uma descrição neutra em relação a fornecedores e legível por máquina de uma API REST (Representational State Transfer) que tanto documenta a interface quanto gera código de cliente, servidores, testes e dublês. Para os formatos de carga, prefira JSON por sua ubiquidade e legibilidade humana e use XML onde um ecossistema já se padroniza nele. Onde você precisar de comunicação de alto desempenho e fortemente tipada entre serviços, considere o gRPC (um framework de chamada remota de procedimentos) com Protocol Buffers (Protobuf), um formato binário compacto definido por esquema, que por sua vez é uma especificação aberta. O ponto não é a tecnologia específica. É que o contrato seja publicado, legível por máquina e implementável de forma independente. Veja o capítulo 2.3 para mais profundidade em design de interfaces.

Adote o padrão reconhecido do seu domínio

A maioria dos setores convergiu para padrões de interoperabilidade específicos do domínio. Use-os em vez de inventar os seus. A saúde é o principal exemplo. O HL7 (Health Level Seven, um órgão de padrões e seus padrões de mensagens mais antigos) foi em grande parte superado para trabalhos novos pelo FHIR (Fast Healthcare Interoperability Resources), um padrão moderno que modela conceitos clínicos (paciente, observação, medicamento) como recursos web trocados por APIs REST usando JSON ou XML. Nas finanças, a ISO 20022 é o padrão aberto para mensagens de pagamento e financeiras estruturadas e ricamente anotadas, hoje adotado por sistemas de pagamento no mundo todo. Nos dados geoespaciais, o OGC (Open Geospatial Consortium) publica padrões como WMS e WFS para serviços de mapas e de feições. Outros exemplos incluem OASIS e UBL para documentos de negócio e IFC (BuildingSMART) para a construção. Escolher o padrão reconhecido compra um ecossistema inteiro de ferramentas conformes, fornecedores e pessoal treinado.

Ancore o significado em identificadores, sistemas de códigos e ontologias

A interoperabilidade semântica exige vocabulários compartilhados. Use identificadores padrão para que a mesma coisa do mundo real tenha a mesma referência em todo lugar (por exemplo um código de país ISO, um LEI para uma pessoa jurídica ou um identificador nacional de paciente). Use sistemas de códigos e terminologias publicados (listas controladas de conceitos codificados com significados definidos) em vez de texto livre: SNOMED CT e LOINC para termos clínicos, CID (Classificação Internacional de Doenças, ICD) para diagnósticos, Unicode para texto. Onde as relações entre conceitos importam, use uma ontologia (um modelo formal e legível por máquina dos conceitos e de como se relacionam) expressa em padrões como RDF e OWL (a W3C Web Ontology Language). A governança desses vocabulários é uma responsabilidade de governança de dados. Veja o capítulo 7.1.

Integre por padrões baseados em normas, não por fiação ponto a ponto

Favoreça padrões arquiteturais que mantenham o número de integrações linear em vez de combinatório. N sistemas ligados ponto a ponto podem exigir até N×(N−1)/2 conectores sob medida. Os mesmos N sistemas, cada um conforme a um padrão compartilhado, exigem apenas N implementações desse padrão. Use gateways, contratos de API publicados e modelos canônicos de dados para que um novo participante se integre uma vez contra o padrão, em vez de contra cada sistema existente. Esse também é o antídoto contra o aprisionamento: como o contrato é aberto, um fornecedor pode ser substituído sem tocar em todos os conectados a ele.

Exija conformidade e certificação

Um padrão só entrega valor quando as implementações de fato o cumprem. Insista em testes de conformidade (verificações automatizadas de que uma implementação atende à especificação) usando suítes de testes e validadores publicados (por exemplo os validadores do FHIR e o teste Touchstone, ou a validação de esquema OpenAPI no seu pipeline de build). Onde existir um programa formal de certificação (um órgão independente atestando a conformidade, como nos esquemas nacionais de certificação de TI em saúde), prefira produtos certificados e exija a certificação nos contratos. Embuta verificações de conformidade na integração contínua, para que o desvio do padrão quebre o build em vez de aparecer em produção.

Compromissos: prós e contras

Abordagem	Prós	Contras / custo
Padrão aberto	Muitos fornecedores, sem aprisionamento, ferramentas do ecossistema, parceiros futuros se integram barato	O padrão pode ser amplo/complexo, adoção mais lenta de funcionalidades de nicho, evolução no ritmo de comitê
Integração ponto a ponto sob medida	Rápida para a primeira conexão, encaixe exato, mínimo aprendizado inicial	O custo cresce de forma combinatória, frágil, refeita a cada mudança, gera aprisionamento
Formato/API proprietário de fornecedor	Funcionalidades ricas, suporte do fornecedor, início rápido dentro de um ecossistema	Aprisionamento, custo de troca, dados difíceis de extrair depois, poder de preço passa ao fornecedor
Padrão de domínio (FHIR, ISO 20022)	Significado compartilhado, mão de obra treinada, alinhado aos reguladores	Curva de aprendizado, mapeamento de dados legados, custo de gestão de versões e perfis

A troca principal é a conveniência de curto prazo versus a opcionalidade de longo prazo. Uma integração sob medida ou proprietária é quase sempre mais rápida de montar para a primeira conexão, e é por isso que as organizações derivam para o aprisionamento uma decisão razoável de cada vez. Os padrões abertos antecipam o custo (aprender a especificação, mapear os dados existentes, construir testes de conformidade) e o devolvem toda vez que um novo parceiro, fornecedor ou sistema entra sem reescrita. Para um sistema de longa vida e com muitos participantes, o que descreve quase toda plataforma corporativa e governamental, o caminho baseado em padrões vence de forma decisiva. Para um vínculo individual genuinamente descartável, o sob medida pode ser racional. O erro é tratar plataformas de longa vida como se fossem vínculos descartáveis.

Perguntas para discutir com sua equipe

Quem é dono da interoperabilidade organizacional (os acordos de compartilhamento de dados, os modelos de consentimento e o alinhamento de processos) de que a sua integração técnica depende? A maioria dos projetos acerta os níveis técnico e sintático e emperra no organizacional: os bytes chegam e são interpretados, mas nenhum acordo rege quem pode enviar o quê a quem, para qual finalidade, sob qual consentimento. No governo, os dados de um cidadão cruzam agências que são donas de seus sistemas e respondem a bases legais diferentes, então uma interface FHIR perfeita é inútil até o acordo de compartilhamento e o modelo de consentimento existirem. Levem a troca entre fronteiras mais importante e nomeiem o instrumento legal e o responsável de cada lado, não só a API. Se esse responsável não tem nome, a integração passará em todos os testes técnicos e ainda assim ficará bloqueada em produção. Tratem esses acordos como artefatos de design com o mesmo rigor do esquema de mensagem.
Quanto vocês se apoiam nas extensões proprietárias de um padrão, e outra implementação conforme ainda conseguiria conversar com vocês? Os padrões incluem válvulas de escape, e abusar delas é aprisionamento de fato com um selo de aberto: vocês afirmam FHIR ou ISO 20022, mas nenhum fornecedor independente consegue de fato interoperar com o seu dialeto. Isso se infiltra uma customização razoável de cada vez, e é por isso que um grande parque deve medi-lo deliberadamente. Levem uma mensagem real e contem quanto do significado dela viaja em campos padrão versus extensões personalizadas. Quanto maior a parcela personalizada, mais fraca a portabilidade e mais forte o poder de preço do fornecedor incumbente. Prefiram criar perfis dentro das regras do padrão, e devolver as lacunas ao padrão, em vez de extensões privadas. O ponto inteiro do caminho aberto é que um fornecedor possa ser substituído sem tocar em todos os conectados, e as extensões o corroem em silêncio.
Em qual versão e perfil de cada padrão vocês estão, e quem governa essa escolha em todo o parque? “Suporta o padrão” não significa nada sem disciplina de versão e de perfil, porque dois sistemas podem ambos afirmar FHIR ou ISO 20022 e ainda assim não conseguir conversar se implementam versões ou perfis diferentes. Numa grande organização, com muitos fornecedores e ciclos longos de contratação, as versões se afastam em silêncio até uma integração quebrar. Levem um inventário de cada interface, seu padrão, sua versão e seu perfil e nomeiem quem é responsável por mantê-los alinhados e por planejar as atualizações. Embutam a versão e o perfil nos testes de conformidade do pipeline para que o desvio quebre o build em vez de aparecer em produção. Sem essa governança, sistemas nominalmente conformes ainda assim não interoperam, que é exatamente a falha que os padrões abertos deveriam prevenir.
Quando um contrato ou um fornecedor diz “suporta o padrão”, que teste independente de fato prova isso, e onde esse teste roda? Uma afirmação de conformidade sem teste por trás é marketing, e falha no pior lugar: em produção, depois que o dinheiro trocou de mãos e o sistema está no ar. Para uma grande organização que compra de muitos fornecedores, a tentação é aceitar uma caixa marcada num questionário, porque insistir em conformidade validada atrasa a contratação e estreita o grupo de licitantes. Levem o validador ou a suíte de testes publicados de cada padrão de que dependem (por exemplo os validadores FHIR e o Touchstone, ou a validação de esquema OpenAPI), uma amostra de mensagens reais passadas por ele e a cláusula do contrato que amarra aceitação e pagamento à aprovação nele. A atração concorrente é velocidade versus prova: um produto certificado pode custar mais e levar mais tempo para entrar, mas um não verificado transfere a falha para a sua equipe de integração. No governo e em contextos regulados, onde existem esquemas nacionais de certificação de TI em saúde ou de pagamentos, exijam a certificação no contrato e liguem o validador à integração contínua para que o desvio quebre o build, porque uma afirmação que vocês nunca testaram é um passivo que descobrirão numa auditoria ou numa queda.
Quantas das suas integrações ainda são ponto a ponto, e qual é o custo combinatório real de deixá-las assim? Os conectores individuais sob medida são a coisa mais rápida de construir para o primeiro vínculo e a mais cara de manter num parque, porque a contagem cresce rumo a N×(N−1)/2 enquanto um padrão compartilhado precisa de apenas N implementações. Numa grande organização esse espalhamento se acumula uma decisão razoável de cada vez até o mapa de integração ficar impossível de manter e cada mudança de sistema reverberar por uma dúzia de conectores frágeis. Levem um inventário das integrações classificadas como ponto a ponto versus baseadas em padrões, o número de conectores tocados pela última grande substituição de sistema e uma estimativa do tempo de engenharia gasto mantendo vínculos personalizados. A tensão é que migrar a fiação ponto a ponto em operação para trás de um gateway ou de um modelo canônico é trabalho real sem retorno imediato em funcionalidades, então perde para o roteiro a menos que alguém quantifique o custo de carregamento. Para plataformas corporativas e governamentais que vivem por décadas e acrescentam participantes continuamente, o caminho ponto a ponto é um imposto lento. Nomeiem um responsável pela arquitetura de integração e um plano para rotear os novos participantes pelo padrão em vez de contra cada incumbente.
Onde vocês estão transmitindo significado como texto livre que um sistema de códigos ou terminologia publicado deveria carregar, e quem governa esses vocabulários? A interoperabilidade semântica é onde a maioria das integrações falha em silêncio: os bytes chegam e são interpretados, mas um diagnóstico, uma moeda ou um país guardado como cadeia de texto sem restrição significa uma coisa para quem envia e algo sutilmente diferente para quem recebe. Para uma grande organização o custo é invisível até que um relatório, uma análise ou um regulador exponha que o mesmo conceito foi codificado de três maneiras em três sistemas. Levem exemplos de campos hoje mantidos como texto livre, os identificadores e sistemas de códigos padrão que poderiam substituí-los (SNOMED CT e LOINC para dados clínicos, códigos ISO para países e moedas, um LEI para pessoas jurídicas) e as taxas de erro ou o esforço de conciliação que o texto livre está escondendo. A consideração concorrente é que mapear dados legados para vocabulários controlados é trabalhoso e nunca é demonstrado, então é cronicamente subfinanciado em relação à camada de transporte. No governo, onde o registro de um cidadão é montado a partir de muitos sistemas independentes e um código não coincidente pode negar um benefício ou corromper um prontuário, tratem a governança de vocabulários como uma responsabilidade nomeada de governança de dados (capítulo 7.1), não um detalhe de implementação deixado a cada equipe.

Perspectiva por setor

Startup. A velocidade vence, e os padrões abertos são como uma equipe minúscula alcança muitos clientes sem construir muitos conectores. Fale os formatos que todo parceiro já suporta (OAuth para login, iCalendar para agendamento, webhooks para eventos, JSON sobre um contrato OpenAPI) para que uma integração alcance milhares de clientes e uma troca de fornecedor toque um único adaptador. Evite inventar o seu próprio formato ou ligar à mão a pilha de cada cliente. Isso é manutenção futura que você não consegue bancar. O caminho dos padrões custa um pouco mais no começo e mantém barata a troca num mercado que você ainda não consegue prever.

Pequena empresa. Sem especialistas em integração e com orçamento apertado, trate a interoperabilidade como uma decisão de compra e não como um projeto de construção. Prefira ferramentas que já falem o padrão aberto do seu setor e exponham uma API documentada, para que seus dados continuem portáveis se você trocar de fornecedor. Pergunte a um fornecedor em potencial como você tira seus dados e em que formato antes de assinar, porque a opção proprietária barata de hoje é o parque preso de amanhã. Você raramente rodará um teste de conformidade, então apoie-se em produtos certificados ou amplamente interoperáveis.

Grande empresa. O desafio é governar a interoperabilidade entre muitas equipes, fornecedores e ciclos longos de contratação. Torne obrigatório o padrão de domínio (FHIR, ISO 20022, OGC) e um contrato OpenAPI publicado, depois mantenha um inventário de cada interface com sua versão e perfil e um responsável, para que sistemas nominalmente conformes não se afastem. Roteie os novos participantes por gateways e modelos canônicos em vez de fiação ponto a ponto, ligue a validação de conformidade à integração contínua e meça quanto do seu tráfego viaja em campos padrão versus extensões proprietárias. Gerenciem o aprisionamento e a portabilidade como uma posição deliberada de custo total de propriedade, não um acidente.

Governo. Os padrões abertos são frequentemente um mandato, porque os serviços públicos atravessam agências que nenhum órgão controla e os fornecedores mudam em ciclos de vários anos. Exijam testes de conformidade e, onde existirem esquemas, a certificação nacional em todo contrato e demandem portabilidade de dados para que um fornecedor que sai não possa manter os dados do público como refém. Ancorem o significado em identificadores nacionais e terminologias publicadas para que o registro de um cidadão signifique a mesma coisa entre departamentos e tratem a interoperabilidade organizacional por acordos explícitos de compartilhamento de dados e modelos de consentimento com responsáveis nomeados. A transparência e o dinheiro público argumentam ambos pelo caminho aberto e implementável de forma independente em vez de qualquer conveniência proprietária.

Exemplos

Startup. Uma pequena startup que constrói um aplicativo de produtividade para equipes se conecta às ferramentas existentes dos clientes por padrões abertos e não por conectores sob medida: OAuth para login, iCalendar para agendamento e webhooks para eventos. Como fala formatos que todo provedor de calendário e de identidade já suporta, uma integração alcança milhares de clientes em vez de um e trocar depois um fornecedor de pagamento ou de e-mail toca um único adaptador. Se tivesse construído à mão um vínculo personalizado com a pilha de cada cliente, cada novo logotipo teria significado outro conector para escrever e manter.

Grande empresa. Um banco multinacional moderniza seus pagamentos internacionais migrando de um formato proprietário legado de mensagem para a ISO 20022. Como o padrão carrega dados estruturados e ricamente anotados (pagador, beneficiário, finalidade, campos regulatórios) e não texto livre, os sistemas a jusante de triagem de fraudes, conciliação e relatórios consomem um formato canônico em vez de uma dúzia de interpretadores sob medida. Quando o banco depois troca o fornecedor do seu gateway de pagamentos, o novo fornecedor já fala ISO 20022, então a troca toca o gateway e não os cem sistemas atrás dele. O padrão aberto converteu uma migração de fornecedor, de uma reconstrução de vários anos, numa substituição contida.

Governo. Um serviço nacional de saúde precisa que hospitais, clínicas, laboratórios e um aplicativo para pacientes (construídos por fornecedores diferentes ao longo de duas décadas) compartilhem prontuários com segurança. Ele torna obrigatório o FHIR para a troca de dados: cada sistema expõe dados de paciente, observação e medicamento como recursos FHIR sobre APIs REST, usando identificadores padrão (um ID nacional de paciente) e terminologias clínicas (SNOMED CT para condições, LOINC para resultados de laboratório) para que os códigos signifiquem a mesma coisa em todo lugar. Os fornecedores precisam passar na validação de conformidade FHIR e ter certificação nacional de TI em saúde antes de se conectar. Um novo sistema de clínica se integra uma vez contra o padrão FHIR em vez de construir vínculos sob medida com cada incumbente, e um cidadão pode ver um prontuário unificado montado a partir de muitos sistemas independentes. A interoperabilidade organizacional é tratada por acordos de compartilhamento de dados que regem quem pode acessar o quê e por quê, satisfazendo as obrigações de conformidade (capítulo 4.6).

Justificativa de negócio: motivações, ROI e TCO

O argumento financeiro para os padrões abertos é um argumento sobre o custo total de propriedade (TCO) ao longo da vida de um sistema, não sobre o preço de etiqueta da primeira integração. O custo da integração sob medida escala com o número de conexões e é pago de novo a cada mudança. O custo da integração baseada em padrões é pago uma vez por participante e amortizado em todo o parque. O retorno do investimento (ROI) aparece como menor mão de obra de integração, entrada mais rápida de novos parceiros e fornecedores, menores custos de troca quando fornecedores têm desempenho ruim e a prevenção do clássico imposto do aprisionamento, em que um fornecedor único sobe os preços porque nenhum concorrente consegue concorrer.

Para a liderança, enquadre o caso em torno da opcionalidade e da concorrência. Os padrões abertos mantêm a contratação competitiva (capítulo 10.3). Quando as interfaces são publicadas e testadas quanto à conformidade, vários fornecedores podem concorrer em pé de igualdade, o que derruba o preço e eleva a qualidade ao longo de contratos sucessivos. Eles também reduzem o risco do futuro, porque mudanças regulatórias, fusões e programas de modernização ficam todos mais baratos quando dados e interfaces são portáveis. O maior custo oculto de ignorar os padrões é a eventual migração forçada: extrair dados de um formato proprietário depois do fato, com o fornecedor original ausente ou pouco cooperativo, rotineiramente custa muitas vezes o que um design baseado em padrões teria custado no começo. Os governos reconhecem cada vez mais isso e tornam obrigatórios os padrões abertos justamente para proteger o erário do aprisionamento por décadas.

Antipadrões e armadilhas

Interoperabilidade técnica confundida com o trabalho todo. A mensagem chega e é interpretada, mas os dois lados discordam sobre o que um campo significa, e então os dados ficam errados em silêncio.
“Baseado em padrões” só no nome. Um produto afirma suportar um padrão mas nunca passou em teste de conformidade e diverge na prática.
Texto livre onde existe um sistema de códigos. Guardar diagnósticos, moedas ou países como cadeias sem restrição destrói a interoperabilidade semântica.
Extensões proprietárias que engolem o padrão. Usar as válvulas de escape de um padrão tão pesadamente que nenhuma outra implementação consegue interoperar: aprisionamento de fato com um selo de aberto.
Espalhamento ponto a ponto. Acrescentar mais um conector sob medida a cada vez, até o mapa de integração virar uma bagunça combinatória impossível de manter.
Caos de versões e perfis. Nenhuma governança sobre qual versão ou perfil de um padrão está em uso, de modo que sistemas nominalmente conformes ainda não conseguem conversar.
Ignorar a interoperabilidade organizacional. Uma troca técnica perfeita bloqueada porque não existe acordo de compartilhamento de dados, modelo de consentimento nem alinhamento de processos.
Construir o seu próprio padrão. Inventar um formato sob medida quando já existe um padrão de domínio maduro e adotado, herdando toda a sua manutenção para sempre.

Modelo de maturidade

Nível 1: Iniciar. A integração é ad hoc e ponto a ponto. Os formatos são proprietários ou não documentados. O significado é transmitido por texto livre e conhecimento tribal. Substituir qualquer sistema ou fornecedor é um grande projeto. O aprisionamento é generalizado e em boa parte não reconhecido.
Nível 2: Desenvolver. Formatos comuns como JSON ou XML aparecem e algumas APIs são documentadas, mas a prática varia de equipe para equipe. A interoperabilidade ainda é em sua maior parte sintática. O acordo semântico é inconsistente e por projeto. Os padrões são escolhidos de forma reativa, e a conformidade é afirmada mas não testada.
Nível 3: Padronizar. Os padrões abertos de troca de dados (OpenAPI e o padrão de domínio relevante, como FHIR ou ISO 20022) são documentados e obrigatórios em toda a organização. Identificadores, sistemas de códigos e terminologias compartilhados provêm a interoperabilidade semântica. O teste de conformidade faz parte do pipeline de entrega, e a integração segue padrões baseados em normas e não fiação ponto a ponto.
Nível 4: Gerenciar. A interoperabilidade é medida e controlada em relação a linhas de base. Métricas são acompanhadas e revisadas: a parcela de integrações baseadas em padrões versus ponto a ponto, a proporção do significado das mensagens que viaja em campos padrão versus extensões proprietárias, as taxas de aprovação nos testes de conformidade do pipeline, o desvio de versões e perfis no parque e o prazo de integração e as taxas de defeitos ao receber um novo participante. As versões e os perfis são governados, a certificação é exigida dos fornecedores e verificada, e o risco de aprisionamento é quantificado e não apenas sentido. As decisões de adotar, atualizar ou aposentar uma interface são tomadas com base nessa evidência.
Nível 5: Orquestrar. A interoperabilidade é continuamente melhorada e integrada em toda a organização. A interoperabilidade organizacional (acordos, consentimento, alinhamento de processos) é tratada de forma sistemática ao lado das camadas técnicas, a organização contribui de volta com os padrões de que depende e a portabilidade é uma restrição permanente de design. O parque se adapta à medida que os padrões evoluem e os participantes entram ou saem, reequilibrando a arquitetura de integração e a governança de vocabulários sobre a evidência medida e não sobre o incidente.

Ideias para discussão

Para a sua troca de dados mais crítica, em qual dos quatro níveis (técnico, sintático, semântico, organizacional) ela está mais fraca hoje?
Se o seu fornecedor principal dobrasse o preço na renovação, quanto tempo e quanto dinheiro custaria trocar, e o que torna isso assim?
Quais das suas integrações são ponto a ponto, e o que seria preciso para movê-las para trás de um padrão aberto compartilhado?
Onde vocês estão guardando texto livre que um sistema de códigos ou terminologia publicado poderia substituir, e que erros o texto livre esconde?
O “suporta o padrão” nos seus contratos exige passar num teste independente de conformidade ou de certificação, ou é meramente afirmado?
Quais mandatos de padrões abertos (nacionais ou setoriais) já se aplicam a vocês, e vocês de fato os cumprem ou apenas dizem que cumprem?

Principais conclusões

Interoperabilidade significa usar a informação trocada, não apenas transmiti-la. Projete para os quatro níveis: técnico, sintático, semântico e organizacional.
Prefira padrões abertos, publicados e implementáveis de forma independente a integrações sob medida e formatos proprietários, que geram aprisionamento e custo combinatório.
Padronize a camada de API e de troca de dados (OpenAPI, JSON/XML, gRPC/Protobuf) e adote o padrão reconhecido do seu domínio (FHIR na saúde, ISO 20022 nas finanças, OGC no geoespacial).
Ancore o significado em identificadores, sistemas de códigos, terminologias e ontologias compartilhados. A interoperabilidade semântica é onde a maioria das integrações falha em silêncio.
Exija testes de conformidade e, onde houver, certificação. Um padrão só é real quando as implementações demonstravelmente o cumprem.
Julgue a escolha pelo custo total de propriedade e pela opcionalidade ao longo da vida do sistema. Para plataformas de longa vida e com várias partes (quase todos os sistemas corporativos e governamentais), os padrões abertos vencem, e o governo cada vez mais os torna obrigatórios.

Referências e leitura complementar

HL7 International, FHIR (Fast Healthcare Interoperability Resources) specification (hl7.org/fhir)
ISO 20022, Universal financial industry message scheme (iso20022.org)
OpenAPI Initiative, OpenAPI Specification (Linux Foundation)
Open Geospatial Consortium (OGC) standards (WMS, WFS, and successors)
European Commission, European Interoperability Framework (EIF) and the Interoperable Europe Act
UK Government, Open Standards Principles and the Technology Code of Practice (GOV.UK)
W3C, RDF, OWL (Web Ontology Language), and semantic-web standards
SNOMED International (SNOMED CT), Regenstrief Institute (LOINC), and WHO (ICD) terminologies
gRPC and Protocol Buffers specifications (Cloud Native Computing Foundation / open source)
NIST and IEEE literature on systems interoperability and conformance testing