2009-11-23 7 views
6

Frecuentemente escucho una arquitectura orientada a servicios (SOA) como una palabra de moda entre clientes no técnicos o gerentes de programas con poca preocupación o comprensión de lo que realmente implica (ejemplo: "¿Puedo comprar? una SOA? "). También hay mucha desinformación sobre SOA (ejemplo: "Solo las aplicaciones web pueden usar SOA") y una falta general de comprensión de sus capacidades (ejemplo: "SOA puede hacer que todos tus datos funcionen juntos").Ayudando a los gerentes y clientes a entender SOA

¿Cuáles son algunos hechos clave que usted, como alguien que comprende el aspecto técnico de SOA, utiliza para educar a los administradores de programas sobre el uso apropiado y la comprensión de SOA? ¿Cuál es la mejor manera de dejar las cosas claras con gente no técnica?

+1

Estoy anticipando comentarios de "conviértalo en un wiki de la comunidad" ... Argumentaría que la mejor (es decir, la más completa/bien pensada) respuesta debería obtener la mayor cantidad de votos y ser aceptada como respuesta –

Respuesta

4

Para personas no técnicas, utilizaría el siguiente concepto. Todo el mundo profesional está orientado al servicio.

  • En lugar de hornear una galleta por usted mismo, vaya al panadero.
  • En lugar de intentar curarse a usted mismo, va al médico.
  • En lugar de escribir un programa, usted pídale a un programador que haga esto para usted.

Esto implica dos ventajas principales:

  • Cada uno hace su trabajo mejor que si que todos estábamos tratando de resolver todos nuestros tareas por separado.
  • Hay camino, que permite a los no profesionales para comunicarse con aquellos, que va a resolver nuestra tarea (en mundo real tal manera es dinero y contratos comerciales)

En el mundo del software, la arquitectura se implementa mediante la definición de servicios especializados (aplicaciones) que están dedicados a realizar tareas específicas y mediante la definición de protocolos, que resuelven el problema de las comunicaciones entre dichas aplicaciones. Cuando se implementa este tipo de arquitectura, se obtiene algunos beneficios, que pueden ser también asignados al mundo real:

  • Si el médico no está disponible, no se puede puede curar, pero al menos se puede obtener una cookie de la ¡panadería! En software, esto significa que un servicio fallido no rompe todo el sistema.

  • Por lo general, los médicos y los panaderos no comparten la misma habitación y esto les permite operar mejor. Al igual que en el software, puede colocar cada servicio en su propio hardware.

Para el mundo del software esto significa, mejor disponibilidad, facilidad de mantenimiento, reutilización y costos reducidos. ¡Buena suerte!

0

Quizás tenga algunas aplicaciones en su compañía para usar como demostración.

Trate de mostrarles el panorama general con una gran cantidad de servicios poco dependientes con algunas necesidades/características comunes creadas por varios equipos, y retirando aquellas características incorporadas pero de uso común y utilizándolas como proveedores de servicios.

La otra cosa que me vino a la mente es mostrarles los diversos conectores que los servicios pueden usar para comunicarse (tal vez hay algunas aplicaciones heredadas de screencraping muy antiguas). Además, el concepto del bus de mensajes con normalización y manejo de transacciones necesita ser aclarado. En mi opinión, las personas no técnicas deberían ver todo este concepto de SOA como servicios vagamente combinados que hablan entre sí con cualquier tipo de mensaje, donde los servicios son escritos/administrados/gobernados por diferentes equipos (por lo que las declaraciones formales de servicio y los SLA pueden ser útiles) .

Trate de evitar mencionar vendedores, si es posible. O mencione muchos proveedores y tecnologías para cada parte para mostrarles las distintas opciones.

1

"SOA es como contratar nuevos empleados cuando el trabajo es demasiado grande para el equipo actual". Cada parte del sistema completo es análoga a un empleado. Los gerentes entienden a los empleados;)

Cuestiones relacionadas