Artículo de Arquitectura Empresarial recomendado!

a todos!, les recomiendo leer el artículo “Estudio de las prácticas de Arquitectura Empresarial en las grandes empresas del Valle del Cauca”, en este no solo encontrarán información acerca de cómo está desarrollando la práctica de Arquitectura Empresarial en el departamento, sino que también se refiere acerca de la competencia de arquitectura empresarial en los Ingenieros de Sistemas de Información. El artículo ya está disponible en la revista Ingenium No. 13 y lo podrán descargar registrándose en . Una vez registrados ingresen por Archivos y seleccionen Ingenium No. 13…No se pierdan de leer este artículo!

Publicado en Anuncios, Conceptos de EA, Excelentes Enlaces! | Etiquetado , , | 1 Comentario

1er Simpocio Nacional de Arquitecturas de TI y Gobierno de TI


El día 16 de mayo del presente año se llevó a cabo el 1er Simpocio Nacional de Arquitecturas de TI y Gobierno de TI en la ciudad de Cali, en el marco de COLCOM 2012. En este Simpocio se presentaron los resultados del estado actual del ejercicio de arquitectura empresarial en un grupo de grandes empresas del Valle del Cauca, el cual recuerden fue el que dio origen a la creación de este blog. El evento contó con la presencia de 7 ponentes, los temas y expositores fueron:

Estado actual del ejercicio de arquitectura empresarial en un grupo de grandes empresas del Valle del Cauca
Andrés Millán, MSc. Director del Programa de Ingeniería de Sistemas de la Universidad Santiago de Cali.
¿Cómo estructurar un proyecto de Arquitectura Empresarial?
Jorge Villalobos Ph.D. Director del Departamento de Ingeniería de Sistemas y Computación de la Universidad de los Andes
– Análisis de alineación entre servicios de negocio y servicios de TI
Darío Correal Ph.D. Coordinador de la Maestría en Arquitecturas de Tecnologías de la Información de la Universidad de Los Andes.
Estrategias de Outsourcing para soportar los procesos de arquitectura y Gobierno de TI
Luis Benavides Ph.D. Gerente de Rain Concept
– Transformaciones de negocio guiadas por un enfoque Arquitectura Empresarial (EA) y basadas en TI
Jorge Arias Magíster en Sistemas y Computación Universidad de Los Andes. Chief Architect para Oracle Consulting LAD .
– Cómo complementar Arquitectura Empresarial con BPM para alcanzar mayor productividad y eficiencia organizacional.
Danny Salcedo Especialista en Procesos Para Desarrollo de Software, actualmente se desempeña como Arquitecto de Soluciones de IBM.
– La Arquitectura Empresarial como Apoyo al Gobierno de TI
Hugo Arboleda Ph.D. Director de la Maestría en Gestión de Informática y Telecomunicaciones en la Universidad Icesi.

Publicado en Anuncios, Excelentes Enlaces! | Etiquetado , , , , | 2 comentarios

Inicio de las actividades de divulgación de los resultados del estudio del estado del arte de arquitectura empresarial en el Valle del Cauca!

Aprovecho este esparcio para invitarlos a una de las primeras actividades de la celebración de los 16 años de la Facultad de Ingeniería de la Universidad Santiago de Cali, la cual lleva por nombre EXPLORA 2012. Este es un evento de investigación que integra el I Encuentro de Investigadores de la Facultad, el X Encuentro de Semilleros Interno y el informe de resultados de grupos de investigación. Se realizará del 9 al 11 de Abril, de 2 a 9 p.m. En este evento aprovecharemos para dar inicio a la primera actividad de divulgación de los resultados del estudio del estado del arte de arquitectura empresarial en las grandes empresas del Valle del Cauca
No se lo pierdan!

Publicado en Anuncios | Etiquetado , | Deja un comentario

Curso de Arquitectura Empresarial en Cali!

A finales del mes de julio la empresa ITEA estará llevando a cabo un curso de Arquitectura Empresarial, es una excelente oportunidad para conocer del tema. El curso contará con entrenadores certificados TOGAF V9.0:
-Leonardo Ramírez
-Andrés Jaramillo
-Marco Rodríguez
-Andrés Millán

Inversión: un asistente $672.800
dos asistentes del mismo grupo empresarial $1.160.000
Incluye impuestos, material impreso, refrigerios y certificados del curso

Julio 22,23,29 y 30 Agosto 5 y 6 de 2011 Sesiones Viernes 6:30 p.m. a 9:30 p.m.- Sábados de 8:00 a.m. a 1:00 p.m.

Para reservar el cupo deben comunicarse al teléfono (2) 485 4455 en la ciudad de Cali. Para mayor información pueden visitar la página WEB www.iteasolutions.com.co, o contactarse al correo electrónico info@iteasolutions.com.co

Publicado en Anuncios | Etiquetado , | Deja un comentario

AOGEA Colombia!!


AOEGEA Colombia, es una propuesta nacida de la comunidad del Open Group, que procura universalizar los conceptos de Arquitectura Empresarial (AE), tomando a Colombia como piloto en esta tarea para el mundo de habla hispana. En aras a este propósito el capitulo Colombia propone apropiar e implementar AE a partir del negocio, la industria, el sector, la nación, en una escala de madurez de apropiación del concepto reflejando el impacto de su instrumentación en el fortalecimiento y desarrollo tecnológico social y económico para la región de América Latina y el Caribe (ALC), motivo por el cual cuenta con el apoyo de los países del G20 y el PNUD.

Para quienes deseen hacer parte del grupo pueden unirse en la siguiente página:

www.aogea.com.co

Publicado en Anuncios, Excelentes Enlaces! | Etiquetado | Deja un comentario

La Arquitectura Empresarial y el Ingeniero de Sistemas

Los ingenieros de sistemas generalmente se concentran en el sistema que se está desarrollando actualmente, sin ocuparse mucho de la empresa que soporta dicho sistema. Este artículo explora los puntos de conexión que existen entre la arquitectura empresarial y la arquitectura de sistemas, y describe cómo la arquitectura empresarial beneficia y a la vez limita el desarrollo de sistemas. Su objetivo es ayudar a los ingenieros de sistemas a comprender mejor cómo sus esfuerzos en los proyectos que crean o modifican sistemas pueden verse limitados por, y pueden a su vez modificar la arquitectura de la empresa a la cual soportan dichos sistemas. En la empresa de hoy, impulsada por los negocios, existe una relación directa entre la capacidad de negocios de la empresa y la funcionalidad implementada en los proyectos.

El cambiante panorama del desarrollo de sistemas

Las empresas actuales están dejando de lado los sistemas separados que brindan funcionalidad aislada, para adoptar sistemas mucho más integrados en los cuales se potencian los servicios para ofrecer operaciones robustas y eficientes. Por lo tanto, los sistemas dentro de la empresa están más estrechamente integrados y los esfuerzos por modificarlos son más complejos. El ingeniero de sistemas que trabaja en un proyecto ya no se puede focalizar exclusivamente en el sistema que se está modificando, sino que también debe comprender cómo interactúa el sistema con otros sistemas dentro de la empresa.

La Figura 1 ofrece una descripción general de este cambio de foco. Anteriormente la arquitectura empresarial contaba con el soporte de sistemas separados independientes. Había un discreto distanciamiento entre la arquitectura empresarial y los ingenieros de sistemas, con sus problemas afines. Hoy en día el desarrollo de sistemas se basa mucho más en los negocios. Hay una fuerte necesidad de responsabilidad financiera de TI y los gastos en sistemas y éstos deben ajustarse a su beneficio comercial. Por ello, la alineación entre negocio y desarrollo es crucial. Hay una participación constante entre el arquitecto empresarial y el ingeniero de sistemas que conduce a una mayor alineación negocio/TI y colabora con la gobernabilidad técnica en todo el ciclo de vida, los arquitectos empresariales participan durante más tiempo y los ingenieros de sistemas se involucran antes. Por último, los servicios implementados soportan la obtención y el monitoreo de datos durante la operación. El análisis de este intercambio impulsa cambios futuros.

Figura 1: Alineación de arquitectura e ingeniería al inicio del ciclo de vida

Definiciones

Al hablar sobre sistemas en diferentes niveles es importante definir explícitamente términos que de otra manera serían ambiguos dada la diversidad de significados y usos existentes.

Empresa

Una definición de empresa es una organización de negocios i . La organización podría ser parte de una compañía, una compañía entera o incluso una participación en varias compañías. Para simplificar el tema, pensemos en una empresa como una compañía. Aunque hay una gran cantidad de maneras de analizar una empresa, con el fin de razonar acerca de la evolución de una empresa, es útil considerarla como un sistema a gran escala. Como todo sistema: a) tiene una razón de ser, ya que brinda ciertos valores a quienes se involucran en ella; b) posee una financiación que le permite operar; c) realiza algunas acciones, cumpliendo con una serie de requisitos; y d) está integrada por componentes, trabajadores y sistemas de menor nivel, que colaboran para que logre su funcionalidad. (A lo largo de este artículo, el término “componente” se utiliza para referirse a una parte del todo que colabora con otras partes.)

Arquitectura empresarial

Hay muchas definiciones para arquitectura empresarial. Por lo general, el término arquitectura empresarial aparece en mayúsculas como sustantivo propio (por ejemplo, la disciplina de la Arquitectura Empresarial), aunque, como usted podrá observar, nosotros no lo estamos usando de esta manera. Nos referimos a la arquitectura empresarial simplemente como la descripción de la arquitectura de la empresa en cuestión. La disciplina de la Arquitectura Empresarial aúna negocio, estrategia, proceso, método y componentes desde una cantidad de perspectivas diferentes. Estas perspectivas están definidas y varían según los diferentes enfoques dados a la Arquitectura Empresarial. Las Arquitecturas Empresariales son realizadas por Arquitectos Empresariales. Las responsabilidades de un Arquitecto Empresarial exceden el enfoque de este documento.

Por lo tanto el propósito de un arquitecto empresarial, según se define en este artículo, es describir los componentes de una empresa, sus relaciones, cómo colaboran e interactúan entre sí con el “mundo exterior”. Una arquitectura empresarial ofrece la orientación para implantar los componentes de la empresa. La implantación de los componentes produce un cambio en el estado de la empresa.

Sistema

Un sistema es un grupo de elementos que forman un todo unificado y cumplen un fin común ii . El fin común es la razón de ser del sistema. Uno o más involucrados reconoce/n la necesidad que satisface el sistema. Por lo tanto, el objetivo del sistema es satisfacer una serie de necesidades de los involucrados, es decir los requisitos del sistema. Estos requisitos incluyen qué funcionalidad se muestra y también cómo se muestra la funcionalidad dadas las cualidades requeridas y las limitaciones existentes (es decir requisitos no funcionales). El sistema satisface sus requisitos ejecutando un conjunto de acciones. Las acciones satisfacen las necesidades de los involucrados. Como el sistema es un grupo de elementos, las acciones del sistema son realmente ejecutadas mediante la colaboración de estos componentes.

Cabe destacar que los componentes pueden ser cualquier cosa: hardware, software o personas. Las personas que participan en un sistema como componentes colaboradores se llaman trabajadores. Algunos de los componentes en sí mismo, se pueden considerar sistemas en todo su derecho y generalmente se los llama subsistemas. Aunque en realidad los trabajadores también pueden considerarse sistemas, según lo descripto anteriormente, no los tratamos así, sino como objetos constitutivos ya que no nos incumbe aquí cómo colaboran sus partes internamente.

Ingeniero de Sistemas

El título de Ingeniero de Sistemas se ha aplicado a individuos que desarrollan cualquier actividad vinculada con la ingeniería de sistemas. Hemos observado “Ingenieros de Sistemas” responsables de todo, desde planeamiento, hasta obtención de requisitos, captura de arquitectura, integración y testeo. Muchas de sus actividades trascienden la disciplina tradicional de la Ingeniería de Sistemas. En este artículo, nos focalizamos en el rol del ingeniero de sistemas para garantizar que el resultado del esfuerzo de desarrollo se “ajustará” al resto de la empresa y operará de manera homogénea. Esencialmente, es responsabilidad del ingeniero de sistemas crear o actualizar la arquitectura del sistema, cumpliendo con todas las restricciones impuestas por la empresa en general.

