Compartilhe esta publicação
Por qué no todos los proyectos de IAM cruzan la línea de meta
Según una encuesta realizada por KPMG en 2009, el 75% de los proyectos de IAM ofrecen menos de lo esperado. La mayoría de las veces, para muchas fallas en el diseño de software, la culpa es de estimaciones deficientes.
Según el libro The Mythical Man Month-Month de Frederick P. Brooks Jr., más proyectos de software han fracasado por falta de tiempo que por todas las demás causas combinadas.
Este libro señala cinco deficiencias importantes en la forma en que se realizan las estimaciones:
1. Las técnicas de estimación están poco desarrolladas. Pero reflejan una suposición tácita que es completamente infundada, a saber, que todo estará bien;
2. Las técnicas de estimación confunden engañosamente el esfuerzo con el progreso, ocultando la suposición de que los hombres y los meses son intercambiables;
3. Como no estamos seguros de nuestras estimaciones, los administradores de software a menudo no tienen la cortesía obstinada de los demás;
4. El progreso del cronograma está mal monitoreado;
5. Cuando se reconoce el retraso en la programación, la respuesta natural (y tradicional) es agregar mano de obra.
En muchos casos donde los proyectos fallan, la culpa recae en sus estimaciones y gestión del proyecto.
Me gustaría presentar una visión diferente. Si bien mi discusión se relaciona principalmente con los proyectos de IAM, creo que algunos de ellos son igualmente aplicables a todos los proyectos de software.
Aquí, compartiré mi experiencia y mis conocimientos sobre por qué no todos los proyectos de IAM cruzan con éxito la línea de meta.
RFP/RFI “Todo lo que pueda obtener”
Un RFI (Request For Information/solicitud de información) es un medio formal para obtener informaciónes generales de los proveedores, mientras que un RFP (Request For Proposal/solicitud de propuesta) es una forma muy formal y estructurada de obtener información específica del proveedor.
Las RFP/RFI se realizan en una etapa temprana de un proyecto, y, probablemente, las personas que las escriben no saben exactamente lo que necesitan, entonces eligen el camino más seguro o más fácil.
Ellos saben que necesitan de un proyecto de IAM, por lo que buscan algunos productos en el mercado, copian la lista de características según los requisitos y la publican como RFI/RFP.
Esto cubrirá más de lo necesario y, finalmente, terminará con una "RFP/RFI todo lo que pueda obtener".
Sin embargo, hay respuestas entre sí y no. Durante el proceso de evaluación de una RFP/RFI, lo que más importa es el número de “sí”. Un proveedor con el mayor número de "sí" pasará por la primera ronda de selección.
El problema está en los detalles, cuando empiezas a mirar la columna de "comentarios".
Es posible que haya perdido fácilmente su combinación perfecta durante la evaluación, ya que ha inundado la RFP/RFI con requisitos poco realistas y terminará comprando un producto de un proveedor a un precio muy alto.
No estoy diciendo que debamos eliminar las RFP/RFI por completo, pero producir RFP/RFI al estilo "todo lo que pueda obtener" no es la manera correcta de comenzar su proyecto de IAM.
Decisiones Desconectadas / Política Interna
Hace unos años, en WSO2, trabajamos con un importante instituto financiero de EUA para crear una plataforma de control de acceso unificada para toda la empresa.
Tenían más de 70 equipos y cada uno desarrolló su propia forma de controlar el acceso.
Algunos utilizaron una base de datos para almacenar las reglas de control de acceso en sus propios esquemas, mientras que otros simplemente las codificaron en el código de la aplicación.
Otra empresa con la que hablé había estado luchando durante más de dos años para iniciar su IAM.
En este caso particular, el principal desafío fue crear un modelo de identidad unificado en todas las aplicaciones.
Tenían más de 30 almacenes de identidad utilizados por varias aplicaciones y el mismo usuario estaba duplicado en cada almacén de identidad sin ningún identificador de correlación.
Es un problema bastante factible de resolver técnicamente, pero primero, cada departamento debe aclarar cómo debe proceder.
Estas no son histórias aisladas. A medida que crece una organización, el mejor enfoque sería tener pequeños equipos funcionales.
Este modelo de empoderar a cada unidad de negocios para que tome sus propias decisiones ayuda a las organizaciones a moverse rápidamente, sin esperar a construir una solución completa para toda la empresa.
Siembra lo que puedas cosechar pronto
Graham Williamson señala en su último libro, “Gestión de la identidad: una perspectiva de negocios”, que en muchos casos los gerentes comerciales no están al tanto de los cambios en la tecnología que pueden aplicarse a las organizaciones pequeñas.
La evolución de los sistemas de administración de identidades basados en la nube y muchos productos de administración de identidades de software de código abierto han reducido en gran medida el costo de las iniciativas de IAM.
La necesidad de millones de dólares para nombres "grandes" ya no es necesaria. En WSO2, construimos un producto IAM de código-fonte completamente abierto y brindamos soporte de producción.
Este es el modelo de negocio que siguen la mayoría de las empresas de software de código abierto sigue.
¿Cuál es el desafío entonces? Como señaló Graham, muchos gerentes no entienden este cambio que ha tenido lugar en el dominio de IAM y son reacios a pensar en él como una función que tendrá un impacto.
La resistencia a invertir en iniciativas de IAM, y intentar mantenerlas con un presupuesto bajo, impide que alguien obtenga los beneficios y allana el camino para otra iniciativa de IAM sin éxito.
Cree su propia solución de IAM
Hay algunas razones por las que algunas empresas prefieren una solución de IAM interna en lugar de un producto desarrollado por un proveedor: presupuesto limitado, requisitos complejos, control sobre el código y razones históricas.
No digo que las soluciones IAM domésticas sean siempre malas. Sin embargo, no todas las empresas prefieren crear su propia solución IAM para mantener el control sobre su código.
No debe intentar crear internamente una solución de IAM casera si no tiene el nivel adecuado de experiencia.
La infraestructura de IAM es la parte más sensible de su negocio. Un secuestro de cuenta puede resultar en la quiebra de su empresa.
Si su organización es pequeña, puede concentrarse más en lo que puede hacer mejor al delegar la administración de su infraestructura de IAM a un proveedor que sea experto en ese dominio.
No son solo las pequeñas empresas las que subcontratan su infraestructura de IAM a proveedores externos, incluso las más grandes prefieren hacerlo.
Enamorado de la jerga
Hace varios años, SOA (arquitectura orientada a servicios) y ESB (enterprise service bus - autobús de servicio corporativo) eran las jergas más populares. Todos querían tener una SOA o una ESB.
Con los avances, ambas jergaes se han ido desvaneciendo progresivamente y tienen ciclos de vida de Microservicios y API Gateway. Lo que impulsa su negocio es lo que necesita, no la jerga.
El cisne verde
Los patrones de identidad no nacen solos. Una vez que hayas definido su problema, tú debes dedicar algún tiempo a investigar el patrón de identidad para encontrar una solución.
Nuevamente, no se guíe por los patrones, sino por su propia declaración del problema. Siempre hay margen de mejora.
Si crees que tu problema no se está resolviendo correctamente, no dudes en crear la solución. Así es como los estándares de identidad han evolucionado a lo largo de los años.
Encontrarás personas en algunos equipos de proyectos que odian los patrones.
Simplemente encontrarán algún artículo o blog que declare que cierto patrón no es lo suficientemente seguro o está muerto, y presionarán a todo el equipo con esa idea, sin ningún descubrimiento profundo de los hechos.
Estas personas son los “cisnes verdes”, a quienes no les gustan los patrones y modelos y deciden comenzar a reconstruir todo desde cero, en consecuencia, terminan perdiendo todos los plazos previstos.
Vista corta
Los proyectos de IAM fallan en diferentes etapas: algunos en la fase inicial, algunos se desvanecen lentamente, pero cuando lo hacen, derriban todo el negocio.
La escalabilidad de una infraestructura de IAM es fundamental para el éxito de cualquier proyecto.
Antes de evaluar cualquier proyecto de IAM, debe tener una idea de la carga que espera hoy, así como de lo que esperaría dentro de 6 a 12 meses.
Otras cosas de las que debe preocuparse son la cantidad de solicitudes y sesiones de inicio de sesión simultáneas y la cantidad de usuarios.
Para cualquier proyecto de IAM, la extensibilidad del producto subyacente es extremadamente importante. Si observas los últimos cinco años de la industria de IAM, descubrirás la velocidad con la que está evolucionando.
Construcción/Operación en Silos
Las personas en diferentes departamentos a menudo hacen sus propias tareas, lo que lleva a silos operativos. Sin embargo, la verdadera ventaja para el negocio proviene de vincular estas diferentes actividades.
Por ejemplo, Nike, como parte de su iniciativa de transformación digital, creó Nike Digital Sports en 2010 para proporcionar coordinación, innovación y algunos recursos compartidos para los numerosos esfuerzos digitales de la empresa.
Muchas empresas almacenan datos de clientes en diferentes fuentes de datos, posiblemente administradas por diferentes departamentos.
Una vez que las cosas están desconectadas, incluso si el proyecto individual puede tener éxito, fracasará como un todo, ya que será una operación muy costosa construir un perfil unificado de un determinado lead o cliente.
Una iniciativa que debería preocuparte en estos casos y que además aportará más valor a la empresa es CIAM (Gestión de identidad y control de acceso de clientes).
El sistema tiene la oportunidad de vincular todas las preferencias rastreadas contra el usuario anónimo con el nuevo lead.
Con el tiempo, las preferencias del lead se pueden rastrear de manera más significativa y el equipo de ventas/marketing de la empresa puede trabajar en colaboración para convertir al cliente potencial en un cliente.
En este punto, recopila los datos más confiables sobre el cliente, con la verificación adecuada. Luego, a partir de ahí, el sistema CIAM continuará monitoreando las preferencias del cliente para producir datos más significativos, lo que permitirá a la gerencia de la empresa tomar decisiones más informadas.
Tener una visión de la iniciativa del IAM de la empresa es de vital importancia. Una vez que tenga una visión, puede guiar a cada departamento para lograr lo que se debe hacer para que todo se integre para generar más valor para la empresa.
Bloqueo de proveedores
No experimentará el bloqueo del proveedor a corto plazo, pero a largo plazo, cuando comience a construir su infraestructura de IAM sobre un producto de proveedor, se volverá cada vez más dependiente.
Algunas empresas no solo desarrollan extensiones para sus productos de IAM, sino que también crean toda la pila de aplicaciones en función de las APIs del proveedor. Nuevamente, esto es el resultado de una gestión e ingeniería de proyectos miopes.
Los datos de la aplicación también pueden conducir al bloqueo. Esto puede suceder especialmente con los proveedores de IAM basados en la nube.
Incluso si estos proveedores de IAM en la nube admiten la exportación de datos, será difícil y costoso crear herramientas para interpretarlos y hacerlos significativos y funcionales.
El bloqueo de proveedores es una de las razones por las que se debe prestar más atención a los estándares abiertos y al software de código abierto.
Siempre debe intentar mantener estándares abiertos entre sus aplicaciones y el producto IAM.
Si ha escrito código en una API de producto no estándar, primero desarrolle un wrapper en el costado de su aplicación para asegurarse de que su aplicación no esté demasiado vinculada a la API del producto IAM.
Si decide usar otro producto IAM algún día, solo necesita cambiar el wrapper. Esta será una opción menos onerosa.
Este artigo foi escrito por Miguel Lorenzo e publicado originalmente em Prensa.li.