Estados de madurez de la Arquitectura Empresarial

En el pos de la relevancia del MO, aprendimos que el punto de partida de una Arquitectura Empresarial es el modelo operativo, el cual nos indica cómo operamos actualmente y cómo deseamos hacerlo en el futuro.

Otro de los pasos dentro de una Arquitectura Empresarial, es evaluar los estados de madurez de la AE, para poder hacerlo existen muchas propuestas en el mercado, aquí les dejo una que proponen en el libro: “Enterprise Architecture as Strategy” de Jeanne W. Ross, Peter Weill, David C. Robertson:

1. Business Silos Architecture

Se hace evidente la presencia sistemas legados y otros que no manejan comunicación entre sí. La integración y estandarización de los procesos de negocio es casi nula. El rol de TI es automatizar lo procesos de negocio, los administradores de negocio diseñan los procesos de negocio y especifican los requerimientos funcionales a TI. Ti desarrolla o compra aplicaciones para cumplir con los requerimientos del negocio.

El estudio que hace el MIT a varias empresas arroja que el 12% se encuentran en este nivel.

Una organización que se encuentre en un nivel de madurez mayor, puede recaer en este cuando su negocio crece rápidamente o cuando se hacen fusiones con otras empresas, es aquí donde la organización debe hacer un gran esfuerzo para volver a cambiar de nivel Business silos.

2. Standardized technology Architecture (Estandarización)

Su principal objetivo es la reducción de costos, lo que significa que si se reducen o simplifican plataformas se disminuye la administración de las mismas.

Con la administración y apoyo de “estándares tecnológicos”, se obtiene:

• Reducción del riesgo
• Reducción del costo al compartir servicios como: Soporte, mantenimiento, compras, confiabilidad, seguridad, desarrollo y entrega a tiempo.
• Reducción del número de software que produce funcionalidad similar
• Se incrementa un acceso compartido a los datos, se introducen bodegas de datos, las transacciones siguen siendo individualmente en cada una de las aplicaciones.
• Se comparte infraestructura y servicios

3. Optimized Core Architecture (Optimización del Nucleo)

Las compañías se mueven de una vista local de datos a una vista empresarial, su principal objetivo estandarizar los datos y los procesos de negocio, más dependiente del modelo operativo, el ROLE de TI es asegurar la reusabilidad de los datos y de la plataforma que soporta los procesos de negocio generalmente en un enfoque y esfuerzo TOP-DOWN. Se analizan requerimientos y capacidades de TI, para estar alineado con el modelo operativo de la organización es aquí donde se evidencian oportunidades y apalancamientos.

4. Business Modularity Architecture (Modularización)

Habilita la agilidad estratégica través de la personalización y reúso de módulos (escancia del negocio). El principal objetivo crear nuevos módulos o re-usarlos para compartirlos transversalmente a las unidades del negocio. Estos servicios deben contar con interfaces estándar para acceder a módulos relacionados con datos, recursos internos y externos. El ROL de TI es proveer vínculos entre los procesos de negocio y las interfaces estándar. También en este nivel se identifican desarrollar y mejorar módulos que extiendan el core del negocio, para poder responder al cambio de condiciones del mercado para ello se usa el reúso de la experiencia en procesos, datos y estandarización tecnológica.

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

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.

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:

LINK:http://www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html

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)

http://www.oracle.com/technology/software/products/middleware/index.html

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

http://www.oracle.com/technology/software/products/database/xe/htdocs/102xewinsoft.html

3) Descargue e instale Enterprise Repository (11.1.1.2.0)

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

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

5) Instalar JDeveloper http://www.oracle.com/technology/software/products/jdev/index.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.

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