Programa

Un programa es una iniciativa adoptada para cambar el estado de la empresa, para proporcionar alguna capacidad nueva o mejorada. Su propósito es mover a la empresa de su estado actual al estado futuro, modificando alguna parte de la empresa, agregando o modificando componentes de la empresa. Los programas se ejecutan mediante la implementación de uno o varios (normalmente varios) proyectos. Obsérvese que los programas pueden tener un alcance mucho menor que el de toda la empresa. Sin embargo, para simplificar el tema a tratar aquí, sólo expondremos los programas que impactan sobre toda la empresa.

Proyecto

Un proyecto es una actividad de desarrollo con un objetivo, inicio y fin específicos, focalizado en brindar algún resultado de valor mensurable que contribuya con una capacidad. Es común que un proyecto se focalice en la introducción de un sistema nuevo en la empresa, o la modificación de un sistema existente, aunque su alcance podría ser mayor o menor. Los proyectos tienen sus propios objetivos y presupuestos. Normalmente se combinan con otros proyectos formando parte de un programa (ver la Figura 2).

Figura 2: Cómo los programas y los proyectos afectan a la empresa

Descripción del nivel actual de la empresa

Ya sea documentada o no, toda empresa tiene una arquitectura integrada por componentes y sus relaciones y colaboraciones, a menudo capturadas en dibujos, diagramas, documentos, modelos, etc. Además de la arquitectura, la empresa tiene una serie de requisitos que debe cumplir. También hay pruebas para determinar cuan bien la empresa cumple con sus requisitos.

Nuevamente, ya sea documentado o no, toda empresa tiene sus requisitos y pruebas. Cuando se implementa una nueva edición de algún componente de la empresa, se realizará una determinada cantidad de pruebas para garantizar que el componente cumpla con sus requisitos. Esto incluye que no dañe cualquier funcionalidad de mayor nivel por la forma en que interactúa con otros componentes. Si estas pruebas detectan algún problema, éste debe rastrearse como defectos de la empresa hasta tanto se resuelva. (El problema podría ser el componente recientemente emitido o un comportamiento inesperado de algún componente interviniente.)

Por ello, observamos que estos artefactos, cuando existen y se combinan, forman una descripción completa de elementos clave de la situación actual de la empresa (ver la Figura 3):

*Requisitos (y sus impulsores, como motivación y objetivos)
*Arquitectura (incluyendo diseño e implementación)
*Pruebas
*Defectos

Figura 3: Artefactos actuales de la empresa

Los programas cambian a la empresa

Según lo definido anteriormente, el propósito de un programa es mover a la empresa del estado actual al estado futuro. Muchas veces esto incluye crear una serie de artefactos que describen el estado futuro. Sin embargo, si el estado actual está bien documentado, no es necesario volver a documentar las porciones de elementos (requisitos, arquitectura y pruebas) que no son modificadas por el programa. Sólo es necesario actualizar los artefactos actuales con los cambios establecidos por el programa. Estos cambios son deltas que se necesitan aplicar a los artefactos actuales para describir el estado futuro deseado.

En lugar de empezar desde cero, los artefactos del programa deberán describir los cambios del estado actual. Esto asume que se ha comprendido bien (capturado) el estado actual. Si esto no fuera así, no todo está perdido. Como de todas formas es necesario documentar el estado futuro, los artefactos creados pueden convertirse en artefactos actuales a nivel de la empresa después que se ha creado el programa.

Los programas pueden variar en cuanto a su alcance, desde modificar un aspecto de la empresa, a transformar todo el negocio de la misma. Por ello, es fácil exceder el alcance de un programa único para generar el conjunto completo de artefactos actuales para la empresa. En cambio, cada programa puede generar los artefactos para las porciones que modifica. Como muchos programas afectan varias áreas de la empresa, las brechas se eliminan. Este enfoque evita tener que esperar un conjunto completo de artefactos actuales antes de iniciar cualquier programa de cambio. Este enfoque puede avanzar hasta que las restantes brechas en los artefactos actuales de la empresa sean relativamente pequeñas y pueden resolverse mediante tareas separadas para cerrar directamente las brechas. Para obtener una representación completa y coherente de la empresa, todos los programas empresariales deben usar convenciones estándares para representar tanto los artefactos actuales, como los futuros (o por lo menos convertir sus artefactos de/a la convención estándar), y efectivamente deben comenzar a construir en base a los artefactos creados por los programas anteriores. De lo contrario, será muy difícil lograr la correlatividad entre los artefactos creados por diferentes programas y lograr una representación única coherente de la empresa. Además, los artefactos actuales se deben conservar como un repositorio único homogéneo. No es importante cómo se construye el repositorio, es decir si es un archivo único o una consolidación de bases de datos. Lo importante es que se conserve y se puede acceder a él como una representación consolidada coherente.

Si (o una vez que) los artefactos actuales de la empresa están disponibles, el programa deberá comenzar con estos artefactos y capturar los cambios que se necesitan implementar al programa. Esto incluye deltas de los requisitos, actualizaciones a la arquitectura y modificaciones en las pruebas acordes a los cambios de requisitos. Los deltas de los requisitos capturan los cambios deseados en el comportamiento esperado. Estos cambios deseados, aún cuando se informan inicialmente de manera informal o se perfeccionan más adelante, impulsan los deltas de la arquitectura. Tanto los deltas de requisitos, como los deltas de la arquitectura pueden impulsar cambios en el conjunto de pruebas.

Cuando se ejecuta el programa (es decir, sus proyectos son implantados), se pueden realizar las pruebas para verificar que los requisitos hayan sido cumplidos y para detectar cualquier defecto en la implantación, los requisitos, o las pruebas propiamente dichas. Normalmente cualquier defecto detectado se resolverá en el ámbito del programa. Sin embargo, algunos defectos no pueden resolverse en el ámbito del programa, y por lo tanto se convierten en defectos adicionales a nivel de la empresa.

