Ago 21

IBM SOA Foundation es un paquete de software integrado, y basado en estándares abiertos que permite implementar una Arquitectura Orientada a Servicios (SOA)

IBM SOA Foundation esta diseñado para apoyar la extensión de valor de las aplicaciones y procesos de negocio de una Empresa, los módulos que componen SOA Foundation han sido seleccionados para soportar cada etapa del ciclo de vida de los Procesos de Negocio.

WebSphere Business Modeler

Es especialmente útil para brindar valor a las organizaciones en el clima actual de fusiones y adquisiciones, tercerización de procesos de negocios, reingeniería de procesos y automatización de los procesos que antes eran manuales o semiautomáticos, debido a que las compañías desean evitar la dificultad y el gasto de reinstrumentar un proceso que no cumple con el desempeño esperado.

WebSphere Business Modeler

 

WebSphere Business Modeler es una herramienta de modelado construida según estándares abiertos y basada en Eclipse, una plataforma universal de herramientas de desarrollo de software de código abierto, lo cual le permite integrarse fácilmente con la arquitectura existente de una organización. El software se basa en BPEL (Business Process Execution Language), un estándar abierto basado en XML utilizado en la automatización de procesos de negocio basado en Web Services, y brinda soporte para exportar los modelos a formatos UML y las herramientas de desarrollo Rational Rose XDE.

WebSphere Integration Developer

WebSphere Integration Developer tiene por objeto proporcionar un entorno de desarrollo integrado para la creación, la realización de pruebas, la integración y la implantación de aplicaciones J2EE y servicios Web. Basado en Eclipse Versión 2.0 y escrito según las especificaciones de la norma J2EE, WebSphere Integration Developer ayuda a optimizar y simplificar el desarrollo de aplicaciones J2EE con métodos recomendados, herramientas visuales, plantillas y generación de código.

WebSphere Process Server.

Websphere Process Server es esencialmente un servidor de aplicaciones J2EE de IBM que incluye el componente para coreografía de procesos. Este es un motor de workflow basado en BPEL con las siguientes características:

 

  • Soporte de integración, instalación y ejecución de procesos de negocios basados en BPEL.
  • Herramientas intuitivas que permiten arrastrar y pegar para definir visualmente la secuencia y el flujo de los procesos de negocios BPEL.
  • Un depurador de procesos de negocios visual para depurar y visualizar paso a paso la ejecución del proceso de negocio del BPEL.
  • Soporte de compensación para proveer soporte de “rollback” a transacciones o procesos de negocios que requieran esta funcionalidad.
  • Manipulador de fallas integrado que provee un manera visual e integrada de realizar el manejo de excepciones en el flujo.
  • Un constructor de condiciones visual para definir la ejecución de lógica condicional en los procesos de negocio.
  • Posibilidad de incluir código Java como parte de los procesos.

 

El soporte para macroflujos extiende el alcance de BPEL para incluir actividades que requieren interacción humana dentro del proceso de negocios, este incluye:

 

  • Nodos específicos para representar un paso en un proceso de negocio que se realiza manualmente.
  • Facilidades para la asignación genérica de personas a una actividad de un proceso.
  • Interfaz grafica basada en Browser para acceder a la lista de ítems de trabajo y ejecutar las tareas asignadas o transferirlas a otros usuarios.
  • Administración de ítem de trabajos para controlar la creación, transferencia y eliminación de ítem de trabajos.

WebSphere Business Monitor.

Permite el análisis continuado de los datos de ejecución de procesos en tiempo real generados por IBM WebSphere MQ Workflow, WebSphere Business Integration Message Broker y WebSphere MQ Integration Broker con el objeto de optimizar los procesos empresariales.

Ago 17

