martes, 7 de septiembre de 2010

La relevancia del Modelo operativo, en una iniciativa de Arquitectura Empresarial

Continuando con los beneficios y una ventana a la Arquitectura Empresarial, el punto de partida para un re-diseño organizacional es el modelo operativo de la Empresa.

El año pasado hice una introducción de los modelos operativos, ahora he tenido la oportunidad de profundizar este tema, la adopción de un modelo conduce a la organización, a obtener oportunidades de negocio y de crecimiento para poder competir en un mercado cambiante, para la toma decisiones, debemos apoyarnos en la estrategia de negocio, que nos direccione a alcanzar las metas del negocio. Y es aquí donde el modelo enmarcado dentro de la visión de la empresa, juega un papel muy importante en la estandarización e integración de procesos, para poder entregar productos y servicios a nuestros clientes.

Un modelo operativo tiene un profundo impacto de cómo una organización implementa sus procesos de negocio e infraestructura de TI, pues bien los modelos operativos poseen dos dimensiones la estandarización y la integración de los procesos de negocio y existen cuatro tipos de MO: Diversificado, Coordinado, Replicado y Unificado. Veamos cada uno de ellos:

Diversificado
Las unidades de negocio de una compañía poseen pocos clientes y proveedores en común, las unidades de negocio son diversificadas, ofrecen diferentes productos y servicios a diferentes clientes y las decisiones y control se hacen cada unidad de negocio.

Coordinado
Posee un alto nivel de integración y poca estandarización de procesos. Diestras de una sola imagen corporativa existen múltiples canales, uno de los beneficios fuertes son las cross-selling o ventas cruzadas.

Replicado
Manejan alta estandarización, las unidades de negocio no dependen de otras transacciones o datos, cada unidad de negocio implementa un conjunto estandarizado de procesos de negocio a manera de imagen/espejo.

Unificado
Las unidades de negocio se integran con procesos estandarizados y coordinados, maximizando la eficiencia en la entrega de productos y servicios a los clientes

En cuanto a las dimensiones, la estandarización implica un costo, la integración un esfuerzo organizacional para que las unidades de negocio, puedan compartir información y así aumentar la eficiencia, la coordinación, la transparencia y la agilidad.
Una compañía dependiendo de sus unidades de negocio y de su despliegue geográfico puede aplicar o adoptar diferentes modelos operativos.

Para quien quiera profundizar este tema les recomiendo este libro: Enterprise Architecture as Strategy de Jeanne W. Ross, Peter Weill, David C. Robertson

miércoles, 7 de julio de 2010

BPCC (Business Process Competency Center)

A continuación unas pequeñas notas y reflexiones de la conferencia de BPM in Action, del tema “The Heart of Business Process Management”:

BPM viene siendo adoptado por pequeñas, medianas y grandes empresas con el objetivo de obtener un retorno de inversión y responder acertadamente al time- to-market. Sin embargo una tecnología BPMS no es suficiente para lograr el resultado que espera el negocio, es importante quienes ya se encuentran dentro de una iniciativa BPM generen un centro de competencias de procesos de negocio (BPCC - Business Process Competency Center) o se unan a uno ya existente, este puede ayudar al diseño y gestión de la Arquitectura empresarial de negocio.

Esto con el fin de diseñar, implementar y administrar soluciones BPM con éxito, para realizarse deberá existir una divulgación continua en la organización, esto involucra a todos los recursos que se vean transversalmente afectados por los proyectos. Debe existir un capital de conocimiento donde se puedan identificar las mejores prácticas, estándares, plantillas, manejo de seguridad, Reglas de negocio comunes, herramientas tecnológicas, perfiles. El BPCC a través de asesorías por parte de un equipo de expertos, va apoyar los proyectos BPM enfocándolos en la alineación con los objetivos del negocio, para que sean más maduros, administrables y exitosos.


Taxonomia del BPCC (Business Process Competency Center)