Al finalizar el programa, la empresa está en el estado futuro definido por el programa. Como este es el nuevo estado actual para la empresa, es necesario actualizar los artefactos actuales a nivel de la empresa. Esto es sencillo porque el programa ya ha producido todos los cambios necesarios para los artefactos. La Figura 4 que muestra una ilustración del flujo de artefactos. (Obsérvese que, como es posible que varios programas se estén ejecutando simultáneamente, en este momento la empresa puede implantar cambios adicionales fuera del alcance del programa. Estos cambios adicionales se fusionarán en el estado actual de la empresa al finalizar dichos programas.)

Figura 4: Flujo de artefactos entre programa y nivel de la empresa

Los proyectos implementan el programa

Los programas definen un conjunto de cambios que crean o modifican alguna capacidad de extremo a extremo. Para lograr la capacidad nueva, normalmente es necesario crear sistemas nuevos o modificar varios sistemas existentes (quizás mediante la adquisición de una aplicación nueva o cambiando algún proceso). Es usual definir y ejecutar varios proyectos, uno por cada sistema afectado, para lograr todos los objetivos del programa.

Cada proyecto tiene un alcance específico que debe cumplir. Ese alcance está directamente relacionado con los cambios requeridos en la arquitectura para implantar la nueva capacidad. Es decir el programa define qué nueva funcionalidad se requiere de los sistemas afectados para implantar la capacidad, y cada proyecto implanta la nueva funcionalidad para su/s sistema/s. Aunque es posible que un proyecto implante cambios que soporten más de un programa, esto es mucho menos frecuente y por lo tanto no nos referiremos a ello en este documento.

Es más frecuenta que los requisitos a nivel del programa se implanten a través de varios sistemas. En estos casos, se crea un diseño a nivel del programa para mostrar cómo colaboran los sistemas. Este diseño asigna responsabilidades a cada uno de los sistemas involucrados. Las responsabilidades se ajustan a los roles que desempeñan en las colaboraciones. Este diseño satisface los deltas de los requisitos a nivel del programa. El resultado es un conjunto de requisitos que derivan de cada uno de los sistemas. No obstante, hay veces en las que un requisito a nivel del programa se implanta totalmente en un único sistema. En estos casos, el requisito a nivel del programa se asigna directamente a un único sistema. Ver la ilustración de la Figura 5 que muestra estas relaciones.

Figura 5: Flujo de requisitos del programa al proyecto

Pero, aquí nuevamente, al ejecutar el proyecto no necesitamos comenzar de cero excepto que el proyecto esté creando un sistema nuevo. Si el alcance del proyecto consiste en modificar un sistema existente, entonces el sistema tiene un estado actual. Tiene requisitos que cumplir, una arquitectura, pruebas que han sido realizadas y probablemente algunos defectos abiertos. Según lo descripto anteriormente para los artefactos actuales de la empresa, si estos artefactos no están disponibles, se pueden crear en base a una cantidad de proyectos. Como ocurre con los artefactos de la empresa, los artefactos de sistemas necesitan mantenerse en un repositorio y en un formato homogéneo para potenciarlos eficientemente.

Los artefactos de sistemas actuales, así como los artefactos de la empresa actuales, incluyen requisitos, arquitectura, pruebas y defectos existentes. Por lo tanto si un sistema tiene artefactos actuales existentes entonces en lugar de comenzar con una lista en blanco, el proyecto deberá crear sus artefactos futuros como cambios de los artefactos actuales. Así como el programa brinda actualizaciones de los artefactos de la empresa, el proyecto también ofrece actualizaciones de los artefactos de sistemas. Obsérvese la Figura 6 para consultar las relaciones existentes entre artefactos de sistemas actuales y artefactos de proyectos.

Figura 6: Flujo de artefactos entre el nivel del proyecto y el nivel del sistema

Unir todas las piezas

Lo descripto anteriormente brinda un flujo de extremo a extremo para la evolución de la empresa y de los sistemas, incluyendo sus artefactos actuales, a través de la ejecución de programas y proyectos. Hay que admitir que esta es una visión simplificada, que asume sólo un paso entre la empresa y sus sistemas. Por supuesto existe la posibilidad de que se produzcan pasos adicionales con los niveles intervinientes y sus artefactos. Sin embargo, se utiliza el mismo enfoque, el cual se puede aplicar homogéneamente a cada nivel de descomposición existente, con las decisiones apropiadas en cuanto a qué mecanismo (programa, subprograma, proyecto, subproyecto, etc.) actualizan estos niveles intervinientes. La Figura 7 muestra el flujo completo, de extremo a extremo, para esta visión simplificada.

Figura 7: Flujo de extremo a extremo de la empresa a los sistemas

Conclusión

Algunas organizaciones ya han desarrollado prácticas para administrar sus artefactos actuales para los niveles de empresa y sistemas y están cosechando los beneficios de potenciar estos artefactos. Otras recién están comenzando y avizoran beneficios futuros. Sin embargo, el objetivo y el enfoque son iguales en todos los casos. Para administrar eficientemente la evolución de la empresa, es necesario comprender sus requisitos y funcionalidad actuales y cómo logra esa funcionalidad (su arquitectura). Además es necesario comprender si su desempeño actual es el correcto en términos de pruebas y defectos existentes.

No es eficiente recrear estos artefactos en cada programa. En cambio las organizaciones desean reutilizar el conocimiento que poseen actualmente y desarrollar los artefactos como los desarrollos de la empresa. Por ello, la organización siempre tiene una visión precisa del estado actual, es capaz de planificar eficientemente la evolución de la empresa y reduce el esfuerzo total realizado, potenciando los artefactos en cada programa. Aún cuando sea poco práctico capturar un set completo de artefactos actuales para toda la empresa, las organizaciones obtienen beneficios al capturar los artefactos para una parte de la empresa, cuanto mayor sea esta parte, mayor será el beneficio.

