Michael BT Bell es un novelista, [1] artista, productor y arquitecto de software empresarial estadounidense , principalmente reconocido por desarrollar la metodología de Arquitectura de Software Incremental, [2] el marco de modelado orientado a servicios (SOMF) , [3] [ 4] [5] [6] [7] la construcción de arquitectura de software multidimensional (MSAC), [8] y la notación de modelado de computación en la nube (CCMN). [9] Su investigación y publicaciones innovadoras en los campos de la arquitectura de software , inteligencia artificial , arquitectura orientada a servicios , microservicios , ingeniería basada en modelos , computación en la nube y big data son reconocidas internacionalmente por su contribución a las comunidades de diseño y desarrollo de software .
Bell obtuvo su maestría en ciencias de la computación en 1992 en la City University de Nueva York ( CUNY ).
Después de graduarse, como desarrollador de software y consultor de arquitectura empresarial , dedicó su carrera a mejorar las operaciones comerciales y tecnológicas de las instituciones financieras de Wall Street . Desarrolló algoritmos y metodologías de software innovadores para plataformas de comercio electrónico de gran volumen . Esto incluyó módulos para la ejecución de aplicaciones comerciales, métodos de persistencia para grandes volúmenes de datos y diseño de implementaciones de software de red e Internet de alta velocidad .
Ha trabajado para JP Morgan Chase , Citibank , UBS-Paine Webber , Deutsche Bank , American Express , TD Waterhouse , Pfizer , AIG , Prudential y el Departamento de Asuntos de Veteranos de los Estados Unidos .
La metodología de construcción de arquitectura de software multidimensional (MSAC) se presenta en el libro Software Architect de Bell [10] publicado en 2023 por Wiley (editorial) . La sección Software Architect Toolbox del libro profundiza en dos puntos de vista principales de la MSAC:
1) Un ecosistema geométrico y topológico de arquitectura de software cuántico en el que se implementan aplicaciones y sistemas 2) Fundamentos del diseño de software
3D .
La construcción de arquitectura de software multidimensional (MSAC) introduce un entorno de producción cuántica en constante evolución, un espacio topológico que está sujeto a modificaciones estructurales geométricas durante el tiempo de ejecución y/o el tiempo de diseño.
Estos cambios en el espacio tridimensional de la estructura del ecosistema de implementación se deben a la evolución de los atributos del entorno arquitectónico y al comportamiento impredecible de las implementaciones de software que afectan el panorama de producción en su conjunto. La imagen animada a continuación muestra un entorno de producción dinámico que alberga entidades de software y las marcas que imprimen en la estructura de su espacio .
Cada implementación de software, como una aplicación de software , un servicio o un sistema implementado en un ecosistema geométrico y topológico MSAC, está representada por tres dimensiones: ancho/anchura, largo /profundidad y alto (como se ilustra en la siguiente imagen animada).
Este modelo de implementación 3D está diseñado para aumentar el nivel de especificidad del diseño de software necesario para la construcción, implementación, integración y mantenimiento en entornos de producción. La metodología MSAC se introduce para visualizar y diseñar construcciones de software 3D en cualquier espacio, aquí en la Tierra, en cualquier continente, región o estado, e incluso software implementado en el espacio u otros planetas.
Cada una de estas dimensiones de software especifica atributos estructurales de arquitectura únicos en un sistema de coordenadas . Por ejemplo:
Ancho : granularidad, modularidad, nivel de complejidad estructural, nivel de complejidad del código fuente
Longitud : escalabilidad, número de consumidores, número de interfaces, métricas de consumo de recursos informáticos
Alto : capas de arquitectura de software, pila de soluciones (pila de tecnología), pila de entorno de arquitectura de software, pila de capacidad técnica o empresarial
En 2008, Bell presentó el marco de modelado orientado a servicios (SOMF) [11] [12] a la comunidad de desarrollo de software en su libro Modelado orientado a servicios. [13]
El marco de servicios, impulsado por el modelado específico de la disciplina , fue diseñado para fomentar la consolidación de activos de software, la reducción de la redundancia de los sistemas y la aceleración del tiempo de comercialización. SOMF [14] incluye un lenguaje de modelado y una metodología de ciclo de vida (ver la imagen a continuación) adecuados para reducir la brecha entre las organizaciones de negocios y de tecnología de la información en la empresa.
El marco también incluye disciplinas y prácticas de modelado de sistemas de software, con el propósito de diseñar aplicaciones de software. Además, SOMF [15] ofrece una variedad de estilos arquitectónicos, como arquitectura empresarial , arquitectura de aplicaciones , arquitectura orientada a servicios , [16] y computación en la nube .
Además, SOMF consta de tres segmentos principales, como se ilustra a través del siguiente videoclip:
Segmento de prácticas y entornos de modelado. Prácticas de abstracción y realización superpuestas con tres entornos de modelado correspondientes: entorno conceptual, entorno de análisis y entorno lógico.
Segmento de disciplinas de modelado. Cada uno de los entornos de modelado contiene disciplinas correspondientes: disciplina de arquitectura conceptual, disciplina de descubrimiento y análisis de servicios y disciplina de arquitectura lógica.
Segmento de artefactos. Esta parte de SOMF identifica los principales artefactos necesarios para cada entorno de modelado.
Tradicionalmente, para promover el establecimiento y el crecimiento de una arquitectura empresarial de estado final, los arquitectos, generalmente profesionales de TI de alto nivel, entregan un diagrama que representa un panorama de producción futuro. [17] En la mayoría de los casos, estos diseñadores de software afirman que una arquitectura de este tipo es inquebrantable y podría soportar tendencias rápidas del mercado y una evolución tecnológica compleja. Su afirmación también parece asegurar que la arquitectura ilustrada funcionaría perfectamente en producción. ¿Lo haría?
Sin embargo, en muchos casos, esta arquitectura que se presenta en el papel es simplemente una propuesta académica que luego no logra brindar estabilidad del sistema, continuidad comercial ni un rendimiento excelente. En otras palabras, esta arquitectura especulativa tiende a fracasar debido a fallas de diseño y, lo que es más importante, a la falta de una estrategia de arquitectura organizacional.
Para abordar la implementación de aplicaciones y sistemas defectuosos en la producción y reducir el riesgo de dañar el entorno operativo, Michael Bell introdujo el enfoque de la arquitectura de software incremental, que exige la presentación de planos arquitectónicos a prueba de balas. Este diseño empresarial también debe estar certificado por una amplia gama de partes interesadas de la organización para evitar calamidades financieras y discontinuidades comerciales.
¿Cómo es posible entonces garantizar que el diseño ilustrado en el papel realmente generaría un entorno de producción estable? El término "estable" significa que los sistemas implementados cumplirían con los requisitos comerciales y no funcionales. La promesa de la arquitectura de software incremental, por lo tanto, se basa en el principio fundamental de "primero diseñar y luego desarrollar". Pero esto por sí solo no es suficiente para evitar la carga financiera causada por implementaciones fallidas. Igualmente importante es otro principio relacionado que exige modificar los estatutos de las organizaciones de desarrollo: la fase de construcción de software tal como la conocemos ahora, debe centrarse en demostrar que los supuestos de la arquitectura ciertamente funcionarán en la producción. En resumen, "la construcción de software debe seguir el ritmo de la evolución del diseño". Obviamente, no al revés. El término "evolución del diseño" significa que los arquitectos deben impulsar el ciclo de vida del desarrollo del producto, durante el cual la arquitectura del estado final podría modificarse de manera incremental, mientras que la construcción de software sigue las alteraciones del diseño hasta que se alcanza la madurez de la arquitectura.
Para demostrar que una arquitectura de estado final funcionaría sin problemas en la producción, el diseño de la gran empresa debería descomponerse en subarquitecturas. [18] Por lo tanto, esta descomposición de la arquitectura de estado final permitiría a los diseñadores profundizar en su arquitectura detallada y permitiría a los desarrolladores centrarse en la construcción de segmentos de la arquitectura, uno a la vez, o algunos en paralelo. Pero demostrar que cada segmento individual de la arquitectura de estado final funciona como está diseñado no significa que toda la arquitectura empresarial en su conjunto funcione sin problemas. Para verificar si una arquitectura de estado final es estable y podría soportar las presiones del entorno de producción, se debería considerar una prueba de estrés de la arquitectura general para asegurar su estabilidad y aptitud.
Considere el proceso de Arquitectura de Software Incremental, [19] como se muestra en el diagrama provisto a continuación:
1. Descubrimiento y análisis de la arquitectura de estado final. Determinación de sistemas y aplicaciones relacionadas en una propuesta de arquitectura de estado final .
2. Descomposición de la arquitectura de estado final. El proceso de descomposición se impulsa segmentando el gran diseño empresarial en regiones estructurales, conductuales y volátiles, de modo que los desarrolladores puedan demostrar que estas subarquitecturas realmente funcionarían en producción.
3. Verificación de la arquitectura de estado final. Las tareas de autenticación incluyen la fundamentación del diseño (construcción de software), pruebas de estrés de la arquitectura de estado final y planificación de la capacidad empresarial.
Michael Bell ha publicado varios libros y artículos. A continuación se muestra una selección: