Arquitectura Empresarial Agil para la Transformación Digital.

La transformación digital se define como un proceso de cambio fundamental en las empresas iniciado por nuevas ventajas competitivas a través de la evolución de TI en una parte esencial de la creación de valor.

Para desbloquear estos nuevos potenciales, las empresas convierten sus productos en servicios y comienzan a operar junto con sus clientes en la creación conjunta con el objetivo de maximizar el valor. Los habilitadores importantes son los sistemas sensibles al contexto que ayudan a adaptar los servicios a los requisitos individuales y situacionales de los clientes. Para ser capaces de ofrecer estos servicios digitalizados, las empresas deben pensar en procesos comerciales modulares, multifuncionales y distribuidos que les permitan la integración en los ecosistemas. El resultado del cambio es la capacidad de crear valor personalizado para el cliente a costos de producción en masa.

La presente gráfica permite identificar una propuesta ágil para acompañar el proceso de Transformación Digital. El primer paso, es derivar el modelo de negocio de la estrategia de negocio digital, el modelo de negocio contiene información como propuesta de valor, segmentos de clientes o flujos de ingresos. El segundo paso es elaborar una arquitectura ideal. El objetivo de este paso es detallar el modelo de negocio de una manera muy aproximada. La arquitectura ideal contiene descripciones de los principales procesos, principales servicios de TI e información que se necesita para su realización. Una característica importante es que no hay restricciones. El objetivo de la arquitectura ideal es dar espacio al arquitecto para nuevas ideas sin tener en cuenta los sistemas heredados o las restricciones estratégicas. 

Posteriormente, la arquitectura real se deriva de la arquitectura ideal. En este paso, se consideran la estrategia de transformación y la arquitectura actual. Dado que el cambio fundamental durante una transformación digital debe realizarse de forma incremental, siempre hay sistemas e interfaces heredados que se deben tener en cuenta. Sin embargo, el arquitecto no debe seguir utilizando sistemas heredados a ningún precio. La acumulación de arquitectura sigue ideas similares a las de la acu-mulación de productos en el enfoque de scrum. En función de las diferencias entre la arquitectura actual y la real, las historias de usuario se definen en el backlog de arquitectura. Estas historias de usuario son sistemas de servicio encapsulados con interfaces definidas. Un conjunto definido de historias de usuarios puede ejecutarse a través del microciclo independientemente de otras historias de usuarios. Describen a los usuarios, la funcionalidad deseada y el beneficio. No hay detalles sobre el software o hardware usado. El objetivo de esto es crear espacio libre para el equipo de desarrollo. Dentro de este jercicio, se priorizan las historias de usuario. Además, se define qué historias de usuario crea la empresa y cuáles proporcionan los socios dentro del ecosistema. Los servicios que forman parte de la competencia central o que no están disponibles en el mercado se desarrollan sin ayuda.

 Después de ejecutar el ciclo macro, el ciclo micro se puede iniciar por primera vez. Este ciclo comienza con la elección de las historias de usuario prioritarias del backlog. La cantidad depende de la velocidad de cambio que busca una empresa. El siguiente paso es la fase de construcción o de selección del servicio. Durante la fase de construcción, los desarrolladores implementan las historias de usuario en un sprint. Pero en la mayoría de los casos, la selección de servicios listos para usar es la mejor opción. Especialmente cuando un servicio no es parte de la competencia central y ya está disponible en la plataforma utilizada, se debe evitar un desarrollo interno. Después de la implementación o compra, se prueba cada historia de usuario. Las pruebas se pueden realizar junto con un cliente de prueba o en un banco de pruebas aprobado previamente por las partes. El siguiente paso es la revisión. Hay tres decisiones posibles. La primera posibilidad es que la historia de usuario se marque como completada. Luego, los equipos comienzan con la siguiente historia de usuario. La segunda posibilidad es que se requieran adaptaciones y el microciclo tenga que empezar de nuevo. La tercera posibilidad es que haya hallazgos que tengan un impacto en toda la arquitectura. Entonces el ciclo macro comienza de nuevo. Con el primer paso del ciclo macro, la arquitectura aún debe seguir mejorando. Con cada pase, hay más detalles. El ciclo macro siempre debe dar suficiente espacio para las decisiones en el ciclo micro. Son compatibles para encontrar un entorno de prueba adecuado.