Sin una visión precisa de la situación actual, cada programa debe: a) crear una representación del estado actual desde cero, examinando la empresa antes de avanzar con los trabajos del programa; b) intentar construir una representación del estado actual aplicando sucesivamente modificaciones implantadas por programas anteriores; o c) desistir del intento de representar el estado actual e intentar modificar una arquitectura desconocida, con la esperanza de que las modificaciones no produzcan consecuencias no deseadas. Hemos visto a las organizaciones intentar estas tres opciones, sólo para aprender dolorosamente que se necesita contar con una visión precisa del estado actual de la empresa para su correcto funcionamiento.

Es igualmente cierto que las organizaciones se benefician ampliamente con la reutilización de artefactos a nivel de los sistemas. Una empresa tiene muchos sistemas y por lo tanto los beneficios de la reutilización se multiplican por la cantidad de sistemas. La complejidad de muchos sistemas ha superado ampliamente la capacidad de cualquier individuo para mantenerlo completamente en su mente. Los artefactos que capturan los requisitos, la arquitectura, las pruebas y los defectos de un sistema constituyen una necesidad para la comunicación. Los beneficios de potenciar estos artefactos con cada proyecto nuevo incluyen: mayor homogeneidad, menos errores y menor esfuerzo general.

Hemos ilustrado cómo la arquitectura de la empresa brinda la base para su evolución mediante los programas. Los programas individuales y la organización toda se benefician al especificar el programa en términos de cambios del estado actual de la empresa. Estos cambios impulsan y restringen el trabajo realizado en los proyectos. Los proyectos desarrollan sistemas a partir de su estado actual, pero lo hacen sólo para cumplir con los requisitos asignados y derivados que provienen del programa. Para completar el ciclo, los proyectos y los programas deben aplicar sus cambios al sistema y a los artefactos de la empresa actuales, así podrán ser precisos cuando se produzcan modificaciones futuras.

fuente: http://www.ibm.com/developerworks/ssa/rational/library/edge/09/jun09/enterprisearchitecture/index.html

Publicado en Conceptos de EA, Procesos de Negocio | Etiquetado | 1 Comentario

Comparativo de Frameworks de EA

Crear una Arquitectura Empresarial a partir de cero puede ser una tarea de enormes proporciones, los marcos de EA simplifican el proceso y guían al arquitecto a través de todos los ámbitos del desarrollo de la arquitectura. Un framework de Arquitectura Empresarial proporciona entonces una colección de las mejores prácticas, estándares, herramientas, procesos, y plantillas para ayudar en la creación de la Arquitectura Empresarial y generalmente incluyen:

• Vocabulario Común, modelos, y taxonomía
• Los procesos, los principios, estrategias y herramientas
• Arquitecturas y modelos de referencia
• orientación prescriptiva (procesos de EA, el contenido de la arquitectura, hoja de ruta de la aplicación, la gobernanza)
• Catálogo de prestaciones y artefactos de la Arquitectura Empresarial
• Contenido del metamodelo de la Arquitectura
• Recomendaciones de conjunto de productos y configuraciones (opcional)

Utilizando un marco de arquitectura empresarial se agiliza el proceso para la creación y el mantenimiento de las arquitecturas a todos los niveles (por ejemplo, la arquitectura del negocio, arquitectura de la tecnologúa, arquitecturas de soluciones) y permite a una organización aprovechar el valor de la arquitectura con las mejores prácticas.

Existen una serie de marcos con el fin de abordar el desafío básico de la evaluación, y la alineación, de los objetivos de la organización con los requisitos técnicos y las estrategias. Algunos ejemplos son Zachman Framework, The Open Group Arquitecture Framework (TOGAF), OMB Federal Enterprise Architecture (FEA), y la Metodología de Gartner (Anteriormente el Metaframework).

Cada framework tiene diferentes fortalezas y debilidades, lo que hace difícil definir cual es el ideal para todas las situaciones. El siguiente gráfico siguiente muestra un comparativo de cuatro Frameworks dando una calificación de 1 a 4, a diferentes criterios, y puede resultar útil a la hora de decidirse por un framework:

Comparativo de Frameworks de EA

fuente de información: An Oracle White Paper in Enterprise Architecture

Publicado en Conceptos de EA | Etiquetado , | Deja un comentario

Oracle Enterprise Architecture Framework OEAF

Ya está disponible en la página EA Frameworks de este sitio información del Oracle Enterprise Architecture Framework OEAF, sus componentes, proceso de desarrollo y beneficios, Visítala !!

Quiero leerlo en este momento!!

Publicado en Conceptos de EA | Etiquetado , , | Deja un comentario

Curso de Arquitectura Empresarial en Cali!!

En el mes de abril, se estará dictando un curso de Arquitectura Empresarial en la ciudad de Cali, de igual manera, se estará haciendo una gira, y el curso se dictará en varias ciudades, para que tenga una información más detallada ingresen al siguiente Link:

Curso Arquitectura Empresarial

Es una buena oportunidad!!!!

Publicado en Anuncios | Deja un comentario

Comparación de las 4 principales metodologías de EA

Los invito a que revisen el siguiente artículo, el cual está extraido del MSDN de Microsoft, en este se da una breve reseña histórica de las EA, y se hace una revisión de los Frameworks TOGAF, Zachman, FEA y Gartner. No dejen de leerlo!!

Quiero ver el artículo de comparación en este momento!

Publicado en Excelentes Enlaces! | Etiquetado , | Deja un comentario

Cómo elegir el Framework de EA adecuado en una organización???

Con la creciente importancia de la Arquitectura Empresarial en las organizaciones, nace la discusión acerca de cómo crear o elegir el Framework de Arquitectura Empresarial adecuado para una organización específica. Pero no es sólo una cuestión de elegir el framework adecuado para la descripción o el desarrollo de una EA, es también importante descubrir si el Framework de arquitectura elegida cumple los requisitos definidos o no. A continuación recomendamos un artículo donde se describen los requisitos que en la actualidad los frameworks de EA deben reunir para constituirse en un procedimiento útil que permita desarrollar, describir y mantener una Arquitectura Empresarial. Muestra una evaluación de los actuales marcos muestra sus carencias e identifica nuevas mejoras.

