Pregunta

Actualmente estoy encargado de la creación de un documentado, guía Arquitectura consistente para el desarrollo de software. Tenemos un montón de gente inteligente haciendo las cosas bien, pero no de manera consistente y repetible.

Estamos utilizando Guía de Arquitectura de aplicaciones de Microsoft 2.0 como punto de partida. Por lo tanto, dar con una arquitectura de aplicaciones es bastante (no voy a decir Fácil) sencillo. Posiblemente porque tengo un par de años de experiencia como desarrollador, así que tener una muy buena comprensión de este reino y también hay un montón de ejemplos y orientación.

Desde nuestra organización tiene un par de aplicaciones que forman 1 o más sistemas que luego instalar "en" clientes ... hemos pensado que tendría sentido para crear una arquitectura de sistema y una Arquitectura Empresarial también. Y aquí es donde empiezan los problemas.

No hay una orientación coherente por ahí. Si busca "Arquitectura del sistema Ejemplos", el material que se obtiene es tan diferente que me estoy preguntando si hay una manera "estándar" para hacer esto.

Desde mi (limitada - con claridad) la comprensión de todo esto, la Arquitectura del Sistema es una abstracción de 1 o más arquitecturas de aplicaciones que muestran cómo funcionan juntos para formar un sistema. Por otra parte, una Arquitectura Empresarial es una abstracción adicional que muestra cómo el sistema (s) encaja en una empresa de organizaciones y cómo interactúa con los procesos de negocio, estrategia de TI y cómo se Integrats en otros sistemas de la empresa.

  • ¿Tengo que totalmente equivocado?
  • ¿Existen normas por ahí (y dónde los puedo encontrar)?
  • ¿Debería haber normas, o sería un "buen" Arquitectura del sistema simplemente ser cualquier documento en cualquier formato que es clara y fácilmente comprensible y útil a sus lectores?
  • ¿Qué los arquitectos experimentados pensar en que el enfoque sin embargo?

No quiero enumerar simplemente un conjunto de patrones relacionados con SOA que puede ser útil ... Me gustaría que sea un poco más enfocado a lo que hacemos, que es las soluciones financieras de construcción en el Servicio Orientado Arquitectura.

Actualización: ¿Qué hay de TOGAF (9) . ¿Alguien tiene experiencia con ella en absoluto y es que vale la pena el esfuerzo de tratar de entender en detalle.

¿Fue útil?

Solución

presenté la pregunta hace un par de días, sino por la continua investigación y después de leer littlegeek 's Reponse, me creo que he encontrado un libro blanco interesante que me pareció muy interesante e informativa.

Leer: Una comparación de las metodologías de la tapa cuatro Empresa-Arquitectura Por: Roger Sessions

un fragmento ...

- - - - - - - - - - - 8 <- - - - - - - - - - - -

Muchas metodologías empresariales y arquitectura han ido y venido en los últimos 20 años. En este punto, tal vez el 90 por ciento del campo utilice uno de estos cuatro métodos:

  • El Marco Zachman para Enterprise Architectures-Aunque auto descrito como un marco, es en realidad define con más precisión como una taxonomía
  • El Marco arquitectónico Open Group (TOGAF), aunque llama un marco, que realmente está definido con mayor precisión como un proceso
  • La Arquitectura-Can empresarial federal considerarse ya sea implementado una arquitectura empresarial o una metodología prescriptiva para la creación de una arquitectura empresarial
  • El Gartner Metodología-puede ser mejor descrito como un estudio de arquitectura de la empresa

Este documento describe estos cuatro enfoques de la arquitectura de la empresa. Lo hace en el contexto de una compañía ficticia que se enfrenta a algunos problemas de operación muy de no ficción. Estos problemas incluyen:

  • sistemas informáticos que se han vuelto inmanejable complejo y cada vez más costoso de mantener.
  • sistemas
  • TI que están obstaculizando la capacidad de la organización para responder a los actuales y futuros, las condiciones del mercado de una manera oportuna y rentable.
  • información de misión crítica que es constantemente fuera de fecha y / o simplemente errónea.
  • Una cultura de la desconfianza entre los lados de negocios y tecnología de la organización.

