TOGAF ADM Fase C: Desarrollo de la arquitectura de la aplicación
De un vistazo
Descripción general de TOGAF ADM
- TOGAF Fase C 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 rol 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 la fase C de TOGAF ADM: Arquitectura de la aplicación
Descripción general de TOGAF ADM
En 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:
- Selecciona 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 aún más en el concepto de dominios de la arquitectura. Esta fase desarrolla la arquitectura de la aplicación y la arquitectura de datos. Formalmente, la Fase C se divide en: Dominio de la 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. Con una particularidad, la Fase C tiene la obligación adicional de habilitar la arquitectura empresarial. Esto no implica tratar la arquitectura empresarial como requisitos, sino confirmar la coherencia de los objetivos resumidos en desarrollo.
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 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 vs. la compra, y la planificación de cambios. La evaluación y comprensión adecuadas de esta fase son fundamentales.
¿Qué es TOGAF Fase C?
En la fase C de TOGAF, estás creando la arquitectura de la aplicación. Arquitectos de aplicaciones Liderar el desarrollo de la arquitectura de su aplicación. decisiones arquitectónicas Las decisiones tomadas en la Fase C para la arquitectura de la aplicación interactúan con las decisiones tomadas en cada dominio de la 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 inyectan costos en la cartera de TI - Modelo funcional
- Dónde 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 de producto
- Las cosas que una organización debe ser capaz de hacer - Modelo funcional
- El flujo de información necesario para realizar las actividades de una empresa - Modelo de integración
- Las actividades completas que realiza una empresa, normalmente agrupadas para mostrar cómo se relacionan entre sí. Modelo de servicio
- ¿Qué es el portafolio de software? Modelo físico
Tenga siempre presente que busca mejorar la organización. La mejora requiere cambio y genera 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 reduce considerablemente el valor potencial.
Al leer, tenga en cuenta que los mismos términos tienen muchos usos. Busque el propósito del modelo y no se deje engañar si la etiqueta difiere de cómo usted 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 centramos en lo que estamos tratando de entender, no en cómo se llama el modelo.
Diferentes modelos explicarán distintos aspectos de la empresa. Juntos, los modelos y los cambios necesarios conforman la arquitectura de la aplicación.
¿Qué es la arquitectura de aplicaciones?
Una arquitectura de aplicación es una descripción de su portafolio completo de software que le indica cuándo comprar, cuándo usar SaaS y cuándo desarrollar. Le indica dónde establecer límites entre sistemas. Le indica cómo abordará el ciclo de vida de su software.
Podemos garantizar que la arquitectura de su aplicación actual no está alineada con la arquitectura de su negocio. Una arquitectura de aplicación requiere una arquitectura empresarial. El desarrollo de la arquitectura empresarial requiere que los arquitectos de aplicaciones se unan a ellos interactuando con las partes interesadas.
Junto con la parte interesada y el arquitecto de negocio, el arquitecto de aplicaciones explora cómo las decisiones de software facilitan y limitan los objetivos de la organización. Consideramos posibles mejoras para comprender el impacto inmediato y a medio plazo. Juntos, descartamos de la hoja de ruta de la arquitectura los posibles cambios que generan poco, requieren demasiado trabajo o generan demasiada incertidumbre.
Cuando estamos desarrollo de equipos de arquitectura empresarial, le contamos a la arquitectos empresariales Dos hechos centrales sobre TOGAF Fase C - Arquitectura de la aplicación. Primero, hasta que tenga una Modelo de desarrollo de aplicaciones, No puede continuar. Hasta que sepa cómo sus opciones de aplicación habilitan y restringen la arquitectura empresarial, los detalles de sus aplicaciones no tienen sentido. En segundo lugar, si creen que necesitan profundizar en la funcionalidad e integración de las aplicaciones, siempre desarrollarán una arquitectura de baja calidad.
En un mundo moderno empresa transformada digitalmente, Todos los dominios de la arquitectura interactúan. Las decisiones en un dominio habilitan, entregan o bloquean resultados en otro. La mayoría de los objetivos de negocio dependen de... Arquitectura de TI adecuada. Iró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 la Fase C de TOGAF, la función del arquitecto empresarial es proteger todo el valor. Dependiendo de las habilidades de los arquitectos de dominio, el arquitecto empresarial debe suplir esta función. Por ejemplo, un arquitecto de aplicaciones podría no ver el impacto de los cambios en la arquitectura empresarial. O podría no articular un requisito de forma que el arquitecto de seguridad pueda actuar.
El rol más importante del arquitecto empresarial es trascender fronteras. Ya sean de dominio, de habilidades o de autoridad, el arquitecto empresarial debe trascenderlas.
¿Cuál es el papel 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. Esto requiere desarrollar modelos que muestren el origen de la deficiencia y cómo superarla. Liderará el análisis de compensaciones con las partes interesadas para determinar la arquitectura objetivo.
El arquitecto de la aplicación deberá colaborar con los demás arquitectos del dominio.
Descifrar 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. Esto requiere desarrollar modelos que muestren el origen de la deficiencia y cómo superarla. Liderará el análisis de compensaciones con las partes interesadas para determinar la arquitectura objetivo.
El arquitecto de la aplicación deberá colaborar con los demás arquitectos del dominio.
Descifrar 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 dan resultados. 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 Simultáneamente. El desarrollo simultáneo requiere un enfoque ágil, justo lo suficiente para probar las restricciones en cascada.
La secuencia clásica implícita en muchos diagramas TOGAF ADM es el orden en el que podemos cerrar el desarrollo de la arquitectura, no iniciarlo.
No caiga en la ilusión de que "el negocio" está de alguna manera separado de sus aplicaciones, datos e infraestructura. Eso no era cierto en el pasado, y en una empresa digital moderna es ridículo. 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 desempeñan un papel fundamental en un equipo de arquitectura empresarial. En una empresa digital moderna, nada ocurre sin software. Las malas decisiones en cuanto a las aplicaciones pueden perjudicar...'el negocio.Los arquitectos de aplicaciones son especialistas en un dominio de arquitectura. No pueden diseñar su dominio sin una interacción regular con arquitectos empresariales, datos, tecnología y arquitectos de seguridad.
Conversaciones sobre el manual de estrategias de inteligencia artificial de Agentic
Conversaciones sobre la Guía de Estrategias de IA de Agentic. Nos hemos sumergido profundamente en el panorama cambiante de la adopción de la IA, participando en un proceso que abarca tanto las complejidades técnicas como la transformación digital en general. Desarrollamos la Guía del Líder Empresarial […]
Descargar la arquitectura de referencia de capacidades críticas para la adopción de IA
Descargue la Arquitectura de Referencia de Capacidades Críticas para la Adopción de IA. La adopción de IA requiere un pensamiento innovador. Actualmente, carecemos de prácticas recomendadas comprobadas para la adopción generalizada de IA que mejoren consistentemente nuestras organizaciones. Necesitamos la capacidad de reimaginar nuestro […]
Descargar Guía del líder empresarial para la IA
Descargar Business Leader's Guide to Artificial Intelligence 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 ni de las mejores prácticas. La tecnología innovadora es novedosa y [...]
Descargar 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 probadas. El estándar subraya dónde [...]
Descargar la Guía de planificación basada en capacidades
Descargar la Guía de Planificación Basada en Capacidades Conduzca siempre para obtener valor. ¡Una mejora a medias es un desperdicio 100%! Nadie enseña a un águila a gatear, caminar o correr. Las águilas vuelan. Descargar Enseñe a volar a sus águilas: Planificación basada en Capacidades [...]
Descargar la Guía de evaluación de las capacidades de arquitectura empresarial
Descargue 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. La planificación basada en capacidades es una de las técnicas de mejora de la arquitectura empresarial más potentes. La mejor práctica de planificación basada en la capacidad utiliza la capacidad como [...]
Descargar ejemplo de principios de arquitectura empresarial
Descargar un ejemplo de principios de arquitectura Descargue un ejemplo de principios de arquitectura empresarial. Los principios de arquitectura empresarial identifican cómo enfocar un problema o una decisión. El enfoque siempre le conduce hacia sus prioridades duraderas. Descargar una muestra de principios de arquitectura empresarial [...]
Descargar la Guía de Gobernanza de la Arquitectura Empresarial
Descargar la Guía de Gobernanza de la Arquitectura Empresarial Descargue la Guía de Gobernanza de la Arquitectura Empresarial para comprender las mejores prácticas para dirigir y controlar el desarrollo de la arquitectura, y el cambio para obtener los resultados esperados. Descargar la Guía de Gobernanza de la Arquitectura Empresarial [...]
Descargar Integración de 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 del sector. Descargar Integración de TOGAF y SABSA Integración de TOGAF y SABSA Incluye SABSA utiliza un [...]
Descargar Arquitectura de referencia de capacidades de arquitectura empresarial
Descargar Arquitectura de Referencia de Capacidades de Arquitectura Empresarial La Arquitectura de Referencia de Capacidades de 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 [...]
Conocimientos esenciales de la fase C
Todas las fases de TOGAF ADM te ayudan a desarrollar los conocimientos necesarios. El resultado de la fase C es la arquitectura de la aplicación candidata, incluida en la arquitectura de los sistemas de información candidata.
| Resultados y resultados | Conocimientos esenciales |
| En arquitectura de aplicación arquitectura de dominio aprobado por las partes interesadas para el problema que se está abordando, con un conjunto de brechas, y trabajar para aclarar las brechas entendidas por las partes interesadas. | ¿Por qué el portafolio de software actual no satisface las preferencias de las partes interesadas?
¿Qué debe cambiar para que el portafolio de software satisfaga las preferencias de las partes interesadas? (Brechas) ¿Qué trabajo es necesario para lograr cambios que sean consistentes con el valor adicional que se está creando? (Paquete de trabajo) Cómo se ajustan las prioridades y preferencias de las partes interesadas en función del valor, el esfuerzo y el riesgo del cambio. (Requisitos de las partes interesadas) |
Tabla 4 de Guía de la serie TOGAF: Guía del arquitecto empresarial para el desarrollo de arquitectura
Fase C: Lo básico
En la Fase C, podemos simplificar el trabajo de un arquitecto de aplicaciones para determinar cómo una empresa debería mejorar. Esto requiere comprender en qué busca ser experta, dónde se queda corta y qué debe cambiar para alcanzar la excelencia.
Los elementos básicos de la Fase C son:
- Conocer cómo el portafolio de aplicaciones permite capturar valor
Toda organización tiene una cadena de valor. Esta actividad transforma un insumo en algo más valioso para sus clientes. Las aplicaciones generan valor o gestionan registros. Tradicionalmente, casi todo el software gestionaba registros.
Debe optimizar su software para su función: creación de valor o gestión de registros. Asuma la gestión de registros. No confunda la importancia de la gestión de registros con la creación de valor.
Conocer el origen del coste y la complejidad
Cada portafolio de aplicaciones genera costos y complejidad. Consideramos el software como un complejo mecanismo de relojería que se fue ensamblando con el tiempo. Conectamos todo con todo. Con productos digitales, un servicio de TI omnipresente. Entendiendo ITFM es una habilidad fundamental.
Debe optimizar su cartera principal para reducir los costos y la complejidad sostenidos. Debe habilitar agilidad empresarial. Las organizaciones digitales modernas sólo pueden mejorar al ritmo del software.
- Saber cómo seleccionar software
Existen cuatro modelos de software: SaaS, suites empresariales, paquetes comerciales especializados y desarrollo a medida. Cada uno tiene un modelo de coste y optimización diferente. Es necesario aplicar el modelo de software adecuado en los lugares adecuados.
- Saber cuándo el software es parte de ''el producto'
Nuestras organizaciones ofrecen un producto o servicio. Software que es...'el producto'' difiere en gran medida del software que respalda el negocio.
- Conocer el flujo de información
Las personas son infinitamente flexibles. Podemos decidir compartir información. Podemos ver una situación de forma proactiva y reaccionar. El software hace exactamente lo que se le indica. El software solo hace lo que se le indica.
El flujo de información se produce alrededor del software para lograr resultados óptimos. Este tipo de flujo de información mina la agilidad empresarial, reduce la eficiencia y aumenta los costos.
- Conocer las expectativas del software
A veces necesitamos un gestor de registros ocasional. A veces necesitamos un sistema autónomo. La mayoría de las veces necesitamos algo que nos ayude sin demasiada sobrecarga. Aprovechamos los conceptos y atributos de modelos de capacidad para orientar las decisiones sobre la arquitectura de nuestra aplicación. Ver el Guía de evaluación de la capacidad de arquitectura empresarial.
- Conozca lo que debe hacer la organización
Toda empresa tiene un conjunto de procesos que debe realizar: creación de valor primario, soporte y administración. Todas necesitan software. Todas crean y producen información. Es necesario saber qué son, qué información consumen y quién los procesa.
- ¿Qué debe cambiar para ofrecer la mejor cartera de aplicaciones?
Desarrollamos la arquitectura de aplicaciones para mejorar una organización. La mayoría de los cambios no suponen una diferencia sustancial. La mayoría de los cambios son superficiales. Dedique su tiempo a cambios sustanciales que impulsen la agilidad empresarial, los costes y la creación de valor.
Los tres elementos esenciales para la finalización de la Fase C:
- Primero, ¿Qué debe cambiar? Cambio de enfoque, diseño organizacional, capacitación, externalización, internalización, automatización. Todos estos son cambios. Los implementamos para mejorar una organización.
- Segundo, ¿Cuándo debe cambiar? ¿Existen dependencias? ¿Qué hay de las precondiciones? ¿Se está preparando el terreno para un cambio posterior?
- Tercero, ¿Cómo sabrá si el cambio tuvo éxito? ¿Cuál es su criterio de gobernanza para el éxito? ¿Cómo protegerá el valor?
Las partes interesadas en la arquitectura empresarial son responsables de todas las decisiones sobre qué debe cambiar y cuándo. El arquitecto de aplicaciones es responsable de describir las pruebas de gobernanza para que las partes interesadas puedan dirigir el proyecto de cambio y los resultados secundarios y terceros.
Formación en arquitectura empresarial y TOGAF
Curso de formación en arquitectura empresarial TOGAF
¿Desea formación para la Certificación TOGAF? Demuestre sus conocimientos de arquitectura empresarial con la Certificación TOGAF Curso de Formación en Arquitectura Empresarial TOGAF® Dé un paso importante para ser un mejor arquitecto empresarial con el Estándar TOGAF, 10º [...]
Formación en arquitectura empresarial personalizada
Formación personalizada en arquitectura empresarial La formación personalizada en arquitectura empresarial aborda el desarrollo profesional que su equipo de EA necesita. Los buenos arquitectos empresariales utilizan un amplio conjunto de habilidades, método, además de conocimientos especializados de dominio para desarrollar la empresa [...]
Educación eficaz en línea
Educación en línea eficaz La educación en línea eficaz funciona. Los estudiantes acceden al mejor profesor disponible. Los estudiantes controlan el ritmo de su aprendizaje. Los instructores pueden compartir abundante material complementario sin distraer del tema principal. Una enseñanza a distancia eficaz [...]
Curso de formación en arquitectura empresarial
Formación en arquitectura empresarial Una arquitectura empresarial eficaz se basa en la arquitectura empresarial. El curso proporciona a los estudiantes las habilidades y conocimientos para desarrollar la arquitectura empresarial en un entorno de arquitectura empresarial. La arquitectura empresarial implica describir la estructura [...]
Curso de formación Avolution ABACUS
Formación Avolution ABACUS La arquitectura empresarial eficaz se basa en el modelado y análisis formal. Ofrecemos formación Avolution ABACUS de arquitectos empresariales prácticos. Los estudiantes adquieren habilidades y conocimientos para crear arquitecturas empresariales y de dominio integradas en este [...]
Arranque del arquitecto de empresa
Enterprise Architect's Kickstart Necesitamos mantener actualizadas nuestras competencias. Ahora más que nunca. Utilice el Kickstart de arquitectura empresarial para mejorar su capacidad de ofrecer una arquitectura empresarial transformadora. Este kick-start de 90 días es la forma en que Conexiam Consulting [...]
Entregables de la arquitectura de la aplicación TOGAF ADM Fase C
Un resultado central de la Fase C es la arquitectura de aplicaciones. Esta forma parte de la arquitectura empresarial completa.
Entregables de arquitectura de aplicaciones de la fase C de TOGAF y casos de uso de arquitectura empresarial
Existen cuatro objetivos fundamentales para el desarrollo de la arquitectura empresarial. Los diferentes entregables de la Fase C de TOGAF tienen distinta importancia para cada objetivo.
| Arquitectura para apoyar la estrategia | Arquitectura para apoyar la cartera | Arquitectura de apoyo al proyecto | Arquitectura para respaldar la entrega de soluciones | |
| Producto del trabajo de la fase C: Arquitectura de la aplicación candidata | Entregable clave
El uso principal es que las partes interesadas comprendan el objetivo y el trabajo. El uso secundario es la creación de especificaciones de requisitos de arquitectura para arquitectos. |
Entregable clave
El uso principal es que las partes interesadas comprendan el objetivo y el trabajo. 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 proveedores internos)
El uso principal es la creación de especificaciones de requisitos de arquitectura para implementadores. |
| Producto del trabajo de la fase C: Elementos de la hoja de ruta del candidato | Entregable clave
El uso principal es que las partes interesadas comprendan el trabajo. El uso secundario es la creación de restricciones para los arquitectos. |
Entregable clave
El uso principal es que las partes interesadas comprendan el trabajo y la dependencia. El uso secundario es la creación de restricciones para los 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 proveedores internos).
El uso principal es la identificación del cambio requerido y las preferencias de cómo ejecutar el cambio, para gestionar la selección y la participación de los socios para la entrega de soluciones. |
| Producto del trabajo de la fase C: Especificación de requisitos de arquitectura | Uso limitado
Generalmente los arquitectos pueden inferir limitaciones a partir de una arquitectura superior. |
Uso limitado
Generalmente los arquitectos pueden inferir limitaciones a partir de una arquitectura superior. |
Entregable clave
Antes de finalizar el inicio del proyecto |
Entregable clave
Antes del compromiso y la contratación |
Tabla 3 Guía de la serie TOGAF: Guía del arquitecto empresarial para el desarrollo de arquitectura
Arquitectura de la aplicación candidata
Existen cuatro objetivos fundamentales para el desarrollo de la arquitectura empresarial. Los distintos modelos tienen distinta importancia para cada objetivo.
Componentes de la hoja de ruta de la arquitectura de aplicaciones candidatas
¿Qué debe cambiar? Si se está modificando el modelo de desarrollo de aplicaciones, la diferencia entre el modelo actual y el objetivo es el candidato a la hoja de ruta. Por lo tanto, es necesario todo lo necesario para posibilitar ese cambio.
A menudo utilizamos un modelo de sistema para resumir el cambio. Este modelo permite la abstracción justa del software real para mantener una conversación sobre planificación y ejecución. Solemos utilizar puntuaciones y paquetes de trabajo para articular un cambio. Para obtener más información sobre el uso de puntuaciones, consulte Guía de evaluación de la capacidad de arquitectura empresarial.
Utilizamos todos los componentes de la hoja de ruta de arquitectura en TOGAF Fase E - Hoja de ruta de la arquitectura.
Especificación de requisitos de arquitectura de la aplicación candidata
Define cómo evaluarás el cambio. ¿Cómo se evaluará la mejora?
A menudo utilizamos puntuaciones en nuestros modelos para describir los requisitos. Cada requisito es una medida de eficiencia, automatización, agilidad o rendimiento. Luego, cuando trabajamos en TOGAF Fase G amaestrado Gobernanza de la arquitectura con un proyecto de cambio Utilizamos estas puntuaciones para evaluar diseños e implementaciones.
Vaya más allá con el Proceso y Método de Arquitectura Empresarial de Mejores Prácticas
Buenas prácticas arquitectura empresarial de Conexiam Navegar
Creación de un Comité de Revisión de Arquitectura Moderna
Poner en marcha una Junta de Revisión de Arquitectura Moderna Poner en marcha una junta de revisión de arquitectura moderna requiere crear un proceso de gobernanza dinámico y establecer un órgano decisorio de apoyo de alto nivel. El objetivo es establecer una gobernanza eficaz de la arquitectura sin burocracia. [...]
Liberar el poder de la planificación basada en capacidades: Guía rápida
Cómo liberar el poder de la planificación basada en capacidades: Guía rápida ¿Está buscando una forma más eficaz de planificar y ejecutar su estrategia empresarial? No busque más: la planificación basada en capacidades. Identificar y utilizar las [...]
Todo lo que debe saber sobre el uso de alternativas arquitectónicas
Todo lo que necesita saber sobre el uso de alternativas de arquitectura Las alternativas de arquitectura son necesarias para un buen desarrollo de la arquitectura empresarial. Cuando comienza el desarrollo de la arquitectura, su empresa tiene deficiencias. Hay áreas que mejorar. Necesita [...]
Comprender la arquitectura empresarial y Agile
Entender la arquitectura empresarial y la agilidad Tanto la agilidad como la arquitectura empresarial están diseñadas para reducir el riesgo. El desarrollo ágil de software destaca en la construcción de algo que nunca hemos tenido antes y que no sabemos cómo construir. [...]
La hoja de ruta de la arquitectura empresarial como diseño
La hoja de ruta de la 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 ayudarles a desarrollar y recorrer el mejor camino a seguir. También [...]
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 objetivo y proporcionar gobernanza para la implementación. Una empresa robusta […]
Cómo definir los principios de arquitectura empresarial
Cómo definir los principios de la arquitectura empresarial. Para definir los principios de la arquitectura empresarial, es necesario comprender qué es un principio y cómo aplicarlo. De esta manera, podemos desarrollar principios de arquitectura sólidos que ayuden a mejorar nuestra organización. […]
Uso del análisis de escenarios para la arquitectura empresarial
Un escenario es simplemente un futuro plausible. El análisis de escenarios examina cómo llegamos a un futuro plausible y cómo afectan los distintos escenarios a nuestras decisiones actuales. Los escenarios ayudan a los líderes [...]
Gestión del trabajo de arquitectura empresarial
Gestión del Trabajo de Arquitectura Empresarial La Gestión del Trabajo de Arquitectura Empresarial es crucial 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 necesitan traducir las [...]
Desarrollo de la estrategia de arquitectura empresarial
Desarrollo de la estrategia de arquitectura empresarial: Plan Estratégico para el Cambio La Estrategia de Arquitectura Empresarial es acción. La acción que emprenderá su organización y los cambios que realizará para alcanzar sus objetivos estratégicos. El desarrollo de la estrategia tiene que ver con la elección. [...]
Modelos, herramientas y técnicas de arquitectura de aplicaciones
La Fase C de TOGAF ADM proporciona la Arquitectura de Sistemas de Información. Esta fase tiene como objetivo 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 y los modelos necesarios.
Las preocupaciones de las partes interesadas identificarán las perspectivas. Existen siete modelos centrales de arquitectura de aplicaciones.
- 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ñado su portafolio de aplicaciones
- Modelo funcional que describe todo lo que necesita que su portafolio de software haga
- 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 garantizar 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 inyectan costos en la cartera de TI - Modelo funcional
- Dónde 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 de producto
- Las cosas que una organización debe ser capaz de hacer - Modelo funcional
- El flujo de información necesario para realizar las actividades de una empresa - Modelo de integración
- Las actividades completas que realiza una empresa, normalmente agrupadas para mostrar cómo se relacionan entre sí. Modelo de servicio
- ¿Qué es el portafolio de software? Modelo físico
Tenga siempre presente que busca mejorar la organización. La mejora requiere cambio y genera 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 reduce considerablemente el valor potencial.
Al leer, tenga en cuenta que los mismos términos tienen muchos usos. Busque el propósito del modelo y no se deje engañar si la etiqueta difiere de cómo usted 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 centramos en lo que estamos tratando de entender, no en cómo se llama el modelo.
Diferentes modelos explicarán distintos aspectos de la empresa. Juntos, los modelos y los cambios necesarios conforman la arquitectura de la aplicación.
Patrones de arquitectura de aplicaciones
Nosotros 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 patrones, y el Trozos duros. El éxito con el patrón requiere abordar la Trozos 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ñar aplicaciones.
- 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 de estrangulador
Problema predecible—reemplazar sistemas heredados
Acercarse—reemplazar gradualmente o “estrangular” un sistema heredado existente mediante la construcción de nuevos componentes a su alrededor para reemplazar el sistema de forma incremental
- Patrón de estrangulador
- Diseño de aplicaciones (Grupo de los Cuatro Patrones de Aplicación)
Como arquitectos empresariales, utilizamos patrones de diseño como restricciones a la libertad de los equipos de desarrollo de aplicaciones. (Ver Arquitectura empresarial y Agile: Restricción de sprints)- Patrón Singleton- garantiza que una clase tenga solo una instancia y proporciona un punto de acceso global a esa instancia
Modelos de arquitectura de aplicaciones
El desarrollo de una arquitectura de aplicación requerirá el desarrollo de varios modelos de arquitectura empresarial. Cada uno explica la cartera de software de la empresa de forma diferente. La Arquitectura de Aplicaciones TOGAF Fase C se centra en el desarrollo de la Arquitectura Objetivo mediante estos modelos. Esto garantiza que el arquitecto de la aplicación objetivo colabore con los demás dominios para optimizar la mejora de 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 demás dominios de la arquitectura empresarial.
Modelo de desarrollo de aplicaciones
El Modelo de Desarrollo de Aplicaciones describe cómo se desarrollará el software. Requiere un Modelo Funcional o Físico. El Modelo Funcional es mucho mejor porque es un software de identificación lógica.
Existen cuatro tipos de desarrollo de aplicaciones: SaaS, suites empresariales, paquetes comerciales especializados y desarrollo a medida. 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. No se permite la personalización.
Se recomienda su uso en actividades empresariales administrativas que indirectamente contribuyen a la generación de valor. Las estrictas restricciones del software restringen la actividad empresarial y contribuyen a la adopción de prácticas estándar del sector.
- Las suites empresariales se caracterizan por múltiples modelos funcionales superpuestos, con un modelo de datos definido. Las interfaces y la funcionalidad se pueden configurar o personalizar. Las personalizaciones siempre generan costos adicionales durante el ciclo de vida. El ciclo de vida está influenciado por terceros.
- Las características de los paquetes comerciales especializados incluyen un enfoque específico y la optimización funcional para la actividad especializada. Suelen estar diseñados en torno a una única forma de abordar la actividad empresarial. Suelen contar con un modelo de datos único y bien definido. Las interfaces y la funcionalidad son configurables. Es posible la personalización. Las personalizaciones siempre generan costos significativos durante el ciclo de vida, el cual está fuertemente influenciado por terceros.
- Las características del desarrollo personalizado incluyen una alineación directa entre los límites y las actividades de su organización. Siempre diseñado para respaldar el modelo de comunicación existente. Enfoque y optimización funcional para la actividad especializada. Se espera un modelo de datos poco definido. Las interfaces y la funcionalidad deben personalizarse. La gestión del ciclo de vida suele ignorarse y conlleva un alto costo continuo.
Se recomienda su uso en actividades empresariales de la cadena de valor primaria. Su flexibilidad permite optimizar la generación de valor. Para un uso eficaz, es necesario comprender la generación de valor actual y futura.
Modelo de desarrollo de aplicaciones
El Modelo de Desarrollo de Aplicaciones describe cómo se desarrollará el software. Requiere un Modelo Funcional o Físico. El Modelo Funcional es mucho mejor porque es un software de identificación lógica.
Existen cuatro tipos de desarrollo de aplicaciones: SaaS, suites empresariales, paquetes comerciales especializados y desarrollo a medida. 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. No se permite la personalización.
Se recomienda su uso en actividades empresariales administrativas que indirectamente contribuyen a la generación de valor. Las estrictas restricciones del software restringen la actividad empresarial y contribuyen a la adopción de prácticas estándar del sector.
- Las suites empresariales se caracterizan por múltiples modelos funcionales superpuestos, con un modelo de datos definido. Las interfaces y la funcionalidad se pueden configurar o personalizar. Las personalizaciones siempre generan costos adicionales durante el ciclo de vida. El ciclo de vida está influenciado por terceros.
- Las características de los paquetes comerciales especializados incluyen un enfoque específico y la optimización funcional para la actividad especializada. Suelen estar diseñados en torno a una única forma de abordar la actividad empresarial. Suelen contar con un modelo de datos único y bien definido. Las interfaces y la funcionalidad son configurables. Es posible la personalización. Las personalizaciones siempre generan costos significativos durante el ciclo de vida, el cual está fuertemente influenciado por terceros.
- Las características del desarrollo personalizado incluyen una alineación directa entre los límites y las actividades de su organización. Siempre diseñado para respaldar el modelo de comunicación existente. Enfoque y optimización funcional para la actividad especializada. Se espera un modelo de datos poco definido. Las interfaces y la funcionalidad deben personalizarse. La gestión del ciclo de vida suele ignorarse y conlleva un alto costo continuo.
Se recomienda su uso en actividades empresariales de la cadena de valor primaria. Su flexibilidad permite optimizar la generación de valor. Para un uso eficaz, es necesario comprender la generación de valor actual y futura.
Modelo de sistema
El modelo de sistema es una abstracción del software en torno a una actividad. Considere el sistema de la cadena de suministro y todo lo que lo compone. El diseño de su modelo de sistema se alineará con el funcionamiento de su empresa.
Al igual que el modelo de capacidades del arquitecto empresarial, un modelo de sistema permite enfocar el pensamiento en un sistema. Se puede considerar la mejora de un sistema completo y luego enfocar los cambios necesarios en todo lo que lo compone e interactúa con él.
Modelo de 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 clave para el valor, el uso y la administración del producto. Un modelo de producto determinará las opciones del modelo de desarrollo de aplicaciones. Necesita desarrollo personalizado, duplicación y una capacidad de adaptación significativamente mayor cuando las funciones se asocian con sus productos y servicios.
Modelo funcional
El modelo funcional desglosa su portafolio de software según su funcionalidad. Identifica todas las funciones que su software necesita realizar. Un buen modelo funcional ofrece una amplia cobertura.
Al igual que el modelo de procesos del arquitecto de negocios, un modelo funcional suele ser una arquitectura de referencia. Resulta eficaz cuando se busca la duplicación y la integración. Suele constituir la base de un modelo de desarrollo de aplicaciones, donde a los diferentes bloques funcionales se les asigna un tipo de desarrollo de aplicación objetivo.
Es fundamental en la planificación del portafolio de aplicaciones. La duplicación y la integración incrementan la complejidad y el costo del portafolio 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 de su software y el método para superarlos. No dude en especificar que el límite no se puede superar o que debe superarse manualmente. Muchas integraciones deficientes de aplicaciones solo generan rigidez. Desarrollar un modelo de integración útil requiere iteración con el trabajo de un arquitecto de negocios que desarrolla... Mapa organizacional y Modelo de información. El modelo de integración, el mapa organizacional y el modelo de información se informan y restringen mutuamente.
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 condensa la Funcionalidad en una caja negra con interfaces conocidas. Un buen Modelo de Servicio es fundamental 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 servicios de aplicaciones, sino liberando el cambio de una parte de la empresa de otra.
Modelo físico
Un Modelo Físico es el portafolio de software real. Lo describiremos en términos utilizados por los proveedores de software comercial y su programa de desarrollo de aplicaciones. Deberá asociarlo con los demás Modelos de Arquitectura de Aplicaciones para adaptar el Objetivo al mundo real.
El modelo físico se utiliza como restricción para los modelos abstractos de arquitectura de la aplicación. También constituye la base de... 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 el desarrollo basado en modelos. Al trabajar en arquitectura para apoyar 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 las implicaciones del Objetivo para las diferentes comunidades. Desarrollar modelos 4+1 ayuda a garantizar que se consideren todos los cambios relevantes.
- Las líneas de información de DODAF extraen todos los flujos de información necesarios. No importa si el nodo es una persona, una organización o un sistema. La información fluirá de entrada a salida. La forma más rápida de eliminar la automatización es incorporar pasos manuales en medio del 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 de apoyo al proyecto | Arquitectura para respaldar la entrega de soluciones | |
| Modelo de desarrollo de aplicaciones | Entregable clave | Entregable clave | Arquitectura superior | Arquitectura superior |
| Modelo de sistema | Entrega regular | Entregable clave | Arquitectura superior | Arquitectura superior |
| Modelo funcional | Entrega regular | Entregable clave | Entregable clave y Arquitectura Superior | Entregable clave y Arquitectura Superior |
| Modelo de producto | Entregable ocasional
El nivel apropiado de detalle a menudo disminuye el valor |
Entrega 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 |
Entrega 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 |
Entrega 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 | Aporte principal
Requiere un sistema o modelo funcional |
Aporte principal
Requiere un sistema o modelo funcional |
Aporte principal
Requiere un sistema o modelo funcional |
Aporte principal
Requiere un sistema o modelo funcional |
Aporte principal
Requiere un sistema o modelo funcional |
Aporte principal
Requiere un sistema o modelo funcional |
Entrada limitada | Entrada limitada |
| Modelo de sistema | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | Aporte principal | Entrada limitada | Aporte principal |
| Modelo de producto | Aporte principal | Aporte principal | Aporte principal | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | |
| Modelo de integración | Entrada muy limitada | Aporte importante al diseño del núcleo
Requiere un sistema o modelo funcional |
Aporte importante al diseño del núcleo
Requiere un sistema o modelo funcional |
Mejor entrada
Es muy difícil encontrar un enlace directo. Vale la pena el esfuerzo. |
Aporte importante al diseño del núcleo
Requiere un sistema o modelo funcional |
Entrada limitada
Úselo solo si no hay otros modelos disponibles |
Aporte importante al diseño del núcleo
Requiere un sistema o modelo funcional |
Aporte importante al diseño del núcleo
Requiere un sistema o modelo funcional |
| Modelo de servicio | Entrada limitada
Los vínculos son importantes, pero es muy difícil ver un vínculo directo. |
Entrada limitada
Los vínculos son importantes, pero es muy difícil ver un vínculo directo. |
Entrada limitada
Los vínculos son importantes, pero es muy difícil ver un vínculo directo. |
Mejor entrada
Es muy difícil encontrar un enlace directo. Vale la pena el esfuerzo. |
Se utiliza como prueba de completitud | Aporte principal
Es muy difícil encontrar un enlace directo. Vale la pena el esfuerzo. |
Aporte 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 que los casos de uso de la arquitectura empresarial son el tipo de cambio, el propósito del equipo de arquitectura empresarial o las preguntas que se hacen comúnmente.
En cada caso de uso de arquitectura empresarial, desempeñamos la misma función: ayudamos a las partes interesadas a tomar mejores decisiones y lideramos iniciativas de cambio exitosas. Lo único que cambia es la pregunta.
| Cambio estratégico | Cambio incremental | Mejorar los costos | Mejorar cualidades | Mejorar 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 de 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 | Informar sobre las restricciones | 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 huecos y restricciones. | Muy útil para huecos y restricciones. | Muy útil para huecos y restricciones. | Muy útil para huecos y restricciones. | Muy útil para huecos y restricciones. | Muy útil para huecos y restricciones. | Muy útil para huecos y restricciones. |
Aplicación de los principios de la arquitectura empresarial a la arquitectura de aplicaciones
Hemos identificado 7 principios de arquitectura que todo arquitecto empresarial debería conocer. La siguiente tabla identifica las implicaciones de estos Principios de Arquitectura para la Arquitectura de la Aplicación. Al realizar gobernanza de la arquitectura empresarial, Necesita probar la arquitectura de su aplicación para garantizar que se ajuste a una arquitectura superior. En este caso, ¿cumple con 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 implica diferenciación ni transformación, procure eliminar el cambio. Evite cualquier cambio en el proceso o sistema que no esté explícitamente justificado en términos de costo y resultados. |
| Enfoque en la excelencia | Alinearse 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 | La ubicación y el estilo de trabajo determinan la interfaz y el modelo de aplicación. |
| Experiencia de usuario sin dolor | Los programas de eficiencia se centran en los procesos de negocio existentes.
Los programas de diferenciación y transformación requieren cambios en la interfaz y la participación del usuario a medida que se desarrolla experiencia con el nuevo proceso. |
| Autoservicio | Las actividades administrativas y la implementación de aplicaciones son de alto costo cuando no son de autoservicio.
Una experiencia de usuario débil tiene un coste elevado. |
¿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 el desarrollo ágil. La guía fundamental proviene del modelo de desarrollo de aplicaciones. Este identifica dónde no se desea un desarrollo ágil.
Arquitectura empresarial y desarrollo ágil se intersectará en cuatro áreas. El La arquitectura empresarial permitirá:
- definir el enfoque ágil
- guiar el backlog en el sprint
- Restringir las opciones dentro de los sprints
- Resolver la dependencia del producto cruzado
Siempre centramos el desarrollo ágil en actividades innovadoras y diferenciadoras, y seguimos rigurosamente las mejores prácticas establecidas en otros entornos. Estas mejores prácticas provienen del software comercial consolidado. 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 agilidad empresarial?
La agilidad empresarial no tiene nada que ver con cómo se escribe el software. La agilidad empresarial se refiere a 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. Utilizamos el mismo atributo de Agilidad y puntuaciones en el Guía de evaluación de capacidades Identificamos los sistemas de información que deben ser capaces de adaptarse a cambios rápidos. Luego, diseñamos la arquitectura para facilitar el cambio.
Modelo de agilidad empresarial
- Estado de alerta: ¿Puedes detectar oportunidades y amenazas?
- Accesibilidad: ¿Puede acceder a la información relevante a tiempo para responder?
- Capacidad de decisión: ¿Puede usted decidir utilizando la información disponible?
- Rapidez – ¿Puedes implementar tus decisiones en el tiempo disponible?
- Flexibilidad – ¿Qué estás haciendo para reducir las barreras a la acción?
¿Cuál es el objetivo de la fase C del TOGAF ADM?
En Fase A, usted identificó un Arquitectura de destino simplificada: la visión de la arquitectura. La Visión de la Arquitectura abarcó todos los dominios. La actividad de la Fase C profundiza en el desarrollo de los dominios de la arquitectura de aplicaciones y datos. El éxito requiere:
- Aborda el problema de cómo la empresa actual no puede satisfacer las preferencias de las partes interesadas.
- ¿Sabe qué debe cambiar para que la empresa satisfaga las preferencias de las partes interesadas? (Brechas)
- Tiene una comprensión suficiente del trabajo que es necesario para entregar los cambios (Paquete de trabajo)
- Comprende la interacción entre los cambios y las restricciones en otros dominios de la 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 limitaciones que se imponen a la arquitectura de la aplicación y las que se imponen a otros dominios.
Recuerde, el TOGAF ADM explora cambios potenciales. Hasta que esté desarrollando el Plan de Implementación en la Fase F, Busca la salida más económica. Tener malas ideas no significa que no estés resolviendo el problema. Debes descartar las ideas débiles. alternativas de arquitectura. Detener las malas ideas antes ahorra dinero y permite cambios exitosos. En cuanto una idea se vuelve mala, deténgase en seco. Elimínela. ¡Celebre su victoria! ¡Celebre que está impulsando un cambio exitoso!
Patrones de arquitectura de aplicaciones
Nosotros usamos Patrones de arquitectura Para aumentar drásticamente la productividad y la calidad de nuestro desarrollo arquitectónico. Utilizamos un sistema simplificado. Plantilla de patrón de arquitectura que nos lleva a comprender la problema predecible, enfoque de patrones, y el Trozos duros. La aplicabilidad del patrón generalmente está 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ñar aplicaciones.
- 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 de estrangulador
Problema predecible—reemplazar sistemas heredados
Acercarse—reemplazar gradualmente o “estrangular” un sistema heredado existente mediante la construcción de nuevos componentes a su alrededor para reemplazar el sistema de forma incremental
- Patrón de estrangulador
- Diseño de aplicaciones (Grupo de los Cuatro Patrones de Aplicación)
Como arquitectos empresariales, utilizamos patrones de diseño como restricciones a la libertad de los equipos de desarrollo de aplicaciones. (Ver Arquitectura empresarial y Agile: Restricción de sprints)- Patrón Singleton- garantiza que una clase tenga solo una instancia y proporciona un punto de acceso global a esa instancia
Reflexiones finales sobre la fase C del TOGAF ADM
Arquitectos de aplicaciones que trabajan con un Equipo de Arquitectura Empresarial Tienen un conjunto de responsabilidades más importantes que el diseño de una aplicación. Necesitan desarrollar las directrices y los marcos de protección para que las personas diseñen, implementen y desarrollen la cartera de aplicaciones de la empresa. En resumen, Un arquitecto de aplicaciones empresariales es distinto de un arquitecto de soluciones o de 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 rol complejo.
- Trabajar con las partes interesadas y las PYME para seleccionar cambios en la cartera de aplicaciones que permitan la mejor organización futura
- trabajar con sus compañeros arquitectos de dominio Explorar cómo las mejoras requeridas en el dominio empresarial se habilitan o impiden en el dominio de la aplicación.
- Trabajar con las partes interesadas para eliminar cambios en la cartera de aplicaciones que generen resultados insuficientes o cuesten demasiado. Además, eliminar cambios en otros dominios que generen costos inaceptables y cambios en la cartera de aplicaciones.
En la fase C de TOGAF ADM, uno de los cuatro pilares fundamentales dominios de arquitectura empresarial Se desarrolla. TOGAF es muy claro: esta arquitectura se desarrolla durante el desarrollo de los demás dominios. Los cambios en un dominio habilitarán, forzarán o bloquearán cambios en otro.
Los equipos de EA altamente funcionales no utilizan a sus arquitectos de aplicaciones como diseñadores de una sola aplicación. Esta función es necesaria, pero sin una arquitectura de aplicaciones que cubra partes significativas de la empresa, no es posible optimizarla.
TOGAF ADM Fase C desarrolla la arquitectura de aplicaciones. La arquitectura de aplicaciones es la base de todas las empresas digitales modernas. Utilice TOGAF Fase C para Concentrar los escasos recursos de cambio en obtener el máximo valor empresarial.