El artículo lleva por nombre “Evaluation of current architecture frameworks”, y se puede acceder a través del siguiente link:

http://www.dcc.uchile.cl/~vramiro/d/p1546-leist.pdf

Publicado en Excelentes Enlaces! | Etiquetado , | 2 comentarios

Evaluación de una EA

Los invitamos a que revisen el ensayo “Evaluando la Aplicación de EA en las organizaciones”, este describe esquemas de evaluación existentes, qué evalúan estos esquemas, y además contiene referencias de páginas y documentos con los cuales podrás profundizar en el tema.

Deseo leer el ensayo en este momento!!

Publicado en Anuncios | Etiquetado , , | Deja un comentario

EA con IBM

Para quienes estén interesados en revisar el enfoque de IBM con sus herramientas para Arquitectura Empresarial, les recomendamos que ingresen a la siguiente página:
http://www-01.ibm.com/software/co/info/itsolutions/enterprisearchitecture/
Allí encontrarán información de herramientas, casos de estudio y artículos con respecto al tema

Publicado en Excelentes Enlaces! | Etiquetado , | Deja un comentario

Ensayo acerca de la innovación!

Les recomendamos lean este ensayo que trata el tema de la innovación dentro de las organizaciones, les ayudará a comprender como la innovación se puede convertir en un factor diferenciador, en una ventaja competitiva. La innovación se puede aplicar también en nuestras vidas y profesión. Recordemos que el tema de Arquitectura Empresarial es considerado como innovador, y aquellos que posean buenos conocimientos y estudios en esta disciplina, pueden convertirse en un profesional con una ventaja competitiva frente a los demás!
Quiero leer el ensayo en este momento!!!

Publicado en Anuncios | Etiquetado , | 2 comentarios

Los Diferentes Roles del Arquitecto

En la actualidad ya existen publicaciones, que han definido unas competencias y responsabilidades con diferencias significativas entre los distintos roles del Arquitecto, para tener claridad de las diferencias entre los diferentes roles del Arquitecto, a continuación realizamos una descripción breve de aspectos tales como competencias, las actividades y los artefactos típicos de cada rol del Arquitecto

A. Arquitecto de Empresa
En este rol, el Arquitecto en la organización debe ser el encargado de apoyar la estrategia de negocio, a través de una buena gestión de la información, y de las soluciones de TI. También ejerce funciones de gobierno y regula normas para la comunicación. Una analogía clásica consiste en comparar al Arquitecto de Empresa con el Planeador de una ciudad que utiliza la estrategia, la planificación y la reglamentación para que cada uno de los grupos se integre y trabajen de una manera efectiva. El Arquitecto de Empresa debe guiar al líder de T, para que sus inversiones, siempre estén alineadas con la estrategia del negocio, y le brinde una ventaja competitiva a la organización [1]. Este Arquitecto debe tener conocimientos profundos en negocios, una buena base de conocimientos de TI, tener habilidades de negociación, de liderazgo y de motivación, conocimientos en gestión de proyectos, de economía. Un amplio conocimiento de Arquitectura Empresarial y de modelado de negocios. Los Artefactos típicos de esta disciplina incluyen mapas de capacidad ó diagrama de dirección empresa, estrategias de integración y de TI, los principios de la Arquitectura, análisis de ciclo de vida y de deficiencias, los mapas de participantes en las áreas de la organización.

B. Arquitecto del Negocio
Universidad Santiago de Cali, Programa Ingeniería de Sistemas
En este rol, el Arquitecto debe entender en detalle, como trabaja la organización, son pieza indispensable en el modelado de procesos de negocio, entienden el proceso desde lo particular, hasta el metamodelo del procesos, esto los lleva a entender cómo los Sistemas de Información apoyan al negocio y en conjunto con el Arquitecto de Empresa, sugieren mejoras. Su participación en cada proyecto es muy valiosa, pues su influencia puede garantizar que dichos proyectos entreguen beneficios para la organización. Un Arquitecto del Negocio, debe poseer un profundo conocimiento en temas de negocios, de modelado de procesos de negocio, de análisis de requerimientos, y de liderazgo. Los Artefactos típicos de este rol de la Arquitectura incluyen, los modelos de procesos de negocio, mapas de procesos, los casos de uso, modelos de información.

C. Arquitecto de la Solución
En este rol, el Arquitecto se basa en las necesidades del negocio, para diseñar las soluciones de TI. Necesidades que preferiblemente deben suplirse haciendo uso de las capacidades de TI y de los servicios de la organización ya existentes. Son los responsables de que las nuevas soluciones estén alineadas con los principios de la Arquitectura. Este Arquitecto debe poseer entonces un amplio conocimiento técnico, de infraestructura, de modelos de datos, de arquitecturas orientadas a servicios. Los Artefactos típicos del rol de Arquitecto de la Solución son los diagramas de aplicaciones, los mapas del sistema, las estrategias de integración, las interfaces técnicas y las de servicios.

D. Arquitecto de Software
El Arquitecto de Software, es un estricto guía en el desarrollo del software de la organización, define la estructura y el diseño del software. Es el responsable de que se cumplan los requisitos funcionales, y los no funcionales, como por ejemplo el rendimiento del software, su flexibilidad, usabilidad, reutilización y calidad. Por lo tanto este Arquitecto debe poseer un profundo conocimiento en programación, frameworks de desarrollo de software, y técnicas de modelado. Los Artefactos típicos del rol de Arquitecto de Software, son los Frameworks, Los diagramas de Clase, y los patrones.

Publicado en Conceptos de EA | 5 comentarios

Comunidades de Arquitectos de Empresa

