Documente Academic
Documente Profesional
Documente Cultură
Contenidos
Prlogo
Por Simon Guest
Las empresas de hoy en da se dan cuenta del potencial que tiene automatizar sus procesos de negocio. Averige sobre la gestin de procesos de negocio de alto nivel a travs de la analoga de un juego de un show televisivo basado en la realidad.
16
Existen dos componentes de sistemas de flujo de trabajo humano y patrones representativos de interacciones de procesos entre las personas y las actividades empresariales. Descubra la forma de aplicar estos componentes para implementar estos procesos.
19
La integracin de aplicaciones es uno de los mayores desafos que enfrentan los arquitectos en la actualidad. Analice brevemente un sistema para la integracin de una aplicacin por medio del uso de herramientas tales como tecnologas de flujo de trabajo.
24
El diseo efectivo de flujos de trabajo requiere diversas tcnicas que hacen que el flujo de trabajo sea un desafo an para los arquitectos ms expertos. Aprenda un mtodo para simplificar el proceso de diseo de sistemas complejos utilizando un nuevo tipo de diagramacin.
27
Si bien construir varios servicios de Web puede ser difcil, administrarlos puede ser realmente difcil. Explore el uso de un modelo que puede ayudarlo a planear capacidades para una empresa habilitada para la prestacin de servicios.
33
Los arquitectos desean identificar los artefactos de forma adecuada y en el nivel de abstraccin correcto. Verifique en esta primera parte de una serie de dos artculos un enfoque para modelar sistemas conectados, orientados al servicio que fomenta una alineacin estrecha entre las soluciones IT y las necesidades del negocio.
Recursos
Fundador Arvindra Sehmi Microsoft Corporation Jefe Editor Simon Guest Microsoft Corporation Consejo Editorial de Microsoft Gianpaolo Carraro John deVadoss Neil Hutson Eugenio Pace Javed Sikander Philip Teale Jon Tobey Editor Comercial Marty Collins Microsoft Corporation Diseo, Impresin y Distribucin: Publicaciones Tcnicas Fawcette Jeff Hadfield, VP de Publicacin Terrence ODonnell, Editor Gerente Michael Hollister, VP de Arte y produccin Karen Koenen, Director de Circulacin Brian Rogers, Director de Arte Kathleen Sweeney Cygnarowicz, Gerente de Produccin
Prlogo
Estimado arquitecto:
Recuerdo bien esa maana. El da estaba despejado y fro, y yo estaba en las oficinas de Microsoft, en Londres, sentado con Arvindra Sehmi mientras me explicaba su visin y me mostraba uno de los primeros magnficos prototipos del Journal. Como bien sabr, desde esa maana en adelante el Journal ha ido cada vez mejor. Usted est leyendo la 7ma edicin del Journal, que llega a 30.000 abonados en todo el mundo tanto en su formato impreso como en su formato online a travs de nuestra nueva pgina, ArchitectureJournal.net que se lanz el mes pasado. Mientras charlaba con Vin, nunca imagin que tres aos despus yo iba a tener el honor de asumir la responsabilidad como editor de la revista. Si bien no hay cambios importantes en el formato, como editor tengo planeado introducir algunas nuevas directivas para The Architecture Journal. Primero y en base a la creciente suscripcin, traduciremos esta revista en ocho idiomas para todo el mundo. Si usted est leyendo esta edicin en otro idioma que no es el ingls, me gustara ser el primero en darle la bienvenida a este nuevo formato y espero que se establezca como una tendencia continua. Segundo, a partir de esta edicin, avanzaremos hacia un enfoque temtico en el que la mayora de los artculos de cada edicin siguen un patrn o tema en comn. Como ya habr visto en la tapa, el tema de esta edicin es Flujo de Trabajo Generacional. Para comenzar con el tema, empezamos con un artculo de Dave Green, arquitecto de nuestro producto Windows Workflow Foundation (WF). Dave comparte las decisiones y razonamientos que enfrent su equipo al construir una plataforma de flujo de trabajo, que en ltima instancia, dieron forma al producto que estn creando. Luego tenemos a Vignesh Swaminathan, gerente de producto en CORDES R&D. En su artculo, Vignesh lo llevar por una Amazing Race y analizar las similitudes entre las matrices de decisiones para el flujo de trabajo en una empresa y un show televisivo popular. Para agregarle un toque humano al Journal, Jesus Rodrguez y Javier Mariscal tratarn los componentes principales de los sistemas de flujo de trabajo humano y describirn los patrones que pueden utilizarse para modelar las tareas relacionadas con las personas. Para conectar todas estas piezas, Kevin Francis analizar la integracin de aplicaciones con un flujo de trabajo en su artculo El Flujo de trabajo en la integracin de aplicaciones. Y para completar el conjunto de artculos sobre flujo de trabajo de esta edicin, Andrew Needleman nos mostrar la tcnica que utiliza para simplificar el proceso de comunicacin de los flujos de trabajo complejos con los expertos de negocios denominada puntos y lneas. Siguiendo los artculos sobre flujo de trabajo, tenemos la suerte de contar con el artculo de William Oellermann sobre el Maduracin de Orientacin al Servicio para Empresas (ESOMM), un modelo de maduracin que analiza la gestin de servicios en la empresa. Finalmente, para cerrar esta edicin, hemos decidido no perdonar a Arvindra completamente y l regresa junto con Beat Schwegler para ofrecernos la Primera Parte de un excelente anlisis de la Modelacin orientada al servicio para sistemas conectados. La segunda parte se publicar en la 8va edicin de este Journal. En trminos generales, ha sido una gran experiencia organizar mi primer ejemplar, y espero que encuentre los artculos tiles y que lo inviten a la reflexin. Como nuevo editor, una vez ms me gustara darle la bienvenida y espero pronto tener noticias de varios de ustedes.
La informacin contenida en la revista The Best of the Microsoft Arquitecture Journal (Journal) se brinda slo con fines informativos. El material publicado en el Journal no constituye la opinin o asesoramiento de Microsoft y no debe basarse en ningn tipo de material publicado en ella sin antes buscar asesoramiento independiente. Microsoft no provee garanta o representacin alguna respecto a la precisin o aptitud de los fines de cualquier material del Journal y en ningn caso Microsoft acepta responsabilidad de ningn tipo, incluyendo responsabilidad por culpa (excepto por dao contra los derechos personales del individuo o fallecimiento), por cualquier tipo de daos o perjuicios o prdidas (incluyendo, sin limitacin, prdida del negocio, rdito, ganancias o prdida consiguiente) de cualquier ndole o naturaleza que resultare del uso del presente Journal. El Journal puede contener imprecisiones tcnicas y errores de tipografa. El Journal se actualizar de vez en cuando y podr otras veces estar desactualizado. Microsoft no acepta responsabilidad alguna por mantener la informacin de este Journal actualizada ni por el incumplimiento del hecho. Este Journal contiene material propuesto y creado por terceros. Hasta el alcance mximo permitido por la ley aplicable Microsoft excluye toda responsabilidad por cualquier acto ilegal que surgiera de un error, omisin o imprecisin en este Journal y Microsoft no se responsabiliza del material suministrado por terceros. Todos los derechos del autor, marcas registradas y cualquier otro tipo de propiedad intelectual del material contenido en el Journal pertenecen y son licencia exclusiva de Microsoft Corporation. Queda totalmente prohibida la copia, reproduccin, transmisin, almacenamiento, adaptacin o modificacin de la forma o contenido del presente Journal sin previo consentimiento por escrito por parte de Microsoft Corporation y los autores individuales. 2005 Microsoft Corporation. Todos los derechos reservados.
Simon Guest
THE ARCHITECTURE JOURNAL Journal 7 www.architecturejournal.net 1
Sntesis Un flujo de trabajo puede ser muy til para resolver problemas de negocios. Aqu investigaremos y nos familiarizaremos con la idea de construir aplicaciones sobre una plataforma de flujo de trabajo. sta plataforma admite conceptos claves y proporciona la base para construir aplicaciones estructuradas utilizando estos conceptos, incluyendo los productos de flujo de trabajo, hasta ahora comprendidos. Estudiaremos una variedad de aplicaciones para explorar las caractersticas necesarias de esta plataforma lo que conduce a un anlisis de los beneficios potenciales al construir aplicaciones sobre una plataforma de flujo de trabajo. Tambin analizaremos Windows Workflow Foundation como un medio para poner en prctica estos beneficios.
La nocin de flujo de trabajo existe desde hace mucho tiempo y ha sido conveniente constantemente como una forma de combatir problemas del negocio. Los problemas a los que se les ha aplicado un mtodo de flujo de trabajo, por lo general, han mostrado tres caractersticas: el valor clave de negocios que proporciona es la coordinacin, por ejemplo, al organizar contribuciones mltiples para la preparacin de un presupuesto o para orientar la revisin de un documento. Cada instancia del proceso de negocios afectado posee una duracin extensa, que por lo general se mide en das, semanas o meses, ms que en minutos. El proceso de negocios posee participantes humanos, quienes generalmente contribuyen con la mayor parte del producto de trabajo. Sin embargo, slo una pequea cantidad de los problemas de negocios que poseen estas caractersticas pueden resolverse aplicando un enfoque de flujo de trabajo. Con frecuencia, el proceso de negocios no se registra en absoluto como informacin que puedan leer las mquinas. Sino ms bien que cada persona que participa en el proceso de negocios interacta con los sistemas de negocios que no conocen las semnticas del proceso como un todo, como por ejemplo un sistema de informacin del cliente, y con otros participantes humanos por medio de canales de comunicacin del contenido neutral tales como correos electrnicos. Cada participante humano utiliza un modelo mental de su participacin en el proceso de negocios total para determinar su comportamiento. Las ventajas de crear un modelo del proceso de negocios que pueda ser ledo por una mquina, es decir, un flujo de trabajo, no son difciles de prever. Tres de los beneficios que puede proporcionar un flujo de trabajo son: introspeccin, monitoreo y optimizacin. Un conjunto de flujos de trabajo relacionados puede utilizarse para lograr la introspeccin dentro del flujo de trabajo a travs de una organizacin. Para monitorear, es muy til saber qu individuos aportan trabajo a qu proceso de negocios cuando se tratan de comprender los costos y trabajos
realizados. Para optimizar, contar con un modelo del trabajo que se emprende y poder utilizar el modelo para interpretar el comportamiento, posibilita el razonamiento acerca de la forma de optimizar el proceso del negocio. Modelo de flujo de trabajo Dados estos beneficios convincentes, Por qu los modelos de flujo de trabajo no se han utilizado de forma ms general? La respuesta ms probable sera que el costo de su uso ha sido muy alto. Estos costos incluyen costos del producto, es decir, el costo directo de la adquisicin de un producto de flujo de trabajo; costos de integracin, en los que los procesos modelados como flujos de trabajo necesitan ser integrados como parte de un sistema de negocios ms amplio y costos de estandarizacin, en los que resulta difcil para una gran organizacin estandarizar en base a una nica tecnologa de flujo de trabajo. Las variaciones en los productos de flujo de trabajo tambin indican que la portabilidad del modelo y las tcnicas representan problemas. Veamos la posibilidad de tratar estos problemas de bloqueo construyendo aplicaciones sobre una plataforma de flujo de trabajo que sea de bajo costo, ubicua, uniforme y de fcil integracin en las aplicaciones. Para ser claro, la idea no es reemplazar productos de flujo de trabajo. Ms bien, la hiptesis es que es til desviar soporte para algunos conceptos centrales del flujo de trabajo e implantarlos en una plataforma sobre la cual se puedan construir productos de flujo de trabajo y otras aplicaciones (Ver Figura 1). Un flujo de trabajo es un modelo, lo que implica una descripcin del comportamiento del negocio que puede ser leda por una mquina y no es cdigo. Ms adelante, analizaremos el significado y beneficios de este concepto en el contexto del valor de una plataforma de flujo de trabajo. Un modelo de flujo de trabajo describe una organizacin de unidades de trabajo. Por ejemplo, supongamos que el proceso de revisin de un documento especifica que Joe escribe el documento y luego Fred lo analiza. Aqu las unidades de trabajo son: en primer lugar la escritura y luego el anlisis del documento, y la organizacin implica que una tarea debe seguir a la otra. Este concepto no es una idea radical. El cdigo que realiza sucesivas llamadas a dos subrutinas es un ejemplo vlido del concepto. El inters reside ms bien en las formas que toma la organizacin. Para evaluar la hiptesis de la plataforma de flujo de trabajo, consideraremos una variedad de aplicaciones del mundo real y exploraremos las caractersticas que tiene que poseer una plataforma de flujo de trabajo si debe probar que es til. El proceso de revisin de un documento toma como parmetros de entrada un conjunto de pares [revisor, funcin] que describen qu personas participan en el flujo de trabajo y en qu funciones. Algunos valores posibles para las funciones son: requerido, opcional, aprobador final y propietario. El proceso de revisin, por lo tanto, contina hasta que todos los revisores hayan realizado las funciones asignadas y notifiquen el resultado al propietario.
DE VARIAS FORMAS, UN HUMANO ES EL SERVICIO ASNCRONO ORIGINAL: UNO NUNCA SABE CUNDO RESPONDER O AN SI LO HAR.
gerente de produccin podra desviar a otro cliente los dispositivos montados para una determinada orden. El encargado del depsito podra verificar su stock fsico para tratar de encontrar los productos que faltan. Cada accin determinada puede realizarse mltiples veces. Una limitacin obvia es que la colaboracin no est completa hasta que alguna combinacin de las acciones precedentes resuelve el dficit. Con frecuencia, tambin existen limitaciones empresariales. Por ejemplo, puede existir una norma que establezca que no est permitido el desvo de entregas de Clientes Oro. Tambin, las acciones los afectar mutuamente. Por ejemplo, puede existir una poltica que establezca que el costo adicional total de las medidas correctivas no puede exceder el 5 por ciento del costo de fbrica original. Por lo tanto, realizar un pedido de entrega ms rpida a un costo mayor puede impedir que un envo sea dividido.
Aplicacin 1
Aplicacin 2
...
Iniciar
Poseer
Propietario
Document review
Revisar
Aprobar
Revisor
Aprobador final
En este caso los tems de trabajo son las acciones que los varios participantes pueden tomar en la medida que buscan solucionar el dficit del inventario. La organizacin, sin embargo, no es la misma que la requerida en la revisin de un documento. Los participantes no son controlados; por el contrario, ellos eligen qu acciones realizar y cundo realizarlas. No obstante, estas elecciones estn limitadas por la organizacin del flujo de trabajo que posee dos aspectos: 1) Las acciones se focalizan en alcanzar una meta; en este caso, resolver el dficit del inventario. Cuando se inicia la resolucin del problema se crea un espacio de colaboracin limitado, y no se cierra hasta que se alcanza el objetivo. 2) Los participantes no son libres de realizar acciones arbitrarias. Ms bien, las acciones disponibles estn determinadas por la funcin que est cumpliendo el participante y por el estado de colaboracin. El conjunto de acciones disponible lo determinan las polticas relacionadas a la meta y las polticas globales tales como la restriccin sobre venta al descubierto de clientes preferenciales. Las acciones disponibles varan en la media que la colaboracin progresa. La experiencia del participante no es ms la de realizar las tareas asignadas. En cambio, un participante consulta las acciones que se encuentran disponibles para l en la actualidad, realiza una o ninguna de esas acciones y luego repite el ciclo. Por lo tanto, aqu el principal requisito nuevo es para la forma de organizacin de los tems de trabajo que est esencialmente orientada a la meta y al estado de los datos. Operaciones con secuencias de comandos Las operaciones con secuencias de comandos son simplemente un conjunto de operaciones que se componen utilizando una secuencia de comandos. Un ejemplo podra ser una herramienta de escritorio que permite a un usuario definir y ejecutar una serie de tareas comunes, como copiar archivos y comentarlos. Sera poco comn considerar el uso de un producto de flujo de trabajo tpico para este propsito. Por lo tanto, si una plataforma de flujo de trabajo fuera lo suficientemente general y de bajo costo, sera posible considerar su aplicacin a este tipo de problemas. Agregara esto algn valor?
UN MODELO DE FLUJO DE TRABAJO QUE EXPRESA EL PROPSITO EMPRESARIAL CENTRAL DE LA APLICACIN, DESPROVISTO DE CUALQUIER MATERIAL TCNICO IRRELEVANTE, ES UNA FORMA EFECTIVA DE LOGRAR ESTA COMUNICACIN ENTRE EL PERSONAL EMPRESARIAL Y SU STAFF.
La esencia de estas aplicaciones es guiar al usuario a travs de una serie de operaciones necesarias para lograr su objetivo. La organizacin de estas operaciones por lo general es utilizada para orientar la presentacin al usuario, ya sea una presentacin generada o un conjunto de botones de comando activados o desactivados sobre un formulario. Una caracterstica de este tipo de aplicacin es que el flujo de trabajo es la parte de la aplicacin que cambia con ms frecuencia. Tambin, los patrocinadores empresariales del sistema estn por lo general implicados en gran medida al especificar los cambios, resaltando la importancia de proporcionar al staff IT y al personal empresarial una va para que se comuniquen de manera clara y efectiva con relacin a los cambios. Un modelo de flujo de trabajo que expresa el propsito empresarial central de la aplicacin, desprovisto de cualquier material tcnico irrelevante, es una forma efectiva de lograr esta comunicacin. Estas aplicaciones tambin requieren flexibilidad dentro de la estructura del flujo de trabajo. En una aplicacin IVR, por lo general el usuario est muy limitado, se mueve a travs de un conjunto de mens estructurados de forma jerrquica. Sin embargo, tambin existen comandos de escape por ejemplo, regresar al men principal o salir del subrbol. La aplicacin de un centro de llamadas tendr ms flexibilidad que la aplicacin IVR si se cambian las opciones ofrecidas al usuario
View Visualizador
Datos
todas las interacciones entre los servicios que ocurren durante la ejecucin manual de un caso de evaluacin para la aplicacin. Este registro podra repetirse. Durante la repeticin, los mensajes originados de forma externa son generados sin intervencin manual, y los mensajes entre el conjunto de servicios que constituyen la aplicacin se verifican por secuencia y contenido en comparacin con el registro original. El flujo de trabajo es el caso de evaluacin, la organizacin de unidades de trabajo que constituyen los servicios que participan. El flujo de trabajo es activo, en el sentido que simula el comportamiento de los mensajes originados de forma externa, y es tambin pasivo, ya que monitorea las interacciones entre los servicios. Una caracterstica nica de esta aplicacin es que el flujo de trabajo es escrito, no por un desarrollador o por un usuario sino por un programa, como parte del acto o registro del caso de evaluacin. La creacin del modelo del flujo de trabajo debe ser totalmente programable. Existen tambin requisitos de actualizacin dinmica y expansin. Se requiere expansin debido a que las semnticas estructurales son ricas. Por ejemplo, slo porque dos mensajes llegaron a un servicio uno atrs del otro en el registro, no hay una implicacin necesaria de que se debe preservar este orden en un registro. Si no existe una dependencia causal entre los mensajes, entonces una repeticin que cambia el orden de los mensajes es correcta. Por lo tanto, la semntica de la secuencia en el modelo utilizado para registrar el caso de evaluacin necesita incluir una nocin de causalidad, que no necesariamente debe ser una caracterstica del modelo del flujo de trabajo central de la secuencia. Se requiere actualizacin dinmica porque la interaccin humana con el modelo ocurre durante la repeticin. Las discrepancias que se descubren durante la repeticin entre el comportamiento observado y el registrado son direccionadas instantneamente a un verificador. Si la discrepancia se debe a que el mensaje incluye una marca de hora que vara de ejecucin en ejecucin, entonces el verificador debera actualizar el modelo para marcar el campo sin importancia. Si la discrepancia ocurre en una evaluacin de regresin debido a que el software ha cambiado, entonces el verificador puede aprobar el cambio y actualizar la evaluacin para esperar el nuevo comportamiento en todas las ejecuciones posteriores. Valor de la plataforma de flujo de trabajo Una plataforma de flujo de trabajo no posee por definicin el conjunto total de caractersticas ofrecidas por los productos de flujo de trabajo tpicos de hoy en da. Sino ms bien, la plataforma de flujo de trabajo que se considera aqu se centra sobre la admisin del concepto de un flujo de trabajo como un modelo de organizacin de los tems de trabajo. Hemos visto que la idea de una organizacin de tems de trabajo es desde luego aplicable entre una gran variedad de aplicaciones, pero el hecho de que pueda utilizarse una plataforma de flujo de trabajo no significa que debe utilizarse.
Diseador del flujo de trabajo Windows Workflow Foundation Flujo de trabajo de la revisin del documento
Actividades estndar Actividades Sharepoint Actividades personalizadas
Tiempo de ejecucin
Programacin
Persistencia
Comunicaciones
Una explotacin ms semntica Tal como lo hemos visto en el anlisis de aplicaciones para operaciones con secuencias de comandos, ampliar el modelo de Debemos plantearnos dos preguntas: Qu valor adicional deriva del enfoque de la plataforma de flujo de trabajo? y Es este flujo de trabajo para especializar an ms el lenguaje modelo listo para usar es una tcnica muy eficaz que proporciona valor enfoque prctico? Este valor del enfoque de la plataforma de flujo adicional. Un ejemplo es la creacin de un lenguaje hecho para los de trabajo debe provenir de la expresin de la organizacin del usuarios finales, al igual que en la revisin de un documento que trabajo como un modelo, que analizaremos ms adelante. se llev a cabo utilizando una definicin improvisada del proceso Resumamos las caractersticas que debe mostrar una plataforma de revisin que analizamos anteriormente. de flujo de trabajo efectiva y prctica. Ejecucin. La especializacin del modelo posibilita agregar Para demostrar la forma en la que un modelo vara de un soporte de tiempo de ejecucin para problemas comunes. Un buen cdigo, el siguiente fragmento de cdigos es un flujo de trabajo vlido por la definicin utilizada aqu, es decir, una organizacin de ejemplo es el estado de ejecucin prologada. De las aplicaciones que hemos analizado aqu, se requiere la administracin del unidades de trabajo: estado de ejecucin prolongada para el proceso de revisin de un documento, colaboracin en la solucin de problemas y public void HandleLoanRequest ( aplicaciones de usuario guiado. El tiempo de ejecucin de la string customerID, plataforma de flujo de trabajo puede resolver inmediatamente Application app) problemas muy difciles utilizando elementos del modelo de { expresin simple para controlar una capacidad comn y liberando if (CheckCredit( al desarrollador para que se enfoque en el problema del negocio. customerId, app.Amount)) Monitoreo. La existencia de un modelo posibilita producir un { flujo de eventos con una semntica significativa sin la necesidad MakeOffer (customerId, app); de ningn esfuerzo adicional por parte del desarrollador. De las } aplicaciones descriptas aqu, este flujo de eventos es til para la
Y, en cierto sentido, es un modelo. Es posible descomponer este cdigo y construir un rbol CodeDOM que lo represente. Sin embargo, las semnticas del modelo resultante son demasiado generales como para ser opacas. Es posible decir que el cdigo contiene llamadas de funcin, pero no es tan fcil distinguir una funcin que representa la llamada de un tem de trabajo de una funcin que convierte nmeros enteros en secuencias. Un modelo de flujo de trabajo distingue estas ideas de forma explcita. Por lo general, un elemento de modelo especializado se utiliza para representar la llamada de un tem de trabajo y las funciones de conversin no se pueden expresar de forma directa en el modelo. Por lo tanto, un modelo de flujo de trabajo es aqul en el cual su grfico se construye desde elementos que son significativos en el dominio del flujo de trabajo. La riqueza semntica de tal modelo puede explotarse de diversas formas.
WF IMPLEMENTA LA IDEA DE UN FLUJO DE TRABAJO COMO UNA ORGANIZACIN DE TEMS DE TRABAJO, EXTRADOS DE LAS IDEAS RELACIONADAS CON LAS CUALES SE HAN ACOPLADO EN LOS PRODUCTOS DE FLUJO DE TRABAJO TRADICIONALES.
revisin de un documento, la colaboracin en resolucin de problemas, evaluacin de registro/repeticin y aplicaciones de usuario guiado. El flujo de eventos puede utilizarse para monitorear instancias de flujo de trabajo o para construir vistas agregadas del estado de una gran cantidad de instancias de flujo de trabajo. La estandarizacin del flujo de eventos facilita mucho ms la construccin de estas vistas agregadas entre los flujos de trabajo que se han desarrollado de forma independiente unos de otros.
EL OBJETIVO DEL TIEMPO DE EJECUCIN DE WF ES BRINDAR LAS CARACTERSTICAS REQUERIDAS POR CUALQUIER FLUJO DE TRABAJO, Y POR LO TANTO EVITAR LA NECESIDAD DE RE-IMPLEMENTARLAS UNA Y OTRA VEZ EN DIFERENTES APLICACIONES, PERO SIN COMPROMETER LA FLEXIBILIDAD DE LA ABSTRACCIN DEL FLUJO DE TRABAJO.
nuevos diseos especializados para comunidades de usuarios en particular o para organizaciones particulares de tems de trabajo. Tambin es posible especializar el diseo provisto, el que se puede utilizar no slo dentro de Visual Studio sino tambin desde adentro de una aplicacin de hosting arbitraria. Hosting. El tiempo de ejecucin del WF es lo suficientemente ligero como para ser almacenado en un contexto de cliente como por ejemplo en el shell de una aplicacin de cliente rico. Tambin posee la suficiente capacidad como para escalar cuando est alojado en un servidor host, como el Sharepoint Server producido por Office 2007. Las necesidades del tiempo de ejecucin de los servidores de WF se abstraen como interfaces de proveedor para servicios como la ejecucin de sub-procesos, transacciones, persistencia y comunicaciones. Se proporcionan soluciones de proveedores tiles listas para usar, pero pueden substituirse si es necesario. Semnticas. Los diferentes problemas responden a las diferentes semnticas de los modelos. WF admite tres estilos principales de flujo de trabajo listos para usar: orientado a datos, flujo y mquina de estados. El flujo es ideal para las aplicaciones en las que el flujo de trabajo est en control como el ejemplo de las operaciones con secuencias de comandos. La mquina de estados es el mejor estilo cuando el flujo de trabajo est orientado por eventos externos, como en aplicaciones de usuario guiado o MVC. Un enfoque orientado a los datos es el indicado para las aplicaciones en las que las acciones dependen del estado, como por ejemplo en la colaboracin para la resolucin de problemas. Estas semnticas pueden ampliarse al construir actividades personalizadas y crear un vocabulario de dominio especfico para que se utilice en cualquiera de estos estilos. Sin embargo, debido a que la estructura de un flujo de trabajo se expresa a s misma como un conjunto de actividades, se puede utilizar el mismo enfoque para definir semnticas totalmente novedosas y nuevos estilos, en el caso que sea necesario. Tiempo de ejecucin normal de un flujo de trabajo El objetivo del tiempo de ejecucin de WF es brindar las caractersticas requeridas por cualquier flujo de trabajo, y por lo tanto evitar la necesidad de re-implementarlas una y otra vez en diferentes aplicaciones, pero sin comprometer la flexibilidad de la abstraccin del flujo de trabajo. Estas caractersticas comunes pueden dividirse en cuatro categoras principales: programacin de la actividad, estado de ejecucin prolongado y transacciones, excepciones y compensacin y comunicaciones. Analicemos cada una en detalle.
LAS TRANSACCIONES ACID SON PARTICULARMENTE TILES PARA MANTENER LA LGICA ENTRE EL ESTADO DEL FLUJO DE TRABAJO Y EL ESTADO EXTERNO COMO POR EJEMPLO EL ESTADO DEL MENSAJE Y LA APLICACIN.
tambin admite una vista ms amplia del manejo de fallas que incluye la idea de compensacin para lograr una finalizacin exitosa de las unidades transaccionales. Comunicaciones. Como hemos visto, es necesario que los flujos de trabajo se comuniquen de varias formas, lo que se refleja en el WF, que admite la comunicacin por medio del mtodo .NET, interfaces de eventos e interfaces de servicios. El soporte para el Marco de Comunicacin de Windows tambin estar disponible en el futuro. Por lo tanto, WF realiza, de hecho, el enfoque de plataforma-flujo de trabajo propuesto aqu. La Figura 4 muestra la semntica de implementacin de alto nivel de la aplicacin de revisin de un documento y la manera en la que se integra todo lo anteriormente analizado. Una implementacin utiliza Sharepoint como el host del flujo de trabajo. El tiempo de ejecucin de WF utiliza el servicio de programacin preestablecido con WF. Sin embargo, los servicios de comunicacin y persistencia preestablecidos son reemplazados con implementaciones especializadas para el host de Sharepoint. El servicio de persistencia almacena el estado del flujo de trabajo de ejecucin prolongada en la base de datos del Sharepoint, y el servicio de comunicacin pone a disposicin del flujo de trabajo las utilidades de interaccin del usuario rico. De hecho, ambos servicios se brindan listos para usar en Microsoft Office 2007. Para definir el flujo de trabajo en s mismo en la revisin de un documento se utilizan tres tipos de actividades. Primero, se utilizan actividades WF listas para usar que proporcionan elementos estructurales como If-Else y While. Segundo, se utilizan actividades proporcionadas como parte de Office 2007 para acceder a los servicios de comunicacin del usuario de Sharepoint. Tercero, se utilizan actividades personalizadas para implementar las semnticas especficas de la organizacin con el objeto de realizar el envo y la delegacin de forma reutilizable y estndar. El diseador WF se utiliza como un medio para definir el flujo de
claros permitiendo que los usuarios y el staff IT se comunique de forma efectiva respecto del comportamiento deseado y que el personal que se integra al proyecto comience a producir con rapidez. Aislamiento del cambio. Las reas de aplicacin que pueden cambiar con ms probabilidad se expresan como flujo de trabajo ms que como cdigo. Al separar las partes de la aplicacin que se mueven con rapidez, los cambios pueden realizarse de forma ms segura. Agilidad. El resultado de todos estos beneficios es la agilidad del negocio. Si los usuarios del negocio pueden comprender el sistema, los desarrolladores pueden ponerse al da con rapidez, y los riesgos asociados con los cambios se minimizan. Por lo tanto, el sistema podra considerarse gil. Una plataforma de flujo de trabajo ampliamente til debe poseer las siguientes caractersticas: debe definir un modelo de flujo de trabajo central como un estndar que sea extensible y totalmente programable en el tiempo de ejecucin y diseo, debe poder comunicarse en una gran variedad de formas ricas, debe ser ligero e integrable y debe poder escalar y desempearse de forma adecuada en entornos de alto volumen. WF es un producto que muestra todas estas caractersticas. Como componente de WinFx y parte de la plataforma de Windows, WF tambin es ubicuo y de bajo costo. El concepto de una plataforma de flujo de trabajo, tal como se la describe aqu, es un modelo configurable y adecuado que posee mltiples beneficios para una gran variedad de aplicaciones, y est totalmente realizado en WF.
Sobre el autor David Green se incorpor a IBM como desarrollador para los laboratorios Hursley en 1977. Desde entonces ha avanzado a lo largo de toda la cadena de suministro de software, trabajando para una compaa de peridicos, American Express, Siemens Nixdorf y para un banco importante en el Reino Unido en una variedad de funciones tcnicas, de pre y post venta. El tema presente a travs de toda su experiencia es la construccin de aplicaciones para el mundo empresarial da a da, pensando que era mucho ms difcil de lo que debera ser crear grandes soluciones empresariales, y tratando de crear enfoques y herramientas para enfrentar este desafo. David ha pasado los dos ltimos aos en Microsoft trabajando en Windows Workflow Foundation, lo que cree es una contribucin importante para la armona de quienes construyen aplicaciones.
1 - Viaje por el mundo simple Nueva York 2 - The Amazing Race (pistas estticas) Nueva York Obtener pista Viajar a la ciudad Viajar a Nueva York Viajar al Cairo Viajar a Nueva York
Lisboa
Cairo
Pistas
3 - Pista inteligente de The Amazing Race ( pistas basadas en parmetros) Nueva York Obtener pista
Viajar a Singapure
Viajar a Secul
10
Proceso de reclamo C
Proceso de reclamo A 3 - Proceso de negocios de alto nivel (enrutamiento de subprocesos basados en parmetros)
Proceso de reclamo D
Para mostrar esta complejidad en accin, supongamos que The Amazing Race siempre cuenta con 5 equipos que compiten en cada nueva carrera (proceso global). Cada equipo, en cualquier etapa del juego, podra haber viajado a travs de una lista de ciudades antes de viajar a la prxima ciudad. Por ejemplo, hay un total de diez ciudades por las cuales pueden competir los equipos, lo que representa diez posibilidades diferentes de la ciudad en la que el equipo est en ese momento. Ellos tambin podran haber llegado a la ciudad en la que estn utilizando alguno de los tres medios de transporte primarios como ruta, ferrovas o aire. Utilizando esta analoga, la tarea de los creadores del juego sera componer el proceso global utilizando estos parmetros de cantidad de equipos, lista de ciudades previas y modo de transporte. Para lograr una combinacin nica de estos tres parmetros, es necesario combinar un proceso de ciudad particular en un proceso global. El proceso global debe asegurar que los participantes no utilicen el mismo medio de transporte ms de una vez consecutiva, y tambin debe asegurar que finalmente los participantes lleguen a la ciudad en la que comenzaron para de este modo dar finalizacin a la carrera. Aplicacin de las reglas El creador del juego tambin debe utilizar la cantidad de equipos para determinar ciertas condiciones especiales al azar y as asegurar que el juego cuente con un contenido ms variado asegurando que los equipos viajen a las diferentes ciudades, en distinto orden y por diferentes medios de transporte. De este
modo, el prximo proceso de ciudad que se debe utilizar en cualquier etapa del proceso global estara determinado por el equipo implicado, la ciudad en la que se encuentran y el ltimo medio de transporte que utilizaron. Esta combinacin traduce aproximadamente 150 caminos de flujo diferente que pueden determinar el prximo proceso de ciudad que se utilizar en el proceso global. la cantidad de posibles caminos de flujo se determina de la siguiente manera: 5 equipos x 10 ciudades posibles x 3 medios de transporte que slo pueden utilizar = 150 elecciones nicas para determinar el prximo
EL PRIMER ASPECTO MS IMPORTANTE PARA GESTIONAR PROCESOS DE NEGOCIO DE ALTO NIVEL ES LA NECESIDAD DE ABSTRAER AL USUARIO DE LOS TECNICISMOS.
proceso de ciudad (Ver Figura 4). Por ejemplo, el equipo nmero tres puede haber llegado a Nueva York por tren y luego determinar el prximo proceso como a Londres por aire. Esta complejidad tambin se traduce para las empresas. Tanto los dominios sobre seguros como financieros proporcionan diversos contextos que necesitan procesos de negocio de alto nivel controlados por reglas basadas en parmetros. Por ejemplo, un reclamo sobre seguros que debe ser investigado por una empresa de seguros global puede necesitar un reclamo de seguros, un proceso de negocios de alto nivel que seleccione un
11
Proceso de reclamo A
Proceso de reclamo B
Nueva York
Proceso de reclamo C
Nueva York
Proceso de reclamo D La complejidad se encuentra en la cantidad de posibles opciones de la empresa en tiempo real, para seleccionar la implementacin de un subproceso en particular. Esta complejidad aumenta con la cantidad de parmetros requeridos.
Nueva York
Viajar a la ciudad
Nueva York
Proceso de negocios independiente del parmetro Proceso de negocios dependiente del parmetro
C
Matriz amplia de posibles procesos de ciudad
12
Nueva York Proceso de negocios independiente del parmetro Proceso de negocios dependiente del parmetro A
Viajar a la ciudad
Nueva York
C
Matriz amplia de procesos de ciudad posibles
Ejemplo: tres parmetros para una carrera por el mundo podran ser: equipo, ciudad y transporte Equipo Ciudad Tansporte Implementaciones nicas posibles
10
150!
5
Figura 5: Un paso ms
11
275!
Investigacin A Investigacin B Validacin A Investigacin C Investigacin A Investigacin B Investigacin C Reclamo aprobado/ rechazado
Validacin C
Validacin C
13
LOS PROCESOS DE NEGOCIO DE ALTO NIVEL SE CREAN AL COMBINAR VARIOS PROCESOS DE NEGOCIO DE BAJO NIVEL, FORMANDO, DE ESE MODO, DOS NIVELES DE BMP.
La solucin de una matriz PDR fomenta el motor de reglas como la capa de control y cambia el motor del proceso a una capa de ejecucin, haciendo que el proceso de negocios de alto nivel fluya de forma ms visible en las reglas ms que en un modelo grfico. Con esta solucin an falta un enfoque estndar para modelar y mantener la base de datos PDR. El punto crtico aqu es que las abstracciones tcnicas que proporciona una herramienta de
Motor de normas
Motor BPM
Nueva York Proceso de negocios independiente del parmetro Proceso de negocios dependiente del parmetro A
Viajar a la ciudad
Nueva York
C
Matriz amplia de procesos de ciudad posibles
14
Motor de normas
Nueva York Proceso de negocios independiente del parmetro Proceso de negocios dependiente del parmetro
Viajar a la ciudad
Nueva York
Motor BPM
C
Matriz amplia de procesos de ciudad posibles
X
modelado del proceso de negocios grfica deberan estar en perfecto estado para modelar y mantener la base de datos PDR. Debido a que la base de datos PDR es una base de datos de reglas, es necesario analizar las herramientas estndar disponibles en el mundo de reglas comerciales. Se destaca la tabla de decisiones ya que ofrece una solucin adecuada para proporcionar una herramienta directa, liviana y sencilla. La tabla de decisin es una herramienta estndar para modelar y gestionar la base de datos de reglas y conforma una excelente abstraccin para los usuarios de la empresa que es simple de utilizar porque est basada en texto. Las tablas de decisin basadas en texto tambin son buenas candidatas para la bsqueda en la base de datos de reglas y permiten al usuario alterar de forma rpida las reglas importantes de definicin del proceso. Al utilizar esta herramienta se puede crear una solucin que tenga un proceso de negocios de alto nivel grfico que se simplifica al externalizar las reglas y se puede proporcionar una capa de servicio en funcin de la base de datos de reglas PDR (Ver Figura 7 y 8). De esta forma, la base de datos de reglas PDR se puede modelar y gestionar a travs de la tabla de decisin. Denominamos a esta solucin una matriz PDR, y los conceptos de proceso global y proceso de ciudad se pueden mostrar como dos niveles. El primer nivel representa el proceso de negocios de alto nivel de toda la empresa y el segundo nivel es un proceso de negocios de bajo nivel reutilizable. El juego final Hemos completado aqu un problema muy prctico con BPM en las empresas: la complejidad al definir y gestionar procesos de Recursos CBC.com www.cbs.com/primetime/amazing_race5
negocios de alto nivel. Los procesos de negocio de alto nivel se crean al combinar varios procesos de negocio de bajo nivel, formando, de ese modo, dos niveles de BMP. Los procesos de negocio de alto nivel estn marcados por la necesidad de reglas basadas en parmetros para seleccionar de forma dinmica un proceso de negocios de bajo nivel. El uso de estas reglas basadas en parmetros para gestionar procesos de negocio de alto nivel, aumenta la complejidad del modelo grfico mltiple con cada valor nuevo para cada parmetro. Este aumento de la complejidad hace que el modelo grfico del proceso de negocios de alto nivel sea difcil de gestionar y poco prctico. La solucin para este problema es utilizar un enfoque basado en las reglas para definir y gestionar los procesos de negocio de alto nivel. Se puede definir y gestionar este enfoque utilizando una matriz PDR basada en una tabla de decisiones. Las tablas de decisiones son herramientas ligeras, no grficas y fciles de usar para crear y gestionar reglas. La matriz PDR abstrae la complejidad de gestionar un modelo grfico de proceso de negocios de alto nivel. Por lo tanto, utilice una matriz PDR para gestionar BMP de dos niveles y vuelva a colocar al usuario comercial en el asiento del conductor de su empresa. Sobre el autor Vignesh Swaminathan es gerente de producto en CORDES R&D India (www.cordys.com), que proporciona un paquete de plataformas de aplicaciones de vanguardia que va ms all de los BPM y EAI bsicos para resolver varios aspectos prcticos de la empresa. En los ltimos cinco aos ha trabajado en la organizacin de procesos de negocio, reglas comerciales, transformacin de datos y otras tecnologas relacionadas. Se especializa en la integracin de datos, procesos y personas. Comunquese con Vignesh a vswamina@cordys.com y vigneshs@hotmail.com. 15
Los sistemas de flujo de trabajo humano y algunos de los patrones ms representativos de interacciones de procesos entre las personas y las actividades empresariales se dividen en dos componentes principales. El primero comprende los sistema de flujo de trabajo humano y la interaccin entre ellos en la medida que se implementan en plataformas de integracin. El segundo componente representa los patrones de diseo del flujo de trabajo humano y la forma en la que son implementados utilizando interacciones entre los sistemas de flujo de trabajo humano. Este debate analizar con detencin estos procesos.
16
Patrones de asignacin de tareas Los procesos orientados al flujo de trabajo han estado presentes en la industria por aos. El conocimiento adquirido sirve como base para mejorar la construccin de sistemas de flujo de trabajo. Directorios Los patrones abstraen los sistemas de flujo de trabajo en diferentes niveles como por ejemplo la aprobacin de tareas, la tpico, el servicio de gestin de tareas recibe una solicitud para creacin de tareas y la gestin del estado de las tareas. No es crear una tarea, interacta con el servicio de identidad para nuestra intencin definir un catlogo de patrones de flujo de seleccionar todas las personas que son aptas para realizar la trabajo humano. Por el contrario, trataremos algunos de los tarea, agrega la tarea a la lista de trabajos (tareas pendientes) patrones ms comunes en los sistemas de flujo de trabajo humano asociadas con los usuarios seleccionados, y asigna polticas y desde el ngulo de la arquitectura que se ha definido plazos de tiempo especficos. Finalmente, un usuario decide anteriormente. trabajar con la tarea y la reclama. El usuario puede entonces Comenzaremos con el anlisis de un ejemplo de flujo de trabajo trabajar con la tarea o solicitar ms datos. de usuario simple. Por ejemplo, un empleado, a travs del portal Un aspecto fundamental de los sistemas de flujo de trabajo del empleado, enva una solicitud de vacaciones. El portal inicia un humano es la capacidad de decidir el grupo de usuarios a quienes proceso de negocio que incluye el modelado de una tarea del se les permite ejecutar una tarea. Este proceso de decisin sobre el usuario puede estar basado en interacciones con plataformas de usuario utilizando un flujo de trabajo simple. La tarea es asignada el gerente de empleados. Cuando el gerente aprueba o rechaza la gestin de identidad. En nuestro ejemplo, los servicios de flujo de solicitud de vacaciones, se notifica al empleado por correo trabajo humano necesitan identificar qu usuarios son aptos para electrnico sobre la decisin del gerente. aprobar la solicitud en este caso el supervisor. Para lograr esta Por lo tanto, esta solucin combina los componentes de flujo de identificacin, una plataforma de flujo de trabajo humano debe decidir el concepto de supervisor desde un conjunto de usuarios y trabajo humano a travs de cuatro interacciones. La tarea es configurada utilizando aplicaciones de cliente que interactan con funciones tradicionalmente almacenadas en un directorio de el servicio de gestin de tareas; se configura el ciclo de vida de la usuarios. tarea o estados de la tarea. Como parte del proceso del negocio, la Se pueden establecer mltiples tipos de relaciones entre las tarea se asigna a un grupo de usuarios utilizando el servicio de personas y los procesos. Una de las ms comunes es la forma en la que las personas interactan con los procesos (funciones de las gestin de tareas. Uno de los usuarios reclama la tarea, y el servicio de gestin de tareas aplica la poltica adecuada para personas). Las personas de una empresa pueden agruparse en prevenir que otros usuarios acten sobre la misma tarea. El funciones que estn relacionadas de forma semntica a alguna actividad de negocio, como por ejemplo administrador del proceso proceso del negocio utiliza el servicio de gestin de tareas para obtener la actualizacin del estado de la tarea. o propietario de la tarea. Otra relacin comn es la forma en la Ahora consideremos un ejemplo de un flujo de trabajo que los procesos identifican con qu persona interactuar secuencial. El flujo de trabajo secuencial representa un contexto (consultas y vnculos de personas). Dentro de un proceso de en el que una tarea debe ser aprobada de forma secuencial por un negocios, ciertos grupos de usuarios son importantes desde el punto de vista de la empresa. Los vnculos de personas se utilizan grupo de usuarios. Por ejemplo, cuando un sistema de aprobacin para representar los diferentes grupos de personas que participan de rdenes de compra procesa una orden de compra utilizando un proceso de negocios, un empleado que pertenece al grupo en la ejecucin de un proceso. Una consulta desde un directorio supervisor evala en principio la orden de compra. Una vez que organizacional se utiliza para determinar los individuos asociados con un vnculo de personas y se refiere al vnculo de personas. En el usuario inicial aprob la orden de compra, el gerente de este usuario tambin la debe aprobar. Despus que el gerente ha nuestro ejemplo, la funcin humana genrica, gerente financiero, aprobado la orden de compra, sta es reenviada a los podra ser habilitada por el supervisor de vnculos de personas, departamentos de facturacin y despacho. Esta solucin posee que est vinculado a la consulta seleccionar autoridad de departamento, en la que el nombre del departamento es finanzas. cuatro interacciones. Interacta con el servicio de gestin de rdenes para configurar las tareas y establecer las polticas El servicio de identidad est a cargo de las caractersticas adecuadas. Define la secuencia de usuarios que deben actuar relacionadas con el usuario como por ejemplo autenticacin, sobre la tarea. Inicia la interaccin de la tarea con el servicio de autorizacin o determinacin de personas. La informacin del usuario, por lo general se almacena en directorios organizacionales gestin de tareas. El primer usuario reclamar la tarea para (por ejemplo, servicios de directorio Active Directory, un directorio comenzar a trabajar con ella, y una vez que ha finalizado, el servicio de gestin de tareas direccionar la tarea al prximo LDAP o una base de datos relacionada). El servicio de identidad usuario del grupo. puede trabajar independientemente del directorio organizacional. Un patrn de flujo de trabajo paralelo representa el contexto en En base al patrn adaptador, es posible extraer el acceso al el cual una tarea debe ser aprobada por varios usuarios al mismo directorio por medio del proveedor, que puede ejecutar las tiempo. Cada persona que aprueba puede agregar comentarios y consultas para obtener la informacin desde el directorio. Este anexos que son independientes de los otros. Por ejemplo, un enfoque extrae las funcionalidades del flujo de trabajo humano proceso de contratacin se utiliza para contratar nuevos desde el almacn del usuario. empleados. Cada entrevistador vota a favor o en contra de un En nuestro ejemplo, supongamos que el gerente quisiera candidato. Si el 75 por ciento de los votos es favorable, se reconstruir la ejecucin del flujo de trabajo de aprobacin de la contrata al candidato. De lo contrario, el candidato es rechazado. solicitud para verificar deficiencias. El servicio de seguimiento El proceso se modela utilizando el flujo de trabajo paralelo, en el mantiene un seguimiento de los cambios de estado relacionados que cada entrevistador puede votar de forma independiente de los con las tareas y cadenas de tareas. Este servicio debe otros entrevistadores. Esta solucin posee cinco interacciones para proporcionar los fundamentos de la funcionalidad requerida para reconstruir los cambios del historial de tareas y realizar un anlisis su implementacin. Interacta con el servicio de gestin de tareas para configurar las tareas y establecer las polticas adecuadas. de las tareas. Define la secuencia de usuarios que deben actuar sobre la tarea.
Servicio de notificacin
Servicio de identificacin
Tambin es necesario un servicio que notifique al supervisor por medio de un correo electrnico el momento en el que se crea la tarea de aprobacin de la solicitud. El servicio de notificacin administra los mecanismos de notificacin para el usuario relacionado con los cambios de estado de las tareas. Los cuatro servicios de tiempo de ejecucin analizados aqu proporcionan una buena perspectiva general de las funcionalidades ms comunes requeridas por los sistemas de flujo de trabajo humano. Si se combinan estos servicios, se pueden tratar algunos de los contextos ms comunes de flujo de trabajo humano. Ahora veamos algunos de los patrones ms comunes de flujo de trabajo humano.
17
La integracin de aplicaciones se ha vuelto cada vez ms comn y la creciente disponibilidad de herramientas y estndares (como los estndares de servicios Web WS-I) y la arquitectura orientada al servicio (SOA) parecen prometer una integracin ms fcil. Existen varios artculos que fomentan la simplicidad de vincular aplicaciones utilizando servicios Web o an SOA. Hoy en da, comnmente se utilizan dos enfoques para integrar aplicaciones: integracin de un bus de servicios e integracin punto a punto (Ver Figura 1). En el contexto punto a punto se crean vnculos directos entre aplicaciones por medio de un vnculo directo a una Interfaz para Programas de Aplicacin (API), un Protocolo de Transferencia de Archivos (FTP) o interfaces por lotes. La transformacin (traduccin) de la informacin puede realizarse mientras se transfieren los datos entre el vnculo. Por lo general, las interfaces punto a punto se implementan sin utilizar un producto de integracin y la traduccin de la informacin se realiza utilizando un cdigo en el punto de integracin en uno o ambos extremos de la interfaz. La integracin de un bus de servicios utiliza una solucin de tecnologa para proporcionar un bus sobre el cual las aplicaciones Figura 1: Integracin del bus de servicio e integracin punto a punto
Transformacin Informacin Agregado de datos Reglas comerciales Gestin de la transaccin Modelo de informacin
Gestin de sesin
Gestin de configuracin
Bus de servicio
Flujo de trabajo Proceso Reglas comerciales complejas Modelado de procesos de negocio Monitoreo de la actividad comercial
19
Usuarios
Flujo de trabajo
BPM
BAM
Capa de informacin
SOA
Normas comerciales
Agregado de datos
Capa de datos
Conectividad
Transporte 1
Transporte 2
Transformacin
llamadas, una solucin de integracin requiere sistemas con ms infraestructura informtica. Por ejemplo, no es poco comn para los operadores del centro de llamadas que cambien entre ms de 10 aplicaciones cuando atienden las llamadas de los clientes. El reemplazo de este tipo de contexto en el que el usuario integra la aplicacin de forma eficaz al copiar y pegar o al volver a escribir informacin en diversas aplicaciones para completar una transaccin, es un orientador comn para la integracin de aplicaciones. Eje central de la arquitectura de la empresa Existen una cantidad de mtodos que pueden utilizarse para integrar aplicaciones detrs de una aplicacin de un centro de llamadas o un sitio Web, y la solucin ms comn en la primera etapa es construir una cantidad de interfaces punto a punto o de bus de servicios. Sin embargo Qu sucede cuando una solucin de un centro de llamadas y una aplicacin de Web necesitan acceder a la misma informacin? El contexto ideal sera reutilizar las interfaces Verdad? Bien, en la mayora de los casos en los que los grupos de desarrollo (y los arquitectos) no estn conectados, ste no es un enfoque comn, dadas las complejidades que se suscitan al tomar una interfaz existente con su propio conjunto de cdigos complejos y permitir que sea llamada por algo ms. El problema aumenta de forma exponencial con la cantidad de interfaces que deben existir entre los sistemas y esto es relativo al tamao de la empresa; las experiencias de empresas ms grandes es sin duda peor que las experiencias de empresas ms pequeas.
Si no se implementa una solucin integral bien diseada da como resultado cdigos duplicados en toda la empresa, enfoques de arquitectura incompatibles en cada sistema, y la inhabilidad
SI NO SE IMPLEMENTA UNA SOLUCIN INTEGRAL BIEN DISEADA DA COMO RESULTADO CDIGOS DUPLICADOS EN TODA LA EMPRESA.
para responder a las necesidades de la empresa de forma inmediata. Estos problemas representan un producto secundario de un enfoque centrado en un proyecto para una arquitectura de solucin. SOA es comnmente presagiada en la actualidad como la solucin para la integracin de problemas entre aplicaciones, pero se requieren una cantidad de caractersticas adicionales para una solucin de integracin verdaderamente eficaz. Estas caractersticas estn enumeradas en la Tabla 1 y se agrupan en tres capas de integracin:
datos por lo general se logra an en los contextos de integracin ms bsicos. En esta capa, los datos se trasladan entre las aplicaciones transformndose para permitir que los datos puedan ser traducidos entre las aplicaciones. agregan datos y llamadas a las aplicaciones para permitir que las llamadas nicas accedan a mltiples aplicaciones, teniendo
20
Transformacin
Reglas comerciales
Gestin de la transaccin
Gestin de sesin
Instrumentacin
Gestin errores
Gestin de configuracin
repetible son mucho ms complejos, en particular cuando un contexto de integracin incluye aplicaciones que ya existen. Por qu todo lo anteriormente citado es importante? Cuando Integracin del proceso La tercera capa se construye sobre la uno construye la primera interfaz entre dos aplicaciones, la simple base de la integracin de datos al agregar e integrar los procesos y datos necesarios para ejecutar un proceso de negocio integracin de datos puede ser suficiente. Sin embargo, en la medida que se construyen ms interfaces el diseo se vuelve ms que opera dentro de los lmites de la aplicacin. importante. Si no se disea y gestiona un contexto de integracin completo puede llevar a su vez a un aumento vertiginoso de costos de cada interfaz. Por el contrario, en la medida que crece la En la medida que uno se desplaza por las tres capas de integracin, el objetivo cambia desde la tecnologa al negocio. Sin funcionalidad que se proporciona en la capa de integracin, el cdigo necesario en cada capa puede reducirse. embargo, el resultado final permite una mayor capacidad para agregar valor al negocio de forma inmediata. Componentes de la capa de integracin Varias vistas de SOA proporcionan un modelo de conectividad Los componentes de una capa de integracin pueden a su vez comn y asumen proporcionar transformacin, pero estas vistas dividirse en tres capas: datos, informacin y proceso (Ver Tabla slo proporcionan la integracin de datos. Los desafos que 1). Adems, pueden separarse en componentes que constituyen enfrenta un arquitecto al integrar aplicaciones de forma eficaz y
en cuenta las reglas comerciales bsicas para permitir que las llamadas nicas combinen aplicaciones.
21
un marco tcnico; los componentes aparecen en azul en la Figura 2. El marco tcnico proporciona los requisitos de plomera e ingeniera. Un marco empresarial brinda facilitadores de negocios, que se muestran en dorado en la Figura 2. Analicemos ms de cerca los componentes que conforman los tres niveles de una capa de integracin. Capa de datos. Los dos componentes de la capa de datos bsica son la conectividad y la transformacin, que forman los cimientos del marco tcnico (Ver Tabla 2). Las interfaces punto a punto nicas que utilizan servicios de Web, con frecuencia se utilizan como ejemplos de SOA, pero varios de los principios de SOA se refieren a la provisin de servicios que empaquetan llamadas mltiples entre los sistemas. Sin embargo, tal como lo mencionramos con anterioridad, los servicios Web existen en la capa de datos, lo que no facilita el uso de estos principios. En este contexto, los servicios Web permiten la conectividad, pero es necesario explorar la capa de integracin para la integracin relacionada con el servicio. Capa de informacin. La capa de informacin est compuesta por componentes que se construyen sobre el marco tcnico (Ver Tabla 3). El marco del negocio se crea sobre la base del modelo de informacin (Ver Tabla 4). Capa del proceso. En la medida que el foco se mueve desde los requisitos tcnicos hacia el valor del negocio, el foco de funcionalidad que debera ser brindado a travs de la capa del proceso cambia para proporcionar el valor verdadero del concepto de la capa de integracin proceso de negocios configurable de forma rpida (Ver Tabla 5).
Al juntar todo esto, existen varias formas en las que se puede implementar una capa de integracin: desarrollo personalizado; uso de programas, paquetes de herramientas, fuente abierta o componentes proporcionados por el sistema operativo y el uso de
SOA ES COMNMENTE PRESAGIADA EN LA ACTUALIDAD COMO LA SOLUCIN PARA LA INTEGRACIN DE PROBLEMAS ENTRE APLICACIONES, PERO SE REQUIEREN UNA CANTIDAD DE CARACTERSTICAS ADICIONALES PARA UNA SOLUCIN DE INTEGRACIN VERDADERAMENTE EFICAZ.
un paquete de integracin ms completo. El desarrollo personalizado se puede aplicar completamente a la capa de integracin, pero no se recomienda dada la disponibilidad de paquetes de herramientas y programas. Algunos programas disponibles brindan la oportunidad de integrar los sistemas de forma inmediata en la capa de interfaz del usuario, como por ejemplo el Customer Care Framework de Microsoft. Este tipo de solucin de integracin proporciona una solucin excelente para la integracin inmediata de los sistemas de bases de datos, para que puedan brindar una interfaz del usuario consolidada, pero es importante comprender los mritos relativos de este tipo de solucin. Las estructuras que posibilitan la integracin de sistemas en la capa de interfaz del usuario proporcionan soluciones rpidas para ciertos problemas que enfrentan las empresas, como por ejemplo mejorar el tiempo de
22
Actitud de Integracin Exitosa Contar con una herramienta y utilizarla de forma correcta son dos cosas muy diferentes, y este anlisis describe una actitud necesaria para lograr una integracin realmente exitosa. Independientemente del mtodo que se utilice, recuerden que si se tiene una visin de la integracin en toda la empresa se podrn lograr beneficios mucho ms grandes para los negocios, la LAS ESTRUCTURAS QUE POSIBILITAN LA integracin en s misma no es trivial y debe considerarse dentro de INTEGRACIN DE SISTEMAS EN LA CAPA DE un contexto de empresa; y mientras se considera el contexto de la INTERFAZ DEL USUARIO PROPORCIONAN empresa y se disea para obtener los mayores beneficios del SOLUCIONES RPIDAS PARA CIERTOS PROBLEMAS negocio es an posible y necesario comenzar a implementar la QUE ENFRENTAN LAS EMPRESAS. solucin en un proyecto nico. La visin empresarial de la integracin debe considerarse lo aplicacin dentro del entorno no representa an un proceso trivial. antes posible. Si bien existe claramente un lugar para la Sin embargo la integracin es mucho ms fcil de lo que sera si integracin punto a punto en el que no es posible una integracin no se utilizase una capa de integracin ya que la integracin de los adicional, un contexto de integracin ms capaz que proporcione datos puede lograrse de forma ms fcil al asociar un nico el flujo de trabajo y otras caractersticas descriptas aqu, brindar conjunto de interfaces conocidas dentro de la capa de aplicacin y ventajas en la medida que crezca la cantidad de sistemas e no dentro de cada aplicacin. Tambin el proceso de integracin integracin. Por lo tanto, es necesario un anlisis fuera del mbito puede agregarse al extender los flujos de trabajo de integracin en de cada proyecto nico para descubrir cualquier oportunidad que el motor de flujo de trabajo, simplemente como integracin BAM, pueda existir. agregado de datos, inclusin en un modelo de integracin y Del mismo modo que con todas las decisiones de arquitectura, dems, ya que son mucho ms fcil de lograr simplemente existen caractersticas, costos, orientadores del negocio y dems extendiendo lo que ya existe. que se tienen en cuenta al tomar decisiones de arquitectura. El El componente de flujo de trabajo es una parte clave de enfoque para la arquitectura de integracin que se recomienda cualquier solucin de integracin que se utiliza para proporcionar aqu es muy conveniente para las caractersticas y conceptos de tanto el procesamiento de flujo de trabajo centrado en las arquitectura de la actualidad. Esperamos que le ayuden a personas a travs de la capacidad de gestin de procesos de comprender algunas de las decisiones que pueden tomarse en el negocio, como para desempear una funcin central al ejecutar los rea. procesos comprendidos en los sistemas vinculados. Estas dos tareas estn bastante separadas y son bastante diferentes, pero ambas se adaptan perfectamente para el uso de herramientas de Sobre el autor flujo de trabajo. Un flujo de trabajo de un sistema de integracin puede incluir pasos como recuperar datos desde cada sistema y Kevin Francis es profesional IT con 19 aos de experiencia en la agregarlos juntos, validar entradas de usuarios y actualizar industria en una variedad de puestos desde CIO en una empresa sistemas conforme a los datos ingresados o actualizados. de fabricacin, analista de seguridad, hasta arquitecto global y Las herramientas de flujo de trabajo proporcionan el mtodo tambin dirigi su propia y exitosa empresa de desarrollo de ideal para llevar a cabo estas actividades, son mucho mejores que software. Kevin ha diseado y administrado proyectos de comercio el uso de cdigos y por lo tanto, pueden proporcionar beneficios electrnico de vanguardia desde que surgi el comercio importantes para la empresa desde una capa de integracin, electrnico. Como arquitecto principal de Infosys, Kevin es dados los siguientes puntos: responsable del xito de la implementacin tcnica de la compaa El trabajo con sistemas mltiples est intrnsicamente orientado a procesos, ejecutando las tareas paso a paso con puntos de decisin, diversificaciones y otros pasos esenciales de flujo de trabajo. Los flujos de trabajo de integracin de sistemas se sitan para sus clientes. Asesora a grandes empresas, trabaja con los arquitectos de Infosys, equipos de desarrollo y clientes para asegurar que cada solucin tcnica incorpore calidad y direccin estratgica del cliente. Kevin es miembro de The Infosys Australia Technology Council y fue galardonado por Microsoft con el premio Most Valuable Professional (MVP) en julio de 2005 por su conocimiento y experiencia como Desarrollador Visual y Arquitecto de Soluciones.
23
Un buen diseo de flujo de trabajo requiere el anlisis del proceso de negocios, el rediseo del proceso de negocios, el anlisis de utilidad y el diseo del software. Esta lista desalentadora de habilidades necesarias hace que el flujo de trabajo sea un desafo para la gran mayora de los arquitectos de software expertos. Cmo desglosar el problema en las ms pequeas partes para comenzar en la direccin correcta? Analizaremos la forma de simplificar el proceso de diseo de sistemas complejos con tipos de usuarios mltiples y cientos de estados potenciales. Para simplificar el proceso se puede pensar en una solucin de flujo de trabajo ms que en un proceso de diseo de flujo de trabajo. Cada proyecto de software posee un proceso central que es la razn principal por la cual existe el sistema o por la cual se est creando. Por ejemplo, el objetivo principal de un sitio de comercio electrnico es facilitar a las personas la compra de productos. El proceso principal es el que necesita la mayor atencin durante su diseo e implementacin. Les mostraremos la representacin con puntos y lneas para modelar lo que lo ayudar a comunicarse con los expertos de negocios sobre procesos complejos para determinar los estados y acciones disponibles en la medida que crea el flujo de trabajo. Comencemos con una visin general de la representacin con puntos y lneas para la creacin de diagramas de flujo de trabajo. En la representacin con puntos y lneas cada punto representa un estado particular en el proceso, y cada lnea corresponde a una accin que puede ser tomada desde este punto. Los puntos y las lneas estn etiquetados y se genera una clave en la medida que se desarrolla el flujo de trabajo. Los puntos estn etiquetados con letras, comenzando por la A, y las lneas estn etiquetadas con nmeros, comenzado por el 1. De esta forma, las lneas y los puntos no se mezclan.
CADA PROYECTO DE SOFTWARE POSEE UN PROCESO CENTRAL QUE ES LA RAZN PRINCIPAL POR LA CUAL EXISTE EL SISTEMA O POR LA CUAL SE EST CREANDO.
Las etiquetas de los estados y acciones no aparecen en el diagrama. Si se tienen descripciones de cada accin y estado, el diagrama no es simple y es difcil de comprender. Para colocar etiquetas para los estados y acciones en una clave, es mucho ms fcil ver flujos de procesos ms largos en espacios ms pequeos, lo que sera casi como normalizar el diagrama. Se pueden cambiar las etiquetas de los puntos sin tener que cambiar el diagrama. Esto posibilita una ms fcil visin y diagramacin de procesos complejos. La diagramacin es simple y flexible, permitiendo que todos puedan precisar con claridad el contenido. La diagramacin es un gran problema en los flujos de los procesos tradicionales. Se debe
24
LOS ESTADOS Y LAS ACCIONES DEBEN INCLUIRSE SI SON NECESARIOS PARA COMPLETAR EL PROCESO QUE SE EST ESTUDIANDO.
Los estados se pueden separar del diagrama principal. Debido a que siempre se va hacia adelante en el diagrama, es posible separar secciones del diagrama sin preocuparse sobre la forma que se conectarn a estados previos en el flujo de trabajo. Por ejemplo, A se conecta a B, y queremos separar B de su propio diagrama porque posee demasiadas descendencias para ajustar en el diagrama existente. No es necesario preocuparse si B posee una accin que va a C y C posee una accin que enva su estado de regreso hacia A. Al etiquetar el estado con A estn conectadas, en vez de tener que reenviar una lnea al estado A original. El diagrama slo se mueve hacia adelante, no hacia atrs, por lo tanto, no es necesario volver a conectar con el punto A original. Esta regla permite una gran flexibilidad cuando uno se est quedando sin espacio en un diagrama. Acciones y estados para flujos de trabajo Ahora trataremos algunas de las ventajas de la representacin con puntos y lneas, veamos la forma de determinar si una accin o estado debe estar en el diagrama. Los estados y las acciones deben incluirse si son necesarios para completar el proceso que se est estudiando. Por ejemplo, si bien iniciar una sesin o registrarse en un sistema de comercio electrnico no cambia el estado del objeto de una orden, esto es necesario para completar la compra. Por lo tanto, debe incluirse como una accin en el sistema y los estados que crean estas acciones deben estudiarse y diferenciarse si se est analizando el proceso de rdenes. Los estados y las acciones no deben incluirse si no son necesarios para completar el proceso que se est estudiando y no cambian los pasos necesarios para completar el proceso que se est modelando. En otras palabras, una accin que lo hace retroceder un paso en el proceso es algo que debe modelarse. Por otro lado, una accin que no est relacionada al proceso no debe modelarse. Por supuesto, existe definitivamente un gran margen de interpretacin sobre qu se debe incluir en el diagrama del proceso; debido a que es necesario encender la computadora para realizar cualquier proceso informtico, es probablemente un poco ridculo incluir esta accin como parte de un diagrama de proceso. Ahora utilizaremos un ejemplo para tratar de clarificar lo que se debe y lo que no se debe incluir en un diagrama con puntos y lneas. Analicemos un ejemplo conocido de un flujo de trabajo para examinar este proceso la compra de productos a travs de un sitio Web de comercio electrnico. Estudiaremos los pasos necesarios que se deben seguir para comprar un producto. Cuando comenzamos a disear un flujo de trabajo de compras, ignoramos pasos que no cambian el estado de la transaccin de compra. Por ejemplo, el proceso de bsqueda de un producto no cambia en absoluto el estado del proceso de la orden. Realmente
Encontrar y agregar un producto en el carro de compras. Registrarse. Iniciar la sesin. Eliminar todos los productos del carro de compras. Cerrar la sesin. Iniciar el proceso de pago. Agregar/seleccionar informacin sobre el envo. Agregar/seleccionar informacin sobre la facturacin. Procesamiento de la facturacin exitoso. Procesamiento de la facturacin fall. Confirmar orden. Salir del proceso de pago.
No hay productos en el carro de compras, no se ha iniciado la sesin. Los productos estn en el carro de compras, no se ha iniciado la sesin. No hay productos en el carro de compras, sesin iniciada. Los productos estn en el carro de compras, sesin iniciada. Iniciar el proceso de pago, no se ha iniciado la sesin, sin envo ni facturacin. Iniciar el proceso de pago, sesin iniciada, sin envo ni facturacin. Proceso de pago, sesin iniciada, envo, sin facturacin. Proceso de pago, sesin iniciada, envo y facturacin. Pago confirmado, sesin iniciada, estado temp (cuadrado). Procesamiento de la orden exitosa, sesin iniciada.
no importa la forma en la que el usuario se mueve por el sitio a menos que realice una de las tres cosas que cambian su estado en curso. Estos tres pasos que pueden hacer avanzar el estado de compra del producto son: agregar un producto en el carro de compras, registrarse en el sitio e iniciar la sesin en el sitio. Por ejemplo, supongamos que vamos a la seccin libros y hacemos un click hacia atrs para regresar a la pgina principal. Cambia esta accin de alguna manera nuestro estado en lo que se refiere a la compra del producto? No. Imaginemos que realiza una bsqueda del sitio .NET books, y se obtiene como resultado una lista de ellos. Luego se realiza un click hacia atrs para regresar a la pgina principal. An no se ha avanzado en el proceso de compra. Incluso si suponemos que contamos con un motor que coincide con las sugerencias de libros del historial de bsqueda, an as no se avanza en el proceso de compra hasta que no se agrega un producto en el carro de compras. Es muy importante que este paso est fuera del diagrama porque de otra forma lo complicara innecesariamente. Podemos combinar la bsqueda y luego agregar un producto en el carro slo en una accin en el diagrama del proceso de compra, denominada buscar y agregar producto. Si deseramos diagramar el proceso de bsqueda de un producto, entonces estaramos interesados en la manera en la que el usuario
25
C
1 5
D A
1 2 3
B
1 2 3 4 6
D C D
2 1 4 5 6
A
12
E
3
CUANDO COMENZAMOS A DISEAR UN FLUJO DE TRABAJO DE COMPRAS, IGNORAMOS PASOS QUE NO CAMBIAN EL ESTADO DE LA TRANSACCIN DE COMPRA.
estado incompleto para el administrador. Es poco probable que el administrador necesite saber ms que esto, excepto para estadsticas globales que se proveeran en un informe ms que en una pantalla de trabajo diario. Adems, si el administrador entra en alguna de estas rdenes puede proporcionar detalles del estado en ese punto. Una de las formas ms fciles de acumular estados para cada usuario es utilizar el mtodo quin tiene la pelota?. En otras palabras, Qu usuario se supone que debe hacer algo para avanzar en el flujo de trabajo? El/Los usuario(s) que se adecuen a esta descripcin deben ver este tem agrupado con otros tem que estn esperando alguna accin de su parte. Luego, se pueden agrupar otros tems abiertos en otra categora y finalmente los tems cancelados/finalizados en una tercera categora. Una recomendacin final con respecto a la representacin con puntos y lneas es utilizar un lpiz y un papel bien grande para crear los diagramas. Otro papel bien grande debe contener los nombres de los estados, y por ltimo, se deben tener los nombres de las acciones. Utilizar hojas de papel separadas y bien grandes de esta manera permite que todos tengan un buen panorama general del proceso completo en vez de tenerlo por separado en mltiples pantallas. El uso de papel hace que todos se enfoquen en el problema en cuestin en vez de que parezca que todo est normal. Si se utiliza papel no existe forma fcil de poner se puede poner con facilidad un gradiente sobre cada punto o de reorganizar los tems para que encajen mejor. Usted debera encontrar esta representacin con puntos y lneas tan til como yo, al descubrir todos los estados y acciones potenciales con los expertos de negocios.
B F
12 5 8
B
12 5
G
7
H
12 5 11
B
9
I
10
selecciona el producto para verlo y agregarlo a su carro de compras. Por ahora, nos concentraremos en diagramar el proceso de compras. Funciones en el proceso de compras Primero, comenzaremos con alguien que simplemente ingres en la pgina inicial de nuestro sitio de comercio electrnico. Analizaremos este caso para ver qu sucede despus en nuestro proceso. Tres posibilidades en cuanto a comportamiento que avanza el proceso de compras son: agregar un producto en el carro de compras, registrar un usuario e iniciar la sesin en el sitio. Se puede ver el diagrama de puntos y lneas para este proceso completo en la Figura 1 y sus claves respectivas en la Tabla 1. Es importante comprender el impacto que tienen las mltiples funciones en el sitio sobre los estados y permisos visibles. Por ejemplo, supongamos que nuestro sitio de comercio electrnico tiene funciones tanto para los compradores como para un administrador. Los compradores son las personas que compran el producto, mientras que el administrador se asegura de que obtengan el producto. El diagrama de puntos y lneas nos ayuda a
Sobre el Autor Andrew Needleman es socio gerente en Claricode (www.claricode.com), desarrollador de soluciones personalizadas exclusivamente para la industria del cuidado de la salud. Ha escrito artculos que se centran en el desarrollo del software para varias publicaciones IT e industrias del cuidado de la salud. Su experiencia en el diseo de flujos de trabajo incluye el diseo de una aplicacin con cientos de estados diferentes, acciones mltiples en cada estado y nueve tipos de usuarios distintos. Esta solucin fue reconocida como una Intel Solution Blueprint para las mejores prcticas en el cuidado de la salud con tecnologas de Microsoft. Pngase en contacto con Andrew en andrew@claricode.com.
26
Cuando se habla con clientes y colegas sobre los servicios Web, se descubre que mucho de la excitacin e inters se enfocan en las especificaciones que han ayudado a esta tecnologa a transformarse rpidamente en una norma de facto: SOAP, WSDL, XML, WS-Security, y dems. Aunque esta estandarizacin es fundamental, con frecuencia nos distrae del siguiente nivel de discusin sobre la manera de aprovechar real y completamente este paquete comn. Estos protocolos nos dan un mayor alcance y reutilizacin que el que alguna vez hayamos logrado con el software, pero su uso individual no cumple ese potencial. Todo el trabajo invertido en normas y consorcios nos permite desarrollar servicios que puedan interoperar con otras aplicaciones y sistemas, pero no necesariamente nos otorga la reutilizacin. Lo que es an ms importante, no nos otorga la manejabilidad. Si se trabaja en una organizacin, o con una organizacin, que obtuvo algn xito con servicios Web, no habr dudas de que se encontrar la necesidad de tratar, (cuando no la desventaja de no hacerlo), las pruebas de servicios, implementacin, versin y administracin. Estas reas son muy problemticas cuando no se identifican antes de construir una cartera de servicios. Esta condicin ha convertido ya a algunas organizaciones en vctimas de su propio xito. Los enfoques que trabajan con muchos servicios con frecuencia fallan al aumentar la cantidad de servicios y su uso. Si no se tienen los principios y prcticas en lugar de promocionar la reutilizacin y brindar manejabilidad al aumentar el uso de servicios, se encontrar el techo de escalabilidad. (Ver la barra lateral, Aclaracin sobre Modelos de Maduracin). Debatir este tema es muy difcil, incluso entre los arquitectos ms experimentados e inteligentes, mucho menos otros participantes menos tcnicos que juegan un rol en el ecosistema de servicios. Algunas de estas dificultades provienen del uso de trminos sobrecargados como servicio, pero mucho de esto proviene de la complejidad pura que est implicada con una arquitectura distribuida en forma masiva que toca muchas reas de una organizacin. Si algo es difcil de debatir, slo se debe pensar en cun difcil puede ser definir una estrategia o planearla.
TODO EL TRABAJO INVERTIDO EN NORMAS Y CONSORCIOS NOS PERMITE DESARROLLAR SERVICIOS QUE PUEDEN INTEROPERAR CON OTRAS APLICACIONES Y SISTEMAS. PERO ESTO NO NECESARIAMENTE NOS OTORGA LA REUTILIZACIN.
clientes. El logro de esta agilidad significa brindar un plan que sea extensible y duradero al mismo tiempo. Al enfocarse en el servicio, y no en el mensaje, implementacin, o uso, ESOMM puede ayudar a construir un plan que cualquier organizacin pueda aplicar ampliamente. Como implementaciones de servicio preferenciales, elecciones de tecnologa, y modificacin de patrones de uso, el modelo deber proveer un mapa de ruta duradero que pueda soportar esos cambios. ESOMM consiste en cuatro capas, cada una con un conjunto de capacidades que como un todo establece un nivel slido de logro y valor para la organizacin para esa capa (ver Figura 1). Este valor debe realizarse completamente si se proveen todas las capacidades adjuntas. Es posible, y ciertamente probable, que una organizacin pueda tratar partes de capas mltiples;
27
Una empresa es capaz de incorporar Extensible servicios y extender su uso, ms all de sus propios lmites. Una empresa puede administrar Soportable eficazmente cantidades crecientes de servicios a los SLAs garantizados. Una empresa implementa, consume y reutiliza servicios en forma eficiente y consistente. Una empresa es capaz de escribir y consumir servicios conforme a normas con un excelente alcance.
Repetible
Utilizable
ampliamente y con mayor xito. Creemos que esta es la perspectiva que ms se descuida, pero puede ser la ms crtica para determinar el xito con la orientacin al servicio. Si es difcil impulsar los servicios, el xito ser limitado, sin importar qu otras reas estn optimizadas. Las capacidades de administracin utilizan aspectos operativos y de rgimen de servicios Web en la organizacin. Esta perspectiva se vuelve ms reconocida y apreciada, pero todava hay ms para entender sobre su valor e impacto. El valor adicional de las perspectivas es la ayuda que brindan para priorizar la implementacin de capacidades especficas en el modelo. Aunque hay una habilidad de ignorar ciertas capacidades
LA CAPA EXTENSIBLE REPRESENTA EL PINCULO DE LA REALIZACIN DE AGILIDAD COMERCIAL Perspectivas del mapa de ruta PROMETIDA POR LOS SERVICIOS Y LA Mediante compromisos e interacciones con clientes en los ltimos REUTILIZACIN DE SERVICIOS COMO BLOQUES DE aos, reconocimos una necesidad de tratar diferentes perspectivas CONSTRUCCIN DE OTROS SERVICIOS, O mediante este modelo. Al hablar de las capacidades en cada capa INCORPORACIN DE SERVICIOS. del modelo, se volvi evidente que haba variables niveles de
apreciacin o consideracin para ellos, segn el rol y desafos del pblico. Por ejemplo, una organizacin tena dificultades en apreciar la necesidad de diseo de interfaz por contrato. Estaban bastante satisfechos utilizando herramientas para generar dinmicamente contratos de servicio y sentan que tenan xito con este enfoque. Cuando hablamos con los usuarios de los servicios del grupo, no obstante, tuvimos una perspectiva totalmente diferente al saber que el uso de tipos de datos especficos y patrones de elementos causaba muchas dificultades durante la implementacin. Al reconocer que no todas las capacidades son impulsadas por propietarios o proveedores del servicio, los inversores pueden tener mayor apreciacin de algunas de las capacidades y tomar decisiones ms informadas sobre el enfoque y priorizacin de estas capacidades. Las capacidades en cada capa de ESOMM estn clasificadas en una de estas tres perspectivas: implementacin, consumo, y administracin (ver Figura 2). Las capacidades de implementacin apuntan al desarrollo y la implementacin de servicios Web desde la perspectiva del proveedor. Esta perspectiva es una que la mayora de las organizaciones aprecian por defecto, y exige la menor cantidad de clarificacin. Las capacidades de consumo son aquellas que satisfacen a los consumidores de los servicios, facilitndoles la implementacin y por lo tanto son adoptadas ms al progresar en el modelo, es bastante arriesgado saltear capacidades a una capa menor dentro de la misma perspectiva. Estos pre-requisitos no slo tienen la intencin de ayudar a hacer crecer el sistema de manera lgica, sino tambin de ayudar a saber cmo utilizar los servicios y soportarlos en la organizacin, porque esta informacin impactar el diseo de ciertas capacidades a capas superiores. Es tambin importante darse cuenta de que una organizacin puede elegir enfocarse en una o dos perspectivas, pero la maduracin total, y por lo tanto el valor total de los servicios, depende del nivel adecuado de atencin a las tres. Descuidar cualquiera de las tres tendr consecuencias, algunas ms obvias que otras. Tales consecuencias seran semejantes a ignorar uno de los grupos alimenticios; se puede hacer, pero limitara algunas de las comidas que se pueden disfrutar y que no son ideales para la salud general. Capacidades del ESOMM Existen 27 capacidades descriptas en el modelo ESOMM, y fcilmente tomara un artculo explicar cada una en detalle (ver figura 3). Aqu daremos un panorama breve de estas y ayudaremos a articular la premisa de cada capacidad y su conformidad con la perspectiva y capa asociada.
28
Soportable
Repetible
Utilizable
29
PARA HACER A LOS CONSUMIDORES DE SERVICIOS MS AUTOSUFICIENTES, HAY QUE BRINDARLES AMPLIA VISIBILIDAD EN SU USO DE SERVICIOS.
generalmente se piensan como herramienta de uso externo pero las polticas tambin pueden ser herramientas poderosas para brindar contexto internamente. Si se necesita cambiar el proceso de ejecucin o conducta en base a quin realiza el pedido, qu formato necesitan los datos, o la hora del da, la poltica ejecutable jugar un rol importante en la habilitacin para la prestacin de servicios. Versiones. Cmo versionar a los servicios Web es algo que se debe manejar en forma diferente de los tpicos enfoques para otro software por su complejidad y extensibilidad. Por ejemplo, para versionar un servicio debe considerarse separadamente del proceso de versionar mensajes del servicio. Afortunadamente, con la flexibilidad inherente de XML y esquemas XML, hay una capacidad de soportar esta complejidad mediante mtodos de versin implcitos y explcitos
30
Consumo
SDKs de servicio Poltica externa
Administracin
Analtico comercial Administracin automatizada de poltica
Extensible
Soportable
Repetible
Utilizable
servicios autosuficientes y soportables es un proceso agilizado para brindar a los nuevos usuarios. Este modelo se usara para soportar usuarios internos y externos e incluye manejo de pedidos de acceso, creacin de nuevas credenciales, y provisin de alertas que notifiquen a los consumidores sobre cambios de servicio o estado de cuenta. Esta capacidad se apoya en la capacidad de auto suministro definida en la capa repetible (2) para brindar un proceso completo de suministro para consumidores de servicio. Monitoreo. El monitoreo y la visibilidad en la ejecucin de servicios es uno de los aspectos ms difciles de soporte de servicios en una escala empresarial debido a la naturaleza distribuida de los servicios Web. La nica manera de tratar este soporte en forma efectiva es abarcar los servicios como un sistema, porque el soporte sobre una base servicio por servicio constituye un esfuerzo frustrante e ineficaz. Aunque existen muchas maneras de establecer este sistema, se cree que una arquitectura de ejecucin comn es el medio ms efectivo. Auditoria. La clave para confiar verdaderamente en los servicios que se brindan en la organizacin es un modelo confiable de auditora que pueda servir como mecanismo de rastreo para saber qu personas realizaron qu actos y en qu momento. Este mecanismo no slo ayuda a resolver cualquier controversia que surja, tambin juega un rol estratgico en un programa de cumplimiento de una empresa. Capacidades de la capa extensible Ahora veremos las capacidades de perspectiva de implementacin para la capa extensible (4), orquestacin del servicio y colaboracin del servicio. Orquestacin del servicio. Para activar servicios Web en procesos comerciales bien definidos, se debe tener capacidad para orquestar. Esta capacidad implica flujos de trabajo que pueden
No obstante, esta capacidad es una caracterstica que las herramientas tpicas de desarrollo de servicio no aprovechan y exige algn planeamiento y soporte para su consistente ejecucin. La perspectiva de consumo de la capa soportable es dnde encontrar visibilidad de ejecucin, portal de servicios, y capacidades de SLAs explcitas: Visibilidad de ejecucin. Tal vez el nico, gran factor en la capacidad de escalar el uso de servicios Web es la capacidad de soportar mayor consumo de servicios brindando capacidades de autoservicio a consumidores existentes y potenciales. Si cada implementacin de servicio requiere una serie de llamadas telefnicas o correos electrnicos, algo de matemtica mostrar que la capacidad del equipo para desarrollar servicios rpidamente se consumir por las necesidades de soporte. Un slo portal que provea acceso a la informacin correcta puede ser un importante factor para reducir la demanda de los equipos de soporte y desarrollo. Portal de servicio. Esta capacidad se dirige a un recurso especfico al que puede accederse mediante un portal de autoservicio. Para hacer a los consumidores de servicio ms autosuficientes, hay que brindarles amplia visibilidad en el uso de los servicios. Ms visibilidad se basa en la capacidad de evaluar servicios brindando un nivel de acceso particionado que ayuda a entender qu ocurre durante la ejecucin para usar solucin de problemas y tambin deducir si algo no cumple con las expectativas. Esta capacidad compartira tambin actividades histricas para ayudar a los consumidores a rastrear la frecuencia con la cual las aplicaciones consumen el servicio. SLAs explcitos. Para fijar efectivamente las expectativas para los servicios a los consumidores, se debe brindar acuerdos explcitos a nivel de servicio (SLAs). Brindar SLAs es una capacidad difcil porque no existe norma disponible para comunicar esta informacin para servicios Web. No obstante, se pueden usar diversas formas de documentacin o comunicacin para compartir en forma eficaz informacin importante en esta rea incluso la expectativa de vida, tiempo de procesamiento anticipado para los pedidos, y cualquier tiempo planificado. Es importante notar que sin un nivel suficiente de visibilidad de servicio y administracin a nivel interno, sera casi imposible soportar SLAs. La perspectiva de administracin del nivel soportable contiene el modelo de suministro, monitoreo y auditora. Modelo de suministro. El siguiente paso para hacer a los
AUNQUE ES IMPORTANTE SABER DONDE UNO SE ENCUENTRA, LOGRAR UNA ORIENTACIN EXACTA ES MENOS IMPORTANTE QUE IDENTIFICAR LAS CAPACIDADES QUE SE NECESITAN TRATAR PARA CONTINUAR AVANZANDO EL VALOR DE LA HABILITACIN PARA PRESTACIN DE SERVICIOS EN LA ORGANIZACIN.
implicar procesos manuales y automticos pero permite definir un uso consistente y repetible de servicios que se pueden modificar con el tiempo. Colaboracin de servicio. Una vez establecidos los servicios como funciones autnomas que se pueden mantener y soportar, se puede comenzar a mejorar para brindar servicios ms complejos y sofisticados. Nos referimos a esta mejora como colaboracin de servicio. Mediante la colaboracin, se pueden definir los patrones de ejecucin sincrnicos y asincrnicos que permiten soportar procesos enteros que constan de servicios existentes. Como ejemplo, se puede tomar un servicio que enva correo electrnico y un servicio que devuelve todos los cambios de horario y exponer un nuevo servicio que enve un correo electrnico a los clientes notificndoles los cambios de horario. La perspectiva de consumo de la capa extensible incluye la poltica externa y las capacidades de SDKs del servicio. Poltica externa. Para establecer una infraestructura segura para proveer servicios a consumidores externos y socios, se deben establecer polticas externas, que incluyen no slo polticas de seguridad soportables externamente, sino las polticas que se han definido para la manera de que estos servicios se puedan unir a los servicios de terceros. Tales polticas incluyen marcas, pago, y trminos de uso que son importantes para proteger los intereses del negocio.
31
Un resultado tpico se brinda en Tabla 1. Este rating para cada capa se determina por la fortaleza de su correspondiente capacidad, que va del uno al cinco, la fortaleza con un ndice de cinco y la debilidad con uno. El promedio de estas cualidades dar un grado total para la capa, redondeado a medio punto. Por ejemplo, en la capa 1, si se tienen tres de las seis capacidades, medidas como fortaleza, dos medidas como adecuadas, y una como debilidad, la maduracin total del nivel ser 3.5. Lo que no se debe obviar en esta discusin sobre rating es el hecho de que ESOMM tiene el objetivo de actuar como mapa de ruta, ms que como herramienta de evaluacin. Aunque es importante saber donde se est, obtener una orientacin exacta es menos importante que identificar las capacidades que se necesitan tratar para continuar avanzando el valor de habilitacin para la prestacin de servicios en la organizacin. Mientras se desee cuestionar algunos interrogantes difciles en forma objetiva en todos los grupos relevantes, se debe tener buena comprensin para los desafos actuales. Si se aplica la estrategia y objetivos de la organizacin se debe poder identificar qu capacidades se deben tratar en el corto, inmediato y largo plazo. Es terriblemente difcil tener una conversacin concisa y Aplicacin del modelo constructiva sobre la empresa habilitada para la prestacin de Ahora que se tuvo la oportunidad de hacer un breve resumen de los componentes de ESOMM, ya se puede empezar a pensar cmo servicios. La meta es proveerles a las personas como arquitectas se puede aplicar a una organizacin. Para decirlo ms claramente, de software algunas herramientas y alguna informacin necesaria para tratar las preguntas correctas al ayudar a la organizacin a aplicar este modelo no se debe considerar como una actividad de lograr valor real mediante esta poderosa tecnologa de una sola vez o un proceso a corto plazo. En cambio, el modelo habilitacin. funciona mejor como plan de trabajo que se puede modificar con Con suerte este breve panorama de ESOMM brindar la el tiempo al crecer el uso de servicios y la experiencia. suficiente informacin para comenzar a aplicar algunos de los Lamentablemente, el inconveniente de usar el trmino conceptos en los esfuerzos de habilitacin para la prestacin de maduracin con un modelo es que las personas inmediatamente querrn saber en qu capa estn sus organizaciones para entender servicios. Cada capacidad fcilmente puede llenar un artculo entero, as que el feedback en cualquier rea es bienvenido. el sentido de su condicin o identidad. Al suceder esto, no hay Muchas personas han contribuido a ESOMM y los conceptos manera adecuada de responder a la pregunta "en qu capa est presentados aqu, pero me gustara agradecer especialmente a mi organizacin?" En vez de dar un grado integral en base a una Wolf Gilbert, Scott Beaudreau, Michel Burger, y Byron Howard por de las capas, tomamos el enfoque de dar a cada capa su propio nivel de maduracin, del uno al cinco, en base a incrementos de a sus aportes. medio punto. Un nivel de maduracin uno significa que no se ha tenido la Sobre el Autor oportunidad de tratar las capacidades de esa capa, y el cinco William Oellerman es arquitecto de soluciones en Microsoft significa que se han dominado todas las capacidades definidas en Consulting Services, que se dedica a dirigir y dar soporte de esa capa. oportunidades de habilitacin para la prestacin de servicios estratgicos en el sector de comunicaciones. William lleg a Microsoft en febrero de 2004 y trabaj ms de diez aos como Recursos arquitecto de software, abarcando consultora y roles corporativos Carnegie Mellon Software Engineering Institute en Avanade, Ericsson, y Micrografx. Ha sido lder de pensamiento Modelo de Maduracin de Capacidades para Software en el espacio de servicios Web durante seis aos como orador (SW-CMM) frecuente en las conferencias de la industria, autor de mltiples www.sei.cmu.edu/cmm/ artculos en revistas comerciales, y autor de Architecting Web Services (APress 2001). Cuando no se encuentra ponindose al da Red de Desarrolladores de Microsoft con las ltimas tendencias y desarrollos de habilitacin para Normas de Industria de Arquitectura para Orientacin al prestacin de servicios, William disfruta ayudando a su mujer a Servicio, Josh Lee ponerse al da con sus dos activas hijas. Microsoft Corporation, 2005.
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/aisforsoa.asp
32
Datos
Interaccin
Mensajera
33
Modelo de la tecnologa
pensamiento sobre la orientacin al servicio y la modelacin de sistemas conectados. En el mejor de los casos, el departamento IT debe proporcionar slo los aspectos de infraestructura de la solucin, y el desarrollo de la solucin debe estar mucho ms firmemente alineado con los grupos de negocios relevantes. La orientacin al servicio y los procesos asociados de desarrollo de software no posibilitarn por s mismos organizaciones orientadas al servicio. Es necesario que sean parte de una estrategia global que organice la transicin hacia la IT orientada al servicio. Modelacin clsica de sistemas Los enfoques actuales de modelacin con frecuencia se centran en los modelos de negocio y los modelos de tecnologa (Ver Figura 2). Idealmente, existe una alineacin y correspondencia estrecha entre el modelo de negocios y el modelo de tecnologa, pero en la prctica, esta relacin por lo general no es el problema. La razn principal son los departamentos IT internos que no trabajan con suficiente colaboracin y efectividad con los negocios. Mientras que los modelos de dominio de la entidad se utilizan por lo general en
PARA CONSTRUIR SISTEMAS EXITOSOS ORIENTADOS AL SERVICIO ES NECESARIO MODIFICAR LA FORMA DE PENSAR SOBRE LA ORIENTACIN AL SERVICIO.
una capa por encima del modelo de tecnologa para colaborar en la solucin del problema, este enfoque no tiende a funcionar bien, principalmente porque cumple con dos propsitos opuestos: la implementacin interna y la exposicin funcional del negocio. Es cuestionable que una alineacin verdadera entre los modelos de negocios y la tecnologa raramente se logra debido a que el espacio entre las dos perspectivas es simplemente demasiado amplio. Por lo tanto, Qu se puede hacer para estrechar la alineacin? Consideremos estos cuatro componentes esenciales: Profesionales IT con miras a lo externo. Los profesionales IT deben volverse ms abiertos a lo externo y deben conectarse ms profundamente con el negocio de su empresa. Si bien no es necesario que sean expertos en negocios, tienen que poseer un lenguaje objetivo que les permita comunicarse con la empresa sobre los negocios. Los arquitectos en particular, proporcionan los canales de comunicacin entre el negocio y los departamentos IT, y deben asegurarse de que los requerimientos y soluciones del negocio sean lo ms independiente posibles. La independencia puede lograrse trabajando muy de cerca con el negocio para asegurar que los contratos que ofrece el departamento IT estn mucho ms alineados con los requerimientos del negocio. En nuestra opinin, considerar esta perspectiva es la mejor forma (si no es la nica) de lograr la granularidad adecuada para los servicios que finalmente se construyen con un enfoque orientado al servicio. En nuestra lengua verncula comn de hoy en da hablamos de exponer la arquitectura del negocio. Si bien las capacidades de un negocio para una industria determinada son muy similares, o incluso idnticas, tanto los empresarios como los profesionales IT puede utilizar un conjunto estndar de preguntas para obtener informacin relevante sobre la arquitectura del negocio y as reunir los requerimientos. Al utilizar un conjunto estndar de
34
EL MODELO DE SERVICIOS ES AQUL EN EL QUE SE PUEDE CAPTURAR LA SEMNTICA NECESARIA PARA EXPRESAR LOS SERVICIOS QUE LOGRAN SOLUCIONES DE ACOPLAMIENTO MS ESCASO Y MS ABIERTAS A LO EXTERNO O AL NEGOCIO.
modelo de servicios es aqul en el que se puede capturar la semntica necesaria para expresar los servicios que logran soluciones de acoplamiento ms escaso y ms abiertas a lo externo o al negocio. El modelo de servicios proporciona una ubicacin lgica para definir los contratos que aseguran que el lado del negocio de su organizacin est alineado con el lado IT desde la perspectiva de los requisitos. Al insertar el modelo de servicios, los arquitectos estn forzados a considerar de forma explcita los artefactos del modelo de servicios en el proceso de diseo. El modelo de servicios ayuda a los arquitectos a descubrir artefactos en el nivel de abstraccin adecuado para satisfacer y alinear las necesidades del negocio. Tambin permite al analista de negocios participar parcialmente del proceso y lograr una mejor trazabilidad de los requisitos del negocio. Por ltimo, los empresario ya conocen la palabra servicio. Por ejemplo, en el contexto de la tercerizacin, un acuerdo de nivel de servicio (SLA) es bien conocido. Las funciones internas (que no se tercerizan) se comprenden de forma similar, a pesar de que (por lo general) estn asociadas con una expectativa de nivel de servicio menos contractual y formal (SLE). En vez de hablar de los servicios y la orientacin a los servicios, es mucho mejor hablar sobre los SLEs ya que los empresarios comprendern su valor. Un aspecto interesante del modelo de tres partes es que varios aspectos de los cuatro principios de la orientacin al servicio, originalmente desarrollados en el nivel de modelo tecnolgico, tambin se aplican a niveles de servicios y de negocios.
Modelo de la tecnologa
Figura 4 1) Representacin de la funcin del negocio, 2) Modelacin de los niveles del servicio y 3) Implementacin de los modelos en diferentes niveles de abstraccin
Modelo de tecnologa
Qu
Capacidades
SLE
Cmo
Organizacin
Motor de organizacin
35
Autonoma
Contrato
Poltica
El desarrollo orientado al servicio se basa en cuatro principios fundamentales que originalmente eran proporcionados por el equipo Windows Communication Foundation (WCF y su cdigo anterior llamado Indigo) de Microsoft. El equipo originariamente desarrollo los cuatro principios para describir la forma de utilizar el modelo de programacin WCF para construir servicios de Web mayoritariamente de grano fino que son ms relevantes para el modelo de tecnologa que para los otros dos modelos. Sin embargo, nos damos cuenta de que podran prestar una perspectiva importante al modelo de tres partes cuando se consideran los principios de servicio empresarial aplicables a niveles del modelo del negocio y de servicio.
que se realizan de forma interna dentro de un proceso de negocios particular no debe impactar las partes externas que dependen de este servicio o proceso particular. La autonoma a nivel del negocio tambin significa que los servicios individuales pueden alojarse dentro de una organizacin o pueden tercerizarse sin un impacto global sobre el proceso de negocios. La autonoma en el nivel del modelo de servicio requiere servicios intercambiables y de acoplamiento escaso. La autonoma a nivel del modelo tecnolgico requiere independencia para la implementacin. Los servicios comparten el contrato y el sistema, no la clase. Este principio tiene mucho que ver con que los servicios no expongan sus componentes internos. Por ejemplo, los pases publican las normas para completar los formularios que otorgan Principios de la orientacin al servicio una visa pero no proporcionan los recursos internos para Los cuatro principios son: los lmites son explcitos; los servicios completarlos. Como otro ejemplo consideremos la son autnomos; los servicios comparten el contrato y el sistema, interoperabilidad .NET y J2EE. Esta interoperabilidad no es posible no la clase; y la compatibilidad del servicio se determina en base a si se tratan de intercambiar tipos especficos de plataformas, sino la poltica. Analicemos cada uno con ms detalle. que ms bien se requiere un sistema o metamodelo intermedio. Lmites explcitos. La orientacin al servicio se basa en un La compatibilidad del servicio se determina en base a la poltica. modelo de transmisin de mensajes explcitos y cruzar un lmite se En el nivel del modelo del negocio, este principio afecta considera un acto explcito. Para utilizar la analoga de cruzar los esencialmente el gobierno y los SLAs y sus definiciones. La poltica lmites hacia otro pas, el acto de pasar de un pas a otro es un definida a nivel meta describe la capacidad semntica de un acto explcito. Desde un punto de vista del negocio, tiene la misma servicio en base a un conjunto de definiciones de sus capacidades. importancia que comprender y definir los lmites funcionales y Cada uno de los principios cumple una funcin importante en el modelo de tres partes e influencia el modelo tecnolgico, de UN BENEFICIO CLAVE AL PRECISAR CON CLARIDAD servicio y del negocio de diferentes formas. La Tabla 1 sintetiza las necesidades y artefactos para cada modelo en relacin con los LA CAPACIDAD DEL NEGOCIO ES QUE MIENTRAS cuatro principios. Veamos qu define cada modelo y cmo se debe LAS ESTRUCTURAS ORGANIZACIONALES Y LOS lograr su creacin.
FLUJOS DEL PROCESO VIENEN Y VAN, LAS CAPACIDADES ESENCIALES DE LOS NEGOCIOS TIENDEN A PERMANECER CONSTANTES CON EL PASO DEL TIEMPO.
Definicin de los modelos Los cuatro principios son: los lmites son explcitos; los servicios son autnomos; los servicios comparten el contrato y el sistema, no la clase; y la compatibilidad del servicio se determina en base a organizacionales dentro de la propia organizacin para identificar la poltica. Analicemos cada uno con ms detalle. claramente las capacidades demarcadas. Desde la perspectiva del El modelo de tres partes de la orientacin al servicio debe poder modelo de servicio, este principio requiere interfaces de servicio representar qu es capaz de realizar un negocio en particular sus que puedan ser consumidas de forma externa. capacidades funcionales claves ms que cmo actan las Los servicios son autnomos. Los cambios que se realizan en un capacidades. Analizaremos brevemente qu es una capacidad de servicio no deben impactar de ningn modo sobre otro servicio. Un negocio. La forma en la que funcionan los negocios dentro de una servicio debe poder volver a escribirse sin impactar de forma organizacin se representa en diferentes modelos de abstraccin a negativa a los consumidores del servicio. Continuando la analoga travs de tres modelos y se muestra en la Figura 4. de los pases extranjeros, un pas puede introducir un nuevo Funcin del negocio. Desde la perspectiva del modelo del sistema de impuestos independientemente de otro pas porque son negocio, lo que un negocio es capaz de realizar se expresa autnomos. De forma similar, a un nivel de negocios, los cambios identificando las capacidades empresariales. Identificar las
36
Creacin de modelos de negocios Para crear un modelo de negocios eficaz, es necesario poder conceptuar el negocio e identificar sus funciones comerciales Nivel 3 principales. Realizar esto, nos permite lograr servicios bien Capacidades del negocio alineados que se organizan de forma estrecha con los requerimientos de nuestros negocios. Distribucin de la capacidad. Esta tcnica fue desarrollada y perfilada por Microsoft para ayudar a conceptuar la forma en la que funciona un negocio y colaborar en la creacin de modelos. Una capacidad de negocio modela lo que realiza una funcin de negocio individual. No se relaciona con la forma en la que se logra capacidades de una empresa es una tarea fundamental mientras el negocio, sino ms bien con su comportamiento visible se desarrolla el modelo del negocio. Las capacidades y tcnicas para determinar las capacidades de una organizacin se analizarn externamente y sus niveles esperados de rendimiento (es decir, sus resultados). Un beneficio clave al precisar con claridad la ms adelante. Las capacidades funcionales poseen una relacin estrecha con la capacidad del negocio es que mientras las estructuras descripcin del contrato de servicios definido dentro del modelo de organizacionales y los flujos del proceso vienen y van, las capacidades esenciales de los negocios tienden a permanecer servicios. Ms all del nivel de abstraccin, esta relacin se constantes con el paso del tiempo. Una capacidad de negocio traduce a una descripcin de interfaces de servicio y en ltima abstrae y encapsula en un bloque de creacin simple a las instancia implementaciones del servicio dentro del modelo de tecnologa. (Ntese que si bien existe una fuerte correlacin entre personas, procesos, tecnologas y procedimientos asociados con una funcin de negocios determinada. La descomposicin del una capacidad y un servicio, no es necesariamente uno a uno). negocio en capacidades proporciona el mayor nivel de Niveles de servicio. Para asegurar la compatibilidad y la desacoplamiento para los contratos de servicio subyacentes. coherencia entre los modelos se presenta la nocin de niveles de Pagar a proveedores, despachar productos y generar facturas servicio. En el nivel del modelo de negocios, los SLEs definen los son ejemplos de capacidades del negocio. En un alto nivel de niveles de servicio esperados. stos representan las expectativas abstraccin, una capacidad del negocio es esencialmente una caja del negocio. Cuando se construye posteriormente un sistema de software para brindar el servicio, el SLE se traduce a SLA. Al nivel negra con ciertas semejanzas para servicios. Por ejemplo, ambas del modelo de tecnologa, SLA impacta la forma en la que se aloja tienen conexiones que son importantes y estn relacionadas pero separadas de sus funciones centrales. el servicio y la manera que se administra el servicio. Desarrollar modelos de capacidad. Un modelo de capacidad Por ejemplo, si las expectativas del negocio o los SLAs son muy constituye una jerarqua subdividida de capacidades de negocios exigentes, entonces sera inapropiado alojar el servicio en un que permite modelar el negocio como una red estructurada de servidor con procesador nico que no ofrece redundancia. Las capacidades, a diferencia de una red integrada fsicamente. Un expectativas y los acuerdos orientan los requerimientos de disponibilidad, confiabilidad, seguridad y manejabilidad de la solucin. De forma similar, si el negocio visualiza el sistema como MOTION DESCRIBE LA FORMA EN LA QUE SE EXTRAE Y DOCUMENTA LA INFORMACIN indispensable, este estado impone responsabilidades adicionales sobre las capacidades de gestin que uno incluye para la solucin. ESTRUCTURAL Y ORIENTADA AL PROCESO JUNTO La forma en la que se representan los niveles de servicios dentro CON LAS CAPACIDADES INDIVIDUALES. de cada uno de los tres modelos se muestra en la Figura 4. En la perspectiva del modelo del negocio, se puede proporcionar modelo de capacidad de negocio es un diagrama que describe la a la expectativa tanto informacin de calidad como de cantidad. La red de capacidades utilizadas por el negocio. El esquema que se fidelidad desde la informacin de calidad hacia la de cantidad se utiliza para construir un modelo de capacidades en diversos vuelve ms especfica en la medida que uno avanza hacia el niveles de abstraccin se muestra en la Figura 5. modelo de tecnologa. Uno pierde informacin de forma efectiva El nivel de abstraccin con el cual se puede visualizar una como parte de las descripciones. Sin embargo, el beneficio de capacidad de negocio vara. Las capacidades nivel 1 son las contar con un conjunto de modelos conectados, en particular si capacidades base comunes a la mayora de las organizaciones, sin pueden describirse en el nivel meta, significa que an se tiene la importar el sector de la industria. El nivel 2 y el 3 (y superiores) capacidad de comprender dnde se originan los requerimientos y proporcionan niveles de detalle adicionales sobre las capacidades qu se relaciona con qu. del negocio. Antes de examinar ms detalladamente cada nivel, Implementacin. Es necesario poder describir la forma en la que ntese que no es necesario descomponer todas las capacidades al se implementarn los modelos y poder expresarlos en detalle. mismo nivel de refinacin; sino ms bien, es necesario poner la Dentro del modelo del negocio, es necesario expresar los procesos atencin sobre las ms importantes para el problema o rea del de negocio externalizados que se han identificado, y luego es negocio que est en construccin. necesario un mecanismo de organizacin para describir los Nivel 1 Capacidades Base. Habiendo estudiado el negocio entre procesos de negocio en el modelo del servicio. Luego, cuando se varias industrias, Microsoft ha descubierto que a un alto nivel de implementan las organizaciones, es necesario tener alguna forma abstraccin los negocios de la mayora de las industrias exhiben de implementacin del flujo de trabajo de la tecnologa o motor de cinco capacidades bsicas junto con un grupo de capacidades del
37
LAS CINCO CAPACIDADES BASE COMUNES A LA MAYORA DE LOS NEGOCIOS SON EL DESARROLLO DE PRODUCTOS Y SERVICIOS, LA GENERACIN DEMANDAS, LA ENTREGA DE PRODUCTOS Y SERVICIOS, EL PLANEAMIENTO Y GESTIN DEL NEGOCIO Y LA COLABORACIN.
ser automatizado o manual. El proceso es esencialmente una organizacin de las capacidades. Las capacidades base tambin incluyen capacidades operativas, que son las cosas dentro de los lmites fsicos del negocio de la organizacin, y capacidades del entorno, que representan a todas las otras personas y compaas que interactan con el negocio y estn fuera de los lmites fsicos del negocio. Estas entidades pueden incluir clientes, socios, proveedores de servicios y autoridades normativas. Son importantes porque todos ellos poseen capacidades que influencian la forma en la que se lleva a cabo un negocio. Es importante destacar que el lmite del negocio no es el mismo que el lmite fsico de la entidad corporativa. Por ejemplo, si algo se terceriza, es an parte de la arquitectura del negocio; aunque el trabajo lo realice alguien fuera de la compaa. Existen algunos ejemplos interesantes de trabajos que se trasladan al otro lado de los lmites del negocio como el check-in en el aeropuerto, una funcin que en la actualidad, con frecuencia la realiza el cliente; es la misma capacidad que posee el mismo SLE. Sin embargo, hoy en da existe una tecnologa diferente que ha permitido que distintas personas realicen el trabajo, en este caso, el cliente. Esta visin global del ecosistema completo de capacidades permite que las organizaciones vean una variedad ms amplia de opciones Figura 6: Capacidades base comunes a la mayora de los negocios
Clientes
Proveedores financieros
38
Proveedores de logstica
Proveedores
2. Generar demanda
Interfaz
Tipo de puerto
capacidad parte del motivo por el cual los clientes, socios o proveedores realizan negocios con la organizacin? Capturar atributos como estos ayuda a definir el SLE en el nivel de negocios y luego los SLAs en el nivel de servicios. La descripcin variada de las capacidades puede pasarse a los grupos de desarrollo quienes pueden utilizar la informacin para seleccionar las tecnologa de implementacin apropiadas, hosts y tecnologas de implementacin en base al SLE orientado al negocio.
La metodologa Motion de Microsoft no lo estimula a prestar atencin a la estructura organizativa de factoring, herramientas o procesos directamente dentro del modelo de capacidades. Sino ms bien proporciona una forma efectiva para ayudarlo a lograr soluciones adecuadas para la implementacin. La metodologa define los siguientes cuatro pasos en el nivel ms alto: Establecer el contexto del proyecto. Se comienza documentando los objetivos del proyecto, luego se genera un mapa de capacidades base y se relacionan los objetivos del proyecto con el mapa de capacidades base. Comprender el negocio. Existen dos esfuerzos paralelos: Capturar vistas del negocio actual, que por lo general comprende la interaccin de los empresarios con las personas IT. Capturar detalles de la arquitectura del negocio, en esta etapa se comienza a construir el mapa de capacidades en el nivel superior. Completar la arquitectura del negocio as-is (como-est). En esta etapa se agregan ms detalles para crear una arquitectura de negocios. Identificar los siguientes pasos recomendados. Se puede haber completado el proceso en este punto o tal vez se ha identificado la necesidad de aplicar tcnicas de mejora para el proceso, anlisis de tercerizacin del proceso de negocios, y dems.
LAS CAPACIDADES DE NEGOCIOS PUEDEN DESCOMPONERSE EN CAPACIDADES DE NEGOCIOS MS GRANULADAS POR EJEMPLO, CUANDO ES NECESARIO DEFINIR ATRIBUTOS MS DETALLADOS.
Capacidades para servicios. Uno de los beneficios claves del enfoque de modelacin de capacidades es que permite identificar los elementos estables del negocio para modelar la arquitectura en base a ellos, y proporciona una capa imprescindible que alinea estrechamente la definicin de servicios en la arquitectura de sistemas conectados. Se pueden delinear lmites en torno a las capacidades por ejemplo, en el nivel del grupo y expresar cada capacidad con contratos. Despus, se pueden exponer estos servicios y crear una organizacin entre estas capacidades utilizando los contratos de servicios. Si bien la organizacin de las capacidades es una forma eficaz para analizar el estado actual de la empresa, tambin se puede construir un mapa de capacidades para un estado futuro deseado de la empresa y se puede definir la forma de transformar el negocio para mejorar su agilidad. Como ejemplo consideremos la tercerizacin. Al dividir las capacidades en aquellas que son centrales para la empresa y aquellas que no lo son, se puede decidir tercerizar a otra empresa las capacidades que no son centrales a travs de un proceso de re-ingeniera. Lo importante desde la perspectiva de la empresa es que la arquitectura soporta los cambios en el proceso del negocio sin cambiar la capacidad. La capacidad del negocio total permanece intacta.
La metodologa a veces se denomina metodologa de desarrollo por etapas porque existen distintos criterios que uno debe satisfacer antes de continuar hacia la siguiente etapa. Tambin es importante comprender que la metodologa motiva la repeticin en cada una de estas etapas. Una vez que se han completado las etapas, se utiliza la informacin que se ha descubierto para construir el modelo posterior. (Ver Recursos para ms informacin).
39
EL BENEFICIO PRINCIPAL AL DOCUMENTAR CAPACIDADES DE FORMA DETALLADA Y SISTEMTICA ES QUE PROPORCIONA UNA COMPRENSIN SLIDA DEL SLE QUE EL NEGOCIO POSEE PARA CADA CAPACIDAD DE NEGOCIOS.
productos y la otra genera todo su dinero de una cuota de membresa que le cobra a sus clientes. Si bien la industria es la misma, ambas compaas deben tener modelos de negocios diferentes. Aplicar a una compaa las mejores prcticas de la industria minorista crear valor en una organizacin y lo destruir en otra. Por lo tanto, es muy importante tener un entendimiento detallado y claro del modelo de negocios. Motion describe la forma en la que se extrae y documenta la informacin estructural y orientada al proceso junto con las capacidades individuales. Esto proporciona la orientacin para realizar la actividad de modelacin en s misma e incluye una gran cantidad de plantillas para ayudarlo a documentar toda la informacin requerida en torno a cada capacidad, (Ver la nota del recuadro lateral Cmo funciona Motion). La metodologa tambin proporciona orientacin para mostrar la forma en la que se complementan una cantidad de esquemas de mejoras de procesos de negocio existentes, incluyendo los programas Zachman, Lean, Six Sigma y la re-ingeniera de procesos de negocio. Motion no slo realiza cosas que este modelo no hace, sino que tambin colabora con las cosas que los otros modelos nunca tuvieron la intencin de realizar. La clave para comprender el motivo por el cual Motion es diferente reside en entender la distribucin de capacidades y la manera en la que difiere de la organizacin del proceso. La arquitectura de las capacidades, y no la arquitectura del proceso, se encuentra en el centro de la metodologa Motion. Al abstraer inicialmente (an ignorndolos) los procesos y analizar las capacidades del negocio, se puede obtener una vista ms estable del negocio de forma intrnseca que es particularmente de valor desde el punto de vista del versionado. Posteriormente, las capacidades se conviertes en bloques de creacin para los procesos. Si miramos ms all de las prcticas actuales, muchas de las cuales no soportan el ritmo rpido de cambio inherente dentro de los negocios de hoy en da, la metodologa Motion se desarrollo como una metodologa de arquitectura para los negocios que puede controlar los desafos presentes y futuros de la economa conectada. La metodologa Motion define aproximadamente 80 atributos que ayudan a documentar las capacidades. Algunos de los atributos que se deben documentar para cada capacidad se han enumerado anteriormente en el anlisis del nivel 3 de capacidades de negocio. El beneficio principal al documentar capacidades de forma detallada y sistemtica es que proporciona una comprensin slida del SLE que el negocio posee para cada capacidad de negocios. Posteriormente, este entendimiento permite obtener SLAs que a su vez ayudan a determinar la tecnologa de implementacin y la topologa de utilizacin ms adecuadas para la implementacin del servicio. Contar con una descripcin completa y detallada permite
40
41
098-105109
Subscrbase en : www.architecturejournal.net