TOGAF ADM Fase C: desarrollo de la arquitectura de la aplicación
de un vistazo
Descripción general de TOGAF ADM
- Fase C de TOGAF en acción
- ¿Qué es la arquitectura de aplicaciones?
- ¿Cuál es el papel del arquitecto empresarial en la fase C?
- ¿Cuál es el papel del arquitecto de aplicaciones?
- ¿Cuál es el papel del arquitecto de seguridad en la arquitectura de aplicaciones?
- ¿Cuál es el papel del equipo de EA en la arquitectura de aplicaciones?
Conocimientos esenciales de la fase C
Reflexiones finales sobre TOGAF ADM Fase C - Arquitectura de aplicaciones
Descripción general de TOGAF ADM
El TOGAF ADM es un enfoque lógico para la creación de conocimiento. Conocimiento utilizado para desarrollar un Arquitectura empresarial que guía el cambio efectivo. Luego, el conocimiento garantiza que se alcance el valor esperado.
El TOGAF ADM se divide en fases, cada fase se centra en la creación de conocimiento que se utiliza para:
- Seleccione el camino a seguir y el objetivo
- llevar a cabo gobernanza de la implementación
- Evaluar el camino a seguir y corregir el rumbo
¿Qué es TOGAF Fase C?
La fase C avanza más en el concepto de dominios de arquitecturaEsta fase desarrolla la arquitectura de la aplicación y la arquitectura de datos. Formalmente, la Fase C se divide en: Dominio de arquitectura de datos y el dominio de arquitectura de aplicaciones son individuales.
Al igual que la Fase B, la Fase C se basa en la Visión de la Arquitectura. Hay un cambio: la Fase C tiene la obligación adicional de habilitar la arquitectura empresarial. No se trata de tratar la arquitectura empresarial como requisitos, sino de confirmar que los objetivos resumidos en desarrollo se mantienen unidos.
Los cambios en un dominio imponen restricciones y requisitos a otros dominios. El objetivo es encontrar el mejor conjunto de cambios en todos los dominios.
Utilizando los pasos de la Fase C, los arquitectos desarrollan los siguientes conocimientos:
- ¿Qué arquitectura de referencia acelerará el desarrollo de la arquitectura?
- ¿Qué puntos de vista impulsarán un análisis relevante para que las partes interesadas seleccionen entre alternativas de arquitectura?
- ¿Qué modelos de arquitectura de aplicaciones y modelos de datos ayudarán a encontrar la fuente de la deficiencia y los cambios que la abordarán?
- donde los cambios en la arquitectura de la aplicación impulsan cambios en otros dominios
- donde los cambios en otros dominios impulsan cambios en la arquitectura de la aplicación
Crea los siguientes productos de obras centrales:
- Vistas que analizan la arquitectura de los sistemas de información del candidato en términos de las preocupaciones de las partes interesadas.
- que una arquitectura de aplicación objetivo actual y candidata
- Brechas en la arquitectura de aplicaciones
- Productos de trabajo de candidatos que cambian el negocio
La fase C se centra en aspectos como el diseño de la aplicación, el flujo de datos, la integración, el enfoque de desarrollo, la construcción frente a la compra y la planificación de cambios. La evaluación y la comprensión adecuadas de esta fase son fundamentales.
¿Qué es TOGAF Fase C?
En TOGAF Fase C, está creando la arquitectura de la aplicación. Arquitectos de aplicaciones Liderar el desarrollo de la arquitectura de su aplicación. El decisiones arquitectónicas realizados en la Fase C para la arquitectura de aplicaciones interactúan con las decisiones tomadas en cada dominio de arquitectura empresarial.
Fase C en acción
La arquitectura de la aplicación ayudará a responder las siguientes preguntas:
- Cómo la cartera de aplicaciones permite la captura de valor: Modelo de desarrollo de aplicaciones
- Dónde se inyecta el costo en la cartera de TI: modelo funcional
- Donde se inyecta rigidez en la cartera de TI: Modelo de Integración
- Cómo funciona la empresa: Modelo de sistema
- Sistemas necesarios para entregar el producto o servicio: Modelo del Producto
- Las cosas que una organización debe ser capaz de hacer: modelo funcional
- El flujo de información que se requiere para realizar las actividades de una empresa: Modelo de Integración
- Las actividades completas que realiza una empresa, generalmente agrupadas para mostrar cómo se relacionan entre sí: Modelo de servicio
- Qué es la cartera de software: Modelo físico
Siempre tenga en cuenta que usted está buscando mejorar la organización. La mejora requiere cambios y entrega valor. El valor y el costo del cambio se pueden medir. La incertidumbre siempre disminuye el valor potencial. La incertidumbre siempre aumenta el costo. Tratamos la incertidumbre como un impacto geométrico. Un poco de incertidumbre disminuye mucho el valor potencial.
Al leer, tenga en cuenta que hay muchos usos de los mismos términos. Busque el propósito del modelo y no se quede atrapado cuando la etiqueta difiera de cómo lo llamaría. Por ejemplo, lo que usted llama un modelo funcional, alguien más lo llamará un servicio. En nuestro consultoría de arquitectura empresarial, siempre nos enfocamos en lo que estamos tratando de entender, no en cómo se llama el modelo.
Diferentes modelos explicarán diferentes aspectos de la empresa. Juntos, los modelos y los cambios necesarios forman la arquitectura de la aplicación.
¿Qué es la arquitectura de aplicaciones?
Una arquitectura de aplicación es una descripción de su cartera de software completa que le indica cuándo comprar, cuándo usar SaaS y cuándo desarrollar. Le dice dónde debe poner límites entre los sistemas. Le dice cómo abordará el ciclo de vida de su software.
Podemos garantizar que su arquitectura de aplicación actual no está alineada con su arquitectura empresarial. Una arquitectura de aplicación requiere un arquitectura empresarial. El desarrollo de la arquitectura empresarial requiere que los arquitectos de aplicaciones se unan a ellos para comprometerse con las partes interesadas.
Con la parte interesada y el arquitecto empresarial, el arquitecto de aplicaciones explora cómo las opciones de software permiten y limitan los objetivos de la organización. Consideramos posibles mejoras para comprender el impacto inmediato y a mediano plazo. Juntos, los cambios potenciales que ofrecen muy poco, requieren demasiado trabajo o tienen demasiada incertidumbre, se eliminan de la hoja de ruta de la arquitectura.
Cuando estamos desarrollo de equipos de arquitectura empresarial, le decimos a arquitectos empresariales dos hechos centrales sobre TOGAF Fase C - Arquitectura de aplicaciones. Primero, hasta que tengas un modelo de desarrollo de aplicaciones, no puedes continuar. Hasta que sepa cómo sus opciones de aplicación habilitan y limitan su arquitectura empresarial, los detalles de sus aplicaciones no tienen sentido. En segundo lugar, si creen que necesitan saltar a la integración y la funcionalidad de la aplicación, siempre desarrollarán una arquitectura de aplicación de baja calidad.
en un moderno empresa transformada digitalmente, todos los dominios de la arquitectura interactúan. Las opciones en un dominio habilitan, entregan o bloquean resultados en otro dominio. La mayoría de los objetivos comerciales dependen de arquitectura de TI correctaIrónicamente, solo podemos desarrollar la arquitectura de aplicación adecuada si tenemos una arquitectura empresarial sólida.
¿Cuál es el papel del Arquitecto Empresarial en la Fase C?
En TOGAF Fase C, el papel del arquitecto empresarial es proteger todo el valor. Dependiendo de las habilidades de los arquitectos de dominio, el arquitecto empresarial debe completarlo. Por ejemplo, es posible que un arquitecto de aplicaciones no vea el impacto de los cambios en la arquitectura empresarial. O es posible que no articulen un requisito en términos en los que el arquitecto de seguridad pueda actuar.
El papel más importante del arquitecto empresarial es cruzar fronteras. Ya sean límites de dominio, habilidad o autoridad, el arquitecto empresarial debe cruzarlos.
¿Cuál es el rol del Arquitecto de Aplicaciones en la Fase C?
En la fase C de TOGAF, esperamos que el arquitecto de aplicaciones entregue la arquitectura del dominio. Eso requiere desarrollar modelos que muestren la fuente de la deficiencia y cómo superarla. Liderarán el análisis de compensación con las partes interesadas para determinar la arquitectura objetivo.
El arquitecto de la aplicación deberá colaborar con los demás arquitectos del dominio.
Desactivar la arquitectura empresarial. Conocer y comprender la Modelo operativo y los atributos de Competencia y Automatización del modelo de capacidad.
¿Cuál es el papel del Arquitecto de Seguridad en la Fase C?
En la fase C de TOGAF, esperamos que el arquitecto de aplicaciones entregue la arquitectura del dominio. Eso requiere desarrollar modelos que muestren la fuente de la deficiencia y cómo superarla. Liderarán el análisis de compensación con las partes interesadas para determinar la arquitectura objetivo.
El arquitecto de la aplicación deberá colaborar con los demás arquitectos del dominio.
Desactivar la arquitectura empresarial. Conocer y comprender la Modelo operativo y los atributos de Competencia y Automatización del modelo de capacidad.
Tenga en cuenta que las deficiencias en un dominio a menudo se resuelven en otro, y los cambios en un dominio a menudo imponen costos y cambios en otro.
¿Cuál es el papel del equipo de EA en la arquitectura de aplicaciones?
Tenga en cuenta que las deficiencias en un dominio a menudo se resuelven en otro, y los cambios en un dominio a menudo imponen costos y cambios en otro.
Interacción con TOGAF Fase B, Fase D y Fase E
Los enfoques en cascada no cumplen. La arquitectura empresarial de mejores prácticas no es una actividad en cascada. El único enfoque exitoso requiere desarrollar la arquitectura empresarial, la arquitectura de aplicaciones, la arquitectura de datos, la arquitectura tecnológica y arquitectura de seguridad simultaneamente. El desarrollo simultáneo requiere un enfoque ágil de lo suficiente para probar las restricciones en cascada.
La secuencia clásica implícita en muchos diagramas TOGAF ADM es el orden en que podemos cerrar el desarrollo de la arquitectura, no iniciarlo.
No caiga en la ilusión de que 'el negocio' está separado de alguna manera de sus aplicaciones, datos e infraestructura. Eso no era cierto en el pasado, y en una empresa digital moderna es irrisorio. Esa ilusión es la forma más rápida de eliminar agilidad empresarial o la posibilidad de transformación digital éxito.
Los arquitectos de aplicaciones tienen un papel fundamental en un equipo de arquitectura empresarial. Nada sucede en una empresa digital moderna sin software. Las malas opciones de aplicación paralizarán 'el negocio.' Los arquitectos de aplicaciones son especialistas en un dominio de arquitectura. No pueden diseñar su dominio sin un compromiso regular con arquitectos de negocios, datos, tecnología y arquitectos de seguridad.
Descargar Guía de inteligencia artificial para líderes empresariales
Descargar Guía para líderes empresariales sobre inteligencia artificial Las organizaciones que aplican con éxito tecnología innovadora han tenido una ventaja competitiva. La tecnología innovadora no viene acompañada de patrones de éxito establecidos y mejores prácticas. La tecnología innovadora es novedosa y […]
Descargue la Introducción al estándar TOGAF, 10.ª edición
Descargar Introducción al estándar TOGAF®, 10.ª edición El estándar TOGAF, 10.ª edición facilita la adopción de las mejores prácticas de arquitectura empresarial. Separa los conceptos universales de las mejores prácticas comprobadas. El subrayado estándar donde […]
Descargar la guía de planificación basada en la capacidad
Descargar la guía de planificación basada en capacidades Conduzca siempre para obtener valor. ¡La mitad de la mejora es un desperdicio de 100%! Nadie le enseña a un águila a gatear, caminar o correr. ¡Las águilas vuelan! Descargue Enseñe a volar a sus águilas: planificación basada en capacidades […]
Descargar la guía de evaluación de la capacidad de la arquitectura empresarial
Descargue la Guía de evaluación de la capacidad de la arquitectura empresarial Descargue una Guía de evaluación de la capacidad de la arquitectura empresarial. La planificación basada en la capacidad es una de las técnicas de mejora de la arquitectura empresarial más poderosas. La mejor práctica de la planificación basada en la capacidad utiliza la capacidad como una gestión […]
Descargar ejemplos de principios de arquitectura empresarial
Descargar principios de arquitectura de muestra Descargue principios de arquitectura empresarial de muestra. Los principios de la arquitectura empresarial identifican cómo abordar un problema o una decisión. El enfoque siempre lo lleva hacia sus prioridades duraderas. Descargue los principios de arquitectura empresarial de muestra […]
Descargue la Guía de gobierno de la arquitectura empresarial
Descargue la Guía de gobierno de la arquitectura empresarial Descargue la Guía de gobierno de la arquitectura empresarial para comprender las mejores prácticas para dirigir y controlar el desarrollo de la arquitectura y cambiar para obtener los resultados esperados. Descargue la Guía de Gobernanza de la Arquitectura Empresarial […]
Descargar Integración TOGAF y SABSA
Descargar Integración de TOGAF y SABSA Reúna SABSA, el mejor marco de arquitectura de seguridad del mundo, y TOGAF, el marco de arquitectura empresarial estándar de la industria. Descargar Integración TOGAF y SABSA Integración TOGAF y SABSA Incluye SABSA utiliza […]
Descargar la arquitectura de referencia de la capacidad de la arquitectura empresarial
Descargar Arquitectura empresarial Arquitectura de referencia de capacidades La arquitectura de referencia de capacidades de la arquitectura empresarial acelerará el establecimiento y la mejora de su equipo de EA. Diseñe su equipo de arquitectura empresarial para el éxito. Identifique y mejore la arquitectura de su empresa […]
Descargar informe de arquitectura empresarial ágil
Descargar el informe de arquitectura empresarial ágil El informe de arquitectura empresarial ágil cubre nuestra experiencia: la arquitectura empresarial ágil es real, práctica y valiosa. Lo hacemos todos los días. Los informes de campo unen los conceptos teóricos y […]
Descargar el estudio de caso de arquitectura empresarial ágil
Descargue el estudio de caso de arquitectura empresarial ágil Descargue el estudio de caso de arquitectura empresarial ágil para ver un ejemplo que desarrolla una capacidad de EA y una arquitectura útil al mismo tiempo. Cubrimos los seis casos de uso […]
Conocimientos esenciales de la fase C
Todas las Fases de TOGAF ADM lo llevan a desarrollar el conocimiento que necesita. El resultado de la Fase C es la arquitectura de aplicación candidata incluida dentro de la arquitectura de sistemas de información candidata.
| Producto y resultado | Conocimiento esencial |
| El arquitectura de aplicación arquitectura de dominio aprobado por las partes interesadas para el problema que se está abordando, con un conjunto de lagunas, y trabajar para eliminar las lagunas entendidas por las partes interesadas. | ¿Cómo la cartera de software actual no cumple con las preferencias de las partes interesadas?
¿Qué debe cambiar para permitir que la cartera de software satisfaga las preferencias de las partes interesadas? (Brechas) ¿Qué trabajo es necesario para realizar los cambios que son consistentes con el valor adicional que se está creando? (Paquete de trabajo) Cómo se ajustan la prioridad y preferencia de las partes interesadas en respuesta al valor, el esfuerzo y el riesgo de cambio. (Requisitos de las partes interesadas) |
Tabla 4 de Guía de la serie TOGAF: Guía del arquitecto empresarial para desarrollar arquitectura
Fase C Bare Bones
En la Fase C, podemos simplificar el trabajo de un arquitecto de aplicaciones para determinar cómo debería mejorar una empresa. Eso requiere comprender en qué está tratando de ser bueno, dónde no está a la altura de los mejores y qué debe cambiar para permitir ser el mejor.
Los huesos básicos de la Fase C son:
- Saber cómo el portafolio de aplicaciones permite capturar valor
Toda organización tiene una cadena de valor. Actividad que transforma un insumo en algo más valioso para sus clientes. Las aplicaciones realizan la creación de valor o brindan mantenimiento de registros. Tradicionalmente, casi todo el software proporcionaba mantenimiento de registros.
Debe optimizar su software para funciones: creación de valor o mantenimiento de registros. Asuma el mantenimiento de registros. No confunda el importante papel del mantenimiento de registros con la creación de valor.
Conocer la fuente del costo y la complejidad.
Cada cartera de aplicaciones genera costos y complejidad. Pensamos en el software como un reloj complejo que se ensambló con el tiempo. Conectamos todo con todo. Con productos digitales y servicios de TI ubicuos comprensión de ITFM es una habilidad fundamental.
Debe optimizar su cartera principal para eliminar el costo sostenido y la complejidad. Debe habilitar agilidad empresarial. Las organizaciones digitales modernas solo pueden mejorar al ritmo del software.
- Saber seleccionar software
Hay cuatro modelos de software: SaaS, suites empresariales, paquetes comerciales especializados y desarrollo personalizado. Cada uno tiene un modelo de optimización y costo diferente. Debe aplicar el modelo de software correcto en los lugares correctos.
- Saber cuándo el software es parte de 'el producto'
Nuestras organizaciones entregan un producto o servicio. Software que es 'el producto' difiere mucho del software que respalda el negocio.
- Conocer el flujo de información.
Las personas son infinitamente flexibles. Podemos decidir compartir información. Podemos ver proactivamente una situación y reaccionar. El software hace exactamente lo que se le dice. El software solo hace lo que se le dice.
El flujo de información ocurre alrededor del software para hacer lo correcto. Este tipo de flujo de información rompe la agilidad empresarial. Paralizan la eficiencia. Estos flujos impulsan el costo.
- Conocer las expectativas del software.
A veces necesitamos un registrador ocasional. A veces necesitamos un sistema autónomo. La mayoría de las veces necesitamos algo que ayude sin demasiados gastos generales. Aprovechamos los conceptos y atributos en modelos de capacidad para guiar las elecciones sobre la arquitectura de nuestra aplicación. Ver el Guía de evaluación de la capacidad de la arquitectura empresarial.
- Saber lo que debe hacer la organización
Cada empresa tiene un conjunto de procesos que debe realizar: creación de valor primario, soporte y administración. Cada uno de ellos necesita software. Cada uno de ellos crea y produce información. Necesita saber qué son, la información que consumen y quién los hace.
- ¿Qué debe cambiar para ofrecer la mejor cartera de aplicaciones?
Desarrollamos arquitectura de aplicaciones para mejorar una organización. La mayoría de los cambios no hacen una diferencia material. La mayoría de los cambios juegan en los bordes. Concentre su tiempo en cambios materiales que impulsen una agilidad empresarial significativa, costos o creación de valor.
Los tres elementos esenciales de finalización de la Fase C:
- Primero¿Qué debe cambiar? Cambios en el enfoque, diseño organizacional, capacitación, externalización, internalización, automatización. Todos estos son cambios. Los hacemos para mejorar una organización.
- Segundo¿Cuándo debe cambiar? ¿Existen dependencias? ¿Qué pasa con las condiciones previas? ¿Está cambiando el escenario para un cambio posterior?
- Tercera¿Cómo sabrá si el cambio tuvo éxito? ¿Cuál es su prueba de gobernanza para el éxito? ¿Cómo protegerá el valor?
Las partes interesadas en la arquitectura empresarial son las responsables de todas las decisiones sobre qué debe cambiarse y cuándo. El arquitecto de aplicaciones es el responsable de describir las pruebas de gobernanza para permitir que las partes interesadas dirijan el proyecto de cambio y los resultados secundarios y terceros.
Formación en Arquitectura Empresarial y Formación TOGAF
Kickstart del arquitecto empresarial
El Kickstart del arquitecto empresarial Necesitamos mantener nuestras habilidades actualizadas. Ahora más que nunca. Utilice el Kickstart de arquitectura empresarial para mejorar su capacidad de ofrecer una arquitectura empresarial transformadora. Este kickstart de 90 días es la forma en que Conexiam Consulting […]
Educación en línea efectiva
Educación en línea eficaz La educación en línea eficaz funciona. Los estudiantes tienen acceso al mejor instructor disponible. Los estudiantes controlan el ritmo de su aprendizaje. Los instructores pueden compartir material complementario valioso sin distraerse del tema principal. La educación a distancia eficaz […]
Curso de formación en arquitectura empresarial de TOGAF
¿Quieres formación para la Certificación TOGAF? Demuestre su conocimiento de arquitectura empresarial con la certificación TOGAF Curso de capacitación en arquitectura empresarial TOGAF® Dé un gran paso para ser un mejor arquitecto empresarial con el estándar TOGAF, décimo […]
Capacitación en arquitectura empresarial personalizada
Capacitación en arquitectura empresarial personalizada La capacitación en arquitectura empresarial personalizada aborda el desarrollo profesional que su equipo de EA necesita. Los buenos arquitectos empresariales utilizan un amplio conjunto de habilidades, métodos, además de conocimientos de dominio especializados para desarrollar […]
Curso de formación Avolution ABACUS
Avolution ABACUS Training La arquitectura empresarial eficaz se basa en el modelado y el análisis formales. Brindamos capacitación en Avolution ABACUS por parte de arquitectos empresariales prácticos. Los estudiantes adquieren habilidades y conocimientos para crear arquitecturas empresariales y de dominio integradas en este […]
Curso de formación en arquitectura negocios
Formación en arquitectura empresarial La arquitectura empresarial eficaz se basa en la arquitectura empresarial. El curso brinda a los estudiantes las habilidades y el conocimiento para desarrollar la arquitectura empresarial en un entorno de arquitectura empresarial. La arquitectura empresarial implica describir la estructura del […]
Entregables de la arquitectura de aplicaciones TOGAF ADM Fase C
Un resultado central de la Fase C es una arquitectura de aplicación. Esta es una parte de la arquitectura empresarial completa.
Entregables de arquitectura de aplicaciones de la fase C de TOGAF y casos de uso de arquitectura empresarial
Hay cuatro propósitos principales para el desarrollo de la arquitectura empresarial. Los diferentes entregables de la Fase C de TOGAF tienen una importancia diferente en cada propósito.
| Arquitectura para apoyar la estrategia | Arquitectura para apoyar la cartera | Arquitectura para Proyecto de Soporte | Arquitectura para respaldar la entrega de soluciones | |
| Producto de trabajo de la fase C: arquitectura de aplicación candidata | Producto clave
El uso principal es la comprensión del objetivo y el trabajo por parte de las partes interesadas. El uso secundario es la creación de especificaciones de requisitos de arquitectura para arquitectos. |
Producto clave
El uso principal es la comprensión del objetivo y el trabajo por parte de las partes interesadas. El uso secundario es la creación de especificaciones de requisitos de arquitectura para arquitectos. |
Antes del inicio del proyecto y la finalización del caso de negocio
El uso principal es la creación de especificaciones de requisitos de arquitectura para implementadores |
Antes de la contratación de socios de ejecución (incluidos los proveedores internos)
El uso principal es la creación de especificaciones de requisitos de arquitectura para implementadores |
| Producto de trabajo de la fase C: Elementos candidatos de la hoja de ruta | Producto clave
El uso principal es la comprensión del trabajo por parte de las partes interesadas. El uso secundario es la creación de restricciones para arquitectos. |
Producto clave
El uso principal es la comprensión de las partes interesadas del trabajo y la dependencia. El uso secundario es la creación de restricciones para arquitectos. |
Uso limitado Se puede utilizar como entrada para proyectos con múltiples cambios interactivos |
Antes de la contratación de socios de ejecución (incluidos los proveedores internos).
El uso principal es la identificación del cambio requerido y las preferencias de cómo ejecutar el cambio, para administrar la selección y el compromiso de los socios de entrega de soluciones. |
| Producto de trabajo de fase C: Especificación de requisitos de arquitectura | Uso limitado
Por lo general, los arquitectos pueden inferir restricciones de una arquitectura superior. |
Uso limitado
Por lo general, los arquitectos pueden inferir restricciones de una arquitectura superior. |
Producto clave
Antes de completar el inicio del proyecto |
Producto clave
Antes del compromiso y la contratación |
Tabla 3 Guía de la serie TOGAF: Guía del arquitecto empresarial para desarrollar arquitectura
Arquitectura de la aplicación candidata
Hay cuatro propósitos principales para el desarrollo de la arquitectura empresarial. Diferentes modelos tienen diferente importancia en cada propósito.
Componentes de la hoja de ruta de la arquitectura de la aplicación candidata
¿Qué debe cambiar? Si está cambiando el modelo de desarrollo de aplicaciones, entonces la diferencia entre el actual y el objetivo es el candidato de hoja de ruta. También lo es todo lo necesario para permitir ese cambio.
A menudo usamos un modelo de sistema para resumir el cambio. El modelo de sistema permite la abstracción suficiente del software real para tener una conversación de planificación y ejecución. Solemos utilizar partituras y paquetes de trabajo para articular un cambio. Para obtener más información sobre el uso de puntuaciones, consulte la Guía de evaluación de la capacidad de la arquitectura empresarial.
Utilizamos todos los componentes de Architecture Roadmap en Fase E de TOGAF - Hoja de ruta de la arquitectura.
Especificación de los requisitos de la arquitectura de la aplicación candidata
Defina cómo evaluará el cambio. ¿Cómo se evaluará la mejora?
A menudo usamos puntajes en nuestros modelos para describir los requisitos. Cada requisito es una medida de eficiencia, automatización, agilidad o desempeño. Luego, cuando estamos trabajando en TOGAF Fase G ejecutando gobernanza de la arquitectura con un proyecto de cambio usamos estos puntajes para evaluar diseños e implementaciones.
Vaya más allá con los procesos y métodos de arquitectura empresarial de mejores prácticas
Mejores prácticas arquitectura empresarial de Conexiam Navegar
Aprovechar el poder de la planificación basada en la capacidad: una guía rápida
Libere el poder de la planificación basada en la capacidad: una guía rápida ¿Está buscando una forma más eficaz de planificar y ejecutar su estrategia comercial? No busque más allá de la planificación basada en la capacidad. Identificar y utilizar los […]
Hoja de ruta de la arquitectura empresarial como diseño
Hoja de ruta de arquitectura empresarial como diseño Una hoja de ruta de arquitectura es una herramienta de planificación que ayuda a los responsables de la toma de decisiones de una organización. Una hoja de ruta de arquitectura dinámica está diseñada para ayudarlos a desarrollar y recorrer el mejor camino a seguir. También […]
Gestión del trabajo de arquitectura empresarial
Gestión del trabajo de arquitectura empresarial La gestión del trabajo de arquitectura empresarial es fundamental para el éxito diario de un equipo de arquitectura empresarial. Los arquitectos deben ofrecer una orientación útil antes de que las partes interesadas tomen decisiones informadas. Los arquitectos empresariales deben traducir […]
Libere el potencial de su negocio: cómo crear un mapa de capacidad eficaz
Libere el potencial de su negocio: cómo crear un mapa de capacidades efectivo ¿Está luchando por identificar las capacidades necesarias para llevar su negocio al siguiente nivel? ¿Le resulta difícil alinear los recursos [...]
Desarrollo de una estrategia de arquitectura empresarial
Desarrollo de una estrategia de arquitectura empresarial: plan estratégico para el cambio La estrategia de arquitectura empresarial es acción. Las acciones que llevará a cabo su organización y los cambios que realizará para alcanzar sus objetivos estratégicos. El desarrollo de una estrategia es una cuestión de elección. […]
Todo lo que necesita saber sobre el uso de alternativas de arquitectura
Todo lo que necesita saber sobre el uso de alternativas de arquitectura Las alternativas de arquitectura son necesarias para un buen desarrollo de arquitectura empresarial. Cuando inicia el desarrollo de la arquitectura, su empresa tiene deficiencias. Hay áreas para mejorar. Necesitas […]
Garantizar la alineación y la rendición de cuentas: el papel crucial de las listas de verificación de gobernanza de la arquitectura empresarial
Garantizar la alineación y la rendición de cuentas: el papel crucial de las listas de verificación de gobernanza de la arquitectura empresarial Las listas de verificación de gobernanza de la arquitectura empresarial simplifican los procesos de gobernanza de la arquitectura empresarial. El proceso de gobernanza debe aprobar la arquitectura de destino y proporcionar gobernanza de implementación. Una empresa sólida […]
Descubra el poder de los patrones de arquitectura empresarial
Descubriendo el poder de los patrones de arquitectura empresarial: una guía completa Toda organización quiere mejorar. Agilizar sus operaciones. Mejorar su agilidad empresarial. Alinear el cambio con sus estrategias. Triunfe en la transformación digital. Arquitectura Empresarial, una disciplina […]
Uso del análisis de escenarios para la arquitectura empresarial
Uso del análisis de escenarios para la arquitectura empresarial Un escenario es simplemente un futuro plausible. El análisis de escenarios analiza cómo llegamos a un futuro plausible y cómo los diferentes escenarios afectan nuestras decisiones actuales. Los escenarios ayudan a los líderes […]
Creación de un Comité de Revisión de Arquitectura Moderna
La creación de un comité de revisión de arquitectura moderna exige crear un proceso de gobernanza dinámico y establecer un órgano de toma de decisiones de alto nivel. El objetivo es establecer una gobernanza de la arquitectura eficaz sin burocracia. […]
Modelos, herramientas y técnicas de arquitectura de aplicaciones
TOGAF ADM Fase C entrega la Arquitectura de Sistemas de Información. Esta Fase existe para desarrollar la arquitectura de aplicaciones y la arquitectura de datos que componen los sistemas de información. En TOGAF, el primer paso es determinar las vistas requeridas y los modelos requeridos.
Las preocupaciones de las partes interesadas identificarán los puntos de vista. Hay siete modelos de arquitectura de aplicaciones centrales.
- Modelo de desarrollo de aplicaciones que describe el método aceptable con el que se desarrollará un sistema
- Modelo de sistema que captura los grandes sistemas en torno a los cuales está diseñada su cartera de aplicaciones
- Modelo funcional que describe todas las cosas que necesita que realice su cartera de software
- Modelo de Producto que identifica la funcionalidad utilizada en los productos y servicios de su organización, así como aquellos que los administran
- El modelo de integración describe cómo fluye la información a través de su cartera de aplicaciones
- El modelo de servicio divide su cartera de aplicaciones en cajas negras y le permite asegurarse de que cada servicio tenga la agilidad, la automatización y otros atributos necesarios.
- El modelo físico identifica las aplicaciones reales, comerciales, SaaS o personalizadas, en su cartera de aplicaciones
La arquitectura de la aplicación ayudará a responder las siguientes preguntas:
- Cómo la cartera de aplicaciones permite la captura de valor: Modelo de desarrollo de aplicaciones
- Dónde se inyecta el costo en la cartera de TI: modelo funcional
- Donde se inyecta rigidez en la cartera de TI: Modelo de Integración
- Cómo funciona la empresa: Modelo de sistema
- Sistemas necesarios para entregar el producto o servicio: Modelo del Producto
- Las cosas que una organización debe ser capaz de hacer: modelo funcional
- El flujo de información que se requiere para realizar las actividades de una empresa: Modelo de Integración
- Las actividades completas que realiza una empresa, generalmente agrupadas para mostrar cómo se relacionan entre sí: Modelo de servicio
- Qué es la cartera de software: Modelo físico
Siempre tenga en cuenta que usted está buscando mejorar la organización. La mejora requiere cambios y entrega valor. El valor y el costo del cambio se pueden medir. La incertidumbre siempre disminuye el valor potencial. La incertidumbre siempre aumenta el costo. Tratamos la incertidumbre como un impacto geométrico. Un poco de incertidumbre disminuye mucho el valor potencial.
Al leer, tenga en cuenta que hay muchos usos de los mismos términos. Busque el propósito del modelo y no se quede atrapado cuando la etiqueta difiera de cómo lo llamaría. Por ejemplo, lo que usted llama un modelo funcional, alguien más lo llamará un servicio. En nuestro consultoría de arquitectura empresarial, siempre nos enfocamos en lo que estamos tratando de entender, no en cómo se llama el modelo.
Diferentes modelos explicarán diferentes aspectos de la empresa. Juntos, los modelos y los cambios necesarios forman la arquitectura de la aplicación.
Patrones de arquitectura de aplicaciones
Usamos Patrones de arquitectura para aumentar drásticamente la productividad y la calidad de nuestro desarrollo arquitectónico. Plantilla de patrón de arquitectura nos lleva a comprender la problema predecible, enfoque de patrón, y el Bits durosPara tener éxito con el patrón es necesario abordar las Bits duros (trabajo requerido, restricciones y limitaciones).
Patrones de arquitectura de aplicaciones de muestra
Los patrones de arquitectura de aplicaciones de muestra cubren el problema de la estructura de las aplicaciones, la migración y cómo diseñarlas.
- Estructura de la aplicación
- Patrón MVC (Modelo-Vista-Controlador)
Problema predecible—organización del código, mantenibilidad y capacidad de prueba
Acercarse—separa una aplicación en tres componentes interconectados: Modelo (datos y lógica de negocios), Vista (interfaz de usuario) y Controlador (maneja la entrada del usuario y actualiza el Modelo y la Vista en consecuencia)
- Patrón MVC (Modelo-Vista-Controlador)
- Migración de aplicaciones
- Patrón estrangulador
Problema predecible—reemplazar sistemas heredados
Acercarse—reemplazar o “estrangular” gradualmente un sistema heredado existente mediante la construcción de nuevos componentes a su alrededor para reemplazar gradualmente el sistema
- Patrón estrangulador
- Diseño de aplicaciones (grupo de cuatro patrones de aplicaciones)
Como arquitectos empresariales utilizamos patrones de diseño como limitaciones a la libertad de los equipos de desarrollo de aplicaciones. (Ver Arquitectura empresarial y ágil: limitar los sprints)- Patrón singleton- garantiza que una clase tenga solo una instancia y proporciona un punto global de acceso a esa instancia
Modelos de arquitectura de aplicaciones
Desarrollar una arquitectura de aplicación requerirá desarrollar varios modelos de arquitectura empresarial. Cada uno explica la cartera de software de la empresa de manera diferente. TOGAF Phase C Application Architecture tiene que ver con el desarrollo de la arquitectura de destino a través de estos modelos. Garantizar que el arquitecto de la aplicación de destino trabaje con los otros dominios para permitir la mejor mejora para su empresa.
En conjunto, los modelos describen la arquitectura de la aplicación. En la arquitectura empresarial completa, estos modelos se vincularán con otros modelos que describen los otros dominios de la arquitectura empresarial.
Modelo de desarrollo de aplicaciones
El modelo de desarrollo de aplicaciones describe cómo se desarrollará el software. El modelo requiere un modelo funcional o físico. El modelo funcional es mucho mejor porque es un software de identificación lógica.
Hay cuatro tipos de desarrollo de aplicaciones: SaaS, suites empresariales, paquetes comerciales especializados y desarrollo personalizado. Cada tipo tiene características e implicaciones únicas.
- Las características de SaaS incluyen software empaquetado con interfaces bien definidas. Un tercero controla el ciclo de vida. La personalización no está disponible.
Se utiliza mejor para actividades comerciales que son administrativas y que apoyan indirectamente la actividad generadora de valor. Las estrictas restricciones de software generan restricciones en la actividad comercial y ayudan a forzar la adopción de prácticas estándar de la industria.
- Las características de las suites empresariales incluyen múltiples modelos funcionales superpuestos, con un modelo de datos definido. Las interfaces y la funcionalidad se pueden configurar o personalizar. Las personalizaciones crean invariablemente costos adicionales durante el ciclo de vida. El ciclo de vida está influenciado por un tercero.
- Las características de los paquetes comerciales especializados incluyen enfoque puntual y optimización funcional para la actividad especializada. Típicamente diseñado en torno a una forma de abordar la actividad empresarial. Por lo general, tiene un modelo de datos único y bien definido. Las interfaces y la funcionalidad se pueden configurar. La personalización podría ser posible. Las personalizaciones invariablemente crean un costo significativo durante el ciclo de vida. El ciclo de vida está fuertemente influenciado por un tercero.
- Las características de desarrollo personalizadas incluyen la alineación directa entre las actividades y los límites organizacionales heredados de su organización. Invariablemente diseñado para soportar el modelo de comunicación existente de su organización. Punto de enfoque y optimización funcional para la actividad del especialista. Espere un modelo de datos mal definido. Las interfaces y la funcionalidad deben personalizarse. La gestión del ciclo de vida generalmente se ignora y conlleva un alto costo continuo.
Mejor utilizado para actividades comerciales en la cadena de valor primaria. La flexibilidad permite la optimización de cómo se genera el valor. El uso efectivo requiere comprender la generación de valor hoy y en el futuro.
Modelo de desarrollo de aplicaciones
El modelo de desarrollo de aplicaciones describe cómo se desarrollará el software. El modelo requiere un modelo funcional o físico. El modelo funcional es mucho mejor porque es un software de identificación lógica.
Hay cuatro tipos de desarrollo de aplicaciones: SaaS, suites empresariales, paquetes comerciales especializados y desarrollo personalizado. Cada tipo tiene características e implicaciones únicas.
- Las características de SaaS incluyen software empaquetado con interfaces bien definidas. Un tercero controla el ciclo de vida. La personalización no está disponible.
Se utiliza mejor para actividades comerciales que son administrativas y que apoyan indirectamente la actividad generadora de valor. Las estrictas restricciones de software generan restricciones en la actividad comercial y ayudan a forzar la adopción de prácticas estándar de la industria.
- Las características de las suites empresariales incluyen múltiples modelos funcionales superpuestos, con un modelo de datos definido. Las interfaces y la funcionalidad se pueden configurar o personalizar. Las personalizaciones crean invariablemente costos adicionales durante el ciclo de vida. El ciclo de vida está influenciado por un tercero.
- Las características de los paquetes comerciales especializados incluyen enfoque puntual y optimización funcional para la actividad especializada. Típicamente diseñado en torno a una forma de abordar la actividad empresarial. Por lo general, tiene un modelo de datos único y bien definido. Las interfaces y la funcionalidad se pueden configurar. La personalización podría ser posible. Las personalizaciones invariablemente crean un costo significativo durante el ciclo de vida. El ciclo de vida está fuertemente influenciado por un tercero.
- Las características de desarrollo personalizadas incluyen la alineación directa entre las actividades y los límites organizacionales heredados de su organización. Invariablemente diseñado para soportar el modelo de comunicación existente de su organización. Punto de enfoque y optimización funcional para la actividad del especialista. Espere un modelo de datos mal definido. Las interfaces y la funcionalidad deben personalizarse. La gestión del ciclo de vida generalmente se ignora y conlleva un alto costo continuo.
Mejor utilizado para actividades comerciales en la cadena de valor primaria. La flexibilidad permite la optimización de cómo se genera el valor. El uso efectivo requiere comprender la generación de valor hoy y en el futuro.
Modelo de sistema
El modelo de sistema es una abstracción de software en torno a una actividad. Piense en el 'sistema de la cadena de suministro' y todo lo que está involucrado en la cadena de suministro. El diseño de su modelo de sistema se alineará con el funcionamiento de su empresa.
Al igual que el modelo de capacidad del arquitecto empresarial, un modelo de sistema le permite dirigir el pensamiento a un sistema. Puede buscar mejorar un sistema completo y luego enfocar los cambios necesarios en todo lo que comprende el sistema e interactúa con él.
Modelo del Producto
Un modelo de producto es una versión especializada de un modelo funcional que destaca las funciones requeridas para sus productos o servicios. Un buen modelo de producto clasificará lo que se realiza en términos comparables.
Un buen modelo de producto formará la base de un Arquitectura de referencia para sus productos Debe especificar las funciones que son fundamentales para el valor, el uso y la administración del producto. Un modelo de producto informará las opciones del modelo de desarrollo de aplicaciones. Necesita desarrollo personalizado, duplicación y una capacidad de cambio significativamente mayor cuando las funciones están asociadas con sus productos y servicios.
modelo funcional
El modelo funcional divide su cartera de software en funcionalidad. Identifica todas las cosas que su software necesita hacer. Los buenos modelos funcionales proporcionan una amplia cobertura.
Al igual que el modelo de proceso del arquitecto empresarial, un modelo funcional suele ser una arquitectura de referencia. Es muy útil cuando se busca duplicación e integración. A menudo constituye la base de un modelo de desarrollo de aplicaciones, en el que se asignan diferentes bloques funcionales a un tipo de desarrollo de aplicación de destino.
Crítico en la planificación de la cartera de aplicaciones. La duplicación y la integración generan complejidad y costos en la cartera de TI.
BIAN, FEAF, ODF de TMForum e IndEA proporcionan modelos funcionales.
Modelo de Integración
Un modelo de integración identifica los límites en su software y la forma en que se cruza el límite. No tenga miedo de especificar que el límite no se puede cruzar o debe cruzarse manualmente. Una gran cantidad de integración de aplicaciones débil solo brinda rigidez. El desarrollo de un Modelo de Integración útil requiere la iteración con el trabajo de un Arquitecto de Negocios que desarrolla un Mapa Organizacional y modelo de información. El Modelo de Integración, el Mapa Organizacional y el Modelo de Información se informan y limitan entre sí.
El modelo de integración es fundamental para permitir la agilidad empresarial, administrar la cartera de aplicaciones y reducir los costos de TI.
Modelo de servicio
Un modelo de servicio es una versión especializada de un modelo funcional que colapsa la funcionalidad en una caja negra con interfaces conocidas. Un buen modelo de servicio es invaluable para desarrollar el modelo de desarrollo de aplicaciones y validar el objetivo en un modelo de sistema. Todas las interfaces de su modelo de servicio deben estar bien identificadas en su modelo de integración.
Un buen modelo de servicio permitirá la agilidad empresarial. No desde el desarrollo de los servicios de aplicaciones, sino liberando el cambio en una parte de su empresa de otra.
Modelo físico
Un modelo físico es la cartera de software real. Lo describiremos en los términos utilizados por los proveedores de software comercial y su programa de desarrollo de aplicaciones. Deberá asociar esto con los otros modelos de arquitectura de aplicaciones para hacer la transición del destino al mundo real.
Utiliza el modelo físico como una restricción en los modelos abstractos de arquitectura de aplicaciones. También constituye la base de la Plan de Implementación y Migración desarrollado a través de la Fase F.
Técnicas de arquitectura de aplicaciones
Utilizamos un amplio conjunto de técnicas para desarrollar y comunicar nuestra arquitectura de aplicaciones.
- UML es omnipresente en un buen desarrollo basado en modelos. Cuando trabaja en arquitectura para respaldar el desarrollo de soluciones, se debe desarrollar un modelo funcional y un modelo de integración siguiendo las prácticas de UML.
- Las Vistas 4+1 son muy útiles para identificar la implicación del Target para diferentes comunidades. Desarrollar modelos 4+1 ayuda a garantizar que esté considerando todos los cambios relevantes.
- Las Líneas de Necesidad de Información de DODAF extraen todos los flujos de información requeridos. No importa si el nodo es una persona, una organización o un sistema. La información fluirá hacia adentro y hacia afuera. La forma más rápida de eliminar la automatización es colocar pasos manuales en medio de un flujo de información.
Modelos de arquitectura de aplicaciones alineados con el caso de uso de la arquitectura empresarial
El nivel de preguntas que responda con la arquitectura de su aplicación impulsará el uso de diferentes modelos de arquitectura de aplicaciones. Por ejemplo, la arquitectura para respaldar la cartera a menudo no desarrollará un modelo de cadena de valor. En cambio, una cadena de valor generalmente será una arquitectura superior y restringe tu libertad.
| Arquitectura para apoyar la estrategia | Arquitectura para apoyar la cartera | Arquitectura para Proyecto de Soporte | Arquitectura para respaldar la entrega de soluciones | |
| Modelo de desarrollo de aplicaciones | Entregable clave | Entregable clave | Arquitectura Superior | Arquitectura Superior |
| Modelo de sistema | Entregable regular | Entregable clave | Arquitectura Superior | Arquitectura Superior |
| modelo funcional | Entregable regular | Entregable clave | Entregable clave y arquitectura superior | Entregable clave y arquitectura superior |
| Modelo del Producto | Entregable ocasional
El nivel apropiado de detalle a menudo disminuye el valor |
Entregable regular
El nivel apropiado de detalle a menudo disminuye el valor |
Entregable clave | Entregable clave |
| Modelo de Integración | Entregable ocasional
El nivel apropiado de detalle a menudo disminuye el valor |
Entregable regular
El nivel apropiado de detalle a menudo disminuye el valor |
Entregable clave | Entregable clave y arquitectura superior |
| Modelo de servicio | Entregable ocasional
El nivel apropiado de detalle a menudo disminuye el valor |
Entregable regular | Entregable clave y arquitectura superior | Entregable clave y arquitectura superior |
Influencia de los modelos de arquitectura empresarial en los modelos de arquitectura de aplicaciones
| modelo de negocio | Modelo operativo | Cadena de valor | modelo de capacidad | Modelo de proceso | modelo funcional | modelo de información | Modelo de Organización | |
| Modelo de desarrollo de aplicaciones | Entrada principal
Requiere un Sistema o Modelo Funcional |
Entrada principal
Requiere un Sistema o Modelo Funcional |
Entrada principal
Requiere un Sistema o Modelo Funcional |
Entrada principal
Requiere un Sistema o Modelo Funcional |
Entrada principal
Requiere un Sistema o Modelo Funcional |
Entrada principal
Requiere un Sistema o Modelo Funcional |
Entrada limitada | Entrada limitada |
| Modelo de sistema | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | Entrada principal | Entrada limitada | Entrada principal |
| Modelo del Producto | Entrada principal | Entrada principal | Entrada principal | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | |
| Modelo de Integración | Entrada muy limitada | Aportaciones principales sobre el diseño del núcleo
Requiere un Sistema o Modelo Funcional |
Aportaciones principales sobre el diseño del núcleo
Requiere un Sistema o Modelo Funcional |
Mejor entrada
Un enlace directo es muy difícil de ver. Vale la pena hacer el trabajo. |
Aportaciones principales sobre el diseño del núcleo
Requiere un Sistema o Modelo Funcional |
Entrada limitada
Usar solo si otros modelos no están disponibles |
Aportaciones principales sobre el diseño del núcleo
Requiere un Sistema o Modelo Funcional |
Aportaciones principales sobre el diseño del núcleo
Requiere un Sistema o Modelo Funcional |
| Modelo de servicio | Entrada limitada
Los vínculos son importantes, pero un vínculo directo es muy difícil de ver |
Entrada limitada
Los vínculos son importantes, pero un vínculo directo es muy difícil de ver |
Entrada limitada
Los vínculos son importantes, pero un vínculo directo es muy difícil de ver |
Mejor entrada
Un enlace directo es muy difícil de ver. Vale la pena hacer el trabajo. |
Se utiliza como una prueba de integridad | Entrada principal
Un enlace directo es muy difícil de ver. Vale la pena hacer el trabajo. |
Entrada principal |
Modelos de arquitectura de aplicaciones para casos de uso de arquitectura empresarial
Todo casos de uso de arquitectura empresarial tratan sobre el cambio. Todos analizan los tipos de cambio y cómo un Arquitecto Empresarial ayuda a los tomadores de decisiones a trazar un camino a seguir.
Considero los casos de uso de la arquitectura empresarial como el tipo de cambio, el propósito del equipo de arquitectura empresarial o las preguntas más frecuentes.
En cada caso de uso de arquitectura empresarial, estamos realizando la misma función. Ayudamos a las partes interesadas a tomar mejores decisiones y liderar iniciativas de cambio exitosas. Todo lo que cambia es la pregunta.
| Cambio Estratégico | Cambio incrementado | Mejorar el costo | Mejorar calidad | Mejore la agilidad empresarial | Mitigación del riesgo tecnológico | Modernización de TI | Transformación Digital | Racionalización de la cartera de aplicaciones | Integración de adquisiciones | |
| Modelo de desarrollo de aplicaciones | Restricciones clave | Directrices clave | Restricciones críticas | Restricciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | ||
| Modelo de sistema | Muy útil
Brechas y limitaciones críticas |
Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | |||||
| Modelo del Producto | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | |||||
| Modelo de Integración | Restricciones de información | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | Brechas y limitaciones críticas | |
| Modelo de servicio | Muy útil para lagunas y limitaciones. | Muy útil para lagunas y limitaciones. | Muy útil para lagunas y limitaciones. | Muy útil para lagunas y limitaciones. | Muy útil para lagunas y limitaciones. | Muy útil para lagunas y limitaciones. | Muy útil para lagunas y limitaciones. |
Aplicación de los principios de la arquitectura empresarial a la arquitectura de aplicaciones
Hemos identificado 7 principios de arquitectura que todo arquitecto empresarial debe conocer. La siguiente tabla identifica las implicaciones de estos Principios de Arquitectura para la Arquitectura de la Aplicación. Cuando actua gobernanza de la arquitectura empresarial, debe probar su arquitectura de aplicaciones para asegurarse de que se ajusta a una arquitectura superior. Aquí, ¿se ajusta a los principios de la arquitectura empresarial?
| Implicación de la arquitectura de la aplicación | |
| No te metas con el éxito | Si el programa no es diferenciación o transformación, busca eliminar el cambio. Busque evitar todo cambio en el proceso o sistema que no esté explícitamente justificado por el costo y el resultado. |
| Enfoque en la excelencia | Alinear con el Modelo operativo el modelo de capacidad.
Aproveche el modelo de desarrollo de aplicaciones para centrar el gasto en la diferenciación. Aproveche el modelo de producto para centrarse en la entrega de productos y servicios. |
| ¿Por qué no uno? | Aproveche el modelo de desarrollo de aplicaciones y el modelo de producto para identificar áreas donde está prohibida la duplicación. |
| Los datos son un activo | Asegúrese de que el control del modelo de datos no se entregue de manera que disminuya el valor del activo de datos. |
| Los sistemas funcionan donde trabajamos | Interfaz de unidad de ubicación y estilo de trabajo y modelo de aplicación. |
| Experiencia de usuario sin dolor | Los programas de eficiencia se centran en los procesos comerciales existentes.
Los programas de diferenciación y transformación requieren cambios en la interfaz de usuario y el compromiso a medida que se desarrolla la experiencia con el nuevo proceso. |
| Autoservicio | Las actividades administrativas y la implementación de aplicaciones son de alto costo cuando no son de autoservicio
UX débil es de alto costo.. |
¿Cómo se alinea TOGAF Fase C con el desarrollo ágil?
La arquitectura de la aplicación proporcionará múltiples restricciones y orientación para un desarrollo ágil. La guía fundamental proviene del Modelo de desarrollo de aplicaciones. Identifica dónde no desea un desarrollo ágil.
Arquitectura empresarial y desarrollo ágil se cruzará en cuatro áreas. los la arquitectura empresarial:
- definir el enfoque ágil
- guiar el backlog en sprint
- restringir las opciones dentro de los sprints
- resolver la dependencia de productos cruzados
Siempre enfocamos el desarrollo ágil en actividades diferenciadoras novedosas y seguimos sin piedad las mejores prácticas establecidas en otros lugares. Las mejores prácticas provienen del software comercial establecido. Asegúrese de alinear la arquitectura de su aplicación con la arquitectura de su negocio y concéntrese en cómo adquiere los sistemas.
¿Cómo se habilita TOGAF Fase C con Enterprise Agility?
La agilidad empresarial no tiene nada que ver con la forma de escribir software. La agilidad empresarial se trata de la capacidad de su empresa para reaccionar ante amenazas y oportunidades inesperadas. Si necesita escribir código, su capacidad para responder a una amenaza u oportunidad está en riesgo.
Un arquitecto de aplicaciones se centrará en el quinto aspecto de la modelo de agilidad empresarial - Flexibilidad. Usamos el mismo atributo de Agilidad y puntajes en el Guía de evaluación de capacidades identificar los sistemas de información que deben ser capaces de cambios rápidos. Luego diseñamos para permitir el cambio.
Modelo de agilidad empresarial
- Estado de alerta: ¿puede detectar oportunidades y amenazas?
- Accesibilidad: ¿puede acceder a la información relevante a tiempo para responder?
- Capacidad de decisión: ¿puede decidir utilizando la información disponible?
- Rapidez: ¿puede implementar sus decisiones en el tiempo disponible?
- Flexibilidad: ¿Qué está haciendo para reducir las barreras a la acción?
¿Cuál es el objetivo de TOGAF ADM Fase C?
En Fase A, identificaste un arquitectura de destino simplificada: la visión de la arquitectura. La Visión de la Arquitectura incluía todos los dominios. Actividad en la Fase C, desarrolla aún más los dominios de arquitectura de aplicaciones y datos. El éxito requiere:
- Abordas el problema de cómo la empresa actual no puede satisfacer las preferencias de las partes interesadas
- ¿Aprende qué debe cambiar para permitir que la empresa satisfaga las preferencias de las partes interesadas? (Brechas)
- Es necesario tener una comprensión suficiente del trabajo para entregar cambios (Paquete de trabajo)
- Comprende la interacción entre los cambios y las restricciones en otros dominios de arquitectura para proteger el valor esperado (Especificaciones de requisitos de arquitectura)
El resultado central de la Fase C es la arquitectura de la aplicación candidata. Los arquitectos de aplicaciones trabajan con otros arquitectos de dominio para comprender las restricciones que se imponen a la arquitectura de la aplicación y qué restricciones se imponen a otros dominios.
Recuerde, TOGAF ADM explora cambios potenciales. Hasta que estés desarrollando el Plan de Implementación en la Fase F, busque la rampa de salida más económica. Las malas ideas no significan que no estás resolviendo el problema. Debes descartar lo débil alternativas de arquitectura. Detener las malas ideas antes ahorra dinero y permite cambios exitosos. En el momento en que una idea se vuelve mala, deténgase en seco. Mata la idea. ¡Celebra tu victoria! ¡Celebre que está permitiendo un cambio exitoso!
Patrones de arquitectura de aplicaciones
Usamos Patrones de arquitectura para aumentar drásticamente la productividad y la calidad de nuestro desarrollo de arquitectura. Usamos un simplificado Plantilla de patrón de arquitectura que nos lleva a comprender la problema predecible, enfoque de patrón, y el Bits duros. La aplicabilidad del patrón suele estar determinada por el trabajo requerido, las restricciones y las limitaciones.
Patrones de arquitectura de aplicaciones de muestra
Los patrones de arquitectura de aplicaciones de muestra cubren el problema de la estructura de las aplicaciones, la migración y cómo diseñarlas.
- Estructura de la aplicación
- Patrón MVC (Modelo-Vista-Controlador)
Problema predecible—organización del código, mantenibilidad y capacidad de prueba
Acercarse—separa una aplicación en tres componentes interconectados: Modelo (datos y lógica de negocios), Vista (interfaz de usuario) y Controlador (maneja la entrada del usuario y actualiza el Modelo y la Vista en consecuencia)
- Patrón MVC (Modelo-Vista-Controlador)
- Migración de aplicaciones
- Patrón estrangulador
Problema predecible—reemplazar sistemas heredados
Acercarse—reemplazar o “estrangular” gradualmente un sistema heredado existente mediante la construcción de nuevos componentes a su alrededor para reemplazar gradualmente el sistema
- Patrón estrangulador
- Diseño de aplicaciones (grupo de cuatro patrones de aplicaciones)
Como arquitectos empresariales utilizamos patrones de diseño como limitaciones a la libertad de los equipos de desarrollo de aplicaciones. (Ver Arquitectura empresarial y ágil: limitar los sprints)- Patrón singleton- garantiza que una clase tenga solo una instancia y proporciona un punto global de acceso a esa instancia
Reflexiones finales sobre TOGAF ADM Fase C
Arquitectos de aplicaciones que trabajan con un Equipo de arquitectura empresarial tienen un conjunto de responsabilidades más importantes que diseñar una aplicación. Necesitan desarrollar las pautas y barandillas para que las personas diseñen, implementen y desarrollen la cartera de aplicaciones de la empresa. En resumen, el El arquitecto de aplicaciones empresariales es distinto de un arquitecto de soluciones o un arquitecto de aplicaciones. que no trabaja con un equipo de EA.
Los arquitectos de aplicaciones que trabajan en TOGAF ADM Fase C tienen un papel complejo.
- trabajar con las partes interesadas y las PYMES para seleccionar cambios en la cartera de aplicaciones que permitan la mejor organización futura
- trabajar con su compañero arquitectos de dominio para explorar cómo se habilitan o previenen las mejoras requeridas en el dominio comercial en el dominio de la aplicación
- trabaje con las partes interesadas para eliminar los cambios en la cartera de aplicaciones que ofrecen muy poco o cuestan demasiado. Además, elimine los cambios en otros dominios que generan costos inaceptables y cambios en la cartera de aplicaciones.
En TOGAF ADM Fase C, uno de los cuatro fundamentos dominios de arquitectura empresarial es desarrollado. TOGAF es muy claro que usted desarrolla esta arquitectura durante el desarrollo de los otros dominios. Los cambios en un dominio habilitarán, forzarán o bloquearán cambios en otro dominio.
Los equipos de EA de alto funcionamiento no utilizan sus arquitectos de aplicaciones como diseñadores de una sola aplicación. Ese rol es necesario, pero sin una arquitectura de aplicaciones que cubra partes significativas de la empresa, no se puede optimizar la empresa.
TOGAF ADM Fase C desarrolla la arquitectura de la aplicación. La arquitectura de aplicaciones es la base de todas las empresas digitales modernas. Utilice TOGAF Fase C para centrar los escasos recursos de cambio en obtener el mayor valor empresarial.