Un Arquitecto de Empresa que pertenezca a una comunidad como sociedades profesionales, grupos de trabajo, foros, blogs y medios de redes sociales, tiene más oportunidades de crecer en su radio de conocimiento, pues podrá intercambiar información con diversas fuentes. Estas comunidades generalmente tienen por razón de ser satisfacer las diversas necesidades de la profesión, y del profesional, orientándose generalmente educación, formación, certificación y establecimiento de grupos. Para pertenecer a estas comunidades el Arquitecto de Empresa no necesariamente debe ser un experto en la materia, por el contrario una vez empiece a ejercer la práctica, es recomendable que se incluya en una de estas comunidades. A continuación se citamo algunas de las comunidades de Arquitectos y de Arquitectos de Empresa más reconocidas:


MSDN Forum on Architecture

The Open Group Architecture Forum
Grady Booch Blog
Blogs by Microsoft Architects
Global Enterprise Architecture Organization
The Center of Advancement of the Enterprise Architecture Profession CAEAP

Publicado en Excelentes Enlaces! | 1 Comentario

Capgemini!

Hola ya está disponible en la página de EA Frameworks información acerca del Framework de Arquitecturas Empresariales de Capgemini
Quiero visitar la página en este momento!!

Publicado en Anuncios | Deja un comentario

Herramienta free para modelar procesos de negocio!

Les recomiendo que visiten el sitio www.bizagi.com, allí podrán descargar el bizagi modeler free, es una herramienta sencilla e intuitiva que les permitirá modelar procesos de negocios, además allí también podrán encontrar tutoriales de la herramienta!

Publicado en Anuncios | 4 comentarios

City One!!

Para que empiecen a desarrollar sus habilidades de Arquitectos, los invito a que prueben el juego City One de IBM, aquí les dejo el Trailer del juego, lo pueden descargar desde la página de IBM.

Publicado en Anuncios | 2 comentarios

Entregables de la Arquitectura Empresarial!

Visiten nuestra zona de enlaces, hemos publicado un nuevo enlace, que los llevará a la página de la Universidad de Syracusa, en donde han publicado la documentación de su Arquitectura Empresarial!…está Excelente!!!
Quiero visitar el enlace!!

Publicado en Excelentes Enlaces! | Deja un comentario

TOGAF y Zachman

Para que conozcas acerca de las diferencias entre las versiones 8 y 9 de TOGAF, además de las diferencias más generales entre TOGAF y Zachman te invitamos leer nuestro último ensayo, vista la página Ensayos de este Blog!!
Quiero leer el ensayo en este momento!!

Publicado en Anuncios | 1 Comentario

SAP EA Framework

Visita nuestra página de EA Frameworks, hemos publicado información a cerca del SAP EA Framework!!!
Quiero visitar la página en este momento!!

Publicado en Anuncios | 1 Comentario

Qué es BPMN??

Business Process Modeling Notation [1] o Notación para el Modelado de Procesos de Negocio, es una notación gráfica desarrollada por la OMG (Object Management Group/Business Process Management Initiative) que muestra los pasos de un proceso de negocio. BPMN representa el extremo a extremo de un proceso de negocio. La notación ha sido diseñada específicamente para coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes del mismo, con un conjunto de actividades relacionadas.


Diagrama de proceso de negocio con BPMN

¿Por qué BPMN es importante?

El mundo de los procesos de negocio ha cambiado dramáticamente en los últimos años. Un proceso de negocio ahora se extiende por varios participantes y la coordinación puede ser compleja. BPMN ha sido desarrollada para proporcionar a los usuarios con una notación libre, beneficiando a los usuarios de una manera similar en que lo ha hecho el estándar UML en el mundo de la ingeniería de software. Existen cursos de capacitación, libros y un cuerpo de conocimiento que los usuarios pueden acceder con el fin de aplicar mejor un proceso de negocio.

¿A quién está dirigida BPMN?

BPMN está dirigido a un alto nivel de usuarios de negocio y a los ejecutores del proceso. Los usuarios de negocios deben ser capaz de leer y comprender fácilmente un proceso de negocio a través del diagrama BPMN. El ejecutor del proceso debe ser capaz de representar el proceso en una implementación física.
BPMN entonces está dirigido a usuarios, proveedores y prestadores de servicios que lo necesitan para comunicar los procesos de negocio de una manera estándar.

Elementos de BPMN

El modelado en BPMN se realiza mediante diagramas muy simples con un conjunto muy pequeño de elementos gráficos. Con esto se busca que para los usuarios del negocio y los desarrolladores técnicos sea fácil entender el flujo y el proceso. Las cuatro categorías básicas de elementos son:

* Objetos de flujo: Eventos, Actividades, Rombos de control de flujo (Gateways)
* Objetos de conexión: Flujo de Secuencia, Flujo de Mensaje, Asociación
* Swimlanes (Carriles de piscina): Pool, Lane
* Artefactos: Objetos de Datos, Grupo, Anotación

Estas cuatro categorías de elementos nos dan la oportunidad de realizar un diagrama simple de procesos de negocio (en inglés Business Process Diagram o BPD). En un BPD se permite definir un tipo personalizado de Objeto de Flujo o un Artefacto, si con ello se hace el diagrama más comprensible.

¿Qué significa esto para los usuarios de UML?

El Lenguaje Unificado de Modelado (UML) adopta un enfoque orientado a objetos para el modelado de aplicaciones, mientras que BPMN toma un enfoque orientado al proceso de modelado de sistemas.
Cuando BPMN tiene un enfoque en los procesos de negocio, UML se enfoca en el diseño de software y por lo tanto las dos anotaciones no están compitiendo, pero son puntos de vista diferentes sobre los sistemas.
BPMN y UML son compatibles entre sí. Un modelo de proceso de negocio no necesariamente tiene que ser implementado como un proceso de negocio automatizado en un lenguaje de ejecución del proceso. Cuando este es el caso, los procesos de negocio y los participantes se pueden asignar a las construcciones, tales como casos de uso y modelos de comportamiento en UML.

¿Cuál es la relación entre BPMN y BPEL?