La comunicación no debe ser uno a uno, se debe preparar al personal involucrado en la organización, por ello es importante generar o hacer uso de un Framework y repositorio de activos de procesos, como guías para administrar proyectos BPM que incluyan talleres, workshops, material interactivo de tal manera que se pueda orquestar a los interesados, garantizando que el equipo de trabajo cuente con experiencias de expertos, herramientas, procedimientos, estándares para diferentes tipos de proyectos.

miércoles, 3 de marzo de 2010

Automatización de Procesos y Siglas

Pra empezar aclaremos algunos conceptos y definiciones:

Proceso: Conjunto de actividades que tiene un inicio y un fin, en los cuales participan recursos humanos o sistemas realizando las actividades en un intervalo de tiempo, generando valor ara la organización

Workflow: Es la automatización de los procesos donde la información y documentación pasan de un participante a otro.

BPM: Es un conjunto de estándares y tecnología que apoya los procesos que se vienen ejecutando en una empresa sin importar la línea de negocio, nos ayuda a evaluar cómo se comportan nuestros procesos a través de métricas y KPIS. Normalmente para abordar una iniciativa BPM se requiere un equipo multiorganizacional ya que generalmente diferentes departamentos o áreas se ven involucradas de forma transversal a los procesos.(En otro post ampliaré este tema)

Qué tipo de estándares manejan los BPMS?

Los BPMS para que sean interoperables manejan diferentes estándares, uno de ellos es el MDA(Model Driven Architecture) arquitectura orientada a modelos, propuesto por la OMG (Object Management Group)

Este contempla 3 capas de modelado:

Capa M3 (Meta – Meta Modelo) conocido como MOF (Meta-Object Facility). Los que definen los estándares

Capa M2 (Meta - Modelo) BPMD, BPMN, etc. Pueden estar expresados en M3 MOF

Por ejemplo dentro de las capas de modelado podemos decir que el estándar BPMN(Business Process Modeling Notation) corresponde al (M2) un meta modelo, el cual los BPMS dejan a nuestra disposición con el fin de que los analistas de negocio generemos un M1 es decir modelos de nuestros proceso de negocio.

Capa M1 (Modelo) Pueden estar expresados en M2Capa

Capa M0 Ejecución ejecución de nuestros procesos

Dentro de los tipos de modelo que propone el MDA se encuentran:

CIM (Computation independent language): Aquí se ven reflejados los requerimientos del sistema, se puede ver como un modelo de dominio.

PIM (Platform independent Model): El modelo es más abstracto sin llegar a definir plataformas ni tecnologías.

PSM (Platform Specific Model): El modelo es más concreto se reflejan un PIM + la plataforma específica. Por ejemplo C# Java u otro.

Para ilustrar un poco los conceptos anteriores de tipos y capas de modelo, la siguiente figura nos muestra las capas y tipos de modelado mapeadas con las dimensiones de la arquitectura empresarial.

Imágen tomada del ibro: Handbook of Enterprise Systems Architecture in Practice de Saha, Pallab
ESB: El Enterprise Service Bus además de ser un patrón de arquitectura, es un software que se encarga de enrutar y transformar mensajes, hace mediación entre protocolos y maneja eventos. (En otro post ampliare este tema). Generalmente se encargan de comunicarse con el Back Office o Core de la organización y se implementan dependiendo de los niveles de madurez SOA en que se encuentra una organización. También son utilizados por los BPMS.

(En otro post ampliaré este tema)

BPEL: Business Process Execution Language. Aquí los procesos son servicios, sincrónico o asincrónicos, los cuales pueden tener actividades humanas y son ejecutados a través de un “Work List”. Inicialmente se llamaba BPEL4WS (2002) una especificación en conjunto con IBM, Microsoft y BEA (Hoy Oracle) , según el comité técnico de OASIS ahora WS-BPEL. No todos los procesos modelados en BPMN de un BPM Suite, se ejecutan sobre este lenguaje existen muchos que de ejecutan sobre motores propietarios cumpliendo el mimos objetivo ejecutar y exponer procesos como servicios.
(En otro post ampliaré este tema)
Para aquellos que buscan diferenciar estas dos últimas tecnologías, les recomiendo leer el siguiente:

