La importancia de los estandares

Posted by Masiosare
March 11, 2008

No, esta vez no voy a hablar de los estándares html. Esta vez voy a hablar de las tecnologías estándar en el mas amplio sentido de la palabra.

Estándar: Adj. Que es lo más habitual o corriente, o que reúne las características comunes a la mayoría.

Si eres un recién egresado de la carrera de ciencias de la computación,  seguramente tu primer trabajo será programación en visual básica, usando una base de datos SQL server en un servidor windows. Tienes suerte. Si, en serio.

dinosaur

Con el tiempo te vas a encontrar con que tienes que dar mantenimiento a cosas como estas:

Y tu trabajo será hacer que esos sistemas sigan funcionando. Mis condolencias. Una vez que tu trabajo es mantener un sistema monolítico como estos, tu carrera esta en peligro. La mayor parte del conocimiento y experiencia que obtengas de estos sistemas no te servirá una vez que te vayas a otra empresa. En muchos aspectos tendrás que empezar de cero, y probablemente tendrás que empezar de negativo, ya que estos sistemas te encierran en el pasado, amarrandote a malas practicas y dejándote atrás en una industria en la que el conocimiento es obsoleto en 6 meses.

Y te conviene tener cuidado de no caer en estas malas no solo por ti, sino por tu empresa. Es cuestión de libertad, pero sobre todo de finanzas. El trabajar con sistemas no estándares les puede estar costando mucho dinero:

  1. Estas herramientas por ser tan exóticas, suelen tener pocos especialistas. Debido al soporte limitado conseguir alguien que te pueda resolver un problema complicado, te puede costar muy caro.
  2. Muchas veces es poco mas que imposible hacer una migración a un sistema operativo mas nuevo. Estarás muy expuesto a problemas de seguridad así como a problemas de performance. Inclusive podría ser difícil o imposible migrar de hardware, en caso de contingencia.
  3. Por la naturaleza de este tipo de herramientas es posible que no puedan crecer al ritmo de tu negocio. Talvez hoy tienes 10 usuarios, pero en un futuro podrías tener 1000. Cuando el sistema no puede crecer, lo mas probable es que tu única opción sea aventar dinero al problema, en términos de hardware. Toma en cuenta que la escalabilidad de un problema en términos de hardware no es lineal. Duplicar la capacidad de procesador no necesariamente reduce a la mitad los tiempos de respuesta, aun paralelizandolo como lo explica la ley de Amdahl. Piensa en términos de escalabilidad.
  4. Si el proveedor de estos sistemas es tu único soporte, te encontraras en el problema de “vendor lock in“. Una vez que un sistema de este tipo es vital para tu negocio, tu proveedor te cobrara lo que el quiera sin que tu puedas hacer mucho para evitarlo.
  5. La curva de aprendizaje suele ser muy alta, costándote muchas horas hombre obteniendo un costo-beneficio mucho menor, ya que son conocimientos poco reusables fuera del campo original del problema.

Te sorprendería saber cuantas empresas del top 100 en este país cuentan con problemas similares. Ahora, que hacer para evitar caer en estos problemas?

  1. Para todo sistema a la medida EXIGE el código fuente. Una vez que tu compras un sistema, ese sistema es TUYO, ya no le pertenece a quien lo creo. El código es de quien lo paga.
  2. EXIGE la documentación completa del software que compres, tanto la documentación técnica como la de usuario. (si, se que es de primaria, pero te sorprendería el porcentaje de software no documentado que existe en este país)
  3. Prefiere que el software que compres este basado en software libre o que sea software libre.
  4. EXIGE que tengas completo acceso a los datos generados en dichas aplicaciones. Otra vez, los datos que generes son tuyos, no de tu proveedor. Además dichos datos deben ser fácilmente exportables a formatos estándares.
  5. Prefiere que el software este basado en lenguajes estándares. Te será mas fácil y barato extender tu sistema si esta hecho en PHP, Ruby, C#, ASP.NET o Java, que si esta hecho en MUMPS o en CLIPPER o en Informix.
  6. En caso de que el sistema sea realizado en un lenguaje propietario, EXIGE que el sistema sea extensible con un API publica y documentada en un lenguaje comercial estándar. Java suele ser una buena opción en estos casos.
  7. EXIGE por contrato que el sistema sea soportado en versiones futuras de sistema operativo al menos por una cantidad determinada de años. Este puede ser un punto complicado de negociar, pero si no lo haces corres el riesgo de que tus servidores sigan corriendo Windows Vista por los siglos de los siglos.

No permitas que tu carrera se reduzca a mantener un software monolítico, créeme, no te conviene.
Parafraseando a un clásico,  esto se trata mucho sobre la libertad, pero sobre todo, de dinero.

Related Posts
ensayo

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Comments
Comment by Alex on March 13, 2008 @ 1:39 pm

Por eso es que aun hay vacantes para empleos de programacion en COBOL ;)

Pingback by La marina estadounidense se olvida de los sistemas cerrados :: Masio IT&#174 &#9786 on March 16, 2008 @ 12:55 pm

[...] sobre sistemas estándares,  una vez que tu ecosistema de sistemas cerrados empieza a crecer, los costos de manutención crecen, tanto por la complicada integración entre ellos, así como por el ya sabido problema de [...]

Comment by MOiSTER on March 16, 2008 @ 9:33 pm

chale, es mi trabajo mantener vivo un sistema hecho en Visual Basic 3, puedes creerlo???? y lo peor es que no quieren que se actualice ni siquiera a visual basic 6.

Pingback by Mis primeros enlaces de la semana | MOiSTER on March 16, 2008 @ 10:02 pm

[...] La importancia de los estandares [...]

Leave a comment

(required)

(required)