BPMS presta apoyo en todo el ciclo de vida de los procesos de negocio, el cual se compone de las siguientes etapas:

  • Modelamiento de los Procesos de Negocio: en esta etapa se crea o modela un proceso de negocio, también es aquí donde se definen mejoras, o cambios a los procesos para optimizarlos. En esta etapa el principal involucrado es el “Analista de Negocios”.
  • Implementación: en esta etapa se integran los componentes necesarios para implementar el proceso. El principal involucrado en esta etapa es el “Ingeniero de TI” para el caso de que los procesos se implementen como soluciones tecnológicas.
  • Ejecución de Procesos: esta es la etapa en donde se explota el proceso desarrollado previamente, en esta etapa los principales involucrados son los “Participantes” del proceso. Además aquí es cuando se recolecta la información para control, y seguimiento.
  • Control y Gestión: esta es la etapa donde se le da seguimiento a los procesos, y donde se analiza la información de su ejecución, por ejemplo: indicadores de desempeño, cuellos de botella, caminos críticos, carga de trabajo, etc., su principal características es que la información se analiza en tiempo real. En esta etapa los principales involucrados son los “Supervisores, y la Gerencia”.

Luego los módulos principales que componen la plataforma BPMS, y que apoyan las etapas del ciclo son:

  • Modelador Gráfico de Procesos: (Business Modeler) que permite modelar los procesos de negocio, simular su ejecución, definir métricas para el monitoreo, y exportar a BPEL (lenguaje estándar de procesos). Tiene un diseñador gráfico de procesos, que permite fácilmente crear los modelos.

  • Ambiente Integración y Desarrollo: (Integration Developer) es la herramienta que permite implementar los procesos, y servicios. Esta herramienta permite integrar las pantallas (para interacción de un participante), y los servicios (interacción con sistemas legados).

  • Servidor de Procesos de Negocio: (Process Server) es el motor que permite ejecutar los procesos de negocio, aquí se ejecutan las Aplicaciones Compuestas ( flujos BPM), los Workflows tradicionales, y la Orquestación de Servicios (procesos compuestos solo por servicios). Este servidor también es el encargado de generar los datos de las métricas, y de monitoreo. Permite intervenir los procesos en tiempo real: balancear carga, cambiar flujo de negocio, y realizar acciones correctivas (según reglas de negocio).
  • Monitor de Actividades de Negocio: (BAM, Business Activity Monitor) esta es una aplicación de administración que permite gestionar los procesos y servicios, gráficamente se pueden ver indicadores de performance, y SLA (Service Level Agreements, niveles de servicio a cumplir). Se puede además definir alertas y triggers de acuerdo a eventos de negocio que sucedan en el proceso. También puede proveer datos reales a los modelos (Business Modeler) para ajustar las simulaciones (y lograr mejoramiento continuo)

La siguiente imagen muestra como se ve la herramienta BPMS, en este caso se muestran pantallas de BEA Aqualogic, pero visualmente las soluciones BPMS son parecidas:

BPMS y Ciclo de Vida de los Procesos
Algunos ejemplos de BPMS:

Ago 16

Uno de los aspectos relevantes en SOA es definir la Arquitectura de Referencia para la Empresa, esta definición permite tener un marco de referencia en donde ubicar los nuevos desarrollos.

La Arquitectura de Referencia SOA plasma los distintos componentes de una solución SOA, principalmente Procesos de Negocio y Servicios, además muestra como interactúan estos componentes con los usuarios de negocio, y con los sistemas existentes en la Empresa (sistemas legados).

Arquitectura de Referencia SOA

 

