Descripción
En un pasado no muy lejano, en un proyecto de tamaño decente en el que estaba trabajando, convencí a un desarrollador senior, un ingeniero de software altamente calificado y experimentado, para que comprara una copia de “Documentación de arquitecturas de software: vistas y más allá”. El proyecto era un poco escaso en términos de documentación y proceso, el equipo lo sabía muy bien y yo estaba tratando de ayudar a mejorar la situación. Poco después de que llegara el libro, una breve conversación en el pasillo vio fuertes expresiones de entusiasmo.
Tan fuerte que se convocó una reunión adicional del equipo del proyecto para la próxima semana. En la reunión, el ingeniero senior mostró este libro maravilloso y expuso muchos de sus mensajes clave al equipo. Por supuesto, estaba complacido de que el libro que había recomendado hubiera tenido tanto impacto. Luego, la siguiente línea me llamó la atención: “Leí las primeras 30 páginas, que eran geniales, pero solo hojeé el resto”. Me sorprendió un poco esta declaración. ¿Por qué el contenido de este libro tan informativo e increíblemente útil fue mayormente desnatado? Seguramente alguien podría aprender mucho invirtiendo un poco de tiempo en leer los capítulos más técnicos. Ciertamente lo hice. Esto me hizo reflexionar sobre la causa raíz de este problema, ya que realmente quería inculcar más conocimiento arquitectónico en los equipos de desarrollo con los que estaba trabajando.
En mi carrera como arquitecto de software itinerante, pasé mucho tiempo asesorando proyectos, brindando habilidades y conocimientos de diseño arquitectónico. Estos proyectos han abarcado muchas organizaciones y diferentes dominios de aplicación durante la última década. Sin embargo, un tema común es que trabajo principalmente en lo que se consideraría dominios generales de aplicaciones de tecnología de la información (TI). El tipo de aplicaciones que crean las instituciones financieras, las empresas de servicios públicos y las agencias gubernamentales para administrar y entregar información a sus clientes y socios comerciales. Estos son, en términos generales, sistemas de información empresarial que aprovechan las tecnologías comerciales estándar (COTS) como bases de datos, middleware, aplicaciones empaquetadas y tecnologías web. Ocasionalmente trabajo en proyectos en lo que se consideran dominios más técnicos, como aplicaciones militares, de control integrado y de telecomunicaciones.
Puedo hacer esto porque muchos de los problemas arquitectónicos subyacentes son los mismos en todos los dominios. Sin embargo, la forma en que estos problemas se manifiestan, las soluciones tecnológicas particulares que se adoptan comúnmente y los vocabularios técnicos utilizados son radicalmente diferentes. Por lo tanto, me especializo en sistemas de TI, aquí es donde espero poder agregar más valor. A veces, mi función consiste en diseñar nuevas arquitecturas de aplicaciones o, en realidad, evaluar con más frecuencia las existentes y ayudar a que evolucionen. En el proceso, trabajo en estrecha colaboración con los miembros de los equipos de proyectos. Esto es agradable Siempre aprendo de ellos, y espero que ellos a veces aprendan de mí. Una característica sorprendentemente común de la mayoría de estos proyectos es la falta de un diseño arquitectónico explícito. Los requisitos funcionales generalmente se capturan, se acuerdan con las partes interesadas y se gestionan, y los diseños que abordan las especificaciones funcionales se desarrollan en detalle. Pero los problemas de arquitectura, el “cómo” la aplicación logra su propósito, el “qué” sucede cuando las cosas cambian y evolucionan o fallan, con frecuencia están implícitos (esto significa que están en la cabeza de alguien) en el mejor de los casos.
En el peor de los casos, simplemente no se abordan de ninguna manera que pueda describirse en términos que no sean accidentales. Con frecuencia, cuando solicito una descripción general de la arquitectura de la aplicación y los requisitos no funcionales de conducción en la primera reunión técnica, las personas comienzan a dibujar en una pizarra. O me muestran el código. Cualquiera de estos rara vez es una buena señal. Los problemas y riesgos de las malas prácticas arquitectónicas son bien conocidos y documentados dentro de la profesión de ingeniería de software.
Una gran cantidad de excelente conocimiento arquitectónico se captura en libros, revistas e informes ampliamente accesibles de miembros del Software Engineering Institute (SEI), Siemens y varias otras instituciones industriales y académicas de renombre. Entonces, reflexioné más, ¿por qué esta información sobre las mejores prácticas y herramientas no está presente en la industria de TI? En respuesta, sólo puedo plantear lo siguiente. En general, las muchas fuentes de información sobre arquitectura de software son extremadamente exhaustivas, aprendidas y extensas, lo que requiere una gran inversión de tiempo para digerirlas por completo. Los libros de SEI, por ejemplo, se basan en muchos años de experiencia trabajando principalmente en aplicaciones militares. Por lo general, estos comprenden grandes sistemas de software integrados en tiempo real, con un conjunto de enfoques arquitectónicos y problemas que tienen un énfasis particular en este dominio de aplicación.
Déjanos un comentario
No hay comentarios