Por que nem todos os projetos do IAM cruzam a linha de chegada

De acordo com um estudo realizado pela KPMG em 2009, 75% dos projetos do IAM oferecem menos que o esperado. Em um estudo conduzido pela McKinsey & Company em conjunto com a Universidade de Oxford, 17% dos grandes projetos de TI têm um desempenho tão baixo que podem ameaçar a própria existência da empresa. Este estudo utilizou uma amostra de 5.400 projetos de TI de grande escala (projetos com orçamentos iniciais maiores que US $ 15 milhões). Na maioria das vezes, para muitas das falhas de projeto de software, as estimativas precárias são as culpadas. De acordo com o livro The Mythical Man Month-Month de Frederick P. Brooks Jr., mais projetos de software deram errado por falta de tempo do que todas as outras causas combinadas. Este livro aponta cinco principais deficiências em como as estimativas são feitas:

1. Técnicas de estimativa são pouco desenvolvidas. Mais seriamente, elas refletem uma suposição não dita que é completamente improcedente, ou seja, que tudo correrá bem.
2. As técnicas de estimativa enganosamente confundem esforço com progresso, ocultando a suposição de que homens e meses são intercambiáveis.
3. Como não temos certeza sobre nossas estimativas, os gerentes de software geralmente não têm a cortês teimosa dos demais.
4. O progresso do cronograma é mal monitorado.
5. Quando o deslize da programação é reconhecido, a resposta natural (e tradicional) é adicionar mão de obra.

Eu não discordo que as estimativas desempenham um papel fundamental em um projeto de software bem-sucedido. Em muitos casos em que você procura no Google por que os projetos de software falham, a culpa recai sobre as estimativas e o gerenciamento de projetos. Eu 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. Desde que entrei na WSO2, há mais de dez anos, tive a oportunidade de conversar com muitos clientes – muitos de empresas da Fortune 100. Uma coisa que aprecio em meu trabalho diário na WSO2 (e na minha vida) é toda oportunidade que tenho de falar com um cliente. Ouvir os clientes ajuda você a entender suas dificuldades, expectativas e desafios. Nem todo mundo com quem falo se torna um cliente da WSO2, mas eles me deixam com algo para pensar. 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” 

Como empresa de produtos, recebemos muitas RFPs/RFIs e concluí pessoalmente algumas delas. 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, possivelmente incluindo preços. Uma RFI faz perguntas gerais, enquanto uma RFP faz perguntas mais específicas. De qualquer forma, a maioria das RFIs/RFPs é preenchida com toneladas de perguntas!

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 (possivelmente de um conjunto de provedores bem estabelecidos), copiam a lista de recursos conforme os requisitos e publicam como uma RFI/RFP. Isso cobrirá mais do que o necessário – alguns recursos nunca serão usados – e, finalmente, terminará com um "RFP/RFI tudo o que você puder obter”.

A maioria das RFPs/RFIs apresenta perguntas sim/não simples com uma coluna de "comentários". No entanto, "nem tudo no mundo real não é Booleano o tempo todo" Existem respostas entre sim e não. Durante o processo de avaliação de uma RFP/RFI, o que mais importa é o número 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, finalmente, acabará comprando um produto de um provedor a um preço muito alto. Somente após alguns meses ou um ano depois, durante a renovação da licença/assinatura, você descobrirá o quanto a mais paga por um conjunto de recursos inativos no rack do servidor.

Há uma parte mais assustadora. Como cada pergunta não contém uma resposta booleana, algumas podem dizer "não" e, na coluna "Comentários", explicar como as coisas podem ser feitas, provavelmente escrevendo algumas extensões a um custo. Uma proposta semelhante pode ser feita por um provedor que tenha um "sim", mas com um custo muito alto. Ao confiar apenas em "sim" e "não" na RFP/RFI, você perde o melhor negócio. Por exemplo, uma pergunta como "Você tem suporte para multilocação?"  é bastante aberta. Alguns provedores têm suporte de primeira classe para multilocação, enquanto outros podem oferecer suporte a multilocação por terem instâncias independentes do produto implantadas por cada locatário. Ambos diriam "sim", mas o último é uma solução muito cara. Caso eles consigam garantir mais "sim" do que o primeiro, eles ainda têm uma chance maior de fechar o negócio.

