SG #18

SOA para humanos. De la competencia a la cooperación

sg — Tue, 13 Mar 2018 14:33:47 +0000

SOA para humanos. De la competencia a la cooperación sg Tue, 03/13/2018 - 08:33

Publicado en

SG #18

Tierra libre

Autor

Emilio Osorio

Las Arquitecturas Orientadas a Servicios y los proveedores con productos casi mágicos para implementarlas, proponen un nuevo paradigma para agilizar la automatización de procesos de negocio. Sin embargo, existe una letra chiquita en estas promesas que normalmente los proveedores de soluciones no hacemos énfasis hasta después de recibir la orden de compra: Implementar SOA en una organización requiere de un cambio cultural profundo y radical. Hasta la fecha, no he visto una “suite integrada” de soluciones SOA que provea una solución mágica a este problema, no hay una licencia de software que resuelva el problema de SOA para los humanos. Las organizaciones deben tener claro que SOA implica antes que nada un cambio organiza- cional, requiriendo una estrategia centrada en las personas antes que en la infraestructura.

A continuación comparto cinco estrategias que pueden ayudarles a asegurar que su organización contemple el factor humano en su adopción de SOA y aumentar las probabilidades de éxito:

1.- Liderazgo y Consenso: El lider de una estrategia de SOA requiere de poder crear un ambiente donde las decisiones se toman por consenso. La única manera de que una organización cambie es que todos sean escuchados, sus preocupaciones sean atendidas y se logren acuerdos donde nadie salga perdiendo. El mayor reto de SOA es pasar de una organización competitiva a una organización cooperativa. El establecer métricas que promuevan la cooperación y no la competencia entre áreas, el reconocimiento a la labor de equipo y un sistema efectivo de toma decisiones consensuado es un primer paso ineludible hacia SOA.

2.- Establecer un Lenguaje Común: El concepto de SOA no tiene estandares, cada proveedor da su versión particular de SOA en el cual mágicamente su producto cumple con todas las expectativas. Esto es increiblemente dañino para una organización, ya que dentro de la misma empresa, dependiendo del proveedor favorito de cada grupo de sistemas, se entenderá SOA como cosas fundamentalmente distintas. Antes de iniciar un proyecto de adopción de SOA debemos definir y divulgar lo que significa SOA para nuestra organización, y los beneficios particulares que buscamos. Lograr que todos hablen el mismo idioma es indispensable para una toma de decisiones en consenso.

3.- Diseñar nuestra propia receta: No existen recetas secretas para SOA. Cada organización tiene retos de negocio, cultura e historia distintas. Se tiene que aceptar que ningun proveedor va a poder darle un SOA “llave en mano” por que no hay otra organización igual a la suya en este sentido. La metodologia de Factores Criticos de Exito (Rockart) está más vigente que nunca al ser una estrategia basada en consenso y en la recopilación de la inteligencia colectiva para planear de forma adecuada. El definir a traves de una sesión formal de factores criticos de éxito, que contemple contextos humanos, organizacionales, tecnológicos, y administrativos es una buena manera de garantizar que se cubren todos los aspectos de una estrategia de cambio hacia SOA.

4.- El negocio antes que la arquitectura: El principal motivo de fracaso en los proyectos de TI es muy claro: el beneficio esperado por el negocio nunca llega. Más que centrarnos en si contamos con una arquitectura con todas las “capacidades”, debemos de centrarnos en un enfoque donde primero entregamos el resultado que las personas de negocio esperan y después nos preocupamos por la arquitectura técnica. Sé que va en contra de todo lo que los “profesionales” de sistemas les decimos, pero la realidad es que si entregamos primero el resultado de negocio sera mas fácil que nos den tiempo y dinero para hacer la arquitectura soñada. En SOA esto quiere decir, primero analizamos los procesos más importantes para el negocio y hacemos lo mínimo indispensable para entregar mejoras en ellos. Nada más.

