Con base en lo que me dicta mi conciencia crítica profesional, tengo la responsabilidad de intentar traer a su atención algunos puntos para su consideración, amable colega en la industria de las tecnologías de información (TI), con respecto al nivel de servicio que ofrecemos a nuestros usuarios y clientes. Esto no es relevante para un solo proyecto, sino para la proyección de nuestro nivel profesional en creación de soluciones de negocio basadas en software. A la fecha, observo algunos intentos nuevos por mejorar en la categoría de Proceso (en algunos casos, Scrum u otros entre los métodos ágiles), pero en la categoría de Diseño/Arquitectura aún observo hábitos que para mí no son convincentes pues no tienen base sobre la cual apoyar mi confianza. Mi punto concreto es que también es necesario intentar mejoras en el nivel de destreza y madurez en la práctica de la arquitectura de soluciones de negocio basadas en software; es decir, desde la definición del problema, pasando por la elaboración iterativa e incremental de una posible solución, hasta el retiro total de la misma. Un ejemplo es que cualquier propuesta de solución debe ser sometida a un estricto escrutinio crítico para ver si realmente representa una solución sólida, estable y sostenible ante el problema de negocio en cuestión. Tal evaluación crítica requiere pensar arquitecturalmente desde múltiples perspectivas. Por ejemplo, el manejo de excepciones: ¿cómo se va a monitorear cada tipo de excepción por parte del personal a cargo de las operaciones en el ambiente de producción, o cualquier otro ambiente operativo?, ¿qué datos tendrá ese grupo para diagnosticar con tino? ¿Son suficientes dichos datos para determinar, con reloj en mano, la remediación adecuada? ¿Se tienen respuestas claras y son satisfactorias para los responsables de monitorear un ambiente productivo? ¿No? Entonces sugiero que se demanden respuestas claras y oportunas para evitar descalabros e insatisfacciones por parte de usuarios y clientes.
☛ Mi punto principal, en general, es que cada uno dentro de los grupos técnicos de cada proyecto (e.g., Scrum Development Team) necesita mejorar en su práctica de pensar arquitecturalmente desde su área de competencia. De esa manera lograremos aproximarnos a mejores soluciones ante los problemas de cada proyecto.
Mi intención no es pretender una respuesta que cierre la pregunta inicial, sino nutrir posibles conversaciones y discusiones sobre pensar arquitecturalmente con cualquiera interesado en el tema. La clave es no sólo incluir miembros de los grupos técnicos (e.g., Scrum Development Team), sino también incluir miembros del negocio en cuestión (e.g., Scrum Product Owner). Es decir, pensar arquitecturalmente no sólo es relevante para grupos técnicos de TI, sino principalmente es relevante para el diseño técnico —i.e., detallado— de las estrategias comerciales de los negocios hacia sus propios clientes (lo cual sería parte de la carnita rescatable de la así llamada “arquitectura empresarial”).
¿Cómo pensó el grupo de albañiles, arquitectos e ingenieros de, por ejemplo, la Torre Latinoamericana –en la Ciudad de México– para que se mantuviera en pie todos estos años? ¿Cuáles valores, principios, prácticas y hábitos fueron parte de su ambiente profesional como para funcionar como grupo de trabajo con tales resultados? El resultado de su modo de pensar y actuar ha permitido que muchos habiten tal edificio por muchos años sin preocuparse de si hoy permanecería en pie. Con su ambiente profesional no sólo edificaron un inmueble material, sino que edificaron bases sobre las cuales se apoyó la confianza de todos en lo que hacían.
Antes pensaba que crear software era una disciplina de ingeniería y que todo proyecto debería tan sólo seguir prescripciones ya establecidas y probadas. Pero después de indagar comprobé que no debe, ni puede, ser así para cada proyecto. Por lo cual, el ejemplo anterior me sirve para pensar más en cómo un ambiente profesional (i.e., conjunto de valores, principios, prácticas, hábitos, etc.) puede ser un caldo de cultivo para ese tipo de resultados.
Una inferencia obvia es que un ambiente profesional debe enfocarse en edificar confianza en lo que se plantea y se hace ahí. Una base sólida sobre la cual apoyar la confianza es la evidencia material verificable, no sólo las palabras y las buenas intenciones. Si de confianza se trata: Lo importante no es quererlo, creerlo o decirlo —eso cualquiera lo hace—, sino demostrarlo. Así se está en mejor posición para cimentar una confianza duradera.
Las profesiones confiables hoy en día se derivan de la confianza que aportan los procesos de las ciencias. Por lo que regresar a los básicos del pensamiento científico es parte de mejorar una profesión hoy en día y de mejorar los ambientes en donde se ejerce cualquiera de las profesiones contemporáneas. Pero, por favor, debe quedar claro, aquí no me refiero al adefesio de “el método científico” que se expone en los sistemas escolarizados tradicionales. Eso sólo existe en las [j]aulas de dichas escolarizaciones. Aquí me refiero a cada perspectiva adulta, amplia, profunda y compleja que del pensamiento científico se ha evaluado desde la filosofía de la ciencia, i.e., epistemología.
Para no extenderme más aquí, intentaré provocarle la curiosidad, amable lector, diciendo que la confianza en las ciencias inicia con la destreza para distinguir entre conocimiento y meras opiniones.
Además, para ser explícito, propongo que pensar arquitecturalmente está ligado de manera directa con el autocultivo necesario para realizar estrictos escrutinios críticos. Pero esa relación no agota los modos de pensamiento relacionados. Los modos de pensar en la categoría del orden superior, i.e., la metacognición, cooperan entre sí necesariamente: el pensar creativo, el pensar crítico, el pensar solidario –por mencionar algunos– interactúan por demanda en un pensar arquitectónico.