Esta Arquitectura debe ser complementada con los componentes específicos de cada Empresa. Además cada proveedor de soluciones (IBM, Oracle, BEA, etc.) tiene su propia Arquitectura SOA de Referencia, que incorpora sus herramientas especificas, pero toda Arquitectura de Referencia por lo menos contempla lo siguiente:

 

 

 

  • Usuarios de Negocio: son lo usuarios de las aplicaciones, pero en SOA son también los participantes de los procesos de negocio, estos pueden utilizar distintas tecnologías para acceder a la aplicación (o proceso de negocio): Desktop, Notebooks, PDAs, Celulares.

  • Aplicación SOA y Portal: Las aplicaciones (aplicaciones SOA, o aplicaciones compuestas), están implementadas usando componentes reutilizables (Portlets, y Servicios), para lo cual se utiliza la tecnología de Portales. Una aplicación de este tipo incorpora todas las funcionalidades de un proceso bajo un ambiente común. La ventaja principal de las soluciones Portal; es que una aplicación desarrollada para un dispositivo se puede ajustar a otro con muy poco esfuerzo, es decir, una aplicación que funciona en un Desktop se puede adaptar para que se vea en una PDA, ajustando los portlets, y su distribución para cada dispositivo. Un portal de ejemplo puede ser este sitio web: “SOAagenda.com”,

  • Servicios de Presentación (Portlets): son los componentes de presentación reutilizables, que en la practica corresponden a secciones reutilizables de las paginas Web. Ejemplos: un portlet de “Calendario”, un portlet para mostrar las “Publicaciones Recientes” de un blog. En el caso de los “Procesos de Negocio” (BPMS) generalmente ellos ofrecen un portlet para ejecutar los procesos, al que llamaremos portlet “Lista de Pendientes”.

  • Procesos de Negocio: son la implementación BPM de los procesos, son procesos que incorporan tareas interactivas (interacción participante), con actividades automatizadas (servicios). Ejemplo: el proceso de “publicar un comentario en un Blog”, que dentro de sus tareas interactivas esta el “ingresar el comentario”, y “aprobar el comentario para su publicación”, y una actividad automatizada es el servicio de “ingresar el comentario en el sistema de Blog”.

  • Servicios de Negocio: son componentes funcionales del negocio que se pueden reutilizar en los distintos procesos, y distintas aplicaciones, generalmente son servicios compuestos (por otros servicios). Ejemplo “ingresarComentarioBlog”.

  • Servicios de Información: son lo servicios atómicos que pueden ser parte de servicios de mas alto nivel. Su principal características es que acceden directamente a los recursos, o sistemas legados, encapsulan las funcionalidades especificas de los sistemas existentes, dándole así una interfaz que permita integrarlos al estándar SOA.

  • Sistemas Legados: son los sistemas existentes en la Empresa, que no están integrados (sistemas silo o isla). Son que soportan actualmente la operación del negocio, y que no están bajo el nuevo esquema de “orientación a servicios”.
Ago 14

Vamos a comenzar desde lo primordial: los estándares de programación para clases Java y páginas JSP, porque generalmente se parte programando sin ninguna estructura, y esto desencadena en que en una Empresa se tienen distintos “estilos” de programación, lo cual hace más difícil entender el programa realizado por otra persona.

Los estándares están definidos por Sun en los siguientes lugares:

http://java.sun.com/docs/codeconv/

http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

Nosotros vamos a presentar un resumen de estos estándares mediante una plantilla base de los 2 módulos básicos de programación, un clase Java, y un página JSP, estas plantillas pueden servir a un departamento de Control de Calidad para verificar que los programas se ciñen al estándar Java, pero la mejor forma de seguir estos estándares es utilizar un IDE (ambiente de desarrollo) como Eclipse, o usar verificadores de código automático.

Otra cosa que muestran estas plantillas es la forma de comentar los fuentes, para que se pueda obtener el JavaDoc correspondiente (documentación automática de Java).

Plantilla de Codificación Java.

Esta plantilla Java se puede extender a otras clases como Servlets.

Una clase Java tiene el siguiente orden:

  1. Comentarios de Inicio
  2. Definición Package
  3. Declaraciones de Import
  4. Declaraciones de la Clase

4.1. Comentario Documentación de la Clase

4.2. Estamento class

4.3. Atributos o Variables Estaticas

4.3.1. public

4.3.2. protected

4.3.3. private

4.4. Atributos

4.4.1. public

4.4.2. protected

4.4.3. private

4.5. Constructores

4.6. Metodos

La siguiente plantilla resume los principales estándares de codificación propuestos por Sun.

/*

* @(#)Plantilla.java version 1.01 2007/01/01

* Copyright (c) 2007 SOA agenda.

*/

package com.soaagenda.ejemplos;

import com.soaagenda.librerias.*; //import de librerias y clases a utilizar

/**

* Descripción de la Clase, ejemplo: Plantilla que muestra

* principales estándares de codificación.

*

* @version 1.01 01 Ene 2007

* @author SOA Team

*/

