En Norma TOGAF<\/a> Tiene claros dos aspectos. Primero, la arquitectura tecnol\u00f3gica respalda directamente la arquitectura de sistemas de informaci\u00f3n (aplicaci\u00f3n y datos) para habilitar la arquitectura empresarial. Segundo, no desarrollamos arquitecturas de dominio secuencialmente.<\/p>\n La transformaci\u00f3n digital requiere la Arquitectura de TI adecuada<\/a>. Se requiere una buena arquitectura tecnol\u00f3gica porque cada dominio de la arquitectura<\/a> permite, entrega o bloquea resultados en otros dominios.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tExplorar la formaci\u00f3n para la certificaci\u00f3n TOGAF\n\t\t\t<\/a>\n\t De un vistazo<\/p>\n Utilice el TOGAF ADM<\/a> Desarrollar el conocimiento necesario para la mejor arquitectura tecnol\u00f3gica. Cada fase del ADM proporciona los insumos y la actividad necesarios para desarrollar el conocimiento sobre un tema espec\u00edfico. El ADM TOGAF es la base del est\u00e1ndar TOGAF. Es el \u00fanico m\u00e9todo universal escalable para desarrollar... arquitectura empresarial<\/a>. Es adecuado para cualquier nivel de detalle. Como todos los modelos l\u00f3gicos, necesita ampliarse para abarcar diferentes niveles de detalle: estrategia, cartera, proyecto y entrega de soluciones.<\/p>\n Si necesitas un Descripci\u00f3n general del TOGAF ADM<\/a>, por favor lea el Explicaci\u00f3n de las fases del ADM TOGAF<\/a>.<\/p>\n En la fase D de TOGAF, Arquitectos tecnol\u00f3gicos<\/a> Lideran el desarrollo de la arquitectura tecnol\u00f3gica. Lo hacen buscando habilitar la arquitectura de los sistemas de informaci\u00f3n, no simplemente recibiendo \u00f3rdenes y satisfaciendo expectativas. Los arquitectos tecnol\u00f3gicos comprenden que una infraestructura duradera es fundamental para su entorno. Deben anticiparse y estar preparados. Tienen que asegurarse de que las expectativas a corto plazo no generen problemas a largo plazo.<\/p>\n Cuando estamos desarrollo de equipos de arquitectura empresarial<\/a>, les contamos a los arquitectos dos hechos centrales sobre la Fase D de TOGAF: Arquitectura Tecnol\u00f3gica. Primero, hasta que tenga un Modelo de desarrollo de aplicaciones,<\/a> No puede continuar. Desarrollar los detalles de su infraestructura antes de comprender las necesidades de la arquitectura de su aplicaci\u00f3n es in\u00fatil. En segundo lugar, si se dedican a una agenda de TI o infraestructura, siempre desarrollar\u00e1n una arquitectura tecnol\u00f3gica de baja calidad. Los dise\u00f1adores y operadores de infraestructura deber\u00edan sentirse limitados por la arquitectura tecnol\u00f3gica.<\/p>\n En una empresa moderna transformada digitalmente, todos los dominios de la arquitectura interact\u00faan. Las decisiones en un dominio habilitan, entregan o bloquean los resultados en otro. La mayor\u00eda de los objetivos de negocio dependen de... Arquitectura de TI adecuada<\/a>. S\u00f3lo podemos desarrollar la arquitectura tecnol\u00f3gica adecuada si tenemos una arquitectura de aplicaci\u00f3n s\u00f3lida.<\/p>\n La verdadera dificultad de la arquitectura tecnol\u00f3gica reside en la larga vida \u00fatil de la infraestructura. Sin una arquitectura tecnol\u00f3gica que establezca restricciones, las decisiones t\u00e1cticas de infraestructura siempre generar\u00e1n peores resultados empresariales.<\/p>\n Existe una correlaci\u00f3n directa entre una buena arquitectura tecnol\u00f3gica y la PaaS moderna, o la mayor\u00eda de las arquitecturas en la nube. Ambas identifican servicios de infraestructura. Ambas limitan y habilitan opciones de datos y aplicaciones. Ambas a\u00edslan las aplicaciones de la infraestructura subyacente.<\/p>\n El TOGAF ADM comienza con Fase A<\/a>. Ofrece una Arquitectura objetivo simplificada: la visi\u00f3n de la arquitectura.<\/a>. La visi\u00f3n de la arquitectura debe incluir negocios, aplicaciones, datos, y dominios tecnol\u00f3gicos<\/em>. Con demasiada frecuencia, vemos a personas simular desarrollar una Visi\u00f3n de Arquitectura. Se presentan con una fantas\u00eda de operaciones empresariales y tratan la Fase D como un ejercicio de implementaci\u00f3n de fantas\u00edas. La arquitectura empresarial real ha desarrollado una arquitectura objetivo simplificada. La actividad de la Fase D profundiza en los dominios de la arquitectura tecnol\u00f3gica. El \u00e9xito requiere:<\/p>\n El resultado central de la Fase D es la arquitectura tecnol\u00f3gica candidata. Los arquitectos tecnol\u00f3gicos trabajan con los dem\u00e1s arquitectos de dominio. Se espera intercambiar expectativas y limitaciones. Todo desarrollo de arquitectura requiere encontrar la mejor soluci\u00f3n para la empresa. La mejor soluci\u00f3n comprende las limitaciones y funciona en todos los dominios.<\/p>\n El objetivo del TOGAF ADM es explorar posibles cambios. Los cambios se equilibran en t\u00e9rminos de trabajo, valor y riesgo<\/a>. Cambios seleccionados o descartados. El conjunto de cambios crea la arquitectura de destino y la hoja de ruta de la arquitectura.<\/p>\n Los arquitectos tecnol\u00f3gicos trabajan con infraestructura. Esta es la parte m\u00e1s dif\u00edcil de cambiar en una organizaci\u00f3n. Los arquitectos tecnol\u00f3gicos deben evaluar cada cambio potencial y estar atentos a cualquier salida. La salida m\u00e1s econ\u00f3mica se da durante el desarrollo de la arquitectura. Detengan pronto las malas ideas. Eliminarlas ahorra dinero y permite un cambio exitoso. La necesidad de planificar con mayor anticipaci\u00f3n la infraestructura requiere que los arquitectos tecnol\u00f3gicos limiten a los dise\u00f1adores e implementadores de infraestructura.<\/p>\n \u2018'\u2018El negocio<\/em>\u2018La empresa es as\u00ed. Siempre lo ha sido. Las empresas digitales modernas no pueden utilizar a personas trabajadoras para superar las limitaciones de las aplicaciones y la infraestructura. Estas limitaciones eliminan la agilidad empresarial y frenan las transformaciones digitales.<\/p>\n Dise\u00f1aron el TOGAF ADM considerando el reto de fragmentar el trabajo y la necesidad de trabajar en conjunto. Desafortunadamente, el diagrama TOGAF ADM cl\u00e1sico muestra el flujo de informaci\u00f3n necesaria. Por favor, no interprete el diagrama como una cascada.<\/p>\n Quien sugiera que la arquitectura empresarial se puede desarrollar secuencialmente se equivoca. Quien diga que hay que dise\u00f1ar la arquitectura de toda la empresa tambi\u00e9n se equivoca. La complejidad y la especializaci\u00f3n de habilidades requieren dominios. Su desarrollo comienza y avanza conjuntamente. Se debe seguir un enfoque \u00e1gil, con solo lo necesario para probar las restricciones en cascada. TOGAF lo denomina iteraci\u00f3n.<\/p>\n Decisiones arquitect\u00f3nicas<\/a> cruzar\u00e1 m\u00faltiples dominios de la arquitectura<\/a> requiere el uso alternativas de arquitectura<\/a>.<\/p>\n Arquitectura tecnol\u00f3gica<\/a> Es uno de los cuatro dominios fundamentales de la arquitectura empresarial. Una arquitectura tecnol\u00f3gica describe su portafolio completo de infraestructura y le indica cu\u00e1ndo adquirir infraestructura, cu\u00e1ndo usar PaaS y cu\u00e1ndo inventarla. Indica d\u00f3nde establecer l\u00edmites entre sistemas y c\u00f3mo abordar\u00e1 el ciclo de vida de su infraestructura.<\/p>\n Podemos garantizar que su arquitectura tecnol\u00f3gica actual no est\u00e1 alineada. Estamos seguros de que comenzar\u00e1 desde una posici\u00f3n donde la planificaci\u00f3n de la infraestructura no ten\u00eda una base s\u00f3lida. arquitectura de la aplicaci\u00f3n<\/a> o arquitectura empresarial.<\/p>\n Cuando tienes una arquitectura tecnol\u00f3gica, tienes el conjunto de servicios de infraestructura que requieren tus aplicaciones. Tienes un conjunto de directrices y restricciones<\/a> Para dise\u00f1ar y operar su infraestructura, usted cuenta con una hoja de ruta tecnol\u00f3gica que sus partes interesadas comprenden.<\/p>\n Para desarrollar la arquitectura tecnol\u00f3gica, sus servicios, directrices y limitaciones, el arquitecto tecnol\u00f3gico debe colaborar con sus colegas y las partes interesadas. Deben analizar c\u00f3mo las distintas opciones de infraestructura facilitan o dificultan las decisiones empresariales y de software. Deben determinar c\u00f3mo el conjunto de opciones posibilita y limita los objetivos de la organizaci\u00f3n. Es necesario descartar los cambios potenciales que aporten poco, requieran demasiado trabajo o presenten demasiada incertidumbre. Las buenas hojas de ruta de arquitectura incluyen los cambios necesarios y minimizan los riesgos.<\/p>\n La arquitectura tecnol\u00f3gica ayudar\u00e1 a responder las siguientes preguntas:<\/p>\n No vemos casi ninguna diferencia entre un buen PaaS o un buen Arquitectura de nube privada<\/a>, y una buena arquitectura tecnol\u00f3gica. Los productos de trabajo principales, una Modelo de sistema<\/a> y Modelo de servicio<\/a>, Son lo mismo. La diferencia radica en que, al usar PaaS o nube p\u00fablica, no es necesario preocuparse por la infraestructura subyacente.<\/p>\n Ir\u00f3nicamente, si ha estado desarrollando una buena arquitectura tecnol\u00f3gica desde TOGAF 8, habr\u00e1 proporcionado un conjunto claro de servicios de infraestructura. Habr\u00e1 especificado las interfaces y los est\u00e1ndares para dichos servicios. Sospechamos que su trabajo se puede transferir f\u00e1cilmente a un cat\u00e1logo de servicios PaaS de nube p\u00fablica.<\/p>\n TOGAF 8 exig\u00eda que los servicios tecnol\u00f3gicos abstrajeran la infraestructura detallada para permitir la portabilidad, gestionar las funcionalidades y habilitar los ciclos de vida de la infraestructura. Esta es la misma raz\u00f3n por la que todos los proveedores de PaaS de nube p\u00fablica hacen que sus clientes utilicen servicios. Si todos hubi\u00e9ramos implementado una buena arquitectura tecnol\u00f3gica, habr\u00edamos evitado el callej\u00f3n sin salida de las aplicaciones inm\u00f3viles, las funcionalidades no implementadas y la deuda t\u00e9cnica.<\/p>\n >>> Saltar a Los fundamentos de la arquitectura de la nube privada<\/a><\/p>\n El est\u00e1ndar TOGAF lo denomina Arquitectura Tecnol\u00f3gica. Nuestra pr\u00e1ctica de consultor\u00eda de arquitectura empresarial<\/a> Generalmente se utiliza infraestructura. Muchos otros requieren una arquitectura de TI. Los esfuerzos por desarrollar una definici\u00f3n universal clara fracasan sistem\u00e1ticamente. Nuestro firme consejo es centrarse en el prop\u00f3sito, m\u00e1s que en la definici\u00f3n.<\/p>\n La l\u00ednea divisoria entre los dominios de la arquitectura nos ayuda a integrar las habilidades y las conversaciones adecuadas. Pensar en este prop\u00f3sito nos permite centrarnos en el desarrollo de una arquitectura \u00fatil.<\/p>\n Pensar en la definici\u00f3n suele llevarte a una discusi\u00f3n sin sentido. \u00bfEs la aplicaci\u00f3n de chatbot con IA, IA o negocio? \u00bfEl correo electr\u00f3nico es una aplicaci\u00f3n o una infraestructura? \u00bfQu\u00e9 hay del reconocimiento facial para el control de acceso? Las posibilidades son infinitas.<\/p>\n Todos los dominios de la arquitectura empresarial se integran entre s\u00ed. Juntos, abarcan la arquitectura empresarial completa. Creamos un dominio para que un arquitecto especializado pueda aplicar t\u00e9cnicas y habilidades. Continuamente surgen nuevos dominios de arquitectura empresarial<\/a>. La mayor\u00eda se absorbe en un\u00a0dominio de la arquitectura empresarial cl\u00e1sica<\/a>\u00a0A medida que se vuelven comunes.<\/p>\n Nuestro consejo es que no te preocupes por lo que es correcto. En cambio, aseg\u00farate de entender lo que la otra persona quiere decir cuando habla. Siempre ten presente lo que tus interlocutores dan por sentado que quieres decir. Asume la responsabilidad de comprender y ajusta tu lenguaje.<\/p>\n Mucha gente asume que un arquitecto empresarial deber\u00eda centrarse en la infraestructura de TI. En varios proyectos de consultor\u00eda, hemos rebautizado a nuestros arquitectos empresariales para evitar este problema. La profesi\u00f3n de Arquitectura Empresarial es clara: la arquitectura de TI es un subconjunto de la arquitectura empresarial. La tecnolog\u00eda es un subconjunto de la arquitectura de TI.<\/p>\n Nos centramos en la interacci\u00f3n de todos los dominios de la arquitectura empresarial con los arquitectos. En muchos equipos, habr\u00e1 arquitectos de datos, arquitectos de aplicaciones, arquitectos de seguridad, arquitectos de negocio y arquitectos de tecnolog\u00eda. Se les puede llamar por su funci\u00f3n o por el t\u00edtulo general de arquitecto empresarial.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tDescargue la Gu\u00eda del Gobernador de Arquitectura Empresarial\n\t\t\t<\/a>\n\t\t\t\t Un resultado central de la Fase D es la arquitectura tecnol\u00f3gica. Esta forma parte de la arquitectura empresarial completa. Por lo tanto, de forma indirecta, existen cinco resultados \u00fatiles para la Fase D de TOGAF ADM:<\/p>\n Tenga siempre presente que busca mejorar la organizaci\u00f3n. La mejora requiere cambio. El cambio genera valor. El valor y el costo del cambio se pueden medir. La incertidumbre siempre disminuye el valor potencial. Cuando el \u00e9xito es incierto, el costo aumenta exponencialmente. Muy poca incertidumbre eliminar\u00e1 lo previsto.<\/p>\n La mayor\u00eda de las veces, cuando hablamos de la arquitectura tecnol\u00f3gica, nos referimos a los modelos y las especificaciones de la arquitectura. Diferentes modelos explicar\u00e1n distintos aspectos de la infraestructura completa. Juntos, los modelos y los cambios necesarios conforman la arquitectura tecnol\u00f3gica.<\/p>\n Al analizar los distintos tipos de modelos, tenga en cuenta que un mismo t\u00e9rmino puede tener m\u00faltiples usos. Es fundamental que no se preocupe demasiado por la etiqueta del modelo. Lo que usted denomina modelo de descomposici\u00f3n funcional, otra persona lo llamar\u00e1 servicio. Nuestra consultor\u00eda en arquitectura empresarial se centra en el prop\u00f3sito, no en c\u00f3mo se denomina el modelo. Puede llamarlo descomposici\u00f3n funcional, modelo de sistema o modelo de servicio. Lo que nos interesa es el prop\u00f3sito del modelo: \u00bfqu\u00e9 intenta aprender y explica eficazmente su modelo c\u00f3mo funciona ese aspecto del trabajo real?<\/p>\n Todas las fases de TOGAF ADM incluyen la informaci\u00f3n y la actividad necesarias para desarrollar el conocimiento necesario. El resultado de la fase D es el desarrollo de una arquitectura tecnol\u00f3gica candidata.<\/p>\nTOGAF ADM Fase D \u2013 Desarrollo de la arquitectura tecnol\u00f3gica<\/h2>\n
\n
\n
\n
Descripci\u00f3n general de TOGAF ADM<\/a><\/h2>\n
\u00bfQu\u00e9 es TOGAF Fase D?<\/h2>\n
\u00bfCu\u00e1l es el objetivo de la fase D del TOGAF ADM?<\/h3>\n
\n
Interacci\u00f3n con TOGAF Fase B<\/a>, Fase C<\/a>, y Fase E<\/a><\/h3>\n
\u00bfQu\u00e9 es la arquitectura tecnol\u00f3gica?<\/h2>\n
\u00bfPara qu\u00e9 se utiliza una arquitectura tecnol\u00f3gica?<\/h3>\n
\n
Arquitectura tecnol\u00f3gica vs. arquitectura en la nube<\/h2>\n
\u00bfLo llamamos Arquitectura Tecnol\u00f3gica, Arquitectura de Infraestructura o Arquitectura de TI?<\/h2>\n
\u00bfCu\u00e1l es la diferencia entre un arquitecto empresarial y un arquitecto de TI?<\/a><\/h2>\n
![\"Arquitectura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_321372600.jpeg\" "\\"Arquitectura")
\n\tEntregables de la arquitectura tecnol\u00f3gica de la fase D de TOGAF ADM<\/h2>\n
\n
Finalizaci\u00f3n de la arquitectura tecnol\u00f3gica de la fase D<\/h2>\n
![\"Arquitectura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_300597970.jpeg\" "\\"Arquitectura")
\n\t\n