sábado, 20 de febrero de 2010

Instalando Oracle Fusion Middleware 11g

Para hacer una instalación rápida, aquí les dejo un pequeño resumen:

1) Descargue e instale: Oracle WebLogic Server 11g Rel 1 (10.3.2)

2) Descargue e instale: Oracle Database 10g Express Edition

3) Descargue e instale Enterprise Repository (11.1.1.2.0)

Descomprima y por cosola (CMD) digite: cd c:\ofm_rcu_win_11.1.1.2.0_disk1_1of1\rcuHome\BIN
Luego ejecute: rcu.bat






A mí se me presento el siguiente error:

RCU-6083:Fallo: Comprobar requisitos para el componente seleccionado:SOAINFRA
Consulte el log de RCU en C:\Oracle\Middleware\ofm_rcu_win_11.1.1.2.0_disk1_1of1\rcuHome\rcu\log\logdir.2010-02-18_22-55\rcu.log para obtener más información.
Consulte el log de RCU en C:\Oracle\Middleware\ofm_rcu_win_11.1.1.2.0_disk1_1of1\rcuHome\rcu\log\logdir.2010-02-18_22-55\rcu.log para obtener más información.
RCU-6107:Fallo de Requisitos de Parámetro de Inicialización de Base de Datos para: processes
El Valor Actual es = 40. Debería ser ser mayor o igual que 200.
http://soadev.blogspot.com/2009/07/error-in-running-repository-creation.html

En caso de presentarse el anterior error ejecutar las siguientes sentencias, en su motor Oracle:
Connect as SYSDBA using user "system"
SQL> connect system/password
SQL> show parameters processes
SQL> alter system set processes=200 scope=spfile;

Si instalo la Express puede hacerlo a través del administrador WEB

Luego retoma el wizard de del repositorio y al dar siguiente ya no se presentara el error:






4) Descargue e instale: SOA Suite de Oracle Fusion Middleware http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

Importante abrir y actualizar el JDeveloper

6) Proceda a configurar un dominio en el Weblogic, y ya estará listo para trabajar con la SOA suite de Oracle.

jueves, 28 de enero de 2010

Beneficios y una ventana a la Arquitectura Empresarial

La arquitectura empresarial facilita el mejoramiento del negocio, le permite actualizarse y refinarse contribuyendo al entendimiento y control del negocio, para permitir una vista completa de la organización.