public class Plantilla extends ClasePadre {

/* Comentario de implementacion, ejemplo: Esta clase no tiene funcionalidades . */

/** atributo1 comentario documentacion atributo

* puede ser de mas de una linea

*/

public static int atributo1; //comentario linea: primero las variables estaticas,

//en orden 1.-public, 2.-protected, 3.-private

/** atributo2 comentario documentacion */

public Integer atributo2; //luego var de instancia, mismo orden 1.-public, 2.-protected, 3.-private

/** atributo3 comentario documentacion */

protected Integer atributo3;

/**

* Descripción para el constructor.

*/

public Plantilla() {

// …implementacion …

}

/**

* Descripción de un metodo.

* @param par1 descripcion primer parametro

* @param par2 descripcion segundo parametro

* @return descripcion de salida (return) del metodo, en caso que no es void

*/

public String hacerAlgo(Integer par1, String par2) {

int entero = 0; //una declaración de variable por linea y al inicio del {bloque}

/* A continuacion mostraremos ejemplos de la identación y formato de las distintas sentencias Java*/

if (entero == 0) {

int entero2 = 1; //una declaración de variable por linea y al inicio del {bloque}

} else if (entero == 1) {

entero++; // solo un estamento por linea

} else {

entero–;

}

for (int i=0; i < 5; i++){

entero=i;

}

while (entero > 0){

entero–;

}

do {

entero++;

} while (entero < 10);

switch (entero) {

case 0:

entero++;

break;

case 2:

entero–;

break;

default:

entero=1;

break;

}

try {

entero=2/entero;

} catch (Exception e) {

System.out.println(”error división”);

} finally {

entero=1;

}

return (”Ok”);

}

}

