ALM y la realidad del negocio
Estoy de acuerdo, en general, con quien opine que ALM representa, principalmente, beneficios para las áreas de negocio en una organización y que en función de eso existen beneficios para las áreas técnicas. Sí, pero no estoy de acuerdo en tomar eso como excusa para ponerle un carácter secundario al trabajo de las áreas técnicas.
Sin embargo, en algunos casos, lamento observar que quien pone tal carácter secundario no es nadie menos que las propias áreas técnicas. Una evidencia de eso ocurre cuando existen planes para la creación de aplicaciones y tales planes incluyen actividades sólo para satisfacer un procedimiento dictado “metodológicamente” pero cuyo valor de negocio es dudoso, por decir lo menos. Un ejemplo de tal actividad es la producción excesiva de documentos estáticos que a la larga nadie lee. Y una razón por la cual pierde sentido su lectura no es que estén mal hechos, pues es común que tales documentos contengan preciosos diagramas finamente elaborados e intercalados con grandilocuentes digresiones, sino que su contenido rápidamente pierde contacto con la dinámica realidad del negocio, convirtiéndose en letra muerta.
Tal situación puede caracterizarse como un patrón, es decir, algo recurrente e identificable en una organización; en muchos casos tal patrón se torna negativo para el negocio. Del mismo modo se pueden identificar otros patrones, tanto positivos como negativos, durante la creación de soluciones de negocio basadas en software.
Otro ejemplo de patrón es el nivel de involucramiento de las áreas de negocio durante el ciclo de vida de una solución. Si la solución es algo que realmente importe al negocio entonces un alto nivel de cuidado y una esmerada atención a los detalles en las especificaciones de tal solución representa un patrón positivo. Tal patrón incluye tanto una especificación concisa de la funcionalidad deseada así como de las pruebas de aceptación de tal funcionalidad. Así como el poder para distinguir la prioridad de negocio entre un conjunto de funciones.
Estrictamente, ALM no trata sólo de adoptar patrones positivos sino, y principalmente, de adoptar un esquema de autocorrección por el cual una organización logre identificar sus propios patrones existentes y pueda, progresivamente, eliminar aquellos patrones que no sirvan al negocio.
El cerebro humano —dicen los neurocientíficos— “alambra” rutas específicas de conexiones entre las células de nuestro sistema nervioso —llamadas neuronas—. Tal “alambrado” forma una especie de patrón o modelo que sirve para hacer más eficiente la operación que el cerebro realiza al interpretar la realidad percibida: en lugar de procesar nuevamente cada percepción nuestro cerebro busca la mejor coincidencia con patrones ya existentes, y completa la percepción con base en lo previamente procesado. Es decir, somos animales basados en hábitos mentales y se requiere un esfuerzo explícito para identificarlos y pensar por encima de tales hábitos.
Por lo que podemos encontrar patrones por todos lados. Hay patrones organizacionales, patrones de procesos, de arquitectura, de diseño, de implementación, etc. Una muy breve lista de referencias al respecto se puede encontrar buscando la palabra «pattern» en mi página de ligas: Links.
Del tema de patrones también se habló en el reciente evento ALM Summit 2011, en particular en la charla de Tim Lister: Project Patterns: From Adrenalin Junkies to Template Zombies.