Ingeniera de Sistemas y Arquitectura Empresarial

Dave Brown, Staff, IBM, Software Group Peter Bahrs, PhD, Distinguished Engineer, IBM, Software Group 01-06-2009 extraido de The Rational Edge: Aprenda con dos expertos reconocidos sobre los puntos en comn clave que comparten la arquitectura empresarial y la arquitectura de sistemas, y cmo la arquitectura empresarial influencia y a la vez restringe el desarrollo de sistemas en general y de los sistemas de informacin en particular. Nota del Traductor: Hay que entender la referencia a Sistemas en su acepcin generalizada, amplia, dentro del campo de la Ingeniera de Sistemas, sin embargo, puede entenderse en el contexto de una visin holstica que los informticos deben darle a una solucin completa y total corporativa, no a uno solo de los componentes de la misma. En este aspecto la Arquitectura Empresarial provee un marco apropiado, acorde a lo que aspira la Ingeniera de Sistemas en las Organizaciones. De The Rational Edge. 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 artculo explora los puntos de conexin que existen entre la arquitectura empresarial y la arquitectura de sistemas, y describe cmo 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 cmo 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 relacin 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 estn dejando de lado los sistemas separados que brindan funcionalidad aislada, para adoptar sistemas mucho ms integrados en los cuales se potencian los servicios para ofrecer operaciones robustas y eficientes. Por lo tanto, los sistemas dentro de la empresa estn ms estrechamente integrados y los esfuerzos por modificarlos son ms 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 tambin debe comprender cmo interacta el sistema con otros sistemas dentro de la empresa. La Figura 1 ofrece una descripcin general de este cambio de foco. Anteriormente la arquitectura empresarial contaba con el soporte de sistemas separados independientes. Haba un discreto distanciamiento entre la arquitectura empresarial y los ingenieros de sistemas, con sus problemas afines. Hoy en da el desarrollo de sistemas se basa mucho ms en los negocios. Hay una fuerte necesidad de responsabilidad financiera y los gastos en dichos sistemas y stos deben ajustarse a su beneficio comercial. Por ello, la alineacin entre negocio y desarrollo es crucial. Hay una participacin constante entre el arquitecto empresarial y el ingeniero de sistemas que conduce a una mayor alineacin negocio con soluciones implantadas y colabora con la gobernabilidad tcnica en todo el ciclo de vida de dichos sistemas, los arquitectos empresariales participan durante ms tiempo y los ingenieros de sistemas se involucran mucho antes. Por ltimo, los servicios implementados soportan la obtencin y el monitoreo durante la operacin. El anlisis de este intercambio impulsa cambios futuros.

Figura 1: Alineacin de arquitectura e ingeniera al inicio del ciclo de vida

Definiciones
Al hablar sobre sistemas en diferentes niveles es importante definir explcitamente trminos que de otra manera seran ambiguos dada la diversidad de significados y usos existentes.