Não digo que devemos eliminar completamente as RFPs/RFIs, mas produzir "RFP/RFI 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 internamente e cada equipe 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. Esses aplicativos evoluíram ao longo de muitos anos – e, em algumas equipes, ninguém ao menos sabia como as coisas funcionavam – e hesitavam em fazer pequenas alterações. Em algumas equipes havia pessoas que estavam muito confortáveis com o que tinham, mas estavam relutantes em se afastar de sua zona de conforto. Tecnicamente, o projeto era desafiador – mas a parte mais desafiadora era trazer todas as equipes para um entendimento comum.

Outra empresa com quem conversei estava lutando por mais de dois anos para iniciar sua IAM. O atraso não foi devido à falta de orçamento ou pessoas tecnicamente competentes, mas principalmente devido a decisões desconectadas. 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. Esses aplicativos foram desenvolvidos por equipes diferentes com diferentes tecnologias, com cada departamento responsável pelo gerenciamento dos usuários em seus respectivos armazenamentos de identidade. É 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. Jeff Bezos, o CEO da Amazon, chama essas equipes de duas pizzas – qualquer equipe deve ser pequena o suficiente para se alimentar com duas pizzas. A Netflix segue uma abordagem semelhante com a arquitetura baseada em microsserviços. Cada equipe possui um conjunto de microsserviços. The Connected Company by Dave Gray fala sobre um modelo similar com pods. Dave argumenta em seu livro que, se você quer uma empresa adaptativa, você precisará liberar as forças criativas em sua organização, para que as pessoas tenham a liberdade de fornecer valor aos clientes e responder às suas necessidades de forma mais dinâmica. Uma maneira de fazer isso é habilitando unidades pequenas e autônomas que podem agir e reagir de maneira rápida e fácil, sem medo de interromper outras atividades de negócios – pods. Um pod é uma unidade pequena e autônoma que é ativada e capacitada para fornecer as coisas que os clientes valorizam. 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, em muitos casos, os gerentes de negócios não estão cientes das mudanças na tecnologia que agora tornam o gerenciamento de identidades uma opção viável para pequenas organizações. Há alguns anos, era difícil justificar a implantação de um sistema de gerenciamento de identidades em uma empresa com menos de 10.000 funcionários, enquanto que, hoje, organizações com apenas mil funcionários podem pagar por um sistema completo de gerenciamento de identidades.

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 bombear 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. O suporte de produção dá a você a garantia de que, caso aconteça alguma coisa com o produto – por exemplo, que bloqueie suas operações comerciais - haverá uma equipe para cuidar desse problema e fornecer uma solução sob um SLA (acordo de nível de serviço) – é como um seguro.

Qual é o desafio então? Como Graham destacou com razão em seu livro, muitos gerentes de nível superior não entendem essa mudança que aconteceu no domínio do IAM e relutam em pensar no IAM como uma função que terá um impacto positivo direto nas operações comerciais do dia a dia. Eles estão prontos para injetar dinheiro em soluções massivas de ERP (planejamento de recursos corporativos), mas não em IAM. Eles estão prontos para investir tempo e dinheiro em projetos onde haverá ROIs rápidos (retorno sobre o investimento). Mesmo que o software de código aberto economize milhões de dólares de seu orçamento anual, há casos em que alguns gerentes questionam a necessidade de investir na compra de suporte à produção. 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. Muitas empresas maiores com orçamento, tempo e pessoas suficientes que investem em tais iniciativas do IAM não têm motivos para fracassar. Muitas empresas de tecnologia de ponta constroem suas próprias soluções de IAM e, mais tarde, até as vendem como um serviço para o resto. Essas empresas mantêm o controle sobre o código para que possam inovar em seu próprio ritmo. Isso também não significa necessariamente que elas construam tudo do zero – provavelmente começarão com o software de código aberto, os farão internamente, começarão a construir em cima disso e depois contribuirão com suas melhorias também para a comunidade. No entanto, nem todas as empresas preferem criar sua própria solução de IAM para manter o controle sobre o código. O IAM não era tão proeminente como é hoje dez/quinze anos atrás. Muitas empresas começaram a criar suas próprias soluções, quando os requisitos não eram tão complexos quanto são hoje. Suas principais preocupações incluem o gerenciamento de funcionários para a folha de pagamento e, possivelmente, permitir que os funcionários façam login em alguns aplicativos da Web com credenciais armazenadas em um Active Directory ou em um servidor LDAP. No Modelo de Maturidade do Forrester Identity Management, essas infraestruturas do IAM estão no nível 0 ou no nível 1. O desafio que enfrentamos hoje é que esses sistemas de IAM evoluíram no passado – tornando-os mais volumosos e frágeis. E a parte mais assustadora é que as pessoas ainda querem viver e seguir em frente com elas.

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 empresa é 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