5 .- La disciplina en el diseño: Existe una multitud de “conectores” y “componentes” que prometen facilitar todo. Sin embargo SOA es antes que nada una disciplina de diseño. Como toda disciplina son los humanos quienes la practican, no el producto de software. Un buen equipo de SOA entiende a todos los niveles que preservar el estilo de diseño es indispensable para obtener los beneficios. Se acabaron los “hacks” y mejoras propietarias. Todo diseño debe de obedecer los principios de diseño de SOA, los arquitectos y desarrolladores deben de practicar esta disciplina. Un comite guía puede ser de gran ayuda para asegurar que esta disciplina se aprenda y se regule.

6.- El valor de aprender: La cultura de hacerlo bien y a la primera no aplica enteramente para SOA. Somos humanos, estamos aprendiendo globalmente como cambiar hacia SOA. Habrá cosas que nos pareceran buena idea en un principio y con el paso del tiempo mostrarán que no lo son. Debemos estar abiertos a rediseñar o refactorizar. Es mejor aceptar de antemano que tendremos que variar el diseño y trabajemos de acuerdo a esto. Con SOA necesitamos iterar y protegernos de los cambios, pero más que nada necesitamos promover la experimentación y el consenso. Nada peor para paralizar SOA que desarrolladores temerosos a “exponerse” con sus compañeros porque no se imaginaron todo bien a la primera. SOA fue pensado para el cambio, aprovechémoslo.

Al final, lo que es indispensable considerar en la implementación de SOA en una organización es cómo lograr el cambio que se requiere para que los beneficios de esta arquitectura den resultado y no nos vaya a pasar que dentro de 10 años tengamos que cambiar a otra bala de plata, porque simplemente hicimos lo mismo que toda la vida, pero ahora con estandares de SOA. Buena suerte.

Bio

Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones. Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org

Agentes de Cambio de Calidad: Acerca de héroes y agentes

sg — Tue, 07 Jan 2014 06:26:25 +0000

Agentes de Cambio de Calidad: Acerca de héroes y agentes sg Tue, 01/07/2014 - 00:26

Publicado en

SG #18

Mejora continua

Autor

Luis Cuellar

La semana pasada me preguntaba un amigo sobre las cualidades de las personas que deben de integrar el equipo de calidad. Esto despertó en mí la inquietud de averiguar el criterio que utilizan otras empresas y complementarlo con ideas propias. La información que obtuve fue muy variada, desde: “es la persona con más experiencia en el modelo de calidad”, hasta “mostró mucho interés en el puesto”. Aun así, la mayoría se agrupan en los siguientes puntos:

1. Conocimiento de Administración de proyectos y/o modelos de calidad. La persona debe saber manejar un proyecto exitosamente, para poder enseñar a otros como hacerlo. Esto es comprensible, sin embargo hay que cuidar lo siguiente:

Ser responsable de un cambio organizacional es más una labor de venta que una labor de administración. El trabajo es mucho menos de dirigir y mucho más de influenciar.
Si la compañía esta buscando mejorar la forma en que hace las cosas, quiere decir que lo que hizo exitoso a un proyecto no necesariamente hará exitoso a los proyectos futuros. Es posible que alguien muy experimentado en la forma de operación tradicional tenga poca flexibilidad hacia nuevas ideas.

2. Amor por hacer las cosas bien. Una persona sin pasión no vende. El único punto de cuidado es la inflexibilidad con la definición de la palabra “bien”. En ocasiones veo a personas altamente técnicas ocupando el puesto de directores de calidad, debido a su gran conocimiento. Pero su nivel de entrega a la perfección en ocasiones los lleva a definiciones muy rígidas. Es muy fácil defender un modelo porque está publicado en un libro o porque la industria dice utilizarlo, pero en general la realidad es mucho más complicada que la teoría.

3. Estudioso y apasionado de su trabajo. Existen muchos modelos de calidad y formas de mejorar un proceso o estructura. Los individuos dedicados a la calidad deben estar conscientes de esto y en constante aprendizaje. Recuerden siempre mantener un balance entre lo que se aprende y lo que se aplica.

Agentes de Cambio

Lo que realmente debe buscarse en estas personas es que sean verdaderos “Agentes de Cambio”, individuos que apoyen a su organización a iniciar una nueva aventura utilizando modelos y metodologías de mejora. Además de los puntos anteriores, un agente de cambio requiere:

Foco. En el área de calidad es muy fácil perder el foco. ¿Quién es tu cliente? ¿Qué quieres lograr? ¿Cómo ayuda esta actividad a avanzar el plan? Si esto no se tiene presente en todo momento, la presión y problemáticas del día con día los guiarán por diferentes caminos al grado de perder la claridad de hacia donde se va o como se llegó a la situación actual.
Humildad. Un Agente de Cambio no tiene todas las respuestas, y debe estar conciente de esto. Su labor es de conciliación y de lograr un acuerdo dentro de la organización que refleje las necesidades de su compañía. Nuevamente, todas las definiciones son buenas y malas dependiendo del grado en que son realistas y pueden aplicarse a la organización en forma exitosa dando un resultado mejor al anterior.
Habilidad para escuchar y ser flexible. Esta es posiblemente la habilidad más importante. Al mismo tiempo de conocer bien el modelo con el que se trabaja, el escuchar y modificar tus ideas, actitudes y estrategias de acuerdo a las limitantes del ambiente es fundamental. Es mejor un proceso bueno bien implantado, a un proceso excelente que nadie conoce, entiende o quiere llevar acabo.
Paciencia, persistencia y optimismo. El trabajo de un Agente de Cambio nunca termina. Siempre hay una mejor forma de hacer las cosas, y es parte de su trabajo descubrirla y mover a la organización en esa dirección. Esto puede llegar a ser frustrante y deprimente, por lo que se requiere perseverancia, optimismo y muy buen humor para salir adelante. Siempre debe verse al cambio como un reto para mejorar.
Habilidades de Negociación. Influir sobre las personas requiere de una constante negociación. Muchas veces escucho a personas del grupo de calidad diciendo cosas como: “Lo que pasa es que nadie me hace caso” o “No entienden lo que esto les puede ayudar”. La realidad es que si no se ha logrado un cambio, es porque no se ha sabido vender y negociar con todos los involucrados.

Conclusión

“Todos los cambios, aun los más deseados, tienen su melancolía; ya que lo que dejamos atrás es parte de nosotros mismos; debemos de morir a una vida antes de entrar a la otra.” —Anatole France

Si estás buscando a alguien para que lleve tu área de calidad, busca entre los Agentes de Cambio de tu organización. Busca gente que sabe operar pero también sabe vender. Si por otra parte tu participas en el área de calidad de tu compañía pregúntate como ves tu rol, ¿eres la persona con todas las respuestas, que va a corregir a los demás?, o ¿eres un Agente de Cambio? Alguien que ayuda a su organización a crear una nueva vida y dejar atrás la anterior para que descanse en paz.

Bio

Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

Una Introducción a Quartz. Calendarización de Tareas en Java

Anonymous — Thu, 03 Jan 2008 15:46:39 +0000

Una Introducción a Quartz. Calendarización de Tareas en Java Anonymous Thu, 01/03/2008 - 09:46

Publicado en

SG #18

Herramientas y Tecnologías

Autor

Erick Frausto

Al desarrollar aplicaciones corporativas es común encontrarse con la necesidad de calendarizar tareas para que sean ejecutadas en automático cada cierto tiempo. Por ejemplo, podemos requerir que todos los días a medianoche se dispare un trabajo de sincronización de datos, o que el último día de cada mes se borren los archivos temporales de algún directorio. Las necesidades de agendar tareas pueden ser diversas y las aplicaciones que requieran de esto también serán muy distintas en tipo y en tamaño. Debido a este amplio rango de aplicación, no es raro encontrarnos con distintas herramientas de scheduling dentro de las cuales unas serán más adecuadas que otras para cubrir nuestras necesidades.

En el caso de aplicaciones desarrolladas con Java EE, podríamos pensar en las capacidades de scheduling que proveen los EJBs como primera opción. Conociendo que el desarrollo de una aplicación empresarial mediante EJBs pudiera no ser la opción mas adecuada para nuestras necesidades, podríamos apostar por desarrollar nuestra aplicación sobre un framework más ligero como Spring, y recurrir al API de Java Timer para resolver la funcionalidad de calendarización de tareas. Sin embargo, Java Timer solo es un API con funcionalidad básica para el manejo de tiempo, y se queda corto de lo que debería proveer un framework completo para calendarización.

