Diferencia entre revisiones de «Adaptar, ampliar, extinguir»
| (No se muestran 11 ediciones intermedias del mismo usuario) | |||
| Línea 1: | Línea 1: | ||
| − | Adaptar, ampliar, extinguir es una traducción del ingles "Embrace, extend and extinguish" que consiste en la política adaptada por las empresas de adaptar | + | Adaptar, ampliar, extinguir es una traducción del ingles "Embrace, extend and extinguish" que consiste en la política adaptada por las empresas de adaptar estándares en sus productos, para introducir variaciones no estándar en los mismos que permiten exterminar los beneficios que el estándar aporta al cliente. |
| − | Muchas empresas no encuentran rentables los | + | Muchas empresas no encuentran rentables los estándares porque le impide retener al cliente con tecnología propia que dificulte la independencia de sus clientes. |
Esto es un problema para el cliente porque al acomodarse la empresa proveedora con sus soluciones propietarias suele deteriorar y encarecer el mantenimiento sobre el producto. | Esto es un problema para el cliente porque al acomodarse la empresa proveedora con sus soluciones propietarias suele deteriorar y encarecer el mantenimiento sobre el producto. | ||
| Línea 7: | Línea 7: | ||
== Como cae un cliente en la trampa == | == Como cae un cliente en la trampa == | ||
| − | + | Muchas veces el cliente ni se plantea los estándares: compra SAP esperando que al ser una solución cerrada no se le pueda considerar responsable del probable fracaso a la hora de integrar sistemas, muchos responsables públicos ya han pagado ese mito de los 90 y todavía hay clientes que se empeñan en intentar integrar sistemas cerrados SAP con sistemas abiertos, acabando con la [[Propagacion de lo propietario]]. | |
| − | + | Sin embargo incluso cuando se usan estándares se corren riesgos. Muchos proyectos empiezan basándose en estándares (XML, Java EE, HTML,...) sin embargo las empresas de consultoría pueden desarrollar productos que no se adaptan totalmente al estándar, con el tiempo estos productos suelen estancarse y la empresa consultora original no la actualiza o la actualiza con elevados costes para el cliente, que se ve obligado a aceptar las imposiciones económicas de la empresa proveedora o quedar vinculado a un sistema obsoleto que no se actualiza. | |
| − | + | == Sw comercial, Sw Freemium y Sw Open Source == | |
| − | Cualquier cliente de [[IBM]] u [[Oracle]] sufre está | + | El software se puede separar en 3 categorías: |
| + | * Sw comercial: Es el software que solo puedes tener si lo pagas. La mayor parte del software corporativo de grandes empresas cae en este grupo | ||
| + | * Sw freemium: Es software que tiene una versión open source (o sino al menos gratis, que no es lo mismo) pero para sacar realmente partido al software es necesario tener una versión de pago. Programas como Liferay, Camunda, Terraform o Alfresco entran en esta categoría. | ||
| + | * Sw Open Source: El software es libre y gratuito para su uso. | ||
| + | |||
| + | En ocasiones el sw freemium es justificable, si la cantidad de funcionalidades que aporta en su modalidad freemium es suficiente para funcionar de forma razonable. En otras ocasiones el sw freemium no presenta las funcionalidades que podemos considerar mínimamente aceptable y se puede considerar una trampa para llevar al usuario a pagar la versión comercial. | ||
| + | |||
| + | == Ejemplos == | ||
| + | |||
| + | * El caso de Accenture con [[NACAR (BBVA)]] se comenta en el mundillo informático como ejemplo de proyecto que empieza en una tecnología estándar (J2EE) y poco a poco el cliente acaba siendo dependiente de la empresa proveedora. | ||
| + | * Cualquier cliente de [[SAP]], [[HP]], [[Microsoft]], [[IBM]] u [[Oracle]] sufre está desvinculación de los estándares al adquirir licencias de sus productos. En teoría sus herramientas respetan muchos estándares, pero los "extienden" y fuerzan a los programadores a depender de sus librerías propietarias. | ||
| + | * El caso de [[Avalon]] con Lexnet entre 2010 y Noviembre de 2015 tiene indicios de implementación de mecanismos de retención de cliente, en un caso de estar [[pillado por un proveedor]], aunque quizás solo era un caso de amiguismo, un sorprendente caso de contrato público, tras contrato público para un sistema que en 2016 acabaría siendo un desastre. <ref>https://www.elconfidencial.com/tecnologia/2017-08-01/lexnet-ministerio-justicia-ciberseguridad_1423484/</ref> | ||
| + | |||
| + | == Referencias == | ||
| + | |||
| + | <references/> | ||
[[Categoría:Conceptos sobre proyectos informáticos]] | [[Categoría:Conceptos sobre proyectos informáticos]] | ||
[[Categoría:Malas prácticas en los proyectos de software]] | [[Categoría:Malas prácticas en los proyectos de software]] | ||
Revisión actual - 22:14 17 nov 2022
Adaptar, ampliar, extinguir es una traducción del ingles "Embrace, extend and extinguish" que consiste en la política adaptada por las empresas de adaptar estándares en sus productos, para introducir variaciones no estándar en los mismos que permiten exterminar los beneficios que el estándar aporta al cliente.
Muchas empresas no encuentran rentables los estándares porque le impide retener al cliente con tecnología propia que dificulte la independencia de sus clientes.
Esto es un problema para el cliente porque al acomodarse la empresa proveedora con sus soluciones propietarias suele deteriorar y encarecer el mantenimiento sobre el producto.
Como cae un cliente en la trampa
Muchas veces el cliente ni se plantea los estándares: compra SAP esperando que al ser una solución cerrada no se le pueda considerar responsable del probable fracaso a la hora de integrar sistemas, muchos responsables públicos ya han pagado ese mito de los 90 y todavía hay clientes que se empeñan en intentar integrar sistemas cerrados SAP con sistemas abiertos, acabando con la Propagacion de lo propietario.
Sin embargo incluso cuando se usan estándares se corren riesgos. Muchos proyectos empiezan basándose en estándares (XML, Java EE, HTML,...) sin embargo las empresas de consultoría pueden desarrollar productos que no se adaptan totalmente al estándar, con el tiempo estos productos suelen estancarse y la empresa consultora original no la actualiza o la actualiza con elevados costes para el cliente, que se ve obligado a aceptar las imposiciones económicas de la empresa proveedora o quedar vinculado a un sistema obsoleto que no se actualiza.
Sw comercial, Sw Freemium y Sw Open Source
El software se puede separar en 3 categorías:
- Sw comercial: Es el software que solo puedes tener si lo pagas. La mayor parte del software corporativo de grandes empresas cae en este grupo
- Sw freemium: Es software que tiene una versión open source (o sino al menos gratis, que no es lo mismo) pero para sacar realmente partido al software es necesario tener una versión de pago. Programas como Liferay, Camunda, Terraform o Alfresco entran en esta categoría.
- Sw Open Source: El software es libre y gratuito para su uso.
En ocasiones el sw freemium es justificable, si la cantidad de funcionalidades que aporta en su modalidad freemium es suficiente para funcionar de forma razonable. En otras ocasiones el sw freemium no presenta las funcionalidades que podemos considerar mínimamente aceptable y se puede considerar una trampa para llevar al usuario a pagar la versión comercial.
Ejemplos
- El caso de Accenture con NACAR (BBVA) se comenta en el mundillo informático como ejemplo de proyecto que empieza en una tecnología estándar (J2EE) y poco a poco el cliente acaba siendo dependiente de la empresa proveedora.
- Cualquier cliente de SAP, HP, Microsoft, IBM u Oracle sufre está desvinculación de los estándares al adquirir licencias de sus productos. En teoría sus herramientas respetan muchos estándares, pero los "extienden" y fuerzan a los programadores a depender de sus librerías propietarias.
- El caso de Avalon con Lexnet entre 2010 y Noviembre de 2015 tiene indicios de implementación de mecanismos de retención de cliente, en un caso de estar pillado por un proveedor, aunque quizás solo era un caso de amiguismo, un sorprendente caso de contrato público, tras contrato público para un sistema que en 2016 acabaría siendo un desastre. [1]
