Compartilhe esta publicação
Por que nem todos os projetos do IAM cruzam a linha de chegada
Este livro aponta cinco principais deficiências em como as estimativas são feitas:
Técnicas de estimativa são pouco desenvolvidas. Mas elas refletem uma suposição não dita que é completamente improcedente, ou seja, que tudo correrá bem.
As técnicas de estimativa enganosamente confundem esforço com progresso, ocultando a suposição de que homens e meses são intercambiáveis.
Como não temos certeza sobre nossas estimativas, os gerentes de software geralmente não têm a cortês teimosa dos demais.
O progresso do cronograma é mal monitorado.
Quando o deslize da programação é reconhecido, a resposta natural (e tradicional) é adicionar mão de obra.
Em muitos casos em que os projetos falham, a culpa recai sobre as estimativas e o gerenciamento de deles.
Gostaria de apresentar uma visão diferente. Embora minha discussão esteja relacionada principalmente a projetos do IAM, acredito que alguns deles são igualmente aplicáveis a todos os projetos de software.
Aqui, compartilharei minha experiência e visões sobre o motivo pelo qual nem todo os projetos IAM cruzam a linha de chegada com êxito.
RFPs/RFIs “tudo o que você puder obter”
Um RFI (Request For Information/Solicitação de Proposta), é um meio formal de obter informações gerais de provedores, enquanto um RFP (Request For Proposal/Solicitação de Informação) é uma maneira altamente formal e estruturada de obter informações específicas do provedor.
As RFPs/RFIs são feitas no estágio inicial de um projeto e, provavelmente, as pessoas que as escrevem não sabem exatamente o que precisam, então escolhem o caminho mais seguro ou mais fácil.
Eles sabem que precisam de um projeto IAM, por isso procuram alguns produtos no mercado, copiam a lista de recursos conforme os requisitos e publicam como uma RFI/RFP.
Isso cobrirá mais do que o necessário e, finalmente, terminará com um "RFP/RFI tudo o que você puder obter”.
No entanto, existem respostas entre sim e não. Durante o processo de avaliação de uma RFP/RFI, o que mais importa é a quantidade de “sim”. Um provedor com o maior número de "sim" passará pela primeira rodada de seleção.
O problema está nos detalhes, quando você começa a olhar para a coluna "comentários".
Você pode ter perdido facilmente sua correspondência perfeita durante a avaliação, pois inundou a RFP/RFI com requisitos irreais e acabará comprando um produto de um provedor a um preço muito alto.
Não digo que devemos eliminar completamente as RFPs/RFIs, mas produzir RFP/RFI no estilo “tudo o que você puder obter" não é o caminho certo para iniciar o seu projeto IAM.
Decisões Desconectadas/Política Interna
Há alguns anos, na WSO2, trabalhamos com um grande instituto financeiro nos EUA para construir uma plataforma unificada de controle de acesso em toda a empresa.
Eles tinham mais de 70 equipes e cada uma desenvolveu seu próprio modo de controlar o acesso.
Alguns usaram um banco de dados para armazenar regras de controle de acesso em seus próprios esquemas, enquanto outros apenas os codificaram no código do aplicativo.
Outra empresa com quem conversei estava lutando por mais de dois anos para iniciar sua IAM.
Nesse caso em particular, o principal desafio era criar um modelo de identidade unificada em todos os aplicativos.
Eles tinham mais de 30 armazenamentos de identidades usados por vários aplicativos e o mesmo usuário foi duplicado em cada armazenamento de identidades sem nenhum identificador de correlação.
É um problema bastante viável para resolver tecnicamente, mas primeiro, cada departamento deve esclarecer como eles devem proceder.
Estas não são histórias isoladas. À medida que uma organização cresce, a melhor abordagem seria ter equipes funcionais pequenas.
Esse modelo de capacitar cada unidade de negócios para tomar suas próprias decisões ajuda as organizações a avançar rapidamente, sem esperar para construir uma solução completa para toda a empresa.
Semeie o que se pode colher logo
Graham Williamson destaca em seu último livro, “Identity Management: Uma perspectiva de negócios”, que em muitos casos os gerentes de negócios não estão cientes das mudanças na tecnologia que podem ser aplicadas em pequenas organizações.
A evolução dos sistemas de gerenciamento de identidades baseados na nuvem e muitos produtos de gerenciamento de identidades de software de código aberto reduziram imensamente o custo das iniciativas de IAM.
A necessidade de milhões de dólares para "grandes" nomes não é mais necessária. Na WSO2, construímos um produto IAM de código-fonte completamente aberto e fornecemos suporte à produção.
Esse é o modelo de negócios que a maioria dos negócios de software de código aberto segue.
Qual é o desafio então? Como Graham destacou, muitos gerentes não entendem essa mudança que aconteceu no domínio do IAM e relutam em pensar nele como uma função que terá um impacto.
A resistência em investir em iniciativas IAM, e tentar mantê-las sob um orçamento baixo, impede que qualquer pessoa aproveite os benefícios dela e prepara o caminho para outra iniciativa IAM malsucedida.
Construir sua própria solução IAM
Existem algumas razões pelas quais algumas empresas preferem uma solução IAM doméstica a um produto desenvolvido pelo provedor: orçamento limitado, requisitos complexos, controle sobre o código e razões históricas.
Eu não digo que as soluções de IAM domésticas são sempre ruins. No entanto, nem todas as empresas preferem criar sua própria solução de IAM para manter o controle sobre o código.
Você não deve tentar criar uma solução de IAM caseira internamente se não tiver o nível adequado de conhecimento.
A infraestrutura do IAM é a parte mais sensível do seu negócio. Um sequestro de conta pode resultar em falência para sua empresa.
Se sua organização é pequena, pode se concentrar mais no que pode fazer melhor, delegando o gerenciamento da infraestrutura do IAM a um provedor que seja especialista nesse domínio.
Não são apenas as pequenas empresas que terceirizam a infraestrutura do IAM para provedores externos, até mesmo as maiores preferem fazê-lo.
Apaixonados por jargões
Há vários anos, SOA (arquitetura orientada a serviços) e ESB (enterprise service bus - barramento de serviços corporativos) eram os jargões mais populares. Todos queriam ter um SOA ou um ESB.
Com os avanços, ambos os jargões se desvaneceram de forma incremental, e tem vida útil de Microservices e API Gateway. O que impulsiona o seu negócio é o que você precisa e não são os jargões.
O cisne verde
Os padrões de identidade não nascem sozinhos.
Depois de definir seu problema, você deve gastar algum tempo pesquisando o padrão de identidade para ajudá-lo a criar uma solução.
Mais uma vez, não seja guiado pelos padrões, mas por sua própria declaração de problema. Há sempre espaço para melhorias.
Se você não achar que seu problema está sendo resolvido corretamente, não hesite em criar a solução. É assim que os padrões de identidade evoluíram ao longo dos anos.
Você encontrará pessoas em algumas equipes de projeto que odeiam os padrões.
Eles simplesmente encontrarão algum artigo ou blog que declare que um determinado padrão não está seguro o suficiente ou morto, e farão lobby com essa ideia para toda a equipe, sem nenhuma descoberta profunda dos fatos.
Essas pessoas são os “cisnes verde”, que não gostam de padrões e modelos e decidem começar a reconstruir tudo do zero, consequentemente, acabam perdendo todos os prazos planejados.
Visão curta
Os projetos do IAM falham em diferentes estágios: alguns na fase inicial, alguns desaparecem lentamente, mas quando o isso acontece, eles derrubam todo o negócio.
A escalabilidade de uma infraestrutura IAM é fundamental para o sucesso de qualquer projeto.
Antes de avaliar qualquer projeto do IAM, você deve ter uma ideia sobre a carga que você espera hoje, bem como o que você esperaria em 6 a 12 meses.
Outras coisas com as quais você precisa se preocupar são o número de solicitações e de sessões de login simultâneas e o número de usuários.
Para qualquer projeto IAM, a extensibilidade do produto subjacente é extremamente importante. Se você observar os últimos cinco anos do setor de IAM, descobrirá a velocidade com que está evoluindo.
Construção/Operação em Silos
Pessoas em diferentes departamentos frequentemente fazem suas próprias tarefas, levando a silos operacionais. No entanto, a verdadeira vantagem para o negócio vem da vinculação dessas diferentes atividades.
Por exemplo, a Nike, como parte de sua iniciativa de transformação digital, criou a Nike Digital Sports em 2010 para fornecer coordenação, inovação e alguns recursos compartilhados para os muitos esforços digitais da empresa.
Muitas empresas armazenam dados de clientes em diferentes fontes de dados, possivelmente gerenciados por diferentes departamentos.
Uma vez que as coisas estão desconectadas, mesmo que o projeto individual possa ser bem-sucedido, ainda como um todo, ele falhará, pois será uma operação muito cara construir um perfil unificado de um determinado lead ou cliente.
Uma iniciativa com a qual você deve se preocupar em tais casos e que também agregará mais valor à empresa é o CIAM (Gerenciamento de Identidades e Controle de Acesso de Clientes).
O sistema tem a oportunidade de vincular todas as preferências rastreadas contra o usuário anônimo com o novo lead.
Com o tempo, as preferências do lead podem ser rastreadas de maneira mais significativa e a equipe de marketing/vendas da empresa pode trabalhar de maneira colaborativa para torná-lo um cliente.
Nesse ponto, você coleta os dados mais confiáveis sobre o cliente, com a devida verificação. Então, a partir daí, o sistema CIAM continuará monitorando as preferências do cliente para produzir dados mais significativos, permitindo que a administração da empresa tome decisões mais informadas.
Ter uma visão da iniciativa do IAM da empresa é extremamente importante. Depois de ter uma visão, você pode orientar cada departamento a alcançar o que precisa ser feito para que tudo possa ser integrado para gerar mais valor para a empresa.
Bloqueio do provedor
Você não experimentará o bloqueio de provedor no curto prazo, mas, no longo prazo, quando começar a construir sua infraestrutura de IAM sobre um produto de provedor, você ficará cada vez mais dependente.
Algumas empresas não apenas desenvolvem extensões para seus produtos IAM, mas também criam toda a pilha de aplicativos com base em APIs de provedores. Mais uma vez, isso é resultado de gerenciamento e engenharia de projeto míopes.
Dados de aplicativos também podem levar ao bloqueio. Isso pode acontecer principalmente com provedores de IAM baseados na nuvem.
Mesmo que esses provedores de IAM na nuvem suportem a exportação de dados, será difícil e caro criar ferramentas para interpretá-los e torná-los significativos e funcionais.
O bloqueio de provedores é um dos motivos pelos quais se deve prestar mais atenção aos padrões abertos e de software de código aberto.
Você deve sempre tentar manter padrões abertos entre seus aplicativos e o produto IAM.
Caso você tenha escrito um código em uma API de produto não padrão, primeiro desenvolva um wrapper do lado do seu aplicativo para garantir que o aplicativo não esteja atrelado demais à API do produto do IAM.
Se você decidir usar outro produto IAM algum dia, só precisará alterar o wrapper. Esta será uma opção menos onerosa.
Texto adaptado do artigo original escrito por Prabath Siriwardena, Senior Director - Security Architecture da WSO2. Você pode visualizá-lo aqui.
Este artigo foi escrito por Daniel Gonçalves e publicado originalmente em Prensa.li.