Es aquí donde entra en juego Java Quartz. Quartz es un framework de scheduling open source que provee funcionalidad avanzada para la calendarización de tareas en Java. Entre estas están:

• Cualquier tarea escrita en Java es susceptible de ser agendada dentro del framework para ser ejecutada.
• Podemos agendar tareas en donde solo indiquemos la fecha y hora de ejecución y a partir de ahí definir una frecuencia de ejecución (ejemplo, ejecutar la tarea el primero de enero a las 12:00 a.m. y a partir de ahí, ejecutarse cada 3 días) hasta agendar tareas mediante el poder de las expresiones de Cron (ejemplo, ejecutar la tarea el segundo lunes de los meses de enero a septiembre del año 2008 a partir de las 8:00 a.m. cada 15 min. hasta las 10:00 a.m.).
• Definir un medio de persistencia donde se almacene la información de tareas y sus agendas para poder darle la posibilidad al framework de recuperar dicha información ante fallas de la aplicación.
• Capacidad de trabajar en un ambiente de clusters.

Con esta funcionalidad, es claro que Quartz es una excelente opción que nos proporciona un framework robusto de scheduling, con integración en aplicaciones empresariales que requieran de alta disponibilidad mediante sus características de persistencia y clustering, adicionalmente ofreciendo la posibilidad de integrarlo con cualquier framework sobre el cual se desarrolle nuestra aplicación.

Un ejemplo sencillo
Después de haber comentado acerca de lo que es Quartz y las características que nos ofrece, el siguiente paso es aplicar Quartz en un ejemplo práctico y qué otra manera de iniciar un ejemplo de este tipo sino es con el clásico “¡Hola, mundo!”.

Cualquier tarea escrita en Java es susceptible de ser agendada dentro de Quartz, con el único requisito de que la clase que desarrolle dicha tarea implemente la interfaz org.quartz.Job la cual define un método execute que luce de la siguiente manera:

public void execute(JobExecutionContext context) throws JobExecutionException;

Después de hacer que nuestra clase que desarrolla la tarea que deseamos agendar implemente la interfaz Job, el siguiente paso sería preparar el ambiente de ejecución, lo cual consiste en:
1. Crear un Job a partir de esta clase
2. Asociarle un objeto de tipo Trigger (donde indicaremos cada cuándo la tarea deberá ser ejecutada)
3. Obtener una instancia de la clase Scheduler donde registraremos el Job creado.

El listado 1 muestra un ejemplo de la implementación de la interfaz Job, mientras que el listado 2 muestra como se prepara el ambiente de ejecución.

package quartzdemo;
 import org.quartz.Job; 
 import org.quartz.JobExecutionContext;
 import org.quartz.JobExecutionException; 
 
 public class HolaMundoJob implements Job{
 
 public void execute(JobExecutionContext jobExecutionContext) 
 throws JobExecutionException {
 System.out.println(“¡Hola, mundo! :D”);
 }
 
 }

Listado 1. Implementación de la interfaz Job

package quartzdemo;
 import org.quartz.JobDetail; 
 import org.quartz.Scheduler; 
 import org.quartz.SchedulerException;
 import org.quartz.SimpleTrigger; 
 import org.quartz.Trigger; 
 import org.quartz.helpers.TriggerUtils; import org.quartz.impl.StdSchedulerFactory; 
 public class Test {
 
 public static void main(String[] args) {
 try {
 // Creacion de una instacia de Scheduler
 Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler(); 
 System.out.println(“Iniciando Scheduler...”);
 scheduler.start(); 
 // Creacion una instacia de JobDetail
 JobDetail jobDetail = new JobDetail( 
 “HolaMundoJob”, 
 Scheduler.DEFAULT_GROUP,
 HolaMundoJob.class); 
 
 // Creacion de un Trigger donde indicamos 
 //que el Job se 
 // ejecutara de inmediato y a partir de ahi en lapsos
 // de 5 segundos por 10 veces mas. 
 Trigger trigger = new SimpleTrigger( 
 “HolaMundoTrigger”, 
 Scheduler.DEFAULT_GROUP, 
 10, 5000); 
 
 // Registro dentro del Scheduler
 scheduler.scheduleJob(jobDetail, trigger);
 
 // Damos tiempo a que el Trigger registrado 
 //termine su periodo 
 // de vida dentro del scheduler
 Thread.sleep(60000); 
 
 // Detenemos la ejecución de la 
 // instancia de Scheduler 
 scheduler.shutdown();
 
 } catch(Exception e) {
 System.out.println(“Ocurrió una excepción”);
 }
 }
 
 }