Vários anos atrás, SOA (arquitetura orientada a serviços) e ESB (enterprise service bus - barramento de serviços corporativos, tradução livre) eram os jargões mais populares. Todos queriam ter um SOA ou um ESB. Avanço rápido até hoje, 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 – não os jargões.

O cisne verde

Os padrões de identidade não nascem sozinhos. Há muitos comitês sob os órgãos padrão, como W3C, IETF, Fundação OpenID, OASIS, Iniciativa Kantara, e muitos mais – trabalhando dia e noite com pessoas absolutamente incríveis, discutindo os problemas no espaço de identidade, construindo soluções e padronizando-as. 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 corrigindo-a. Então você pode até mesmo tomar sua solução para um corpo padrão e ver como ela pode ser transformada em um padrã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. Em junho de 2012, Eran Hammer (principal autor e editor da especificação OAuth 2.0 da época) renunciou e lançou uma luta contra o OAuth 2.0. Ele escreveu em seu famoso blog OAuth 2.0 e a estrada para o inferno "Eles dizem que o caminho para o inferno é pavimentado com boas intenções. Bem, isso é o OAuth 2.0. " Mesmo que aqueles tenham sido os primeiros dias no OAuth 2.0, isso ainda provocou muita discussão. Este era o momento em que estávamos desenvolvendo o suporte do OAuth 2.0 para o WSO2 Identity Server, e fomos questionados sobre o motivo pelo qual estávamos construindo um padrão em falência. Avançando até hoje, o OAuth 2.0 evoluiu muito e se tornou o padrão de fato para proteger as APIs. Muitos desenvolvimentos nos últimos dois anos têm preferido o OpenID Connect em detrimento do SAML 2.0, onde o OpenID Connect é um padrão criado sobre o OAuth 2.0.

Qualquer equipe deve estar ciente do tipo de pessoa "Cisne Verde" que não gosta de padrões e modelos, decide começar a reconstruir tudo do zero e acaba perdendo todos os prazos planejados.

Canivete suíço

Uma vez lidei com um problema muito interessante. Uma organização que conheci começou a criar sua própria solução de IAM em um produto IAM de "código aberto". Conforme seus requisitos evoluíram, eles começaram a personalizar o código-fonte original do produto e continuaram a adicionar novos recursos. Atualmente, mais de 50% do código em execução para atender aos requisitos são escritos por eles. A maioria desses novos recursos não está diretamente relacionada ao IAM, mas, na verdade, é específica do aplicativo. Por exemplo, eles armazenam informações de usuários e dados de negócios relacionados a usuários em diferentes fontes de dados. Aplicativos diferentes escrevem nessas fontes de dados – todos os dados gravados nessas fontes de dados precisam ser agregados/correlacionados e gravados em outra fonte de dados. A parte de agregação e correlação precisa acontecer a cada 10 minutos. Eles encontraram um mecanismo de fluxo de trabalho e um planificador de tarefas no produto IAM, escreveram seu próprio fluxo de trabalho incorporando a lógica de agregação/correlação e, usando o planificador de tarefas, agendaram sua execução para cada 10 minutos. Este não é um caso de uso do IAM – mas um problema de integração, onde eles precisam apenas de um mecanismo BPEL. Além disso, eles fizeram muitos outros trabalhos personalizados dentro do produto IAM para atender às necessidades dos aplicativos de fluxo ascendente. Eles não podem alternar facilmente o provedor, pois os componentes personalizados que desenvolveram não serão executados fora desse produto. Para tornar as coisas bastante assustadoras, mesmo que esse produto seja de código aberto, não é possível executá-lo em um ambiente de produção sem uma assinatura. Assim, eles não podem nem mesmo terminar o suporte de seu provedor. Este cliente está agora pagando um provedor de produtos para executar seu próprio código (mais de 50%)!

Esta é uma repercussão que resultou da não identificação de limites funcionais claros – e da tentativa de transformar a infraestrutura do IAM em um canivete suíço. Devemos evitar pensar em um produto da IAM como um canivete suíço e obter toda a nossa complexa lógica de negócios para executá-lo apenas para benefícios de curto prazo.

Visão curta

Os projetos do IAM falham em diferentes estágios – alguns na fase inicial (mesmo antes do pontapé inicial), alguns desaparecem lentamente, mas quando o fazem, eles derrubam todo o negócio. A escalabilidade de uma infraestrutura IAM é fundamental para o sucesso de qualquer projeto. O gerenciamento de projetos míopes não se preocupa com o futuro, mas só quer que algo funcione para atingir metas de curto prazo. 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 de login simultâneas, o número de sessões de login simultâneas e o número de usuários.

