 | Nivel: Introductoria 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 común clave que comparten la arquitectura empresarial y la arquitectura de
sistemas, y cómo la arquitectura empresarial influencia y a la vez restringe el
desarrollo de sistemas.
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 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.
IBM®ofrece una serie de productos y métodos para asistir al Arquitecto
Empresarial y al Ingeniero de Sistemas a través del ciclo de vida. Si usted desea
conocer más acerca de estos productos específicos, este
vínculo es un bueno comienzo. En cuanto a los métodos, la Figura 8 ilustra
algunos de los métodos que se aplican a lo largo del ciclo de vida.
| Model Driven Systems Development | Service-Oriented Modeling and Architecture *1 | Component Business Modeling *1 | IBM Global Services Method *1 | | Visión | | | | | | Estrategia | | | | | | Adquisiciones | | | | | | Requisitos | | | | | | Arquitectura Empresarial | | | | | | Arquitectura de Servicios | | | | | | Simulación | | | | | | Arquitecturas Técnicas | | | | | | Diseños | | | | | | Implantación | | | | | | Pruebas | | | | | | Implementaciones | | | | | | *1 Sólo para IBM Global
Business Services |
Figura 8: Métodos que soportan Arquitectos Empresariales e Ingenieros de Sistemas
a lo largo del ciclo de vida
La visión simplificada presentada en este artículo brinda una base de comprensión
común para toda la organización. Mediante la ilustración clara de las relaciones que
hemos descripto, los ingenieros de sistemas podrán comprender mejor cómo sus
esfuerzos se ven limitados por o colaboran con la arquitectura general de la
empresa. Además, hemos ilustrado la relación directa entre la capacidad de negocios
de la empresa y la funcionalidad implementada en los proyectos.
Temas avanzados
Hay algunos temas secundarios que merecen ser mencionados, pero cuyo desarrollo
completo excede el alcance de este artículo:
- 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 más fácil 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 asignación de
responsabilidades y los criterios con los que deben cumplir. Esto permite
distribuir eficientemente las responsabilidades dispersas geográficamente en
centros de desarrollo, dentro y fuera de la empresa.
- Entorno estándar: aunque no se requiera, un entorno estándar (proceso y
herramientas de desarrollo en común, gestión de cambios, gestión de
configuraciones y obtención e informes de métricas) se puede usar en todos los
proyectos y programas, con lo cual se obtienen beneficios adicionales. Además,
el entorno en común soportará la representación común requerida para los
artefactos en todos los programas.
 |
Reconocimientos
Agradecemos a Ernest Vogel, Cindy VanEpps y Arvind Sathi por su aporte en la creación
del flujo de artefactos original. Además, las siguientes personas han mejorado la
calidad de este artículo mediante sus comentarios: Pete Eeles, Jos Jennekens, Jim
Densmore y Fred Mervine.
Notas
- Webster's Ninth New Collegiate Dictionary, 1985 Merriam-Webster Inc., ISBN
0-87779-509-6.
- ibid.
Recursos Aprender
- Conozca más acerca de otras aplicaciones en IBM Rational Software Delivery Platform,
que incluye herramientas de ayuda para desarrollo paralelo y equipos dispersos
geográficamente, además de software especializado en gestión de arquitectura,
gestión de activos, gestión de cambios y versiones, gestión integrada de requisitos,
gestión de procesos y carteras y gestión de calidad.
- Visite el área de software Rational en
developerWorks para consultar sobre recursos técnicos y mejores prácticas 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 más acerca de las herramientas de Rational con estos cursos,
que van de nivel introductorio a avanzado. Los cursos en este catálogo se pueden
comprar a través de capacitación basada en computadora o basada en Internet. Además
hay algunos cursos introductorios sin cargo.
- Suscríbase a Rational Edge newsletter para obtener
artículos sobre los conceptos que sustentan el desarrollo eficiente de
software.
- Suscríbase a IBM developerWorks newsletter, una
actualización semanal de los mejores tutoriales, artículos, descargas, actividades
comunitarias, transmisiones por Internet y eventos de developerWorks.
- Navegue por la biblioteca de tecnología para consultar
los libros referidos a éstos y otros temas.
Obtener los productos y tecnologías
Comentar
Sobre los autores | 
| | Dave Brown es Principal Solution Architect en la organización de servicios IBM
Rational®. Ejerce un cargo en el equipo internacional de Solution Delivery
Assurance, dando asesoramiento al personal técnico de Rational sobre los contratos
más estratégicos con clientes. Fue líder mundial de Solution Architecture Community
of Practice para la marca Rational Software de IBM. Dave ha sido consultor de Rational desde 1997, especializándose 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 años 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 Tecnología de IBM, y CTO de
Government Solutions en IBM. Tiene 20 años 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 prácticas en la implementación 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,
Ingeniería de Sistemas y transformaciones de TI en gran escala. |
Evalúe esta pagina
| |