Buenas Practicas Básicas de Programación Java.

  • Acceso a Instancia y Variables de Clase: Evitar el uso de variable publicas.

  • Asignación Variables: Evitar asignar mas de una variable en un misma sentencia.
    • a = b = c +1; //evitar esto!!
    • if (c++ == d++) { //evitar esto!!

  • Uso de Constantes: Usar siempre cantantes para valores fijos.
    • if (c == 1) { //evitar esto!!
    • if ( c == ESTADO_ACTIVO ) { //asi si!!

  • Uso Paréntesis: Usar explícitamente para definir precedencia, para mejor entendimiento del programador.
    • if ( a = = b && c = = d || e == f ) { //evitar esto!!
    • if ( ( (a = = b) && (c = = d) ) || (e = = f) ) { //así si!, no hay forma de entender precedencia.

  • Valores de Retorno: Evitar “return” de condiciones simples.
    • if (booleanExpression) { //evitar esto!!

return true;

         }else{

                          return false;

          }

    • return booleanExpression; //esto si!!
    • if (condition) { //evitar esto!!

    return x;

    } else {

    return Y;

    }

      • return ( (condicion) ? x : y); //esto si!!

      • Expresiones condicionales ‘?’: La condición debería ir siempre entre paréntesis.
        • x >=0 ? x : -x; //evitar esto!!
        • ( x >=0 ) ? x : -x; //así si!!

      • Clases como parámetros de entrada: de forma de reducir la cantidad de parámetros de entrada de un método, de ser orientado a objetos, y hacer mas estable el método, por ejemplo para un método “actualizarCliente()” puede que ahora solo necesitemos actualizar 2 variables “nombre” y “email”, y solo esas pasamos como parametros, pero si mañana necesitamos una tercera, debemos cambiar todas las llamadas al método del sistema, por otro lado si pasamos una clase Cliente, solo se cambia la clase internamente.
        • public void actualizaCliente( String rut, String nombre, String email) //evitar esto!!
        • public void actualizaCliente( ClaseCliente cliente) // esto si!! es Orientado Objetos

      Plantilla de Codificación JSP.

      El orden dentro de una pagina JSP es:

      1. Comentarios de Inicio
      2. Directivas JSP
      3. Directivas Librerías de Tags
      4. Declaraciones JSP
      5. HTML y tags JSP

      La siguiente plantilla muestra los principales estándares JSP, esta plantilla se centra en los estándares JSP, y no incluye estándares HTML.


      <%–

      - Author: SOA Team

      - Date: 28 Marzo 2007

      -

      - Derechos Reservados Soa Agenda.

      - @(#)

      - Description: Estos son los “Comentarios de Inicio” de la Plantilla Ejemplo Estandares JSP.

      –%>

      <%– 2.-Directivas JSP –%>

      <%@ page session=”true”

      import=”java.util.*”

      errorPage=”../principal/paginaError.jsp”

      %>

      <%– 3.-Directivas Librerias Tags –%>

      <%@ taglib uri=”/WEB-INF/jsp/libreriatags.tld” prefix=”tags” %> <%– Aqui van las librerias de tags –%>

      <%– 4.-Declaraciones JSP: instancias variables, y metodos de la JSP –%>

      <%

      private int entero;

      public int transformaEntero(float Numero) {

      //implementaciòn

      }

      %>

      <%– 5.-HTML y tags JSP –%>

      <html>

      <head>

      <title>Titulo de la Pagina que aparece en el Browser</title>

      </head>

      <body>

      <jsp:useBean id=”cliente” class=”com.SOAagenda.segurosvida.Cliente” /> <%– declaracion de un javabeans –%>

      <h1>

      Rut:

      <tagsSAgenda:formateaRut value=”${cliente.getRut()}” /> <%– un tag que usa al beans –%>

      </h1>

      <hr />

      <table border=”1″ cellpadding=”5″>

      <%– Un if en JSP y ejemplo identación –%>

      <% if (entero == 0) { %>

      <tr>

      <td>Nombre:</td>

      <td><%= cliente.getNombre()%></td> <%– expresion explicita %>

      </tr>

      <% } %>

      <tr>

      <td>Apellidos:</td>

      <%– expresion Javabeasn muestra –%>

      <td><jsp:getProperty name=”cliente” property=”apellidos”/></td>

      </tr>

      </table>

      <%– incluir otra pagina –%>

      <%@ include file=”../principales/piePagina.jsp” %>

      </body>

      </html>

      Buenas Practicas de Programación JSP.

      • Solo Lógica de Presentación: Una pagina JSP debe evitar tener lógica de negocio, y lo que “nunca” debería tener es lógica de acceso a base de datos, se debe tener ojalá solo lógica de presentación, esto es, solo instrucciones de creacion de JavaBeans, instrucciones para mostrar sus atributos (getters) y uso de funciones de presentación (como transformaciones), también puede incluir cualquier estamento condicional (if, else, while, do while, switch).

      · Una pagina jsp debe evitar tener definición de métodos:

      public int procesarPago() { //esto NO!!

      //implementación

      }

      · Debe evitarse tener llamadas a método de negocio:

      cliente.calculaSaldo();//esto NO!!

      Si puede tener llamadas a getters de un bean:

      cliente.getSaldo(); //esto SI!!.

      · Debe evitarse tener grandes porciones de código Java, que no tengan que ver con lógica de presentación , por ejemplo si dentro de los tags jsp”<% %>” hay sobre 10 líneas, este código ya es “sospechoso” de incluir lógica de negocio, lo mas probable es que dicha lógica deba ir dentro de un Servlet, o clase Java:

      <%

      //…mas de 10 líneas entre estos tags JSP , es Sospechoso!!

               %>

      Ago 13

      Parte fundamental del del “SOA Governance” es organizar la administración de proyectos informaticos, y el primer paso es definir una metodología acorde con esta nueva Arquitectura.

      La dirección de proyectos informáticos es una disciplina compleja, y una forma de manejar esta complejidad es adoptar un estructura de dirección de proyectos (PMS: Project Management Structure), es decir, adoptar una metodología.

      Existen varios estándares:

      • PMI PMBOK: (Project Managment Body Of Knowledge) Este es la metodología propuesta por la asociación Project Managment Institute (PMI), es un estándar ampliamente difundido en EEUU. www.pmi.org
      • PRINCE2: (Projects IN Controlled Enviroments)Es la metodología propuesta por el Gobierno Ingles, y ampliamente difundida en Europa. www.ogc.gov.uk/methods_prince_2.asp
      • RUP: (Rational Unified Process)
      • XP: (eXtreme Programing) es la metodología mas difundida de la asociación Agile, que agrupa varias metodologías de respuesta rápida y altamente flexibles.
      • CMMI: (Capability Maturity Model Integration). Es un método de mejoramiento a los procesos http://www.sei.cmu.edu/cmmi/cmmi.html
      • P2M: (Project & Program Management for Enterprise Innovation) es el estándar Japonés. http://www.pmaj.or.jp/ENG/P2M_Download.htm
      • V-Modell: es el modelo alemán promovido por el Gobierno, y el ministerio de defensa de ese país. www.v-modell.iabg.de/
      • HERMES: adaptación del modelo alemán V-Modell promovido por el Gobierno Suizo. http://www.hermes.admin.ch/

      Estas metodología intentan resolver la siguientes preguntas para un Proyecto:

      · Quien? (roles dentro de un proyecto)

      · Que? (procesos, actividades y entregables dentro de un proyecto)

      · Cuando? (plan de un proyecto, oportunidad, reglas de decisión)

      · Como? (como se asignan roles, como se realizan actividades, herramientas)

      Las distintas metodología resuelven en mayor o menor grado dichas preguntas, por ejemplo se indica que CMMI resuelve principalmente el “Que”, mientras que otras metodologías como V-Modell resuelven en forma mas completa todas las preguntas, por eso algunos expertos consideran CMMI como solo un estándar mas que una metodología, en otras palabras, se puede alcanzar un nivel de madurez CMMI usando metodologías como RUP o V-Modell, de hecho la metodología PMI PMBOK tiene su propio modelo de madurez OPM3 (Organizacional Project Management Maturity Model).

      Al momento de seleccionar una metodología hay que tener las siguiente consideraciones:

       

      no hay una única tecnología mejor que todas, ya que algunas se adaptan mejor que otras a una Empresa u organización, y esto depende de la tolerancia al riesgo de la empresa, su nivel de madurez, su tamaño, etc. Todas las metodología manejan las grandes etapas del ciclo de vida de un proyecto, lo que cambia entre ellas es el nivel de disciplina.

      Otro aspecto a tomar en cuenta es que toda metodología se debe adaptar a la Organización, e incluso se pueden combinar las metodologías porque generalmente no son excluyentes, logrando una metodología mas ajustada a la realidad de la Organización.

      Hay que considerar que las metodologías no lo son todo por si mismas, hay que prepara el ambiente, y preparar a los profesionales, la empresa debe promover la cultura de “Project Managment”.

      Las metodologías en boga son; PRINCE2 y PMBOK, y sus principales caracteristicas son:

       

      Tabla Comparacion PMI y Prince2

      Actualmente el tema de Project Management orienta más su investigación en las PMO (Project Management Office) y en las herramientas de apoyo para la administración de proyectos (Project Management Applications). Las PMO son centros de excelencia que apoyan y supervisan a los Jefes de Proyectos, y a la actividad de Administración de Proyectos, para el caso d SOA la PMO es el centro de excelencia de Arquitectura (SOA COE).

       

      Ago 10

      Implementar una Arquitectura Orientada a Servicios (SOA) en una compañía es un proceso complejo, debido a que SOA se basa en desarrollar componentes (servicios) reutilizables, y con estos servicios componer nuevas soluciones tecnológicas para el negocio, esto implica un cambio cultural en como se construyen los sistemas, y un cambio en el ámbito de la soluciones:

      • En SOA los proyectos son transversales abarcan distintas áreas, y distintas aplicaciones, siguiendo el flujo transversal de los procesos de negocio de las compañías.
      • En SOA las soluciones se comparten, y se construyen para que los próximos proyectos se vean beneficiados.

      Los servicios deben ser diseñados e implementados de forma tal que puedan ser reutilizados en distintas áreas, en distintos procesos de negocio, y en distintas aplicaciones

      Esto determina que en la Empresa comienzan a proliferar partes móviles e independientes de los sistemas (los servicios), que deben ser organizadas, y deben ser informados para asegurar su reutilización.

      Además otro objetivo fundamental de SOA, es que los componentes sean flexibles, que se adapten fácilmente a los cambios. Los servicios deben ser flexibles, y los procesos de negocio implementados sobre SOA también, luego los cambios tecnológicos, o de negocio afectarán en menor medida a una Empresa, y específicamente afectarán en menor medida a los sistemas que utilizan dichos componentes. Esta flexibilidad permite salir en forma oportuna con nuevos productos, o soluciones (Time2Market).

      La reutilización, y flexibilidad son los fundamentos de SOA, solo con ellos se logra bajar los costos de mantención, se logra aprovechar de mejor forma los recursos implementados, mejorar la productividad, y el time2market., es decir obtener el retorno de la inversión (ROI).

      Lograr este tipo de componentes reutilizables, y flexibles, e implementar soluciones basadas en ellos, no es una tarea fácil, porque no basta solo con utilizar ciertas herramientas, si no además se apoya fuertemente en el cumplimiento de estándares, y buenas practicas, y es por eso que se denomina “Arquitectura” (Orientada a Servicios). Se pueden desarrollar componentes sobre tecnología SOA, pero aun así no asegurar su reutilización, o flexibilidad (ver articulo al respecto).

      Este cambio cultural, la administración de partes y piezas, la disciplina para seguir estándares, y el lograr desarrollar soluciones efectivamente reutilizables y flexibles, necesitan de un esquema de administración especial: SOA Governance.

      Algunas definiciones respecto de SOA Governance:

      “Estructura de toma de decisiones, y responsabilidades, cuyo objetivo es promover determinado comportamiento en el área de Tecnologías de la Información” .

      “SOA Governance define cambios en la administración del área tecnológica (TI) para asegurar que los conceptos y principios de SOA, y su arquitectura distribuida sean manejados apropiadamente, y que sea capaz de lograr los objetivos de negocio de los servicios” 

      “SOA Governance ya no es una opción, es un imperativo, sin esta administración (governance) el retorno de la inversión es mucho menor, y todo proyecto SOA estará en riesgo” .

      “En el 2006, la carencia de mecanismos de Governance en los proyectos medianos de SOA (proyectos de menos de 50 Servicios) han sido la razón mas común de falla de los proyectos”.

      “Lograr crecer en SOA con la disciplina necesaria para asegurar la reutilización de los servicios, y que se evite la duplicación de servicios, esto solo se puede lograr a través de procesos de Governance cuidadosamente diseñados, y fuertemente impuestos”.

      Bajo el enfoque SOA, los costos de implementación comienzan a bajar a medida que se van reutilizando los servicios. Por eso es la importancia de asegurar la reutilización y flexibilidad de los servicios, porque es lo que finalmente justifica la inversión en SOA.

      SOA Governance debe definir:

      • Que Hacer: El plan global de proyecto SOA de la Empresa, define el “SOA Roadmap” (Plan de Ruta SOA).
      • Quien lo Hace: La estructura organizacional (los grupos de trabajo), define la “SOA Office”.
      • Como Hacerlo: Los procesos (procedimientos) de administración, las normas.
      • Como Medirlo: Las métricas para medir el éxito

      Ago 09

      BPM (Business Process Management),o BPMS (BPM Suite) es el conjunto de servicios y herramientas que facilitan la administración de procesos de negocio. Por administración de procesos entendemos: análisis, definición, ejecución, monitoreo, y control de los procesos.

      BPM además contempla soporte para interacción humana, e integración de aplicaciones, y es aquí la diferencia fundamental con la tecnología de WorkFlow existente, que es que BPM integra en los flujos a los sistemas.

      Flujo BPM

      Las soluciones del tipo WorkFlow solo se limitaban a definir el flujo de actividades humanas, o de documentos, y con esto obtener el seguimiento de los procesos, pero en estos casos si un participante del proceso requería como parte de sus actividades ingresar datos en una aplicación, entonces debía salir del ambiente del WorkFlow, levantar la aplicación, y luego de terminada su operación volver al WorkFlow y registrar el cambio de estado, o termino de la actividad. En BPM todo esta integrado en el mismo flujo lo que es mas natural para un participante, el completa su actividad dentro del flujo BPM, y tras bambalinas se actualizan los sistemas que se tengan que actualizar.

      En la practica un flujo BPM (o modelo de proceso BPM) visualmente es muy parecido a un WorkFlow, la diferencia esta en que en que uno puede notar que ciertas actividades son realizadas por personas, y otras son actividades sistematizadas (realizadas por sistemas), y ambas aparecen en el flujo.

      El otro “valor agregado” de BPM es que ofrece una solución completa, que abarca todo el ciclo de vida de un proceso de negocio: análisis, modelamiento, ejecución y monitoreo de los procesos.

      En BPM el modelo del proceso se convierte en el núcleo de la implementación del proceso como solución tecnológica. El modelo del proceso de negocio (su diseño), que realiza el área de negocios de una empresa, es “en si” lo que se ejecuta sobre el “servidor de procesos” (el motor de BPM). Dicho en otras palabras: la “lógica de negocio” principal que antes bajo las tecnología tradicional se debía programar, y colocar sobre un “servidor de aplicaciones” (tradicional), ahora se reemplaza por un modelo que se sube al “servidor de procesos” con mucho menos intervención del área de TI (menos programación).

      En la practica una buena solución BPM debería poder ejecutar un proceso modelado por el área de negocio, sin la necesidad de que TI tenga que programar una sola línea de código, y obtener como solución algo equivalente a un WorkFlow Tradicional (sin integración de sistemas). Luego el área de TI debería tomar este “workflow”, e implementarle los formularios de entrada (de interacción con usuarios), y los “servicios” (las actividades automatizadas) para completarlo en un flujo BPM.

      Hacer que un modelo se convierta en un proceso ejecutable requiere de varias tecnologías habilitantes (enabling tools), cuando estas tecnologías se proveen juntas se le llama BPMS, las principales son:

      • Motores de Orquestación: permiten coordinar la secuencia de actividades según los flujos y reglas del modelo de procesos.
      • Herramientas de Análisis y Business Intelligence: permiten analizar la información producto de la ejecución del proceso en tiempo real.
      • Motores de Reglas: (Rule Engines) ejecuta reglas que permiten abstraer las políticas y decisiones de negocio de las aplicaciones subyacentes.
      • Repositorios: mantiene los componentes y recursos de los procesos (definiciones, modelos, reglas, etc. ) disponibles para su reutilización en múltiples procesos
      • Herramientas de Simulación y Optimización: permite a los administradores del negocio, comparar los nuevos diseño de procesos con el desempeño operacional actual.
      • Herramientas de Integración: permiten integrar el modelo con otros sistemas, con los sistemas legados de la empresa.


      Algunos ejemplos de BPMS:

      BPM también es vista como una disciplina de administración, que requiere que las organizaciones se cambien a un pensamiento centrado en los procesos y que reduzcan su dependencia de estructuras tradicionales de territorio y funcionalidad (los llamados silos). Es un enfoque estructurado que emplea métodos, políticas, métricas, practicas de administración, y herramientas de software para mejorar la agilidad y el desempeño operacional.

      La disciplina BPM tiene implicancia en 4 aspectos del negocio:

      • Estrategias
      • Governance (Administración y Control)
      • Estructura Organizacional (Organization)
      • Cultura.
      Ago 09

      SOA agenda

      Generales Comments Off    [Digg!] este articulo   [del.icio.us] este articulo   [Technorati] este articulo   [StumbleUpon] este articulo

      Hoy damos comienzo a este sitio, cuyo objetivo principal es ser una referencia en los temas de Java, SOA (Service Oriented Architecture), y BPM (Business Process Management). Creemos que estos temas son de real importancia para las empresa hoy en día, y especialmente para las áreas de TI (Tecnología de Información), y son la próxima evolución (no revolución) en el desarrollo de soluciones tecnológicas para las empresas.

      Detrás de SOA Agenda hay un equipo de expertos, y consultores, al cual llamamos el “S.O.A.T.” (Service Oriented Architects Team), o simplemente “SOA agenda Team”, los cuales están encargados de plasmar su experiencia en este sitio, y que sea una fuente de recursos e información para las áreas de TI, y de todo aquel que quiera conocer mas de estos temas.

      Desde ya agradecemos la participación de todos los que quieran hacernos sus comentarios, y quieran complementar nuestros artículos, o simplemente quieran hacer preguntas al respecto. Y para nosotros no hay preguntas “básicas” en estos temas, porque son temas nuevos y en evolución, luego no son de dominio masivo.

      En un comienzo no tendremos muchos artículos a disposición, pero esperamos muy pronto contar con un archivo de utilidad, y que de acuerdo a las consultas y comentarios vayamos llenando esta area.

      Mar 28

      SOA

      Generales Comments Off    [Digg!] este articulo   [del.icio.us] este articulo   [Technorati] este articulo   [StumbleUpon] este articulo

      Esta es una fecha especial para SOA Agenda.