BPEL es un lenguaje basado en XML para describir un proceso de negocio en el que la mayor parte de las tareas representan las interacciones entre los procesos y servicios web externos. El proceso BPEL mismo se representa como un servicio Web, y se realiza por un motor BPEL que ejecuta la descripción del proceso. BPMN es un conjunto estándar de diagramación de las convenciones para la descripción de los procesos de negocio. Está diseñado para visualizar un rico conjunto de la semántica de flujo del proceso dentro de un proceso y la comunicación entre procesos independientes. Su objetivo es apoyar la captura de detalle suficiente para permitir que sea la fuente de una descripción del proceso ejecutable. BPEL Actualmente se considera la norma más importante para la ejecución de lenguajes, la traducción de BPEL se especifica en el estándar BPMN. Por su diseño hay algunas limitaciones en las topologías de proceso que puede ser descrito en BPEL, así que es posible representar los procesos en BPMN que no se pueden asignar a BPEL. Hay algunos conceptos, tales como sub Ad-Hoc-procesos, que BPMN puede representar que no puede aplicarse con cualquier tecnología.
http://www.bpmn.org/

Publicado en Procesos de Negocio | 1 Comentario

DEMO SOA WEBSPHEERE IBM

Les recomiendo ver este video de SMART SOA de IBM, a traves de este visualizaran por medio de un ejemplo los beneficios que conlleva la implementacion de SOA dentro de las organizaciones

Publicado en SOA | 1 Comentario

SOA Arquitectura Orientada a Servicios

Service Oriented Architecture SOA [1] es un modelo de componente que interrelaciona unidades funcionales diferentes de una aplicación, denominado servicios, a través de interfaces y contratos bien definidos entre estos servicios. La interfaz se define de una manera neutral que debe ser independiente de la plataforma de hardware, del sistema operativo y del lenguaje de programación en los que se implemente el servicio. Esto permite que los servicios, construidos en una variedad de tales sistemas, interactúen entre sí de una manera uniforme y universal.
Esta característica de tener una definición de interfaz neutral que no esté fuertemente sujeta a una implementación en particular se conoce como loose coupling entre los servicios. El beneficio de un sistema sueltamente acoplado es su agilidad y capacidad para sobrevivir a cambios evolutivos en la estructura e implementación de las partes internas de cada servicio que compone toda la aplicación. Por otra parte, tight-coupling significa que las interfaces entre los diferentes componentes de una aplicación están estrechamente interrelacionados en función y forma, haciendo que sean frágiles cuando se requiera alguna forma de cambio en partes de la aplicación o en toda la misma.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes:
– XML – HTTP
– SOAP – WSDL – UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser “orientado a servicios” pero es altamente recomendable su uso.

Tabla 1. Terminología SOA

Capas de SOA
Esta arquitectura en capas parcialmente muestra cómo los servicios están alineados con los procesos de negocio, mientras que los componentes de la empresa entregan los servicios. Los procesos de negocio pueden ser apoyados por la orquestación de los servicios expuestos en las aplicaciones compuestas. Esta arquitectura se apoya en varias capas verticales, incluyendo:
– Una capa de infraestructura que es comúnmente conocido como Bus de Servicios Empresariales (ESB).
– Una capa de control y gestión para garantizar la calidad del servicio y para lograr los requisitos no funcionales.
– Una capa de arquitectura de datos.
– Una capa de gobierno

Figura 9. Capas de SOA

Similitudes y Diferencias entre SOA y EA

Parecería entonces que SOA y EA son lo mismo, porque las dos buscan alinear objetivos, tiene unas capas unos dominios, pero en realidad, son diferentes, y trabajan de la mano. A continuación se resumen las similitudes y diferencias al considerar los conceptos de la arquitectura, tanto en SOA y EA:

SIMILITUDES

Dominios de SOA y EA comparten muchas similitudes. Por ejemplo:
– Tanto la dirección arquitectónica dominios similares.
– Ambos están destinados a TI a alinear estrechamente con las empresas.
– Tanto la entrada uso basado en los objetivos de negocio.
– Ambos requieren estrategias similares y las actividades de planificación.

DIFERENCIAS:

– Mientras que el enfoque de los dominios de la arquitectura de EA está en el nivel macro, los dominios de la arquitectura SOA de trabajo a nivel micro. Más específicamente: EA se centra en la definición de componentes de negocio, mientras que SOA se centra en los servicios empresariales.
– EA se ocupa de los entornos de aplicaciones y aplicaciones empresariales, mientras que el alcance de SOA es en el modelado de servicio.
– EA se ocupa de la infraestructura a nivel de empresa, incluyendo servidores, bases de datos, y así sucesivamente, mientras que SOA se centra en la infraestructura que soporta los servicios, a saber, el Bus de Servicios Empresariales.
– Las direcciones de EA patrones de integración empresarial y cuándo deben ser utilizados, incluyendo la integración punto a punto, la transferencia de archivos, y otros métodos tradicionales de integración de aplicaciones. SOA proporciona un enfoque de integración basado en el uso de los servicios. Aunque el enfoque de SOA para la integración puede llegar a ser el enfoque más flexible y recomendó, debe considerarlo como uno de los planteamientos de EA tiene que definir y apoyo.

Tabla 2. Dominios SOA vs EA

Es obvio entonces que los dominios de SOA son un subconjunto de los dominios de EA. Por ejemplo, SOA no tiene que ver con el desarrollo de la arquitectura empresarial. En su lugar, utiliza los resultados de los procesos de negocio y otros artefactos de la arquitectura empresarial, como componente de modelado de negocio (CBM), como insumo para identificar los servicios empresariales. Por el contrario, EA tiene que ver con el desarrollo de la arquitectura de negocios, incluyendo los procesos de negocio y CBM entre otros. Del mismo modo, desde el punto de vista de arquitectura de aplicaciones, SOA tiene que ver con el modelado y desarrollo de servicios y los componentes que se tienen, mientras que la arquitectura de EA no sólo tiene que ver con SOA, sino también con otros componentes, paquetes y sistemas de toda la empresa.

En el siguiente link, podrá encontrar Demos, a cerca de los beneficios de SOA:
http://www-03.ibm.com/e-business/la/co/download/videos/popup_stream.shtml


[1] http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/?S_TACT=105AGX22&S_
CMP=ISSUE

Publicado en SOA | 3 comentarios