Listado 2. Preparación del ambiente de ejecución

Al ejecutar este código veremos en consola un resultado parecido al siguiente:

30/09/2007 01:45:27 PM org.quartz.simpl.SimpleThreadPool initialize
INFO: Job execution threads will use class loader of thread: main
30/09/2007 01:45:27 PM org.quartz.simpl.RAMJobStore initialize
Iniciando Scheduler...
INFO: RAMJobStore initialized.
30/09/2007 01:45:27 PM org.quartz.impl.StdSchedulerFactory instantiate
INFO: Quartz scheduler ‘DefaultQuartzScheduler’ initialized from default resource file in Quartz package: ‘quartz.properties’
30/09/2007 01:45:27 PM org.quartz.impl.StdSchedulerFactory instantiate
INFO: Quartz scheduler version: 1.4.5
30/09/2007 01:45:27 PM org.quartz.core.QuartzScheduler start
INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
¡Hola, mundo! :D

¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
¡Hola, mundo! :D
30/09/2007 01:46:27 PM org.quartz.core.QuartzScheduler shutdown
INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutting down.
30/09/2007 01:46:27 PM org.quartz.core.QuartzScheduler pause
INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED paused.
30/09/2007 01:46:27 PM org.quartz.core.QuartzScheduler shutdown
INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutdown complete.

En los mensajes arrojados por la consola, nos daremos cuenta que al principio aparece la información de inicialización de la instancia de Scheduler que obtuvimos, posterior a estos encontraremos los “¡Hola, mundo!” producto de las ejecuciones de nuestro Job que registramos dentro del Scheduler y finalmente veremos los mensajes que arroja la finalización de la instancia de Scheduler.

Como mencioné anteriormente, Quartz soporta el manejo de expresiones de Cron que permiten hacer agendas más complejas que tan solo indicar un número de lapsos y periodo de ejecución para un Job. Imaginemos el caso de una empresa que tiene un proceso para calcular el nivel de producción que se tuvo en un mes, por lo que quisiéramos ejecutar este proceso en automático el último día de cada mes a las 6:30 pm que es la hora en que se termina la jornada laboral.

El cambio a realizar en nuestro ejemplo, sería en la forma de crear el Trigger. Ahora en lugar de hacer una instancia de SimpleTrigger crearíamos una instancia de CronTrigger de la siguiente manera:

Trigger trigger2 = new CronTrigger(“HolaMundoTrigger”, 
 Scheduler.DEFAULT_GROUP, 
 “0 30 6 L * ?”);

La intención aquí no es explicar como funcionan las expresiones de Cron, simplemente quiero hacer ver las posibilidades que ofrece Quartz. Quartz puede ser aprovechado tanto por aplicaciones muy sencillas, como por aplicaciones empresariales de misión crítica que mantengan una alta disponibilidad.

Los invito a conocer más sobre Quartz en http://www.opensymphony.com/quartz/

Referencias:
• Chuck Cavaness. “Quartz Job Scheduling Framework”. Prentice Hall.

Bio

Erick Frausto se desempeña como Arquitecto Java EE para ISOL (Ingeniería de Soluciones). Actualmente está trabajando en un proyecto para Afores en conjunto con la empresa EFP (Especialistas en Fondos de Previsión Social) donde está aplicando Quartz. Es egresado de Ing. en Informática de UPIICSA-IPN, es desarrollar Java certificado por Sun. Erick dedica este artículo a su familia y a las hermosas personas que ha encontrado en su camino.

SG #18

SOA para humanos. De la competencia a la cooperación

Publicado en

Autor

Agentes de Cambio de Calidad: Acerca de héroes y agentes

Publicado en

Autor

Agentes de Cambio

Conclusión

Tags

Una Introducción a Quartz. Calendarización de Tareas en Java

Publicado en

Autor