Muitos projetos começam com um baixo número de usuários e uma baixa taxa de tráfego. A parte complicada é que, em alguns projetos, há uma enorme diferença entre a carga média e a carga de pico. Por exemplo, muitas pessoas farão login em um sistema de folha de pagamento baseado em SaaS em seu dia de pagamento. Como você pode planejar a capacidade para esses casos? É difícil. Não podemos ter software e hardware, provisionados para lidar com a carga de pico o tempo todo. Isso é um enorme desperdício de recursos. Uma opção é fazer o dimensionamento dinâmico. O sistema gerará novos nós, quando a carga aumentar, e diminuir quando a carga diminuir. Ao avaliar um produto do IAM, se você não se preocupar com o suporte ao dimensionamento dinâmico, o projeto falhará ou você acabará pagando pela maioria dos recursos não utilizados, o que também é um fracasso.

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. A SAML comandou a federação de identidades e o domínio SSO por muitos anos e hoje, quem tomou o bastão foi o OpenID Connect,. Além disso, ao analisar a história dessas empresas, muitas crescem hoje por meio de aquisições, fusões e parcerias. Somente nos EUA, o volume de fusões e aquisições totalizou US $ 865,1 bilhões nos primeiros nove meses de 2013, segundo a Dealogic. Isso representa um aumento de 39% em relação ao mesmo período de um ano atrás -–e o maior total em nove meses desde 2008. O que isso significa para o gerenciamento de identidade corporativa? Você teria de trabalhar com vários repositórios de usuários, protocolos de autenticação, sistemas legados e muito mais. Se a sua infraestrutura de IAM aborda apenas metas de curto prazo e não pode se estender além disso, logo se tornará um legado – e um pesadelo na manutenção. Além disso, a introdução de novos recursos será dispendiosa.

Construção/Operação em Silos

Pessoas em diferentes departamentos/unidades 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. Quando os sistemas são projetados do zero, sem a coordenação em mente, até mesmo uma simples integração se tornará bastante cara.

Muitas empresas armazenam dados de clientes/leads em diferentes fontes de dados, possivelmente gerenciados por diferentes departamentos. Por exemplo, as empresas podem usar várias fontes/sistemas de dados desconectados, como: sistemas de CRM (Salesforce, Sugar CRM, Microsoft Dynamics, Net Suite CRM etc.), plataformas/soluções de marketing (Dataxu, Appboy, MailChimp, Google Analytics, Salesforce Pardot etc.), plataformas de e-commerce (Shopify, Magneto, Oracle Micros etc.), soluções de detecção de fraudes, mecanismos de risco, sistemas de gerenciamento de conteúdo (Microsoft SharePoint, Drupal, WordPress, Joomla, DotNetNuke etc.), plataformas de gerenciamento de dados (Blueconic, DoubleClick, Lotame, Krux etc.), e muito mais. 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/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). Um sistema CIAM fornece ingredientes para nutrir um usuário anônimo para um cliente conhecido, fornecendo a integração necessária entre sistemas originalmente desconectados. O perfil progressivo (progressive profilling) é um aspecto de um sistema CIAM. É o processo pelo qual o sistema aprende sobre um cliente de maneira progressiva. Primeiro, o usuário anônimo é simplesmente um visitante do site da empresa. Suas preferências podem ser rastreadas através de cookies e podem ser usadas para promover conteúdo que seja mais interessante para ele. Em um estágio, o usuário anônimo se tornará um lead ao preencher um formulário de contato. Agora, o sistema CIAM 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. Já mencionei uma empresa que desenvolveu 50% do código em execução, mas foi bloqueada em um produto devido à natureza de sua licença. 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. Se eles não fornecerem uma opção para exportar seus dados, você achará difícil (e também bastante caro) se afastar do provedor. 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 (Eu posso ser um pouco tendencioso em relação a softwares de código aberto, já que represento uma empresa que produz software de código aberto, mas convido você a fazer uma auto-validação contra os fatos que apresento aqui). Qualquer software de código aberto liberado sob a licença Apache 2.0 dá a liberdade de fazer qualquer coisa com ele. É a licença de software de código aberto mais adequada aos negócios. Podemos usar qualquer software sob a licença Apache 2.0 livremente em um ambiente de produção, estender sua funcionalidade e, o melhor de tudo, podemos desenvolver algo exclusivo e até vendê-lo, se quisermos!

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.