Empresa
Una definicin de empresa es una organizacin de negocios. La organizacin podra ser parte de una compaa, una compaa entera o incluso una participacin en varias compaas. Para simplificar el tema, pensemos en una empresa como una compaa. Aunque hay una gran cantidad de maneras de analizar una empresa, con el fin de razonar acerca de la evolucin de una empresa, es til considerarla como un sistema a gran escala. Como sistema: a) b) c) d) tiene una razn de ser, ya que brinda ciertos valores a quienes se involucran en ella; posee una financiacin que le permite operar; realiza algunas acciones, cumpliendo con una serie de requisitos; y est integrada por componentes, trabajadores y sistemas de menor nivel, que colaboran para que logre su funcionalidad. (A lo largo de este artculo, el trmino 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 trmino arquitectura empresarial aparece en maysculas 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 descripcin de la arquitectura de la empresa en cuestin. La disciplina de la Arquitectura Empresarial ana negocio, estrategia, proceso, mtodo y componentes desde una cantidad de perspectivas diferentes. Estas perspectivas estn definidas y varan segn 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 propsito de un arquitecto empresarial, segn se define en este artculo, es describir los componentes de una empresa, sus relaciones, cmo colaboran e interactan entre s con el mundo exterior. Una arquitectura empresarial ofrece la orientacin para implantar los componentes de la empresa. La implantacin de los componentes produce un cambio en el estado de la empresa.

Sistema
Un sistema es un grupo de componentes que forman un todo unificado y cumplen un fin comn. El fin comn es la razn de ser del sistema. Uno o ms 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 tambin cmo 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 colaboracin de estos componentes. Cabe destacar que los componentes pueden ser cualquier cosa: procesos, productos, planes, 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 tambin pueden considerarse sistemas, segn lo descripto anteriormente, no los tratamos as, sino como objetos constitutivos ya que no nos incumbe aqu cmo colaboran sus partes internamente.

Ingeniero de Sistemas
El ttulo de Ingeniero de Sistemas se ha aplicado a individuos que desarrollan cualquier actividad vinculada con la ingeniera de sistemas. Hemos observado Ingenieros de Sistemas responsables de todo, desde planeamiento, hasta obtencin de requisitos, captura de arquitectura, integracin y testeo. Muchas de sus actividades trascienden la disciplina tradicional de un mero integrador. En este artculo, nos focalizamos en el rol del ingeniero de sistemas para garantizar que el resultado del esfuerzo de desarrollo se ajustar toda la empresa y operar de manera homognea. 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 propsito 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 implementacin de uno o varios (normalmente varios) proyectos. Obsrvese que los programas pueden tener un alcance mucho menor que el de toda la empresa. Sin embargo, para simplificar el tema a tratar aqu, slo expondremos los programas que impactan sobre toda la empresa.

Proyecto
Un proyecto es una actividad de desarrollo con un objetivo, inicio y fin especficos, focalizado en brindar algn resultado de valor mensurable que contribuya con una capacidad. Es comn que un proyecto se focalice en la introduccin de un sistema nuevo en la empresa, o la modificacin de un sistema existente, aunque su alcance podra 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: Cmo los programas y los proyectos afectan a la empresa

Descripcin 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. Adems de la arquitectura, la empresa tiene una serie de requisitos que debe cumplir. Tambin 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 edicin de algn componente de la empresa, se realizar una determinada cantidad de pruebas para garantizar que el componente cumpla con sus requisitos. Esto incluye que no dae cualquier funcionalidad de mayor nivel por la forma en que interacta con otros componentes. Si estas pruebas detectan algn problema, ste debe rastrearse como defectos de la empresa hasta tanto se resuelva. (El problema podra ser el componente recientemente emitido o un comportamiento inesperado de algn componente interviniente.) Por ello, observamos que estos artefactos, cuando existen y se combinan, forman una descripcin completa de elementos clave de la situacin actual de la empresa (ver la Figura 3):

Requisitos (y sus impulsores, como motivacin y objetivos) Arquitectura (incluyendo diseo e implementacin) Pruebas Defectos

Figura 3: Artefactos actuales de la empresa

Los programas cambian a la empresa

Segn lo definido anteriormente, el propsito 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. Slo 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 debern 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 despus 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 fcil 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 pequeas y pueden resolverse mediante tareas separadas para cerrar directamente las brechas. Para obtener una representacin completa y coherente de la empresa, todos los programas empresariales deben usar convenciones estndares para representar tanto los artefactos actuales, como los futuros (o por lo menos convertir sus artefactos de/a la convencin estndar), y efectivamente deben comenzar a construir en base a los artefactos creados por los programas anteriores. De lo contrario, ser muy difcil lograr la correlatividad entre los artefactos creados por diferentes programas y lograr una representacin nica coherente de la empresa. Adems, los artefactos actuales se deben conservar como un repositorio nico homogneo. No es importante cmo se construye el repositorio, es decir si es un archivo nico o una consolidacin de bases de datos. Lo importante es que se conserve y se puede acceder a l como una representacin consolidada coherente. Si (o una vez que) los artefactos actuales de la empresa estn 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, an cuando se informan inicialmente de manera informal o se perfeccionan ms 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 implantacin, 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 ilustracin del flujo de artefactos. (Obsrvese que, como es posible que varios programas se estn ejecutando simultneamente, en este momento la empresa puede implantar cambios adicionales fuera del alcance del programa. Estos cambios adicionales se fusionarn 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 (quizs mediante la adquisicin de una aplicacin nueva o cambiando algn 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 especfico 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 ms de un programa, esto es mucho menos frecuente y por lo tanto no nos referiremos a ello en este documento. Es ms frecuenta que los requisitos a nivel del programa se implanten a travs de varios sistemas. En estos casos, se crea un diseo a nivel del programa para mostrar cmo colaboran los sistemas. Este diseo asigna responsabilidades a cada uno de los sistemas involucrados. Las responsabilidades se ajustan a los roles que desempean en las colaboraciones. Este diseo 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 ilustracin 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. Segn lo descripto anteriormente para los artefactos actuales de la empresa, si estos artefactos no estn 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 homogneo 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 tambin ofrece actualizaciones de los artefactos de sistemas. Obsrvese 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 evolucin de la empresa y de los sistemas, incluyendo sus artefactos actuales, a travs de la ejecucin de programas y proyectos. Hay que admitir que esta es una visin simplificada, que asume slo 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 homogneamente a cada nivel de descomposicin 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 visin simplificada.

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

Conclusin
Algunas organizaciones ya han desarrollado prcticas para administrar sus artefactos actuales para los niveles de empresa y sistemas y estn cosechando los beneficios de potenciar estos artefactos. Otras recin estn comenzando y avizoran beneficios futuros. Sin embargo, el objetivo y el enfoque son iguales en todos los casos. Para administrar eficientemente la evolucin de la empresa, es necesario comprender sus requisitos y funcionalidad actuales y cmo logra esa funcionalidad (su arquitectura). Adems es necesario comprender si su desempeo actual es el correcto en trminos 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 organizacin siempre tiene una visin precisa del estado actual, es capaz de planificar eficientemente la evolucin de la empresa y reduce el esfuerzo total realizado, potenciando los artefactos en cada programa. An cuando sea poco prctico 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 visin precisa de la situacin actual, cada programa debe: a) b) crear una representacin del estado actual desde cero, examinando la empresa antes de avanzar con los trabajos del programa; intentar construir una representacin 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, slo para aprender dolorosamente que se necesita contar con una visin precisa del estado actual de la empresa para su correcto funcionamiento. Es igualmente cierto que las organizaciones se benefician ampliamente con la reutilizacin de artefactos a nivel de sus sistemas. Una empresa tiene muchos sistemas y por lo tanto los beneficios de la reutilizacin 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 comunicacin. Los beneficios de potenciar estos artefactos con cada proyecto nuevo incluyen: mayor homogeneidad, menos errores y menor esfuerzo general. Hemos ilustrado cmo la arquitectura de la empresa brinda la base para su evolucin mediante los programas. Los programas individuales y la organizacin toda se benefician al especificar el programa en trminos 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 slo 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 podrn ser precisos cuando se produzcan modificaciones futuras. Existe una serie de productos y mtodos para asistir al Arquitecto Empresarial y al Ingeniero de Sistemas a travs del ciclo de vida. Su eleccin depende del grado de complejidad del sistema, desde metodologas blandas hasta modelos cuantitativos y dinmicos. En cuanto a los mtodos, la Figura 8 ilustra algunos de los mtodos que IBM aplica a lo largo del ciclo de vida. Model Driven Systems Development Visin Estrategia Adquisiciones Requisitos Arquitectura Empresarial Arquitectura de Servicios Simulacin Arquitecturas Tcnicas Diseos Implantacin Pruebas Implementaciones *1 Slo para IBM Global Business Services Figura 8: Mtodos que soportan Arquitectos Empresariales e Ingenieros de Sistemas a lo largo del ciclo de vida La visin simplificada presentada en este artculo brinda una base de comprensin comn para toda la organizacin. Mediante la ilustracin clara de las relaciones que hemos descripto, los ingenieros de sistemas podrn comprender mejor cmo sus esfuerzos se ven limitados por o colaboran con la arquitectura general de la empresa. Adems, hemos ilustrado la relacin directa entre la capacidad de negocios de la empresa y la funcionalidad implementada en los proyectos. Service-Oriented Modeling and Architecture *1 Component Global Business Modeling Services *1 Method *1

Temas avanzados
Hay algunos temas secundarios que merecen ser mencionados, pero cuyo desarrollo completo excede el alcance de este artculo:

Arquitectura orientada a servicios (SOA): Al establecer los artefactos actuales de la empresa y la arquitectura en particular, permite comprender mejor el uso de servicios comunes en toda la empresa. Por consiguiente, es ms fcil analizar la arquitectura y definir los programas para implantar SOA. Desarrollo distribuido: Al articular los tipos y las relaciones de artefactos entre programas y proyectos, permite comprender mejor la asignacin de responsabilidades y los criterios con los que deben cumplir. Esto permite distribuir eficientemente las responsabilidades dispersas geogrficamente en centros de desarrollo, dentro y fuera de la empresa. Entorno estndar: aunque no se requiera, un entorno estndar (proceso y herramientas de desarrollo en comn, gestin de cambios, gestin de configuraciones y obtencin e informes de mtricas) se puede usar en todos los proyectos y programas, con lo cual se obtienen beneficios adicionales. Adems, el entorno en comn soportar la representacin comn requerida para los artefactos en todos los programas.

Reconocimientos
Agradecemos a Ernest Vogel, Cindy VanEpps y Arvind Sathi por su aporte en la creacin del flujo de artefactos original. Adems, las siguientes personas han mejorado la calidad de este artculo mediante sus comentarios: Pete Eeles, Jos Jennekens, Jim Densmore y Fred Mervine.

Notas
1. 2. Webster's Ninth New Collegiate Dictionary, 1985 Merriam-Webster Inc., ISBN 0-87779509-6. ibid.

Recursos para los Ingenieros que se aplican propiamente en el campo de la Informtica

Aprender

Conozca ms acerca de otras aplicaciones en IBM Rational Software Delivery Platform, que incluye herramientas de ayuda para desarrollo paralelo y equipos dispersos geogrficamente, adems de software especializado en gestin de arquitectura, gestin de activos, gestin de cambios y versiones, gestin integrada de requisitos, gestin de procesos y carteras y gestin de calidad. Visite el rea de software Rational en developerWorks para consultar sobre recursos tcnicos y mejores prcticas para productos de Rational Software Delivery Platform. Navegue por cursos online de Rational basados en computadora, basados en Internet y guiados por instructores. Perfeccione sus habilidades y aprenda ms acerca de las herramientas de Rational con estos cursos, que van de nivel introductorio a avanzado. Los cursos en este catlogo se pueden comprar a travs de capacitacin basada en computadora o basada en Internet. Adems hay algunos cursos introductorios sin cargo.

Suscrbase a Rational Edge newsletter para obtener artculos sobre los conceptos que sustentan el desarrollo eficiente de software. Suscrbase a IBM developerWorks newsletter, una actualizacin semanal de los mejores tutoriales, artculos, descargas, actividades comunitarias, transmisiones por Internet y eventos de developerWorks. Navegue por la biblioteca de tecnologa de IBM para consultar los libros referidos a stos y otros temas.

Obtener los productos y tecnologas

Descargue versiones de prueba de software IBM Rational. Descargue versiones de evaluacin de productos IBM y comience a usar las herramientas de desarrollo de aplicaciones y productos middleware de DB2, Lotus, Tivoli, y WebSphere.

Comentar

Consulte blogs de developerWorks y participe endeveloperWorks community.

Sobre los autores

Dave Brown es Principal Solution Architect en la organizacin de servicios IBM Rational. Ejerce un cargo en el equipo internacional de Solution Delivery Assurance, dando asesoramiento al personal tcnico de Rational sobre los contratos ms estratgicos con clientes. Fue lder mundial de Solution Architecture Community of Practice para la marca Rational Software de IBM. Dave ha sido consultor de Rational desde 1997, especializndose en arquitectura y proceso de software y sistemas. Anteriormente. Dave particip en todos los aspectos del ciclo de vida del desarrollo de software durante sus diecisiete aos de carrera en TRW.

El Dr. Peter C. Bahrs es un distinguido ingeniero de IBM, Senior Certified IT Architect, Master Inventor, miembro de la Academia de Tecnologa de IBM, y CTO de Government Solutions en IBM. Tiene 20 aos de experiencia en la industria de TI. Peter lider la Integrated Modeling and Management Solution for Enterprise Architecture de IBM, es codirector de la Conferencia Anual de la Academia de IBM sobre lecciones aprendidas y mejores prcticas en la implementacin de SOA. Colabor en Network Centric Operations Industry Consortium, OMG, IEEE y Open Travel Alliance. Entre los clientes de Peter se encuentran la Oficina de Aduanas de los EUA, la Marina de los EUA, UBS AG, USAA, Grupo KBC, Northrop Grumman, Medco y CIBC. Peter posee una amplia experiencia en Arquitectura Empresarial, Ingeniera de Sistemas y transformaciones de TI en gran escala.