o que diabos é um NGOSS? Eu usei muito o termo, relacionado ao” contrato NGOSS”, mas para aqueles que não estão familiarizados com o espaço OSS/BSS ou o TMF, pode ser misterioso. A Tata Consultancy Services, uma grande e ativa empresa de serviços profissionais, recentemente fez um artigo sobre” reimaginar ” o OSS/BSS, um artigo da TMF perguntando se há vida além dos serviços de conectividade. Existem contrastes e semelhanças interessantes entre os dois documentos, vale a pena explorar.
NGOSS significa “Next-Generation Operations Support System”. É um termo que tem sido amplamente utilizado por pelo menos 15 anos, e é frequentemente usado pelo TMF em suas especificações. Muitas das coisas do TMF são apenas membros, e então não posso citá-lo (ou, se não for um membro na época, não posso nem acessá-lo), exceto resumindo. O artigo da TMF é particularmente útil por causa disso; é um resumo público da maneira como o corpo vê o futuro da “transformação”. O artigo da Tata é interessante porque reflete uma visão profissional-serviços do mesmo processo de transformação.
a abertura do papel Tata tem as platitudes usuais sobre a largura de banda. “À medida que as empresas se adaptam cada vez mais a um modelo predominantemente online em linha com a nova realidade, a necessidade de alta largura de banda e serviços de rede confiáveis está aumentando. Consequentemente, os provedores de serviços de comunicação (CSPs) estão experimentando uma demanda exponencial por serviços e dependem do progresso nas tecnologias de virtualização para continuar escalando a taxas atuais.”
o problema com isso, além de seu status de platitude (mais uma declaração de demanda “exponencial” e vou vomitar), é que a questão real não é o crescimento da demanda, é o encolhimento do lucro. Nenhum operador ficaria insatisfeito com o crescimento da demanda por largura de banda, se pudesse cobrar incrementalmente pelo crescimento. Eles não podem, então eles precisam encontrar algo diferente de largura de banda para vender ou reduzir o custo de produção de largura de banda para compensar o fato de que Serviços de largura de banda mais altos não geram preços proporcionalmente mais altos.
este mesmo problema colore a próxima seção, que é chamada de “repensar a função OSS”. Ele cita os objetivos da TMF para a modernização do OSS, nenhum dos quais implica lidar com esse problema de compressão de lucro. Na verdade, essa seção do documento é por isso que muitos estrategistas de operadores são a favor de desmantelar toda a coisa OSS/BSS e começar de novo. Não é que nenhuma meta útil seja definida (a automação é um dos atributos de um futuro OSS/BSS), mas que nada é dito sobre alcançá-los.
que vem na próxima seção, que é chamada de “dirigir funções oss bem orquestradas”. Esta seção finalmente faz uma recomendação útil; OSS/BSS deve ser orientado a eventos. Eu tinha esperanças aqui, porque o TMF era de fato a fonte do conceito—chave em Oss e automação de operações-que NGOSS contrato que mencionei no início deste blog. Infelizmente, nem o termo nem o conceito são levantados no artigo da Tata. O que diz é que “as futuras funções OSS devem ser criadas e oferecidas como serviços compostos por microsserviços para suportar a orquestração automatizada de ponta a ponta de recursos de rede híbridos (físicos, lógicos e virtuais).”
o artigo da TMF, em contraste, abre com a afirmação de que “a conectividade é corretamente vista como um negócio de baixa margem e está rapidamente comoditizando ainda mais.”O objetivo das operadoras é” acertar seu mundo interior com uma base tecnológica ágil e um modelo operacional.”O TMF obviamente inclui seu principal alvo OSS / BSS neste mundo interior, mas, obviamente, a agile technology foundation tem que se estender à infraestrutura.
O mecanismo de obtenção de seu “mundo interior, a fim de” é, por implicação, 5G. O TMF diz que é fundamental, a fim de “fazer a maior parte dos extremamente dispendiosa e shift para 5G.” Mas que parece estar em contradição com o parágrafo seguinte, quando o ex-CEO do fórum diz que “Para os consumidores e casa inteligente indivíduos, ‘conectividade’, tende a ter um valor intrínseco e é válido coisa para estar comprando. À medida que você aumenta a escala, no entanto, no Reino da transformação do setor, a conectividade só é valorizada na medida em que está vinculada à solução: “eles não querem comprar conectividade de você, eles querem comprar uma solução.”O 5G é claramente uma estratégia de conectividade para os consumidores, como é toda a infraestrutura do mercado de massa. Se presumirmos que “subir a escala para o reino da transformação da indústria”, ou seja, Serviços de negócios, a chave é vender soluções.
isso parece argumentar para que os operadores concentrem seus negócios de “Provedor de serviços digitais” nas empresas e forneçam soluções para que haja um provedor de SaaS. Essa é realmente uma abordagem inteligente, já que há um negócio de nuvem pública altamente ativo e competitivo que já vende soluções para esses clientes? Especialmente quando a maioria dos problemas de lucro por bit que os operadores têm vem de serviços ao consumidor all-you-can-eat?A resolução, diz uma citação da Vodafone e outros comentários no artigo da TMF, é que ” o que agora chamamos de ‘serviços’ não envolverá apenas a telco, mas compreenderá uma série de parceiros, incluindo as telcos.”Assim, as telcos não são realmente provedores de serviços digitais, mas integradores ou Revendedores de serviços digitais. Uma empresa que está olhando para a transformação como um meio de escapar do aperto de lucro pode se dar ao luxo de ser um revendedor dos serviços de outro jogador?Parece-me que a visão da TMF não está realmente mirando além do OSS / BSS, mas sim sugerindo que as operações e os Serviços evoluem para algo acima da conectividade, fazendo parceria com aqueles que fornecem serviços lá em cima. Isso poderia estar derrotando todo o propósito da” transformação digital”, travando as telcos não apenas em seu nível atual de desintermediação e comoditização, mas também em um nível totalmente novo.Ambos os artigos parecem sugerir que a transformação OSS / BSS é essencial e, pelo menos, implica que uma abordagem orientada a eventos é a resposta. Isso é realmente uma boa ideia, mas perde o desafio de ” como? Para ser orientado a eventos, um sistema tem que reconhecer tanto o conceito de eventos (obviamente) quanto o conceito de “estado” ou contexto. Qualquer pessoa que já olhou para um manipulador de Protocolo sabe que a mesma mensagem, em diferentes contextos/estados, tem que ser processada de forma diferente. Por exemplo, receber uma mensagem de “pacote de dados” no estado “ordenável” para um serviço é claramente um erro, enquanto está tudo bem no estado “transferência de dados”. Para que haja estados e eventos e processos relacionados, você precisa de uma tabela de Estado/evento.
tabelas de Estado/evento são descrições dos contextos coletivos de um sistema cooperativo, e pensar em construí-los é útil na medida em que força os arquitetos de software a considerar todas as possibilidades, em vez de ter algo acontecer que cai pelas rachaduras. No entanto, há um conflito potencial entre o valor das tabelas de Estado/Evento e o número de estados e eventos possíveis. Se você olhar para uma rede complexa como um sistema enorme e plano, você teria uma mesa muito grande para implementar. O TMF e meu próprio trabalho ExperiaSphere lidaram com isso dividindo sistemas complexos em “modelos de intenção” que cada um tinha suas próprias relações de Estado/evento. Composição hierárquica, em suma. Isso é o que NGOSS Contract descreveu.
o ponto aqui é que ambos os artigos perdem o que deve ser seu próprio ponto mais forte, que é que a direção de eventos orientada por modelo de dados para processos por meio de tabelas de Estado/evento alinhadas a componentes é a maneira de criar um comportamento orientado a eventos e um design compatível com microsserviços. Se um modelo de dados de serviço conduz um evento a um processo, o processo pode obter as informações de que precisa apenas do modelo de dados de serviço, o que significa que ele não tem estado e pode ser implantado como um microsserviço ou mesmo em forma sem servidor.
se você retirar a abordagem de contrato NGOSS da história de modernização OSS / BSS, ficará com a coisa que atormentou toda a noção de modernização OSS/BSS desde as primeiras platitudes. Podemos falar de baixo para cima e de cima para baixo, desde que estejamos nos concentrando em metodologias de projeto, mas uma metodologia de projeto impulsiona um projeto, ele não escreve software. Uma arquitetura de software deve emergir da metodologia. Esse é um elemento separado, resultado do processo certo, mas não é a consequência automática de acenar com uma varinha sobre um monte de dados e cantar “de cima para baixo, de cima para baixo!”
isso resume meu problema com o papel Tata. As metodologias de projeto em TI e rede levam a arquiteturas de aplicativos ou serviços, que então enquadram os requisitos para os Componentes da solução e a maneira como eles são integrados e gerenciados. O projeto não é a saída, é o caminho para a saída. O problema com o artigo da Tata é que é mais uma descrição de uma metodologia de projeto (boa, mas não transformadora), em um momento em que já estamos procurando um caminho para a modernização do OSS e, em vez disso, estamos procurando produtos específicos, ou pelo menos arquiteturas. O TMF parece estar indo para o mesmo lugar por um caminho diferente—transformar por parceria com seus antigos inimigos.
o artigo da Tata faz, na seção chamada “o papel dos padrões da indústria”, chamar um problema importante, tão importante que pode realmente ser a barreira para o progresso em direção à meta de modernização do OSS. O artigo cita os modelos TMF e ONF para design de cima para baixo, mas ao longo do artigo está claro que o OSS/BSS “modernizado” precisa ser mais integrado ao resto do ecossistema de rede e serviços. Temos padrões para todas as partes possíveis de todas as estratégias de rede possíveis e, em alguns casos, os padrões até competem. Recentemente, ouvimos aplausos pela Unificação de duas especificações de API de operações diferentes, por exemplo. Devíamos perguntar-nos como os viemos ter em primeiro lugar.
o artigo TMF parece não apenas aceitar essa fragmentação do futuro, mas depender dela. Ceda a mecanização de coisas além do OSS / BSS e concentre-se em aproveitar essas coisas “além” para criar serviços como um pseudo-integrador. OK, isso pode não ser uma visão irracional para o TMF (um corpo dominado pelo OSS/BSS), mas é uma fórmula para se manter desorganizado enquanto enfrenta o que quase precisa ser uma iniciativa unificada-transformação.
é minha opinião que o TMF foi o corpo lógico para modernizar o OSS/BSS, e que o TMF fez (com contrato NGOSS) conceber o paradigma central de direção de eventos para processos através de um modelo de dados, que é fundamental para esta modernização. Todo o resto que os artigos descrevem, toda API que alguém está desenvolvendo ou harmonizando, toda atividade de padrões voltada para qualquer aspecto das operações e gerenciamento, deve se encaixar nessa estrutura de contrato NGOSS. Se isso fosse feito, o resultado seria exatamente o que “NGOSS” representa.
o modelo do contrato TMF NGOSS é igualmente valioso, ou ainda mais valioso, se você entrar no domínio da rede. Um verdadeiro processo de Estado / evento de “contrato” pode gerenciar tudo sobre o ciclo de vida do Serviço, incluindo a parte da rede. Segue-se que uma solução centrada na rede pode ser facilmente estendida para o serviço, o OSS/BSS, domínio. A universalidade da abordagem é boa para a indústria, porque a automação do ciclo de vida do serviço deve ser universal para ser útil.
também deve ser baseado no pensamento de nuvem de última geração. Ambos os artigos parecem concordar com isso, e ainda assim ambos contornam a questão de como fazer isso. Se você está planejando usar ferramentas atuais para realizar algo, você tem que enquadrar sua abordagem em termos dessas ferramentas. Você não pode aceitar a noção de que pode escrever especificações para tudo ou simplesmente traduzir metas na parte superior para recursos arbitrários na parte inferior. Isso é especialmente provável de mordê-lo, uma vez que os processos de padrões levam anos para chegar a uma conclusão. Estamos implantando o 5G hoje e os padrões não estão concluídos, e provavelmente não serão até 2022. Eu me pergunto se há tempo para essas coisas, dado que os operadores já estão enfrentando problemas de infraestrutura que estão se aproximando do ponto crítico.
o contrato NGOSS existe há cerca de 13 anos, e o TMF me disse uma vez que ganhou tração muito limitada. Não parece ser jogado no material TMF atual, embora, como eu disse, Eu não tenha acesso às coisas apenas para membros. A questão, então, é se o TMF está preparado para promover sua própria visão (deslumbrante e única), primeiro dentro do Estreito domínio OSS/BSS e depois na missão mais ampla de automação do ciclo de vida. Se isso acontecer, o TMF assume seu papel legítimo na evolução do NGOSS e define a base para a automação do ciclo de vida do serviço em geral. Caso contrário, caberá a algum outro órgão de padrões ou grupo de código aberto pegar a tocha, e o TMF terá que lutar por relevância em seu próprio espaço.
