Más no significa automáticamente mejor.
Más funciones pueden significar más pantallas, más configuraciones, más administración, más capacitación y más tecnología de la que un equipo realmente necesita.
Entonces cuando un plataforma de seguridad de datos abarca descubrimiento, clasificación, DSPM, En lo que respecta a identidad y acceso, remediación, privacidad, gobernanza, ciclo de vida y seguridad de la IA, los compradores deberían hacer una pregunta razonable:
¿Necesitamos todo esto para resolver el problema que tenemos delante?
A veces la respuesta es no.
Un equipo que intenta encontrar datos confidenciales expuestos no debería necesitar lanzar una transformación a nivel empresarial antes de poder reducir esa exposición. Una empresa centrada en acceso excesivo No debería ser necesario poner en marcha primero todos los flujos de trabajo relacionados con la privacidad, la gobernanza o la IA.
Pero hay otra pregunta que vale la pena plantearse:
Si esos problemas finalmente se cruzan, ¿cuántas veces tendrá que redescubrir y reinterpretar la organización los mismos datos?
Ahí es donde radica la diferencia entre amplitud de la plataforma y exceso de productos empieza a importar.
La sobrecarga de funcionalidades añade capacidad sin reducir el trabajo significativo. Una amplitud útil permite a las organizaciones resolver un problema específico hoy, a la vez que reutilizan la misma información cuando surja el siguiente problema.
La amplitud de la plataforma no es lo mismo que la sobrecarga.
- El número de características es una métrica de evaluación débil. Más funciones no generan automáticamente más valor, y menos funciones no generan automáticamente un resultado más sencillo.
- El alcance de la implementación y el alcance de la plataforma son diferentes. Una organización puede comenzar con un resultado específico sin necesidad de desplegar todas sus capacidades.
- La inteligencia compartida cambia la economía de la amplitud. El descubrimiento, la clasificación, la identidad, la propiedad, las políticas y otros datos contextuales adquieren mayor valor cuando múltiples flujos de trabajo pueden reutilizarlos.
- La capacidad no utilizada no debería generar retrasos operativos. Los compradores deberían comprobar si las funcionalidades que no necesitan actualmente implican tareas de administración, dependencias o implementación.
- Las herramientas específicas pueden, sin embargo, generar un amplio trabajo organizativo. La simplicidad dentro de un producto puede trasladar la integración, la conciliación, la corrección o los requisitos futuros a otros ámbitos.
- Empiece con un enfoque limitado. Conserve las opciones. La estrategia de plataforma más sólida permite a los equipos resolver el problema inmediato sin tener que reconstruir la base cuando los requisitos se amplían.
¿Qué es el exceso de funcionalidades en una plataforma de seguridad de datos?
La sobrecarga de una plataforma de seguridad de datos se produce cuando las funcionalidades adicionales aumentan el coste, la administración, la configuración, la formación, el esfuerzo de implementación o la carga cognitiva sin aportar suficiente valor a los resultados que necesita una organización.
Esa definición importa porque la amplitud por sí sola no es una exageración.
Una plataforma puede ofrecer múltiples funcionalidades, permitiendo a un equipo utilizar únicamente las relevantes para su problema actual. Por el contrario, un producto con un alcance limitado puede generar una carga operativa considerable si las organizaciones deben integrarlo con otras tecnologías para completar un proceso de investigación o remediación.
Por lo tanto, la pregunta útil no es:
¿Cuántas funciones tiene esta plataforma?
Es:
¿Cuánto trabajo adicional crea o elimina la plataforma a medida que cambian los requisitos?
Por qué la amplitud de una plataforma puede parecer excesiva
La objeción tiene sentido intuitivo.
Un comprador parte de un problema específico: encontrar datos confidenciales, comprender la exposición a riesgos, identificar accesos excesivos, proteger los datos utilizados por la IA o mitigar un riesgo particular.
Entonces, el comprador ve una plataforma capaz de abordar muchos problemas relacionados.
Eso puede suscitar preocupaciones legítimas:
- ¿La implementación llevará más tiempo?
- ¿Necesitaremos más administradores?
- ¿Cuánta configuración tendremos que mantener?
- ¿Acaso unas mayores capacidades requieren más partes interesadas?
- ¿Tendrán los usuarios que aprender flujos de trabajo que no necesitan?
- ¿Será más difícil explicar internamente el proceso de compras?
- ¿Estamos pagando por funcionalidades que no vamos a utilizar?
- ¿Estamos resolviendo el problema hipotético del mañana en lugar del problema real de hoy?
Esas preguntas merecen respuesta.
El error radica en asumir que las respuestas se obtienen simplemente a partir del número de capacidades disponibles.
La amplitud de las características, la amplitud de la plataforma y el alcance de la implementación son diferentes.
Estos conceptos a menudo se reducen a una sola idea.
No deberían.
Separar los conceptos
Una plataforma amplia no requiere un punto de partida amplio.
Amplitud de características
¿Cuántas funciones o capacidades ofrece la tecnología?
Amplitud de la plataforma
¿Cuántos resultados relacionados pueden reutilizar una base común?
Alcance de la implementación
¿Qué implementa y pone en funcionamiento la organización actualmente?
Valor empresarial
¿Qué trabajo, riesgo o coste reduce esa implementación?
El principio de evaluación: Evalúe la plataforma por el alcance necesario para lograr el resultado, no por todas las capacidades que la arquitectura puede soportar.
No debería ser necesario desplegar todo para resolver un solo problema.
Esta es la prueba más sencilla para saber si la amplitud se ha convertido en exceso.
Supongamos que el objetivo inmediato es identificar datos sensibles con acceso excesivo.
La organización necesita las capacidades necesarias para descubrir los datos relevantes, clasificarlos, comprender el acceso a ellos, identificar la exposición significativa, priorizar el problema y tomar las medidas adecuadas.
No debería ser necesario poner en marcha todos los flujos de trabajo de privacidad, procesos de gobernanza, políticas de retención o controles de IA antes de poder resolver ese problema de seguridad.
La implementación inicial debe seguir el resultado inicial.
Empieza por el problema. Amplíalo cuando surja otro problema que justifique la ampliación.
Esta distinción permite a una empresa elegir una plataforma con margen de crecimiento sin convertir el primer proyecto en una transformación que dure varios años.
La pregunta clave es: ¿Qué se reutiliza?
La amplitud de la plataforma se vuelve más interesante cuando múltiples capacidades dependen de la misma inteligencia subyacente.
Consideremos el trabajo necesario para comprender un dato empresarial:
¿Dónde está?
¿Qué es?
¿Es sensible?
¿Quién es su propietario?
¿Quién o qué puede acceder a él?
¿Cómo se utiliza?
¿Qué políticas se aplican?
¿Debería la organización conservarlo?
¿Puede un sistema de IA recuperarlo?
¿Qué debería ocurrir cuando la organización identifica un riesgo?
Si cada nuevo proyecto de seguridad, privacidad, gobernanza, identidad, ciclo de vida o IA tiene que responder a esas preguntas de forma independiente, la organización paga repetidamente por el mismo nivel de conocimiento.
Eso crea otro tipo de hinchazón.
La cuestión arquitectónica importante no es cuántos módulos existen, sino cuántas veces la organización tiene que redescubrir la misma verdad.
La inteligencia de datos compartidos cambia el valor de la amplitud.
Una plataforma base útil permite que diferentes flujos de trabajo consuman un contexto compartido en lugar de reconstruirlo.
Discovery puede identificar dónde existen los datos. Clasificación Se puede determinar qué representan esos datos. El contexto de identidad y acceso puede mostrar quién o qué puede acceder a ellos. La actividad puede aportar información sobre su uso. La propiedad y el linaje pueden proporcionar contexto empresarial y de gobernanza. Las políticas y el ciclo de vida pueden influir en los pasos a seguir.
Esa información puede entonces servir de base para tomar diferentes decisiones.
Un equipo de seguridad puede usarlo para priorizar la exposición. El equipo de privacidad puede usarlo para comprender los datos personales. El equipo de gobernanza puede usarlo para la propiedad y las políticas. Los equipos de identidad pueden usarlo para comprender el acceso efectivo. Los equipos de IA pueden usarlo para determinar a qué modelos, copilotos, sistemas RAG o agentes pueden acceder.
Los flujos de trabajo siguen siendo diferentes.
No es necesario empezar de cero cada vez para comprender los datos subyacentes.
Para una mirada más profunda a esa arquitectura, vea qué debería significar realmente la seguridad, la privacidad y la gobernanza unificadas de los datos..
También existe algo llamado sobrecarga de herramientas.
El exceso de funciones llama la atención porque es visible dentro del producto.
La sobrecarga de herramientas puede ser más difícil de detectar porque las organizaciones la distribuyen a lo largo de toda la pila tecnológica.
Un producto con un alcance limitado puede resolver un problema de forma elegante. Eso puede ser precisamente lo que una organización necesita.
Pero a medida que se amplían los requisitos, la organización puede añadir otra herramienta para el acceso, otra para la privacidad, otra para la IA, otra para el ciclo de vida, otra para la actividad y otra para la corrección de problemas.
Cada tecnología puede parecer sencilla si se la considera de forma aislada.
Puede que la arquitectura no.
El uso de más herramientas puede dar lugar a integraciones, inventarios separados, clasificaciones diferentes, políticas inconsistentes, relaciones adicionales con proveedores, administración separada, almacenamiento duplicado y más traspasos entre equipos.
Eso no significa que la consolidación sea siempre la respuesta correcta.
Esto significa que los compradores deben evaluar ambas formas de hinchazón.
Dos formas de hinchazón
Añadir más funciones a un mismo producto no es la única forma en que se acumula la complejidad.
Exceso de funciones
Las funcionalidades adicionales implican configuración, administración, carga cognitiva o costes sin aportar suficiente valor al resultado deseado.
Inflación de herramientas
Los productos separados multiplican las integraciones, los inventarios, la administración, las políticas, la conciliación, los proveedores y las transferencias operativas.
Ninguno de los dos extremos gana automáticamente. Evalúe la arquitectura en función del trabajo total necesario para lograr y mantener el resultado.
¿Una mayor capacidad implica una implementación más larga?
No necesariamente, pero los compradores deberían probarlo.
El alcance de la implementación depende de lo que la organización pretenda poner en funcionamiento, los sistemas involucrados, la arquitectura de despliegue, las integraciones necesarias, la cobertura de datos, la configuración, los procesos existentes y el resultado que se busca.
Una plataforma amplia puede volverse engorrosa si la activación de una funcionalidad crea dependencias de varias otras.
Merece la pena probarlo directamente.
Pregunte si el caso de uso inicial puede funcionar de forma independiente. Identifique las dependencias obligatorias. Determine qué integraciones requiere realmente el primer resultado. Separe las capacidades opcionales de los requisitos previos.
La métrica relevante no es la capacidad total de la plataforma, sino el trabajo necesario para poner en funcionamiento la capacidad que se necesita.
Las preguntas sobre la velocidad de implementación y el tiempo de obtención de valor merecen una evaluación aparte. Nuestra guía para Tiempo de conversión a valor de DSPM Examina con mayor detalle la cobertura, el contexto, la priorización, la remediación y la velocidad de decisión.
¿Una plataforma amplia requiere más partes interesadas?
Una plataforma puede dar soporte a varias funciones organizativas sin necesidad de que todas ellas participen en cada proyecto.
El modelo de partes interesadas debe seguir a la decisión.
Si la seguridad requiere reducir el acceso excesivo a datos confidenciales, los responsables de seguridad e identidad pueden desempeñar un papel fundamental. La privacidad cobra relevancia cuando los datos plantean cuestiones regulatorias o de finalidad. La gobernanza es importante cuando la propiedad no está clara. Los equipos de gestión del ciclo de vida de los datos cobran relevancia cuando la eliminación ofrece la solución adecuada.
Esas dependencias provienen del problema, no simplemente de la plataforma.
De hecho, una base común puede reducir algunas fricciones entre los distintos departamentos cuando las partes interesadas necesitan colaborar, ya que pueden trabajar desde el mismo contexto de datos.
Una plataforma debe conectar a las partes interesadas cuando el problema requiere colaboración, no requerir colaboración simplemente porque la plataforma admite varios equipos.
¿Y el costo?
La amplitud de una plataforma no la convierte automáticamente en económicamente eficiente.
Los compradores deben evaluar qué necesitan, qué van a usar, cómo funciona el embalaje, qué requiere la implementación y cuáles son los costos de administración continuos.
Sin embargo, comparar los costes únicamente a nivel de producto puede hacer que se pasen por alto costes en otras partes de la arquitectura.
Una evaluación más completa puede incluir:
- Costos de software y suscripción
- servicios profesionales y de implementación
- infraestructura
- administración
- desarrollo y mantenimiento de la integración
- capacitación
- descubrimiento o clasificación de duplicados
- traspasos operativos
- esfuerzo de investigación
- esfuerzo de remediación
- Herramientas futuras necesarias para casos de uso adyacentes
El objetivo no es justificar una plataforma más grande.
Es entender el modelo operativo total necesario para producir el resultado.
Más funciones pueden dificultar la explicación interna de una plataforma.
Esta preocupación es real.
Un comprador que intenta resolver un problema de seguridad específico puede tener dificultades para obtener apoyo interno si la tecnología propuesta se describe como una transformación de plataforma gigantesca.
La respuesta no es desplegar todas las capacidades.
Empieza por el problema.
En lugar de:
“Necesitamos una plataforma para DSPM, privacidad, gobernanza, identidad, ciclo de vida, seguridad de IA y remediación.”
Comience con:
“Necesitamos identificar los datos sensibles con acceso excesivo y reducir esa exposición.”
A continuación, explique las capacidades necesarias para lograr ese resultado.
El valor general de la plataforma puede ser importante para la arquitectura, las adquisiciones o la planificación futura sin que ello implique que todos los interesados deban aprobar el primer caso de uso.
Adquiera la plataforma adecuada para el problema que necesita resolver. Evalúe la arquitectura para los problemas que pueda tener que resolver posteriormente.
La IA hace que la reutilización de plataformas sea más importante.
La IA introduce nuevos sistemas y flujos de trabajo, pero gran parte del contexto empresarial subyacente ya existe.
Las aplicaciones y los agentes de IA siguen interactuando con datos. Siguen dependiendo de identidades y permisos. Siguen operando bajo políticas. Siguen pudiendo exponer información confidencial. Las organizaciones siguen necesitando información sobre la propiedad, el origen, la actividad y la corrección de datos.
Por lo tanto, el problema de la IA no parte de cero.
Una organización que ya comprende los datos confidenciales, la identidad, el acceso, el linaje, la propiedad y las políticas puede reutilizar esa inteligencia al evaluar Seguridad de datos de IA.
Esta es una de las razones por las que la arquitectura de la plataforma importa más allá del caso de uso inicial.
El próximo problema de seguridad no debería obligar a la organización a olvidar todo lo que aprendió al resolver el anterior.
Comencemos con el problema.
Pruebe un resultado de seguridad de datos de principio a fin.
Utilice la evaluación interactiva de seguridad de datos de BigID para abordar el descubrimiento, la clasificación, la exposición, el acceso, la priorización y la remediación sin convertir el ejercicio en una transformación de la plataforma.
¿Cómo deben evaluar los compradores la amplitud de la plataforma?
No cuente los módulos.
Elija un caso de uso representativo y analice qué requiere la arquitectura para resolverlo.
| En lugar de preguntar | Haz esta pregunta |
|---|---|
| ¿Cuántos módulos tiene? | ¿Qué capacidades requiere realmente nuestro resultado inicial? |
| ¿Lo hace todo? | ¿Resuelve el problema actual con la suficiente profundidad? |
| ¿Podemos comprar una herramienta estrecha? | ¿Qué sistemas y flujos de trabajo adicionales requeriría el resultado final? |
| ¿Utilizaremos todas nuestras capacidades? | ¿Las capacidades no utilizadas generan trabajo operativo o siguen siendo opcionales? |
| ¿La plataforma es más cara? | ¿Cuál es el coste total de la arquitectura necesaria para lograr el resultado deseado? |
| ¿La amplitud dificulta la implementación? | ¿Podemos poner en marcha el primer caso de uso sin activar funcionalidades no relacionadas? |
| ¿Para qué necesitaríamos el resto? | ¿Podrán los futuros casos de uso reutilizar la inteligencia y las integraciones que establezcamos ahora? |
La mejor estrategia de plataforma comienza con un enfoque limitado sin pensar en términos limitados.
No tiene sentido comprar una funcionalidad simplemente porque existe.
Tampoco tiene sentido obligar a que cada nuevo problema de datos comience con otro inventario, otro ejercicio de clasificación, otra capa de integración y otra interpretación de los datos empresariales.
Una mejor arquitectura favorece tanto la concentración como la reutilización.
Empieza por el resultado que importa ahora.
Implementa lo que ese resultado requiere.
Mide si funciona.
Luego, reutilice la base cuando surja otro requisito legítimo.
Eso es muy diferente a desplegar todo a la vez.
También es muy diferente a diseñar cada compra como si el problema de hoy fuera a permanecer aislado para siempre.
Vea la Fundación en acción.
Comience con un problema de seguridad de datos.
Descubra cómo BigID conecta el descubrimiento, la clasificación, la identidad, el acceso, la actividad, el riesgo y la remediación para que los equipos puedan abordar un resultado de seguridad específico, al tiempo que preservan el contexto de datos reutilizable para lo que venga después.
La amplitud debería reducir el trabajo repetitivo, no crearlo.
Una plataforma tan amplia merece ser examinada con detenimiento.
Los compradores deben comprobar si añade dependencias, configuración, administración, costes, partes interesadas o funcionalidades innecesarias al proyecto inicial. Si es así, se trata de preocupaciones legítimas.
Pero el número de funciones por sí solo no puede responder a esa pregunta.
La evaluación más útil analiza qué requiere la plataforma para el problema en cuestión, qué trabajo elimina, qué inteligencia reutiliza y si las capacidades adicionales siguen siendo opcionales hasta que se vuelvan relevantes.
Esto nos lleva a una definición más clara de amplitud útil:
La amplitud y utilidad de la plataforma permite a una organización comenzar con un resultado, reutilizar lo aprendido y expandirse sin tener que reconstruir repetidamente la base de datos.
El objetivo no es añadir más funciones.
Es un trabajo menos repetitivo.
Preguntas frecuentes sobre la plataforma de seguridad de datos
¿Qué es la sobrecarga de una plataforma de seguridad de datos?
La sobrecarga de una plataforma de seguridad de datos se produce cuando las funcionalidades adicionales aumentan el coste, la configuración, la administración, la formación, el esfuerzo de implementación o la carga cognitiva sin aportar suficiente valor a los resultados que necesita una organización.
¿Una plataforma integral de seguridad de datos requiere una implementación integral?
No. El alcance de la plataforma y el alcance de la implementación son diferentes. Las organizaciones pueden comenzar con un objetivo de seguridad específico y poner en marcha únicamente las capacidades e integraciones necesarias para lograrlo.
¿Cuál es la diferencia entre amplitud de plataforma y exceso de funciones?
La amplitud de la plataforma describe la variedad de resultados relacionados que una base común puede soportar. La sobrecarga de funciones se produce cuando la funcionalidad adicional genera una carga operativa sin aportar suficiente valor. La amplitud resulta útil cuando los equipos pueden reutilizar la inteligencia compartida sin activar ni administrar capacidades innecesarias.
¿Puede una herramienta de seguridad limitada generar complejidad?
Sí. Una herramienta de alcance limitado puede ser sencilla internamente, pero requerir productos adicionales, integraciones, inventarios, traspasos manuales o conciliación para completar un flujo de trabajo de seguridad más amplio. Las organizaciones deben evaluar la complejidad en todo el modelo operativo, en lugar de centrarse en una sola interfaz.
¿La amplitud de la plataforma ralentiza la implementación?
No automáticamente. La implementación depende del caso de uso, las integraciones requeridas, la arquitectura de despliegue, la configuración, la cobertura de datos y las dependencias. Los compradores deben determinar si las funcionalidades de la plataforma no relacionadas siguen siendo opcionales durante la implementación inicial.
¿Una plataforma de seguridad de datos más amplia requiere de más partes interesadas?
No necesariamente. La participación de las partes interesadas debe surgir tras la resolución del problema. Los equipos adicionales cobran relevancia cuando la decisión requiere su experiencia, responsabilidad, políticas o aprobación, y no simplemente porque la plataforma sea compatible con sus casos de uso.
¿Cómo deberían las organizaciones comparar el coste de las plataformas de seguridad de datos amplias y específicas?
Las organizaciones deben evaluar el modelo operativo completo, incluyendo el software, la implementación, la infraestructura, la administración, las integraciones, la capacitación, la investigación, la corrección, la detección o clasificación de duplicados y las herramientas adicionales necesarias para lograr los resultados actuales y futuros.
¿Cómo deben los compradores evaluar la amplitud de una plataforma de seguridad de datos?
Comience con un caso de uso representativo. Identifique las capacidades, integraciones, configuración, partes interesadas y el trabajo operativo necesarios para resolverlo. Luego, determine si los casos de uso futuros pueden reutilizar la información obtenida sin obligar al proyecto inicial a adoptar funcionalidades no relacionadas.
Autor