- - - - - - - - - - - 8 <- - - - - - - - - - - -

El Libro Blanco me ayudó de varias maneras.

  1. Me dio una buena introducción y la historia de la arquitectura (arquitectura de la empresa específicamente)
  2. Se me presentó a lo que el autor sugiere es los 4 arquitecturas principales de la empresa disponibles.
  3. Y luego continúa para comparar de una manera lógica y sencilla, con buenos ejemplos que pude identificar.

No puedo decir que todas mis preguntas han sido contestadas y ahora estoy listo para morir :-), pero mucho ha vuelto más clara y por lo tanto pensé que alguien más por ahí también puede resultar útil.

Me gustaría volver a valorar sus comentarios, sugerencias y preguntas adicionales que pueda tener sobre este tema.

Otros consejos

Usted parece tener una muy buena comprensión de la situación y la comprensión del ámbito de artchitecture.

"Sistemas" Architecure es poco más difícil de definir - se puede buscar "solución" o "TI", pero parece que su buscar cómo su arquitectura de software se relaciona con el mundo de los servidores físicos, con un poco de trabajo en red tirado

  

"Tenemos un montón de gente inteligente haciendo las cosas bien, pero no de manera consistente y repetible."

A continuación, siendo TOGAF 8 Certifed mí mismo, - yo diría que TOGAF trae una sensación de "metodología" a diferentes aspectos de la definición de la arquitectura y una manera de traer un especialista variours grupos técnicos en conjunto y la fijación que firmemente a los objetivos de negocio. TOGAF también ayuda a entender la necesidad de un gobierno de Arquitectura y firmemente trae la idea de cambio (de todas las partes técnica, datos, sistemas, software y de negocios) en el proceso.

La

  1. Método de Desarrollo de Arquitectura
  2. Técnica Modelo de referencia
  3. Normas de base de información
  4. Empresa Continuo

Todo ayudar a recopilar información sobre el esfuerzo Archtecture y proporcionar un enfoque consistente para el desarrollo y EA.

También ayuda a los clientes a entender lo que está haciendo y cómo se puede presentar TOAGF como el método de mostrar cómo encaja.

PS -. Me único estado TOGAF como de utilidad do la cita que he sacado como TOAGF abordaría esto para usted

Hay otras framworks arquitecto por ahí.

No tengo ninguna experiencia práctica en la EA, pero en realidad estoy a bordo con él. Entre los 4 mejores metodologías de EA, me he encontrado con los tres primeros. Sólo que no sé el que Gartner, tal vez debido a la falta de disponibilidad de sus documentos. En mi humilde opinión, cuando estamos hablando de EA, en realidad estamos hablando de alinear el negocio con la tecnología. Así que todas las metodologías de EA debe orientarse negocio. Si no es así, no es en absoluto EA.

Creo TOGAF es bastante útil y comprensible. Sí, es un proceso que evoluciona la arquitectura de referencia actual en la arquitectura objetivo. principios de la arquitectura actúan como la orientación de alto nivel de desarrollo de EA. Los componentes básicos de la arquitectura TOGAF son negocio, arquitectura de la información, y la arquitectura de la tecnología. Y cada uno de ellos puede tener sus propios patrones de arquitectura. NIH ha puesto en marcha un EA con FEAF. Es un buen ejemplo de la aplicación de EA. Creo que es bastante similar al enfoque de TOGAF, al menos desde el punto de vista de los resultados finales.

El único intento razonable crear un marco de modelado para EA hasta ahora ha sido ArchiMate: https: // en.wikipedia.org/wiki/ArchiMate

ArchiMate es un estándar técnico de The Open Group y se basa en los conceptos de la norma IEEE 1471.

Además, vea el siguiente enlace sobre artefactos de EA y la trazabilidad entre ellos:

https://www.ontario.ca/document/go-its-56-ops-enterprise-architecture-principles-and-artefacts-appendix-ontario-public-service

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top