Para realizarlo existen diferentes Framework’s de arquitectura empresarial, los cuales nos indican el estado actual (AS-IS) y futuro o deseado (TO-BE) que podría llegar a tener una empresa, teniendo siempre como foco la realidad del negocio. Uno de estos Frameworks es TOGAF de la Open Group (http://www.opengroup.org/) (Sponsors Platinum: IBM y Hewlett-Packard), el cual presenta toda una metodología con un proceso iterativo basado en fases conocido como Architecture Development Method (ADM) el cual nos sirve para entender y mejorar el negocio en las organizaciones.

A continuación les presento un pequeño preview de lo que encontraran en cada una de sus fases:
Fase preliminar: Entender el negocio, principios, como se va a realizar la gobernabilidad, métodos a ser adoptados.

A. Visión de la Arquitectura: Alcance a nivel de IT (Como todas las demás fases son cíclicas) alineados con los procesos internos
B. Arquitectura Negocio: Estructura organizacional, Procesos, roles, objetivos que buscan los procesos
C. Arquitectura de sistemas de información: Aplicaciones, Seguridad y calidad de los Datos (Clientes, Proveedores, Facturas) “Bases de datos NO” todo lo que se refiere a entidades y objetos de negocio, Portabilidad.
D. Arquitectura Tecnológica: Todo lo que tenga que ver con Hardware, Software, bases de datos estándares
E. Oportunidades y Soluciones: Visibilidad sobre nuevas aplicaciones que apoyaran el negocio
F. Plan de Migración: Como va ser el plan de implantación detallado y como va ser el ROI
G. Gobierno de la implementación: Como, cuando, que personas
H. Arquitectura y gestión del cambio: En qué fase vamos, que hace falta?

Togaf además del método, propone el Enterprise continuum, el cuál es una vista que contiene el capital intelectual y diferentes tipos de artefactos de la Arquitectura.

Para más información TOGAF 9. The Open Group Architecture Framework (TOGAF): http://www.opengroup.org/architecture/togaf9-doc/arch/toc.html

domingo, 15 de noviembre de 2009

Patrones de seguridad para SOA

Cuando aplicamos en general la seguridad atacamos diferentes dimensiones: La primera es la Autenticación que nos indica como nos vamos a autenticar a un servicio, la segunda Autorización es decir que operaciones podemos hacer a que recursos podemos acceder, la tercera es la Auditoría o conocida como no repudio donde podemos hacer rastreos de las operaciones no autorizadas y las ultimas Confidencialidad, Integridad y Disponibilidad las cuales nos aseguran que los datos son confiables, que no fueron alterados en el transporte y que nuestros servicios deben seguir disponibles para nuestros usuarios


EXCEPTION SHIELDING

Problema: Sin filtrar datos de la excepción de salida de un servicio, este puede contener detalles de la implementación interna que puede comprometer la seguridad del servicio y su entorno.

Solución: Asegurar las excepciones sustituyendo los datos sensibles de la excepción, por datos seguros.

Aplicación: En tiempo de diseño, mediante ejecución (subrutinas).

Impacto: El seguimiento de errores es más difícil.



Message Screening

Problema: Un atacante puede transmitir mensajes con contenido malicioso o incorrecto a un servicio, dando lugar a un comportamiento indeseable.

Solución: Cuando un servicio recibe un mensaje, éste hace una serie de controles para detectar el contenido del mensaje de datos dañinos

Aplicación: Cuando un servicio recibe un mensaje este hace una serie de chequeos para detectar el contenido mal formado.

Impacto: Se requiere tiempo de procesamiento extra, y la lógica de detección requiere rutinas especializadas para procesar contenido de los mensajes binarios, tales como archivos adjuntos

Trusted Subsystem

Problema: Un consumidor que tiene acceso a los recursos backend de un servicio directamente, puede comprometer la integridad de los recursos

Solución: El servicio está diseñado para utilizar sus propias credenciales de autenticación y autorización de los recursos backend en nombre de los consumidores

Aplicación: Dependiendo de la naturaleza de los recursos subyacentes, varias opciones de diseño y tecnologías de seguridad se pueden aplicar

Impacto: Si este tipo de servicio se ve comprometido por los atacantes o usuarios no autorizados, puede ser explotado para acceder a una amplia gama de recursos.

Service perimeter guard

Problema: Los consumidores externos que requieren acceso a uno o más servicios en una red privada, podrían atacar el servicio o usuario para acceder a recursos internos

Solución: Un servicio intermedio se establece en el perímetro de la red y este es asignado para trabajar con un FireWall así que pueda establecer comunicación entre la red externa y la interna

Aplicación: Establecer un mecanismo seguro, entre redes externas e internas

Impacto: Adiciona complejidad y sobrecarga al rendimiento ya que hay una labor intermedia
Para más información: http://www.soapatterns.org/masterlist_c.asp

Modelos operacionales

Las empresas tienen modelos operativos y es importante que estas hagan uso de la tecnología para apoyar su modelo.

Dentro de la “Arquitectura Empresarial” (En otro post ampliare este concepto), es importante que las empresas identifiquen en que cuadrante “están” o a cual se quieren “mover en el futuro” ya que la forma de operar debe estar alineada con la estrategia de la organización. A continuación presento un mapa mental que presenta un resumen del paper del MIT donde se encuentran explicados estos modelos:

http://web.mit.edu/cisr/resbrfgs/2005_12_3C_OperatingModels.pdf