Andrés Hevia
Arquitecto SOA, PMP
andres.hevia@gmail.com
Creo que mucho antes de escuchar por primera vez la palabra geek ya me consideraba uno de ellos. A los 14 años me compraron mi primer ordenador (un inolvidable AMSTRAD PC 1512), pero incluso ya antes de esto (mediados de los 80) me llamaba todo lo que oliera a electrónica e informática.
A los 14 años, aprendí GW-BASIC. El primer programa que hice era capaz de calcular la edad que tendrías en el año 2000 únicamente introduciendo tu año de nacimiento
.
Siempre lo tuve claro y me matriculé en la escuela de informática de Oviedo. Para estudiar la carrera superior dí un pequeño salto y me planté en Zaragoza.
Desde el año 1999 trabajo en proyectos en grandes bancos y empresas de seguros. Siempre en el mundo java y JEE (gracias Sun Microsystems ).
Desde hace bastantes años ya, trabajo como Arquitecto SOA intentando conciliar las necesidades del negocio, de los equipos de desarrollo y sobre todo intentando hacer simple lo complejo.

Muy buen blog…. y el comentario de hacer simple lo complejo excelente.. !!! Saludos y felicitaciones por el blog
Muchas gracias. No olvides lo de “intentando” hacer simple lo complejo
Te felicito muy bueno tu blog y ha sido de mucha ayuda en la resolucion de algunas dudas
gracias
Muchas gracias. Me alegro que haya servido de ayuda. Por cierto, que si tienes temas o inquietudes acerca de algo que no se haya tratado en el blog, o que no se haya tratado insuficientemente, espero tus comentarios.
Saludos
Saludos como puedo enviarle una pregunta por correo sobre un tema de tesis sobre SOA este es muy extenso me gustaria preguntarle en que pudiera enfocarme gracias por su blog es de gran ayuda.
Muchas gracias, mi correo es andres.hevia@gmail.com.
Hola Andrés… Lo primero felicitarte por este blog.. es de gran ayuda… por otro lado comentarte una duda que me surge a la hora de implementar SOA… Veo que esta arquitectura es planteable en servicios orientados a cliente…., pero no veo como implementar este tipo de arquitectura en servicios Inter-host… ¿En una aplicación que integra ambos tipos de servicios cabe implementar SOA para dotar de esta arquitectura en ciertos servicios, o por el contrario es conveniente replantear una reingeniera de cada servicio y ver su posible granularidad?
En cuanto a la pregunta que planteas, te contaré como lo veo yo (de manera resumida claro).
En Seguros por ejemplo hay tres grandes aplicaciones (considerando aplicación como una gran agrupación de funcionalidades): Emisión, Recibos y Siniestros.
Si queremos hacer un nuevo servicio que no se sale de la misma aplicación.Por ejemplo, “generar recibo creará un recibo para el tomador del seguro y después se pasará al cobro del banco”. Esto se debería hacer en el ámbito de la misma aplicación por lo que no haría falta una lógica de integración (el tipo de logica que tendría que ir en SOA).
Por otra parte un nuevo servicio que sea “hacer la emisión de la póliza, generando el recibo correspondiente”. Como estamos combinando la lógica de dos aplicaciones, esta integración sí que estará en SOA.
Resumiendo, ponemos en SOA la lógica de integración.
Puedes ver en esta entrada http://pensandoensoa.com/2010/11/24/el-batch-en-el-mundo-soa-ii-2/ un esquema de las capas para hacerte una mejor idea.
Espero haberme explicado.
Saludos.
Enhorabuena por el blog Andres, últimamente las entradas esta realmente bien algunas hasta me suenan muy de cerca.
Me alegra que guste. Gracias por colaborar con tus comentarios. ¿Algún tema que quieras que tratemos?
Muchas gracias Andrés por la aproximación que nos da al SOA, sobretodo por lo que aporta de valor al modelo de negocio. Vivimos en un mundo interconectado, de software de código abierto (en mi caso trabajo con Sugarcrm), me niego a ver la realidad de cada proyecto como: “de acuerdo, empezamos a programar desde cero”. No, nunca más!.
Me ha gustado especialmente: http://pensandoensoa.com/2011/03/07/el-valor-de-soa-para-el-negocio/
Estoy de acuerdo y estoy aplicando a mi propia empresa lo que dice en un tweet: “Un directivo de mi empresa:’cuando tengamos cientos de servicios dejaremos de desarrollar y nos dedicaremos a ensamblar’//así da gusto “.
Sigue así!
David
Hola David:
me alegro de que tú lo has y encima para bien.
Muchas gracias por tu comentario. Los lectores del blog no se caracterizan precisamente por dar feedback
Saludos, cual ha sido tu experiencia en la integracion de la capa SOA con los Sistemas Legacy ej. As400, has realizado la integracion a travez de mensajeria con colas MQ, actualmente participo de una implementacion de SOA con toda las de la ley y diseñar esa integracion es la que mas ha demandado la atension … me gustaria algun contacto via correo para intercambiar ideas.
Buenos días Andrés, felicitaciones por el sitio y la acogida entre el público. Quisiera que trataras el tema de la capa de presentación. Aunque SOA en implementación se asocia generalmente a middleware o capas de integración, quisiera conocer que consideraciones se deben tener en cuenta respecto a la capa de presentación de soluciones orientadas a servicios.
Hola Emilio. Tienes toda la razón. Precisamente uno de los problemas más habituales al que nos enfrentamos cuando intentamos implantar SOA en una empresa es romper con la inercia en el modo de hacer las pantallas.
Algo de esto ya lo abordaba en mi entrada “SOA: atrapada entre la pantalla y la pared” http://pensandoensoa.com/2011/04/26/soa-atrapada-entre-la-pantalla-y-la-pared/
Pero sin duda, creo que es de especial relevancia tocar este tema y explicar claramente qué implicaciones tienen para las pantallas (los frontales de interfaz de usuario) los principios de SOA.
Un saludo
Aquí tienes, recién sacada del horno
http://pensandoensoa.com/2012/02/26/que-papel-juega-la-capa-de-presentacion-en-soa/
Hola Andrés, felicidades por tu blog, me gustaría obtener algún entrenamiento y certificación respecto a SOA, que recomiendas?
Muchas gracias por tu comentario.
No sé si has visto esta entrada, aunque es un poco antigua: http://pensandoensoa.com/2010/08/05/certificacion-en-soa/
El tema que comentas es muy interesante, y merece un post en el blog. Si pedimos ayuda a los lectores, espero que entre todos recopilamos muchos recursos para aprender que SOA que resulten interesantes.
Una pregunta: ¿cómo has conocido el blog?
Gracias por tu respuesta Andrés seguire al pendiente de tu blog. Aún no me decido por donde iniciar mi entrenamiento. Mi mundo es microsoft pero justamente estoy buscando que el conocimiento sea neutral a la marca. ¿En el mercado cual será la que mejor este posicionada?..
Te encontre por en enlace que se encuentra en Wikipedia…
Por lo que comenta Emilio en el comentario de esta entrada http://pensandoensoa.com/2010/08/05/certificacion-en-soa/ la certificación SOA de SOA School es independiente del fabricante. Tal vez sea lo que estés buscando.
Saludos
Hola Andrés, no sabía que tenías un blog. Enhorabuena porque tiene un contenido magnífico y muchas gracias por tus aportes
Hola.
Pues sí, ya ha hecho tres años y tiene más visitas de las que habría pensando
espero seguir así.
Saludos
Hola , mi interesante tu blog, pero en desacuerdo en alguna cosas que dices
Indicar que la logica de integracion es la que esta en SOA , creo que es confuso y que puede llevar a error a tus lectores.
Si la gente piensa que lo unico que tiene que hacer es levantar un servicio para que otro aplicativo lo consuma , no estaras mas que haciendo una integracion entre aplicativos , lo cual es un error desde el punto de vista de SOA.
Al final tendrias el escenario tradicional de EAI pero basado en servicios web y desde luego eso es contra lo que SOA lucha.
Desde el punto de vista mas puritas, el concepto aplicativo tradicional desaparece y lo que nos encontramos es con una coleccion de servicios que estaran alienados con las capacidad del negocio al cual dan cobertura. Este es el concepto que poco gente repara en él como un valor añadido de SOA y que denominan el alineamiento de negocio e IT comentado por muchos autores , especialmente por Erl o Dahan.
Estos servicios , permiteme la simplificacion , son los que los diferentes front-end consumirian para conformar un aplicativo.
Un saludo
Hola:
Muchas gracias por tu aporte. Comentarios como este hacen mejor este blog.
Quizás me haya explicado mal. Lo que digo es que el consumidor y el proveedor del servicio están desacoplados, ya que entre ambos existe un intermediario que hace la conexión entre ambos. Este intermediario, es un patrón de diseño llamado bus de servicios (antes de ser un producto Middleware es un patrón de diseño).
En esta entrada hago mención al ESB http://pensandoensoa.com/2010/08/11/es-necesario-un-esb-en-soa/
Saludos
Estimado Andres, gracias por tus aportes, siempre utilizo el blog como guia en este mundo de SOA.
Felicitaciones por este gran aporte a los que menos saben y suelen perderse un poco en esta tecnologia
Saludos
Eric
Gracias a ti Eric. Da gusto ver que hay que gente que te lee y te dice que el blog le es útil