Leo en este artículo una reflexión acerca de que al área de negocio no le importa cómo está hecho tecnológicamente una funcionalidad o servicio de negocio siempre cuando funcione. Y eso me suscita una reflexión.

Creo que todos hemos oído alguna vez, en algún despacho, aquello «no me importa como está hecho mientras funcione«. Como ya comentaba anteriormente en este blog, parece que la única preocupación es desarrollar la aplicación lo antes posible y ponerla a disposición del negocio. También se suele decir, que a los responsables de la empresa (los que en definitiva pagan el sueldo a los empleados de T.I) no les interesa la tecnología con qué está hecho este software. Evidentemente esto es muy importante hoy en día, con tanta competencia por atraer a un nuevo puñado de clientes.

Mi opinión es que esta mentalidad conlleva riesgos y costes que pueden permanecer ocultos y que es conveniente sacar a la luz. Evidentemente, como profesiones T.I. no debemos agobiar a personas que no son técnicas con un discurso basado en la tecnología (seguro que si nos paramos a mirar una presentación que hayamos hecho hace poco abundaran las siglas tipo WSDL, SOAP, XML, ESB, SOA y cosas por el estilo) olvidándonos exponer que lo principal es mostrarles como con esta tecnología les vamos ayudar a mejorar su negocio. Pero es nuestra responsabilidad, también, no dejar de explicar con un lenguaje accesible los pros y los contras de las decisiones técnicas más relevantes.

Si sólo primamos la velocidad de desarrollo, nos encontraremos por ejemplo con aplicaciones web que:

  1. no separan la lógica de presentación, de la lógica de negocio, ni esta última de la lógica de acceso a datos. Una vez entregado la aplicación y puesta en producción nos encontraremos que su mantenimiento va a ser un auténtico problema. Un mínimo cambio en una tabla nos obligará a cambiar toda la aplicación.
  2. Por supuesto, tampoco será reutilizable. Cuando otra aplicación necesite esa misma lógica de negocio tendrá que volver a implementarla. Y esto se repetirá n veces. En dos o tres años nos encontraremos con decenas de aplicaciones que hacen lo mismo y que tienen la lógica de negocio repetida.
  3. También nos encontraremos con otros problemas no ya funcionales, sino técnicos pero que tendrán un gran impacto sobre el servicio que damos a nuestros clientes. Si primamos únicamente la velocidad de desarrollo y hacemos las aplicaciones «como sea» nos encontraremos que no escalan bien, que no soportan 20 usuarios concurrentes y que dejan de prestar servicio en el momento menos oportuno.
  4. Que tienen errores y que no son tratados correctamente, que no dejan trazas para que podamos investigar que les está ocurriendo. Con un código fuente ilegible, no documentado y difícil de mantener. En definitiva, tal vez en un año o dos, tendremos que hacer de nuevo la aplicación.

¿Merece la pena primar únicamente la velocidad de desarrollo?

Share