Desarrollo de software. Antipatrón. Diseño con arquitectura impuesta

Hay que entender que una organización quiera normalizar los desarrollos que se realizan para la misma, con el objeto de tener un control sobre las tecnologías y soluciones utilizadas en los trabajos y de esta forma reducir el riesgo de cautividad del proveedor (aunque en muchos casos, este riesgo viene dado por su conocimiento funcional) y disminuir los costes de mantenimiento.

De hecho, considero una buena práctica que una organización tienda a eso porque de lo contrario lo que se tiene es un caos tecnológico muy complicado y caro de gestionar.

Ahora bien, cualquier medida llevada al extremo no suele ser positiva. Puede que exista algún tipo de desarrollo que requiera (para ser mucho más óptimo) que la arquitectura, tecnología, metodología de desarrollo o procedimientos de testing, sean distintos a los establecidos.

La aceptación de esa alternativa no debe quedar a expensas de un capricho o de una decisión de carácter individual sino que debe ser expuesta dentro de las posibles alternativas de solución al conjunto de personas que dirijan el desarrollo y mantenimiento de sistemas de información dentro de la organización.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: