martes, 6 de noviembre de 2007

SOA para financieros

Siguiendo con el serial, esta vez veamos SOA desde el punto de vista de la gente de finanzas.

¿Se puede medir el retorno de inversión de SOA?

Como hemos visto, uno de los aspectos más controvertidos en el debate de SOA es la dificultad de medir el retorno financiero de iniciar un cambio hacia SOA. ¿Por qué es tan difícil calcular el retorno sobre la inversión ROI en SOA? La respuesta, es sencilla: porque existen demasiados elementos, que varían entre industrias, empresas para proporcionar un conjunto de modelos o fórmulas capaz de adaptarse a cada situación.
Otro aspecto muy importante a tener en cuenta para determinar el posible valor de SOA, son el origen, objetivo y alcance de la implementación, es decir ¿es una oportunidad provocada por la obsolescencia de herramientas o códigos?, ¿es una necesidad para acercarse al mercado en un entorno muy cambiante?, ¿es una mezcla de múltiples factores?.
Por todo esto, crear una regla que calcule de forma simple el ROI de SOA no puede proporcionar un resultado que se acerque a la realidad. Sin embargo, si es posible evaluar de una forma realista las implicaciones financieras de un desarrollo SOA. Para ello, es necesario contestar primero a una serie de preguntas:
  • Número de procesos del negocio que pueden verse afectados
  • Qué lógica del negocio puede llegar a separarse de la lógica tecnológica
  • Valor de negocio existente en las aplicaciones que corren en la organización en la actualidad
  • El ámbito de aplicaciones de negocio, que pueden llegar a ser integradas en el desarrollo
  • Cantidad y tipología de datos, que puede llegar a ser armonizada
  • El valor proporcionado por la agilidad de cambiar procesos de negocio y los procesos de negocio asociados para aprovechar oportunidades estratégicas de mercado
  • Ahorro en futuros costes en desarrollos de cambios en software más sencillos
  • Costes relacionados con formación
Descubriendo el valor de SOA a partir de pequeños proyectos
Como hemos visto en el anterior apartado, desesctructurar y subdividir todas las dudas que surgen en torno a SOA, parece ser una vía para comprender, no solo que es SOA en si mismo, si no también el valor que tiene. Subdividir todas estas preguntas, en piezas manejables y entendibles, es el paso crítico Identificar las áreas de valor transformándolas en servicios manejables, requiere tantos ejercicios de análisis como áreas y servicios.

De la misma forma los criterios y herramientas de evaluación de retorno, deben ser aplicados dentro de una única organización por los responsables de negocio e IT a cada proyecto individual, área de negocio o conjuntos de procesos que se modifiquen.
La subdivisión en pequeños proyectos SOA puede mostrar de forma inmediata un ROI, permitiendo evaluar el conjunto financieramente a partir de la agregación de estos proyectos.

La importancia del buen gobierno SOA
Un planteamiento débil en cuanto al buen gobierno SOA, puede limitar realmente el valor posible de retorno de SOA. ¿Qué entendemos por buen gobierno SOA? El gobierno de SOA, que es una combinación del gobierno de la infraestructura y del gobierno de las TI, controla el ciclo de vida de los servicios de negocio referentes a SOA. Incluye desde la identificación del portafolio de servicios existentes hasta la identificación de proyectos que distribuirán y utilizarán estos servicios, pasando por el diseño y la implementación, así como la producción y la creación de informes de SOA.
El gobierno de SOA está vinculado al ciclo general de distribución de soluciones. Garantiza que el modelado, la creación y la distribución de servicios, así como el control de los acuerdos de nivel de servicio creen y mantengan el éxito una SOA. El gobierno de SOA es fundamental para garantizar que su cartera de servicios de negocio esté alineado con las estrategias y los procesos de negocio.
Alcanzar un bueno gobierno, no es condición para empezar con SOA, pero si es necesario para alcanzar madurez y poder explotar y obtener todos los beneficios de orientarse a servicios.
Podemos organizar el gobierno de SOA, en las siguientes áreas:
  1. Portafolio de productos
  2. Infraestructura IT
  3. Gestión de proyectos a nivel SOA
  4. Gestión de Operaciones y Servicios
El grado de madurez en el que la organización se encuentre en estas áreas y su alineamiento con la estrategia de negocio, será una métrica que aumente o disminuya el retorno sobre una iniciativa SOA a largo plazo.

¿Cómo podemos estructurar un método para calcular el ROI en SOA?
Forrester Group ha organizado en base a los cuatro áreas anteriores, un cuestionario de auto evaluación del retorno de proyectos SOA. Construyendo a partir de las cuatro áreas definidas en el apartado anterior relacionadas con el buen gobierno, se definen las siguientes actividades, mesurables cuantitativa y cualitativamente.
  1. Productividad del Usuario
  2. Eficiencia en los procesos
  3. Gobierno SOA
  4. Implementación SOA
  5. Innovación de negocio
El planteamiento en cada punto, será describir el entorno natural de cada una de las actividades, definir, puntos concretos de mejora dentro de la actividad y por último, formularnos preguntas cuya respuesta sea cuantificable, que será la base de nuestra medición. Estos puntos concretos, si bien de forma muy distinta, asocian costes de una u otra forma en todas las organizaciones para permitir su ejecución, pero también, su actividad, repercute en beneficios. Cuanto más se profundice en el detalle de estos puntos, más alcance, tendrá la evaluación del retorno.
Una vez evaluemos cada uno de esos puntos, tendremos el cualitativo del retorno de SOA, es decir, una medida de cuanto nos puede ayudar SOA en cada uno de esos ámbitos.
Por último, señalar, y en relación a lo expuesto anteriormente, hacer notar, que la implementación de un criterio de evaluación como el expuesto a continuación, es tanto más sencilla, cuanto más concretas puedan ser las respuestas, hecho, que encaja perfectamente con la idea de evaluar “las partes manejables de SOA”.

________________
Fuentes:

http://www.softwareag.com/es/default.asp

http://www.idg.es

lunes, 29 de octubre de 2007

SOA para CIOs

Continuando con la publicación de nuestro trabajo, esta semana os dejamos el punto de vista SOA que podría tener un Director General.

¿En que me va a ayudar SOA?

SOA es en esencia un concepto sencillo: consiste en estandarizar funciones o servicios de software, para que otro software pueda compartir información con ellos, dentro y fuera de la empresa. “Si miras a tu empresa, probablemente tendrás sistemas duplicados con mucha información copiada entre ellos. Por ejemplo, hay mucha inversión hoy en sistemas CRM, sin embargo las empresas no sacan tanto provecho de ellos. Con SOA podrás alcanzar un mejor retorno de la inversión y reutilizar piezas a nivel macro” dice Dave Mendlen, Director de Web Services Marketing en Microsoft.
SOA es la más actual en una lista de muchas estrategias orientadas a traer a la luz ese detalle que se estaba perdiendo. SOA promete a empresas un portafolio de servicios que pueden ser mezclados de forma rápida y encajados de forma efectiva para crear procesos automatizados, y por lo tanto reduciendo costes de aplicativos de manera significativa.
De acuerdo con una encuesta de Forrester Research, el 46% de las grandes corporaciones que usan SOA (y 27% de las medianas y pequeñas corporaciones) dicen usar SOA para “alcanzar la transformación estratégica del negocio”. Otras encuestas muestran que la expectativa más popular es generar una “ventaja competitiva” y “desarrollar nuevos productos y capacidades”. En una encuesta de CIO/Computerworld se puede observar que el 77% de los entrevistados dicen que SOA aporta más flexibilidad del negocio.
Hasta ahora las empresas que tuvieron más éxito con SOA son las que tuvieron éxito en implantaciones previas de tecnología: grandes empresas con grandes presupuestos destinados a TI (normalmente telcom y instituciones financieras). Estas suelen ser empresas con líderes sofisticados y que apoyan inversiones en tecnología.

¿Que ocurre con mis proveedores de TI?
En el nuevo mundo de SOA, los grandes proveedores están de forma repentina interesados en que sus aplicativos funcionen bien con los demás.
Antes, el miedo que los CIOs tenían de enfrentarse a demasiados problemas de integración le daba una ventaja a un proveedor cuando la empresa quería añadir un aplicativo a su lista. Era más fácil coger un aplicativo de su actual proveedor predominante que correr el riesgo de ir con uno nuevo, por más que ofreciera más funcionalidades, pues los desastres de integración se habían hecho muy conocidos en la industria.
SOA hace una afirmación radical: la tecnología es construida de acuerdo con los servicios especificados por el negocio, no por los procesos internos de un aplicativo de un proveedor. El proveedor ya no importa, lo que importa es la conectividad entre los aplicativos. Como resultado, algunas grandes corporaciones como SAP y Oracle han hecho con que su estrategia sea basada más en la capacidad de integración de sus programas con otros.

¿Debo adoptar SOA en mi empresa? ¿Cuánto cuesta?
La parte difícil de la decisión de implementar o no SOA viene del hecho que es muy difícil medir SOA. “No hay ninguna métrica que diga que si soy mas ágil, reduciré un X% de costes. La dificultad mas grande de SOA es reflejar en una hoja de cálculo su ROI”, dice Daniel Scholler, vicepresidente de investigación en Gartner.
¿Y como se haría un caso de negocio para SOA? ¿Se puede? Es una tarea difícil, pero tal y como afirma Randy Heffner, analista de Forrester Research, hay que hacerla “… no hables con el negocio sobre SOA porque a ellos no les importa. Al negocio solo le interesa escuchar hablar de SOA si reduce costes de aplicativos y los hace funcionar más rápido.”.
¿Y cuando es una buena idea usar SOA? Cuando existe complejidad. Pequeñas empresas consolidadas en una sola infraestructura y las cuales no tienen requerimientos complejos de integración de sistemas no son candidatos para SOA. Las empresas grandes con proveedores responsables de más de un 60% de su infraestructura también se lo tienen que pensar con cuidado antes de ir hacia SOA.
¿Cuanto podría costar? Crear un servicio requiere mas planificación y diseño que los desarrollos de aplicativos convencionales. Heffner (de Forrester) estima que el trabajo adicional necesario para crear desarrollos orientados a servicios pueden costar de 30% a 100% más caros en la fase de diseño, la cual normalmente equivale a 10% del coste total de un proyecto de aplicativos.
¿Y como SOA afectaría mi equipo de TI? Si tienes una empresa con estructura descentralizada, prepárate para las dificultades. SOA no solamente va hacia centralización además la requiere.
¿Cuales son las principales razones para implementar SOA? En primer lugar la reutilización de muchos de los activos en los cuales estas invirtiendo dinero para desarrollar. En segundo lugar, tiene un “time to market” mas rápido, ya que puedes combinar elementos de forma más rápida y puedes reaccionar más rápido a los cambios del entornos. Eso significa que la capacidad de medir el tiempo de creación de un nuevo producto ya no tarda meses, sino en días o semanas, por lo tanto generar ahorros. Eso quizás significa también que no se debería tratar de reinventar la arquitectura tecnológica si el entorno o industria no lo requiere, o no es lo suficientemente dinámico.

___________________

Mas información: www.cio.com

lunes, 22 de octubre de 2007

SOA para todos

El primer paso antes de pasar a explicar como SOA puede ser entendido y afectar al organigrama de la empresa, es conveniente empezar por definir ciertos conceptos básicos.

¿Qué es SOA?
Existen multitud de definiciones, prácticamente cada fabricante de software, autoridad académica o publicación especializada tiene la suya. Proponemos la siguiente definición integradora:
Arquitectura orientada a servicios, SOA, es una propuesta de arquitectura (o estructura base) para la comunicación entre servicios (o unidades de trabajo) que permite el diseño y construcción de soluciones de TI donde los procesos de negocio se organizan y colaboran de manera más eficiente y eficaz.
Como se puede observar en el nombre y la definición están incluidos los conceptos de arquitectura y servicio. Entendemos por arquitectura la estructura de un sistema, sus componentes, propiedades y relaciones entre los mismos. Aunque aplicado de manera intuitiva, se trata de un concepto relativamente moderno. Algunos ejemplos de arquitecturas son: cliente servidor, tres capas, punto a punto, computación distribuida, etc. Por otro lado, un servicio es una representación lógica de una actividad del negocio repetible (comprobar crédito, validar reserva de billete, etc.) que acepta una serie de llamadas y devuelve unos resultados mediante unos protocolos previamente definidos. Tanto para la arquitectura como para los servicios, la tecnología concreta que permite su realización queda fuera de la definición.

¿Por qué SOA?
Conviene citar la excelente respuesta a esta pregunta que da IBM [1]:

"Lo que hace la arquitectura orientada a servicios es crear un lenguaje para que los negocios y la IT hablen entre si. Y ese proceso es un proceso de negocios. Por lo tanto el analista de negocios observa el proceso, lo simula y entonces, uniendo las diferencias - a través del software o de la IT - obtiene el código que luego convierte en un idioma que la persona de IT pueda comprender.
Esto codifica el rol y el vínculo entre los negocios y la IT. Eleva ambos roles, en vez de realzar uno o minimizar otro. De esta manera los pone al mismo nivel y le da la posibilidad de comunicarse con el otro. Lo protege del síndrome de reescribir, revisar, rehacer todo."

Sandy Carter. Vice President, Strategy for Channels and Marketing IBM
Normalmente los objetivos a corto plazo de TI y de negocio son diferentes [2]. Negocio normalmente quiere que TI sea más ágil sin tener que pagar más, y prefiere o necesita desarrollos rápidos para poder ofrecerlos a los clientes. TI necesita recursos para mantener aplicaciones heredadas en perfecto estado y desarrollar nuevas soluciones, y prefiere construir infraestructura que soluciones puntuales. SOA trata de conciliar las dos visiones.

¿Qué no es SOA?
Quizás una buena manera de comprender que es SOA es revisar que no es. SOA no es un producto, una tecnología especifica, un lenguaje de programación, un sistema operativo, una herramienta, un estándar o un paquete de software que se pueda comprar a un fabricante de TI.
SOA es en definitiva una manera de pensar, una manera de organizar la fusión de distintas tecnologías y estándares para lograr el objetivo de reducir la distancia entre negocio y TI.

Un ejemplo
En este ejemplo (utilizado por accenture, SAP [3] y algunas publicaciones) se puede observar un paralelismo entre la industria del automóvil y la de las soluciones software. Si observamos la evolución del diseño y construcción de automóviles a lo largo del tiempo podemos diferenciar tres tipos de estrategias.

Al principio los modelos eran diseñados uno a uno, y tenían procedimientos de fabricación exclusivos. Los productos estaban altamente diferenciados a cambio de costes elevados de diseño y fabricación. Esta fase puede asimilarse a la de producción de software a medida.

El siguiente paso en la industria fue el que los fabricantes acordaron vender el mismo coche bajo dos nombres diferentes. Las piezas eran comunes y estaban dirigidas a compradores similares. El compartir piezas permitió la reducción de costes, pero a costa de la diferenciación del producto. Este quizás es el momento actual para el software, en la que por ejemplo los ERP dan soluciones similares a todos los usuarios y, aunque permiten cierta personalización, el producto final es básicamente el mismo.

La industria del automóvil, más antigua que la del software, se encuentra en nuestros días aún más avanzada. En el modelo actual de plataformas los fabricantes son capaces de ofertar coches muy diferenciados, pero el interior (sistema de frenos, electrónica, etc. son los mismos). Si los componentes internos son de una cierta calidad y están bien ajustados, la calidad del producto final también se ajustará al estándar. Para SOA estos componentes estándar son los servicios, y se puede cambiar un servicio tal y como Volkswagen cambia el alternador usado en el Audi A3 el VW Passat. El concepto de plataforma ha proporcionado a los fabricantes de automóviles la capacidad de fabricar productos muy diferenciados, más rápidamente, a un coste reducido y manteniendo la calidad deseada. La propuesta de valor de SOA es análoga.

El puzzle SOA
Lo que trata de conectar la infraestructura basada en SOA que estamos proponiendo es una serie de usuarios (internos como ventas, o externos como clientes, B2B, socios, etc.) que acceden a los sistemas de información a través de una nueva capa que permite localizar y orquestar los servicios ofrecidos.

Por supuesto detrás de esta simplificación existe un océano de definiciones, conceptos, estrategias y tecnologías que se tratarán de ir ampliando en los siguientes puntos.

_________________________________

[1] IBM – Arquitectura Orientada a Servicios Simplificada

[2] Yogish Pai SOA Blueprint - Why SOA?

[3] SAP INFO - Cutting the Gordian Knot

SOA para directivos

Con este artículo se inicia la publicación del trabajo final que hemos realizado. Se irá publicando a lo largo de 8 entregas en los que se intentará aproximar SOA a cada una de las direcciones que forman una empresa.

El concepto de SOA en sí mismo es suficiente para llenar decenas de manuales. Este documento, por tanto, pretende ser solo una guía introductoria a la materia, intentando acercar este concepto a cada uno de los tipos de directivos que componen la empresa, sean o no miembros del área tecnológica.

Esperamos que lo encontreis útil.

_vitaC_

jueves, 4 de octubre de 2007

Feed SOA

He estado intentando localizar un feed que de noticias especificas de SOA, la verdad, no hay mucho donde escoger. He encontrado este:

http://feeds.feedburner.com/dev2devsoa

Un saludo.

domingo, 23 de septiembre de 2007

Experimentando con Creative Commons

El trabajo nos está quedando chulisimo ¡Enhorabuena a todos por vuestro esfuerzo! Quizás cuando esté terminado podemos colgarlo aquí por capitulos. He añadido a la página una entrada con una licencia de Creative Commons, ¿alguno os sabeis como va esto?

Nosotros también citamos las fuentes, supongo que de alguna manera eso nos autoriza a incluir los contenidos ya que se hace sin animo de lucro y es información pública disponible en Internet.

Supongo que basta con incluirla. Está abajo del todo, en cada página.

viernes, 14 de septiembre de 2007

saluditos desde clase

una breve nota informal para dar las gracias a google por sus múltiples herramientas y servicios gratuitos.