NLTK - Bitácora - La instalación

Gratamente motivado por un proyecto que estoy encarando, estoy aprendiendo NLTK (Natural Language Toolkit), una serie de herramientas de Python enfocadas en el procesamiento informático del lenguaje natural, siendo este el lenguaje que utilizamos los humanos para comunicarnos.

¿Para que me sirve procesar el lenguaje natural utilizado por los humanos? En el extremo simple, para contar la cantidad de veces que se repite una palabra o frase. En el extremo mas complejo, para lograr una comprensión de lo que se quiere transmitir con una porción de texto, y lograr conclusiones o acciones sobre dicha comprensión.

Sin meterme demasiado mas sobre la explicación del procesamiento del lenguaje natural (haré un post cuando tenga una comprensión mayor del tema), paso a comentar los pasos que hice hasta ahora.

Instalé las librerías y herramientas necesarias para poder trabajar con NLTK. Seguí las instrucciones de la documentación pública del toolkit (http://www.nltk.org/download), por lo que el primer paso, la instalación, fue dado.

Ahora, solo resta ponerse a aprender en base a ejemplos, para ir haciendo cosas mas complejas a futuro.

Leer mas

¿Cual es el tamaño ideal de un equipo de arquitectura empresarial?

Según estuve leyendo en Gartner, establecen que según sus investigaciones el tamaño ideal de un equipo de arquitectura empresarial va inicialmente entre un 2% y un 4% del número total de personas que forman parte del área de IT de una empresa. No me cierra de esa frase que supone que Enterprise Architecture es solo IT, cuando tiene una gran relación con la tecnología, eso es cierto, pero también tiene mucho de estrategia y conocimiento del negocio.

No creo que se pueda establecer una relación tan clara y fuerte entre el tamaño de un equipo de EA y el área de IT, en primer lugar por lo antedicho, y en segunda instancia porque es necesario tener en cuenta muchas variables que son propias de cada organización, entre las que se me ocurren:

• El alcance que el área de EA tiene en la organización, ya que no es lo mismo un área que solo se encargue de definir la estrategia de la arquitectura aplicativa, que aquella que tenga dentro de sus funciones la definición de la estrategia de negocio, la arquitectura tecnológica y aplicativa y la definición de tendencias del mercado.
• El nivel de madurez de la organización, ya que si la organización ejerce una planificación estratégica ordenada, se requiere menos esfuerzo de arquitectura para llevarla adelante.
• El presupuesto alocado por la organización para las iniciativas de arquitectura hará crecer o decrecer la cantidad de personas que formen el grupo de EA.
• La madurez en la gestión de los proyectos, y la facilidad para hacer que cada proyecto tenga dependencia de las definiciones de EA definirá el nivel de esfuerzo requerido, y por ende la carga de trabajo que hará aumentar o decrecer al equipo.

Es necesario tener en cuenta muchas cuestiones para definir el tamaño del equipo, y no creo que exista una receta para definirlo. Pero creo que un buen comienzo es la definición de las actividades que realizará el equipo de arquitectura, los entregables que brindará y el nivel de servicio que se espera dar al resto de la organización. En base a esto, sumado a la cantidad de proyectos en ejecución y planificados y el nivel de participación, la tarea de definir el tamaño y capacidad de un equipo de arquitectura no es muy distante a la definición de un equipo para un proyecto cualquiera.

Leer mas

Organización de un equipo de EA

Una buena manera de establecer la organización de un equipo de arquitectura empresarial es tener en cuenta las funciones que debe cumplir el área, el valor que dicha función le brindará a la empresa, y la relación con los procesos de la empresa (como el ciclo de vida de desarrollo o el proceso de planificación estratégica).

Según lo veo, las funciones que cumple un área de arquitectura empresarial se pueden resumir en las siguientes:

• Definición, que cubre la creación y establecimiento de políticas, estándares y guías base, que son el entregable para ordenar la estrategia de arquitectura de los diferentes proyectos de la organización.
• Control, asegurando que los proyectos cumplan las políticas, estándares y guías base, y detectando la necesidad de cambio de dichos entregables definidos (ya que los mismos deben evolucionar y no quedar estancos). Esta función debe entregar un reporte del cumplimiento, excepciones o evoluciones necesarias.
• Acompañamiento de los diferentes proyectos, cumpliendo la función de consultor en cualquier etapa de los proyectos IT, y guiando sobre el cumplimiento de las políticas, estándares y guias base establecidas. Obtiene también información de los proyectos como retroalimentación al repositorio de información de arquitectura y a la planificación arquitectural. No solo se participa como un consultor que aporta conocimientos técnicos, sino también de estrategia y de negocio.
• Transferencia de conocimiento a todos los stakeholders de la organización o a quien requiera contar con los conocimientos generados por el área de arquitectura. Estos conocimientos no solo están relacionados a lo definido por la función de definición, sino también a lo que al área de EA conozca por su participación en todos los proyectos o la investigación sobre tendencias.
• Investigación, que es una función mas que importante, ya que sienta las bases de los conocimientos necesarios para permitir una evolución constante de la arquitectura para brindar siempre el valor requerido.
• Velar por que los activos generados por arquitectura (relacionados a arquitectura aplicativa, arquitectura de datos, arquitectura técnica, etc.) se encuentren actualizados y sirvan para la función que fueron creados, representar el cúmulo de información necesario para conocer el estado actual y establecer el estado futuro de la arquitectura.

Luego, es necesario mapear cada una de estas funciones a los procesos organizacionales, determinando claramente el valor que la función de EA le brindará a la o las etapas relacionadas. De esa forma, se comunicará claramente a los stakeholders el valor brindado (también es importante encontrar la forma de medir el retorno y el valor generado).

Teniendo estas funciones como base y el mapeo con los procesos organizacionales, se cuenta con una base para planificar la organización del equipo, establecer la cantidad de personas que deben formar el equipo de arquitectura, y comunicarlo a las personas adecuadas para la ejecución del plan de EA.

Leer mas

Sobre la impresión de fotos y el poder de las redes

Esta semana tuve una experiencia interesante. Todo empezó hace seis meses, cuando compré en Groupon una promo para imprimir 50 fotos digitales a un muy buen precio, en Megaphoto.
Obviamente, recién recordé hacer el pedido menos de un mes antes de que se venciera el cupón, y porque me avisó Groupon. Entonces elegi las fotos, e hice el tan esperado pedido. Ahí empezó la historia.
Luego de esperar 5 días (el tiempo en que Megaphoto atiende los pedidos de sus clientes según su sitio) Me informan que los pedidos de Groupon se atienden con 15 días de demora en lugar de 5. OK, acepté las nuevas opciones (en realidad no vi la letra chica del cupon). Por cuestiones que no vienen al caso, el pedido cumplió un mes, y yo aún no tenía mis fotos. ¿Que hice? Me puse en contacto con Megaphoto vía mail, obteniendo una respuesta bastante inesperada. Su excusa fué que no podían haber previsto que el 45% de los pedidos por Groupon fueran hechos el último mes, por lo que tenían un retraso y el pedido estaría en esa semana. Otra vez, me mordí los labios y espere.
Esta semana fué que mi paciencia colapsó, e hice uso de una herramienta sobre la cual siempre utilicé para informarme o para estar en contacto con amigos y conocidos, pero nunca para reclamar: Facebook y Twitter. Escribí en el muro de Megaphoto copiando a Groupon, y publique mis quejas en twitter mencionando a Megaphoto y Groupon. A la hora tuve la respuesta de groupon interesado en saber cual era mi problema, y Megaphoto recién respondió a Facebook al día siguiente de la publicación, pero eliminando la misma (la respuesta vino por mail directo a mi, y luego un llamado telefónico). Finalmente hoy ya tengo las fotos en mi poder.
No se que hubiera pasado de no ser por mi incursión en las redes sociales para quejas, pero lo que si se es que resultó mi acción tal como esperaba, sacando algunas conclusiones interesantes de todo esto:

• Siempre ver las letras chicas de los cupones, sea cual sea su proveedor
• Confiar en Groupon, su atención es realmente muy buena
• No confiar en Megaphoto
• Cuando tengo que hacer un reclamo, usar las redes sociales. Nada hiere mas a una empresa que su reputación social.
• Si tengo una empresa en algún momento, y la misma tiene perfil social, nunca eliminar las quejas de mis clientes. Responder por el mismo canal que hicieron el contacto. Megaphoto actuó muy mal eliminando el comentario (parece que solo dejan las publicaciones que hablan bien de ellos)

Leer mas

Mecanismos de integración

En la publicación anterior escribí sobre los puntos a tener en cuenta a la hora de definir una integración entre sistemas. Ahora, voy a comentar, desde mi punto de vista y experiencia, los diferentes mecanismos que existen para resolver esta cuestión, y cual es la relación entre estos y los atributos de calidad anteriormente mencionados.

Antes de empezar, voy a dividir los mecanismos, solo por claridad en la comunicación, entre mecanismos puntuales y masivos. Los primeros son aquellos mecanismos que permiten intercambiar información entre un sistema y otro en forma puntual, digamos de una interacción a la vez (por ejemplo, la solicitud del alta de un cliente, o la consulta de tweets ingresados por un usuario el último mes). Los segundos permiten la integración entre dos sistemas intercambiando grandes volúmenes de información. Los primeros generalmente son utilizados para interacciones online, mientras que los segundos son utilizados para integración batch. Los primeros son generalmente sincrónicos (o el usuario los ve de esa manera), mientras los segundos son naturalmente asincrónicos.

Ahora, una vez establecida esta división, transcribiré en resumidas cuentas cada uno de los mecanismos.

Mecanismos puntuales

Web Services

Los web services son un mecanismo de integración basado en una colección muy amplia de protocolos y estándares, basados todos sobre los mismos estándares sobre los que funciona la web (aunque existen implementaciones de los mismos sobre tecnologías de mensajería). El principal protocolo y estándar en el que se basa es SOAP (Simple Object Access Protocol), que define el formato en que se intercambia la información, dividiendolo básicamente entre header (cabecera que permite configurar el transporte), y el body (que contiene los datos a transmitir). Otro estándar importante es WSDL (Web Service Description Language), que define la estructura del mensaje, estableciendo los tipos de datos, campos y estructura de información a transmitir, sumado a UDDI (Universal Description, Discovery and Integration) para el registro de servicios web.

Con el paso del tiempo, se sumaron otros estándares al stack, para cubrir diferentes funcionalidades o atributos de calidad. De esta forma, tenemos por ejemplo WS-Security, WS-Reliablemessaging, o WS-transaction, que cubrieron aspectos que fueron dejados de lado por la definición inicial de SOAP, aunque agregándole complejidad.

Desde mi punto de vista, es una buena alternativa para interoperabilidad en ambientes heterogéneos, siempre y cuando nos basemos en el estándar SOAP sin ningún adicional del stack WS-*, ya que estos últimos no fueron implementado de la misma forma por todos los vendors. Aunque, si los sistemas a integrar son desarrollados en la misma tecnología y vendor tecnológico, el uso del stack WS-* soluciona diferentes cuestiones que son necesarias tener en cuenta.

Con respecto a la relación con los atributos de calidad, si se aplican bien los conceptos de WS, este mecanismo de integración se encuentra muy a favor de la coherencia semántica, unificación de mensajes y reusabilidad (heredado de la orientación a servicios). En lo que respecta a interoperabilidad, esto es una promesa, que no siempre es bien cumplida y en diferentes ocasiones presenta sus dificultades. El rendimiento de las integraciones se ve menguado debido a lo verboso de los mensajes (se estima que del total de un mensaje WS, solo el 30% representa datos con significado funcional). En lo que respecta a robustez, escalabilidad, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (ESB, Application Server, Web Server). En lo que respecta a los tests, tener el contrato (WSDL) separado de la implementación permite crear servicios "mockeados" que implementen la funcionalidad necesaria para realizar los tests, mientras que los contratos pueden verse como auto-documentados, un beneficio que da XML y el estándar WSDL a este tipo de integraciones.

Cuando utilizarlo:Debido a la carga en cuanto a performance, lo utilizaría en aquellos casos en los que se requiera seguridad, trazabilidad, y cuando la performance no sea un requerimiento fuerte. Si se requieren interfaces autodocumentadas, es la opción por la que se debe ir. También es apto en aquellos desarrollos donde se requieran facilidad de pruebas.

REST

Este mecanismo de integración, cuyas siglas significan REpresentational State Transfer, aparece como una alternativa a los web services, para integraciones basadas en la arquitectura WEB y HTTP como transporte. Es muy utilizado por los grandes jugadores de la WEB 2.0 (Facebook, Google, Twitter y otras lo utilizan para sus APIS).

REST presenta las integraciones basado en los recursos de los sistemas (principal diferencia con respecto a los web services, que se basan en funcionalidades), basándose en la arquitectura HTTP, e implementando los siguientes principios:

• Identificación de recursos a través de URIs (Uniform Resource Identifier)
• La manipulación de los recursos se realiza a través de sus representaciones, utilizando los métodos HTTP de manera explícita (GET - consultar un recurso, POST - crear un recurso, PUT - modificar un recurso, DELETE - eliminar un recurso), y basándose en la información obtenida de la representación de los recursos.
• Mensajes auto-descriptivos, de forma tal que cada mensaje tenga la información necesaria para procesarlo (por ejemplo, estableciendo su MIME type y gestión de cache)
• La hypermedia se usa como motor de gestión de estado. Si bien es un mecanismo de integración stateless (sin estado), la interacción entre consumidor y proveedor se realiza a través de hyperlinks o hypertext presente en la representación.

Como se basa en un estándar ampliamente aceptado (HTTP), intercambiando mensajes JSON (Java Script Object Notation), XML o YAML(Yet Another Markup Language), una de sus principales ventajas son la interoperabilidad, reusabilidad, unificación de mensajes y coherencia semántica (heredados de la orientación a servicios), sumado a un gran soporte de la escalabilidad (heredado de HTTP). Representa una gran mejora en lo que respecta a performance comparado con los web services, ya que disminuye la cantidad de datos innecesarios y sin significado de negocio. Otra vez, la robustez, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (web server). La seguridad es una de sus falencias, ya que como mecanismo básico tiene lo soportado por HTTPS (Secure HTTP), requieriendo agregados como proxies o firewalls para mayor complejidad (por ejemplo, un appliance de HW como Datapower podría cubrir estos requerimientos). El formato de mensaje, si bien no es tan autodocumentado como en el caso de web services, da un cierto soporte a la documentación y comunicación, siempre y cuando se establezcan criterios claros entre las partes.

Cuando utilizarlo: Este mecanismo es una muy buena alternativa a web services. Es fácil de usar cuando los recursos del sistema proveedor están claramente identificados, y no se tengan grandes requerimientos en cuanto a seguridad, trazabilidad y transaccionabilidad (ya que agregar estas características complejizarían el desarrollo). Si lo que se requiere es performance e interoperabilidad, es una excelente alternativa.

XML over HTTP

Este mecanismo se podría ver como un subconjunto de REST, ya que se basa en HTTP como transporte, y para la definición de los datos sensibles al negocio se establece XML para representar los mismos.

La única diferencia entre REST y este mecanismo, es que no cumple los principios establecidos por REST, ya que por ejemplo las interfaces o servicios expuestos pueden no estar representados como recursos, ni hacer uso de URIs para identificarlos.

También puede verse como una simplificación de los Web Services, ya que si bien utilizan XML para la transmisión de datos, no supone la carga de SOAP y WSDL.

Tiene, entonces, una mejor performance que los web services, pero no cuenta con la ventaja de ser autodocumentado, ya que no se requiere un estándar de definición de protocolos, y los mensajes muchas veces son definidos previamente entre las partes. La interoperabilidad estará dada, mientras se mantengan los acuerdos entre las partes, pero nada de los protocolos estándar utilizados juega en contra de esta calidad.

Otra vez, la robustez, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (web server, application server).

La seguridad estará dada por las plataformas subyacentes, mientras que la claridad de documentación y comunicación no es una característica de este mecanismo.

Cuando utilizarlo: No recomendaría utilizarlo, ya que es una versión mala de REST. En caso de aparecer como una alternativa, evaluaría seriamente el uso de REST antes que este.

RSS

RSS (Really Simple Sindication), es básicamente un estándar XML para sindicar o compartir contenidos en la WEB. Su principal uso es la difusión de información a usuarios que se subscriben a una fuente de contenidos.

Su principal uso es la lectura de noticias o novedades en sitios web o blogs, mediante herramientas "agregadoras" (web browsers, Google reader, Bloglines).

La arquitectura que implementa este mecanismo es básicamente un publish-subscribe, en el cual un ente publica información, que interesa a uno o mas consumidores, los cuales no son conocidos por el publicador.

Es muy útil para sistemas que requieran compartir información multimedia, o solo-texto, a diferentes aplicaciones implementadas en diferentes tecnologías, y desconocidas. No es simple realizar este tipo de integraciones, pero existen frameworks como RSS 2.0 (en C#), o RSS Framework (en PHP).

No es un mecanismo que este acorde a la comunicación entre personas o documentación, y cuyo soporte a la performance, disponibilidad, robustez dependerán del tipo de desarrollo implementado.

Por su poca o nula políticas de seguridad, debe usarse en aquellos casos en que la información sea pública y poco sensible.

Cuando utilizarlo: Implementarlo en aquellos casos donde se quiera dar a conocer información que no requiera demasiada seguridad, y que interesa a diferentes consumidores desconocidos, distribuidos en internet.

LDAP

LDAP (Lightweight Direct Access Protocol), permite en su utilización mas común la comunicación con un directorio de identidades, utilizando esta integración para autenticación y autorización.

Pero, por la forma de estructuración basada en una entidad principal, diferentes roles o características de dichas entidades, y dependencia entre entidades, es muy útil en algunos casos. Por ejemplo, en una empresa proveedora de internet, podría tenerse una estructura por ubicación geográfica (AMBA, NORTE, SUR), dentro de cada uno podría establecerse una división por tipo de cliente (gran cuenta, individuo), de los cuales se desprenderían los diferentes servicios que tiene activo el cliente, para su uso por la red, o los sistemas de CRM. ¿como se conectarían estos sistemas con el repositorio? a través de LDAP.

Tiene un uso muy acotado a ciertas funcionalidades, pero es bueno tenerlo en cuenta para no realizar un desarrollo importante teniendo herramientas que puedan resolver la problemática. Las herramientas van desde componentes software pagos (Microsoft Active Directory, Oracle Identity Management) a aplicación gratuitas (Microsoft ADAM, open LDAP).

Es aplicable solo a intranet, debido a la simpleza del protocolo. Las calidades de tiempo de ejecución dependerán de la solución de directorios seleccionada, mientras que las calidades de comunicación no son muy bien implementadas.

Cuando utilizarlo: En aquellos casos en que se requiera implementar una funcionalidad basada en una entidad, que permita establecer una estructura jerárquica centrada en la misma, estableciendo características en dicha entidad, implementar un motor LDAP y realizar la integración mediante dicho protocolo.

Sockets TCP

El protocolo TCP basa su fortaleza en la conexión de sistemas a bajo nivel, siendo uno de los protocolos fundamentales de internet. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el orden en que fueron transmitidos.

Al ser un protocolo de bajo nivel, las funcionalidades que soporten las calidades de tiempo de ejecución deben implementarse desde cero, siendo una solución poco simple de desarrollar. No es una buena solución para cuestiones asociadas al diseño de interfaces (salvo un gran esfuerzo de estandarización y acuerdos entre los participantes), ni para documentación.

Es uno de los mecanismos que mejor performance tiene, siempre y cuando el mensaje a enviar sea simple y no verboso (recordemos que los web services, por debajo, hacen uso de TCP).

La interoperabilidad puede verse como un fuerte, ya que este protocolo es aceptado por aplicaciones que van desde C o C++ hasta Ruby, .NET o Java.

Cuando utilizarlo: Cuando se requiera integraciones simples entre diferentes sistemas, sin requerimientos de seguridad, y cuando la performance sea una necesidad imperiosa.

CORBA

CORBA (Common Object Request Broker Architecture) es un estándar que permite el desarrollo de sistemas distribuidos facilitando la integración mediante invocación a métodos remotos, siendo los sistemas orientados a objetos.

Definido por el OMG (Open Management Group), establece las APIs, los protocolos y mecanismos necesarios para asegurar la interoperabilidad entre aplicaciones. Básicamente lo que hace es transformar la especificación de los servicios en cada tecnología a un IDL establecido y estandar, realizando las transformaciones necesarias. Existen implementaciones estándares para ADA, C, C++, Smalltalk, Java, Python, Perl y Tcl. Existen también proyectos como Remoting.Corba, que intenta integrar aplicaciones .NET con CORBA, o Corba-Ruby para aplicaciones en Ruby.

Su gran fuerte y objetivo es la interoperabilidad, aunque ya no se ve mucho en los nuevos desarrollos, ya que producen un detrimento de la performance y no siempre es tan independiente como se dice de la tecnología subyacente.

Produce dependencia entre las aplicaciones, ya que hace que un sistema conozca los objetos de otro sistema, lo que no es nada bueno para las calidades de diseño, y en tiempo de ejecución tiene diferentes cuestiones que depende de la tecnología en la que se encuentre implementada cada una de las aplicaciones involucradas.

Cuando utilizarlo: Cuando exista una aplicación CORBA que deba integrarse con otros sistemas.

Otros mecanismos

Existen otros mecanismos, que por su poca importancia, o implementaciones no vale la pena bajar a detalle. Estos son por ejemplo Etch, creado por CISCO como un reemplazo a los web services, sin demasiado éxito; o DCOM (Distributed Component Object Model), tecnología propietaria de Microsoft ampliamente usada en VB 6, caida en desuso en nuevas implementaciones.

Mecanismos masivos

Una problemática que se tiene a la hora de decidir utilizar este tipo de integraciones es la definición de cual es el volumen de información que me hace utlizar un medio masivo y cuando usar un online. A los efectos prácticos, vamos a decir que cuando la necesidad de obtener la información es puntual, o puede deberse a una única operatoria de negocio en un corto lapso de tiempo, y cuando dichas operatorias pueden darse desde diferentes fuentes - o usuarios, en un mismo momento, utilizaremos medios puntuales. En cambio, cuando las solicitudes o información provenga en un mismo momento, en forma masiva y en bloques, utilizaremos mecanismos masivos.

ETL

ETL (Extract, Transform and Load) se refiere al proceso implementado para extraer información de una fuente de datos, transformarla, reformatearlos, limpiarlos e introducirlos en otro medio de almacenamiento (DataMart, base de datos, archivos).

Es ampliamente usado en DataWarehouse, pero es muy útil para realizar integraciones que requieran un movimiento de un volumen grande de información.

Desde el punto de vista de diseño son buenas alternativas, ya que se pueden reutilizar los componentes de extracción, transformación y carga, sirviendo los mismos para definir diferentes flujos de integración, aunque hace que sea necesario conocer la estructura de datos de los sistemas origen y destino, lo que hace muy grande el acoplamiento. La performance dependerá de la forma en que se implemente, siendo muy buenas estas soluciones para asegurar robustez, seguridad, disponibilidad e interoperabilidad.

En cuestiones de diseño no es tan bueno, ya que pocas soluciones son auto-documentadas.

Existen en el mercado diferentes soluciones que implementan este tipo de integraciones, como Informática PowerCenter, Oracle WareHouse Builder, o Microsoft SQL Integration Services.

Cuando utilizarlo: Cuando se requiera integración mediante movimiento masivo de información entre diferentes plataformas heterogéneas utilizando diferentes fuentes de datos, y en los que no sea inconveniente el acoplamiento entre sistemas (cabe aclarar que las soluciones de ETL del mercado tienen la capacidad de desarrollar conectores, lo que minimiza el acoplamiento).

Mecanismos híbridos

Colas / Mensajería

Un sistema de mensajería permite la comunicación entre aplicaciones de forma indirecta. Esto se logra mediante el envío de mensajes a un administrador de mensajes, al cual están asociadas las aplicaciones, y es este último quien se encarga de administrarlos y distribuirlos según diversas configuraciones.

N

o es necesario especificar una aplicación de destino a la hora de enviar mensajes, sino que especifica el nombre de una cola.

Una aplicación puede tener una o mas colas de entrada y una o diversas colas de salida.

No es necesario preocuparse por de la tecnología existente en la aplicación destino, o si la aplicación destino no se encuentra disponible (en el caso de los mensajes asincrónicos), sino que el motor de colas se encarga de reenviar el mensaje si la misma se encuentra detenida o bien de iniciarla dependiendo del caso.

Un mensaje consta de dos partes básicas: el header (que contiene información de control que facilita el funcionamiento del administrador), y la data (información a intercambiar entre las aplicaciones).

En la implementación básica, una aplicación entrega un mensaje al administrador (motor) de mensajería, el cual mantiene el mensaje vivo hasta que llegue su tiempo de expiración, o hasta que el consumidor del mensaje lo tenga en su poder.

La integración vía mensajería se basa en la robustez mediante la persistencia de los mensajes enviados, la gestión de prioridades de entrega (por defecto, el mecanismo de entrega es FIFO, pero existen formas de adaptarlo), o expiración de los mensajes (ya que los mismos no pueden estar presentes en la infraestructura del administrador por siempre).

La implementación de colas de mensajería aseguran un bajo acoplamiento entre los sistemas (ya que implementa un modo de comunicación asincrónico, siendo el administrador quien se encargue de entregar el mensaje), al mismo tiempo que asegura la interoperabilidad (siempre y cuando se utilicen motores de colas estándares, estándares de facto o con conectores multi-tecnológicos, como IBM MQ, o implementaciones JMS como ActiveMQ o RabbitMQ).

Las calidades relacionadas a diseño dependerán del buen criterio que se implemente para crear las integraciones, lo mismo que sucede con las cuestiones de comunicación. No es una solución buena para el test.

Existen diferentes motores en el mercado, pasando de los propietarios (Microsoft MSMQ), a los estándares "de facto" (IBM MQ, Oracle AQ), y los estándares tecnológicos (Rabbit MQ, Apache Active MQ).

Cuando utilizarlo: Siempre que se pueda, y cuando el manejo de mensajería asincrónica no sea una contra (ya que, por ejemplo, se requiera conocer en el momento la entrega del mensaje y su respuesta). Tener en cuenta las tecnologías involucradas para seleccionar el motor de colas.

Archivos

La integración a través de archivos es una de los mecanismos mas utilizados desde hace ya mucho tiempo. Se basa en el acuerdo entre las partes involucradas acerca del contenido y formato del archivo, para que luego el proveedor de la información genere un archivo basado en el mismo ante cada necesidad de integración, y lo deposite en un repositorio pre-acordado. Luego, el o los consumidores de la información proceden a la lectura, interpretación, y actuación en consecuencia de la información contenida.

Este mecanismo de integración permite manejar la independencia entre aplicaciones, siempre y cuando los datos involucrados en los archivos no incluyan información relacionada a la implementación de un determinado sistema, y asegura la robustez y disponibilidad de la información (aunque la interoperabilidad esta asegurada). La seguridad es manejada a través de permisos en los repositorios, y mecanismos de encriptación (como PGP - Prety Good Privacy). No es bueno para documentación, ya que no es un mecanismo auto-documentable, salvo en los casos en que se utilicen estándares de integración masiva, como por ejemplo EDIFACT (Estandar desarrollado por la ONU para intercambio de documentos comerciales).

Cuando utilizarlo: Siempre que se pueda usar un ETL, lo priorizaría ante este mecanismo. En caso de no poder utilizarse ETL (por costos, por ejemplo), usarlo en cualquier integración masiva que no pueda reemplazarse por colas.

Base de datos

No voy a explayarme mucho sobre el uso de una base de datos para integrar varias aplicaciones. Solo voy a decir que, si bien es simple de realizar (ya que la conexión a base de datos es lo segundo mas estandarizado luego de los archivos), y que es un mecanismo robusto y seguro, no recomiendo su uso, ya que genera una dependencia muy fuerte entre los sistemas involucrados, hecho que luego es muy difícil de cambiar. Cualquier integración que se piense a través de base de datos, se puede reemplazar por los mecanismos antedichos.

Leer mas

Cuestiones a tener en cuenta en integración de sistemas

Cuando hablamos de integración de sistemas, o de la definición de los mecanismos mediante los cuales diferentes soluciones SW se integran para poder cubrir en conjunto los requerimientos de negocio, es necesario tener en cuenta atributos de calidad que guíen dichas integraciones, junto a los requerimientos funcionales que fomentan el desarrollo.

Estos atributos de calidad, a modo ilustrativo, pueden dividirse de la siguiente manera:

Calidades asociadas al diseño

Estas calidades están relacionadas a las tareas de definiciones de interfaces o conexiones entre sistemas, sumado al diseño de los protocolos, mecanismos y formatos de interacción. Si bien no impactan en forma directa en el funcionamiento de las interfaces, es muy importante tener en cuenta estos aspectos para hacer más feliz la vida de aquellas personas involucradas en el desarrollo.

Coherencia semántica
La coherencia semántica es mi atributo de calidad preferido. Cuando hablamos de integración, la coherencia semántica se refiere a la separación de incumbencias entre los diferentes sistemas. Se debe tener en cuenta que la información expuesta sea de importancia para los consumidores de la misma, pero sin dar a conocer información técnica de implementación. Así, por ejemplo, dar a conocer un id interno de una base de datos, si este no tiene ningún significado de negocio, es una mala práctica.

Unificación de mensajes

Hay que buscar que los protocolos definidos para las integraciones sigan una regla coherente para definir sus protocolos de integración. Si bien parece mas un atributo que aumenta la reusabilidad, es bueno tenerlo en cuenta por separado, para que lo tengamos siempre presente. Es muy incómodo ver, en un sistema, dos integraciones distintas que hacen referencia a un nombre de dos maneras diferentes, uno como "customer_name", y otro como "nombre_cliente". Definir estándares hace más feliz la vida de los involucrados en la integración.

Reusabilidad
Hay que pensar las integraciones de forma tal que puedan utilizarse para cubrir diferentes problemáticas, y que no sean aplicables a un solo caso en particular. Para lograr esto, es imprescindible pensar a las integraciones en pos de que las mismas tengan un sentido de negocio, y que una interfaz no dependa funcionalmente de otra. Por ejemplo, si tenemos dos integraciones, una denominada "cálculo de importe" que tenga como parámetro el importe básico y los impuestos, y otro "calculo de impuestos", que también tenga como parámetro el importe básico, pero además le sumamos la categoría impositiva del cliente, es una mala práctica hacer que el consumidor de la funcionalidad deba orquestar ambas integraciones (obteniendo el impuesto de "calculo de impuestos", para luego pasarlo a "calculo de importe". Sería mejor definir una única integración, llamada "calculo de importe", con parámetros importe básico y categoría impositiva, que internamente obtenga el importe y calcule el total.

Calidades asociadas al tiempo de ejecución
Diferentes cuestiones o decisiones que tomemos van a impactar en forma perjudicial o beneficiosa en el tiempo de ejecución de los servicios. A continuación voy a describir cada una de las calidades relacionadas con las integraciones.

Disponibilidad
La disponibilidad se define como la proporción de tiempo que un elemento SW se encuentra funcionando y trabajando. Es necesario conocer los requerimientos de disponibilidad de cada uno de las integraciones, y no aplicar una única estrategia a todo el sistema en su conjunto. Me gustaría que quede claro, en este punto, que no es necesaria siempre una disponibilidad del 100%, y que no todos los consumidores de las integraciones requieren la misma disponibilidad. Recordemos que a mayor disponibilidad, mayor costo y complejidad. No sumemos complejidad sin una necesidad real.

Interoperabilidad
Es vital tener en cuenta la necesidad de interoperabilidad que tendrá el sistema en cuestión para poder pensar en las cuestiones correctas. Se llama interoperabilidad a la capacidad que tiene uno o mas sistemas para intercomunicarse entre si, de forma tal que sea simple reemplazar un componente por otro, o modificar un sistema internamente sin impactar en el resto de los participantes de la integración. Además, está relacionado con la independencia tecnológica entre diferentes sistemas. Por ejemplo, si tengo aplicaciones desarrolladas en .NET, otras en J2EE y otras en Ruby, utilizaré mecanismos de integración agnóstico a las tecnologías, mientras que si todos mis sistemas se desarrollan en una única tecnología, podrá utilizar mecanismos propietarios (convengamos que este caso es poco probable).

Facilidad de administración
Este es un aspecto pocas veces tenido en cuenta a la hora de desarrollar una aplicación en general, y también aplica muy bien cuando pensamos en integraciones entre sistemas. Debemos tener en cuenta los requerimientos de administración, gestión de incidentes, trazabilidad y seguimiento de las ejecuciones. Es vital en entornos distribuidos, donde los logs de las aplicaciones serán muy diferentes entre si, y muy pocas veces nos permitirá seguir con detalle la ejecución de un flujo de integración.

Performance
La performance, rendimiento, o la medida que nos permite conocer el nivel de respuesta ante una petición a una integración es algo que siempre será visto como "de vital importancia", siendo el requerimiento que la respuesta "sea presentada lo más rápido posible". Lo que tenemos que saber es ¿como mido "lo mas rápido posible"? ¿como impactará el rendimiento solicitado en el resto del sistema? ¿Cual es realmente el requerimiento de performance?. Debemos tener en cuenta todo el conjunto (consumidor, proveedor, medio, entorno) a la hora de hablar de performance en integraciones, y actuar en base a las mismas.

Robustez
La robustez es la capacidad de mantenerse un sistema (o componente SW) en funcionamiento ante determinadas condiciones de falla o inesperadas. En el caso de las integraciones, está intimamente relacionado con la capacidad de mantener los mensajes o pedidos hasta que sean tratados, manejar transaccionabilidad de las interacciones, o devolver alguna respuesta al sistema consumidor aunque no sea mas que un mensaje de error (ejemplo, twitter y su famosa ballena).

Escalabilidad

La escalabilidad es la habilidad que tiene un sistema para aumentar su capacidad de procesamiento para soportar aumentos en la carga del mismo, sin perjudicar el rendimiento de las integraciones implementadas. Para lograrlo, hay que tener en cuenta, entre otras cosas, la capacidad de aumento de HW para lograr soportar mayor carga, el soporte a multi threading y multi core, y el aprovechamiento al máximo de los recursos utilizados.

Seguridad

La seguridad es la capacidad de prevenir acciones que perjudiquen al sistema, ya sean estas realizadas en forma maliciosa o accidental. Un sistema seguro es aquel que previene de accesos indebidos, al mismo tiempo que evita la modificación de los activos del sistema. Este es un atributo de calidad que no se lleva del todo bien con las integraciones, ya que puede penalizar el rendimiento, complicar la mensajería, y requerir cuestiones administrativas que son un tanto tediosas. Pero es necesario y muy importante tener en cuenta estas cuestiones, mas cuando las integraciones que exponga nuestro sistema serán la puerta de acceso a la modificación de datos y valores.

Calidades del sistema
Estos son atributos de calidad que deben tenerse en cuenta para poder dar una visión completa al sistema, no solo desde el punto de vista de mejoras en el diseño, desarrollo o tiempo de ejecución, sino también en el resto del ciclo de vida de un desarrollo.

Simplicidad de test

Las integraciones, al involucrar diferentes sistemas, grupos de desarrollo y equipo de personas, además de diferentes tecnologías y desarrollos diversos, presentan mucha dificultad para ser testeadas. Es necesario tener en cuenta los requerimientos de creación de escenarios de prueba y criterios de aceptación, y facilitar la ejecución de los mismos para comprobar la calidad del desarrollo.

Calidades de comunicación
Estamos hablando de integración entre sistemas, OK. La experiencia me dice que cuando pensamos en este tipo de integraciones, nos olvidamos que las mismas son desarrolladas por personas, y si las personas no pueden comunicarse, integrarse y trabajar en conjunto, estos desarrollos no llegan a ninguna parte. Es vital la capacidad de comunicación en estos equipos de trabajo, que por otro lado son multidisciplinarios, y con diferentes intereses. Estas calidades no impactan directamente en el desarrollo, ni en la ejecución, pero tenerlas en cuenta realmente nos hace la vida mas feliz.

Utilidad para comunicación al usuario final

Al hablar de integraciones, entendemos muchas veces que no es necesario tener en cuenta al usuario final, ya que todo lo relacionado con integrar sistemas pasa "entre bambalinas", y el no debería enterarse, en el mejor de los casos. En la práctica, este escenario feliz no pasa, y muchas veces debemos dar explicaciones sobre porque el sistema de venta vende pero el CRM no se entera de las nuevas altas, o simplemente mostrar la complejidad del cambio que nos están pidiendo, al impactar en muchos sistemas de nuestra arquitectura. En estos casos, debemos pensar las integraciones (o solo los nombres) de manera tal que sea simple comunicarlas a usuarios no técnicos. Tal vez solo baste con tener una planilla donde se listen todas las interfaces y sus nombres funcionales, aunque otras veces es algo mas complejo.

Utilidad para documentación
Que mejor que tener un desarrollo que se auto-documente. Eso nos ahorra mucho trabajo, y encima es mejor cuando este trabajo es algo que no es muy feliz hacer. Si la metodología de desarrollo que estamos utilizando no requiere muchísima documentación innecesaria, es muy útil pensar en que los diseños o desarrollos de las integraciones se auto-documenten (por ejemplo, utilizando WSDL o REST para definir los protocolos).

Notas finales
En esta entrada intente explayarme sobre aquellos atributos de calidad con los que me topé en mi experiencia al desarrollar integraciones. No quiere decir que todos existan en todos los casos, ni que debamos aplicar todos a todos los desarrollos, ni siquiera que sean los únicos. Pero creo que sirve como guía para comenzar, o ayuda-memoria para no olvidarnos de cosas que creo importantes.

Leer mas

Integración de sistemas

Como la próxima semana tengo que dar la clase de integración en APIT, me puse a pensar en el tema, y caí en la cuenta que es una buena excusa para volver a escribir.
En este primer post (primero de esta serie hablando de integración), tengo ganas de contar sobre la importancia de tener en cuenta ciertos aspectos en la integración de sistemas, mas que nada en areas de arquitectura empresarial (aunque la integración ya no se aplica solo a empresas, sino que cualquier desarrollo de SW debe ser capaz de integrarse e interactuar con otros).
En primer lugar, como dije anteriormente, hoy en día ya es virtualmente imposible que un sistema funcione totalmente isolado. El entorno complejo en el que nos encontramos hace que un desarrollo, para poder cumplir con la funcionalidad requerida, depende de otros aplicativos (apis de herramientas de redes sociales, servicios expuestos por otros sistemas de la empresa), lo que genera la necesidad de brindar soluciones complejas, formada por sub-soluciones sw separadas que forman un conjunto en base a integración.
Por otro lado, hay que tener en cuenta que la complejidad de las soluciones y desarrollos, sumado a ciertas estrategias de vendors, y la problemática de negocio cada vez mas intrincada, hace que una se desarrollen soluciones de SW "de nicho" especializados (CRM, Sales, Billing, Gestor de campañas, Inventario y logística), estrategia encontrada con lo que se veía hace unos años atras, con el surgimiento de las grandes moles ERP. Esta tendencia, por un lado hace que las soluciones se encuentren enfocada en resolver problemáticas puntuales y específicas de una manera muchas veces mejor que las soluciones genéricas, pero por otro lado hace necesario unir estas soluciones separadas, para poder lograr una coherencia funcional entre todas ellas.
La última oración me lleva al último punto, el hecho de que las soluciones a las problemáticas de negocio en las empresas no están dadas en su mayoría por soluciones separadas e isoladas, sino que el negocio funciona en base a una serie de sistemas coexistiendo en forma colaborativa.

Entonces, la integración de sistemas me gusta decir que son "Las decisiones de arquitectura que se toman durante el ciclo de desarrollo de un software, para permitir la coexistencia y colaboración con otras soluciones de SW, teniendo en cuenta atributos de calidad definidos para la solución, sin perder en cuenta cuestiones como independencia funcional, o coherencia semántica"

Leer mas

Impacto de las nuevas tecnologías en la industria musical

Desde hace unas semanas, estoy escribiendo un paper que trata sobre como las nuevas tecnologías (que cada vez son mas, y mas rápido aparecen) impactaron e impactan en el funcionamiento de la industria de la música.

Fue un desafío importante salir de la industria a la que estoy acostumbrado, y meterme en un ambiente nuevo y algo desconocido. Creo que valió la pena el esfuerzo, y salió algo bastante bueno. Posiblemente a futuro salgan nuevas versiones, con mayor tiempo dedicado y nuevas novedades.

En el siguiente link, pueden ver el paper del que les hablo (paper).

Comentarios, bienvenidos!

Leer mas

Intentando resolver los problemas de comunicación por email

Estoy convencido que los principales problemas en el día a día laboral, provienen de no saber comunicarse.

Y como una de las principales formas de comunicación a nivel corporativo es el email, la complicación es todavía mayor. ¿Porque? Creo que si existen problemas de comunicación interpersonal, se potencian cuando se plasman en escrito. Propongo algunos tips para poder evitar dichos inconvenientes. Muchas de estas cosas pueden parecer obvias o tontas, pero seguro si pensamos nos vamos a acordar de mails que no cumplian con dichos items.

Reglas básicas

Identificación: Es necesario que en el mail este identificado bien el remitente del mismo, y a quien esta dirigido. Una buena práctica es comenzar el mail con el o los nombres de los destinatarios, y firmar el mail al final.

¿De que estas hablando?: Personalmente, me molesta cuando los mails no tienen un subject relacionado al cuerpo del mismo. Es odioso. Es imprescindible, primero, poner un título a los mails, y que el mismo tenga relación con el contenido. Nada de "Hola", o "Eso que me pediste".

No gritar: No escribir todo el mail con mayúsculas. Queda muy chocante, y es complicado de leer. Utilizar este recurso solo cuando sea necesario, y para resaltar una parte muy acotada del texto.

Look & Feel: Que los mails sean agradable de leer. El hecho de no utilizar párrafos, o escribir todo en una misma línea, hace que se ahorre espacio (nada), pero hace ilegible el mensaje. Es útil dejar una linea en blanco entre párrafos (primero, usar párrafos), no escribir frases muy largas, y revisar ortografía y gramática.

No demorar la respuesta: La incertidumbre predispone de mala forma a la gente. Responder el mail lo mas rápido que se pueda, al menos para hacer saber que en un tiempo se le dará una respuesta mas concreta.

Practicar Yoga antes de responder: Cuando se reciba un email chocante, hiriente o que nos moleste por x motivo, no contestarlo en forma inmediata. Tomarse un tiempo necesario para enfriar el tema, y responder cuando nos encontremos tranquilos. Empeoraremos las cosas de otro modo.

No pedir confirmación automática de lectura: Pone en una situación incómoda al receptor. O hace pensar que no leyó el mensaje, o brinda información que tal vez no se quiera dar.

Longitud correcta: No escribir correos interminables, ni muy cortos que no digan nada. Una buena práctica puede ser releer el mail antes de enviarlo. O ponerlo a prueba en un grupo reducido (el grupo de trabajo mas cercano). Si es necesario enviar mucha información, es mejor escribir el detalle en un documento -que se adjunte, o en una wiki o blog, que se linkee.

Ordenar por importancia: Casi nadie lee los mails en forma completa. Aprovechémonos de la costumbre, y hagamos que el primer párrafo sea un resumen ejecutivo del resto del mail.

Ser cordial: Esto será muy obvio, pero es muy útil. Detalles como llamar al receptor por su nombre, o saludar al principio y final del mail, son tips que ayudan mucho. Sumado a escribir en forma amistosa y generosa o colaborativa, y no atacar a las personas, sino a las posiciones, casi asegura el éxito.

Aplicar reglas básicas de comunicación: Temas como el parafraseo para comprender, o no guardarse puntos por mas obvios que parezcan (no todos conocen lo mismo que uno), son reglas que ya se dan como aplicadas, y muy útiles.

No reenviar a los reenviados: Antes de reenviar un mail, corroborar quienes lo recibieron, para no generar mails repetidos en la casilla de nadie.

Cuidar el lenguaje: No utilizar lenguaje grotesco ni hiriente en los mails. Recordemos que quedan guardados!

Ser imparcial: No escribir el mail desde una posición de absoluto conocimiento, sino bajar a la tierra el concepto buscando que le otro no creo que estamos transmitiendo estar encima de otro. Usar palabras como: creo que, considero que, me parece que, entiendo que, según mi punto de vista, desde mi perspectiva.

Reglas básicas de redacción

Algunos tips básicos de redacción, útiles para tener en cuenta. Conocer estos elementos es interesante, mas que nada para no repetir conectores y no aburrir:

ELEMENTOS DE ENLACE: Son partículas o expresiones que ayudan a lograr la continuidad en el enlace de ideas dentro de los párrafos, o para relacionar unos con otros. Estas son:

• Las que indican sucesión de la misma idea: al principio, en segundo lugar, a continuación, por último.
• Las que indican limitación: pero, no obstante, con todo, sin embargo.
• Las que indican exclusión: por el contrario, antes bien.
• Las que indican concesión (derecho a ): aunque, si bien, es cierto que.
• Las que indican distribución: bien (unos)... bien (otros).
• Las que indican consecuencia: por lo tanto, pues, luego, por consiguiente.
• Las que indican continuidad: pues bien, ahora bien, además, por otra parte, como decíamos.

CONECTORES: Relacionan conceptos mostrando un efecto de relación particular entre los mismos:

• ADICION Y, también, además, más, aún, por otra parte, sobre todo, otro aspecto.
• OPOSICION Pero, sin embargo, por el contrario, aunque, no obstante.
• CAUSA EFECTO Porque, por consiguiente, por esta razón, puesto que, por lo tanto, de modo que, por eso, en consecuencia, esto indica.
• TIEMPO Después, más tarde, antes, seguidamente entre tanto, posteriormente, ahora, luego.
• AMPLIACION Por ejemplo, en otras palabras, es decir.
• COMPARACION Tanto como, del mismo modo, igualmente, de la misma manera, así mismo, de igual modo.
• ENFASIS Sobre todo, ciertamente, lo que es peor.
• RESUMEN O FINALIZACIONFinalmente, en suma, en conclusión, par terminar, para conclusión, etc.
• ORDENPrimero, segundo, siguiente, luego, a continuación, seguidamente, en primer lugar, por último, aún, al final, al principio, al inicio, pronto.
• REAFIRMACIONCon todo, decididamente, en efecto, en realidad, decisivamente, a pesar de todo, de todos modos, justamente.
• CONTRASTEPor otra parte, en cambio, por el contrario, de otra manera, por otro lado.
• CONDICIONSi, supongamos, supuesto que, siempre que, dado que.
• EJEMPLOSTal como, como caso típico, en representación de, como muestra, verbigracia, por ejemplo.

Principalmente, no olvidemos que del otro lado hay PERSONAS

Leer mas

Cambiando el enfoque de la arquitectura empresarial

Cursando la MGSTT, en UDESA, me pregunté como los conceptos de negocios que estaba adquiriendo podían ayudar a la mejora de la estrategia de arquitectura empresarial. Leyendo la nota de InfoQ sobre el mismo tema, me di cuenta que es factible aplicar los conceptos (algunos, no todos) para mejorar el alineamiento entre EA y el negocio. Algunos:

• Porter: No creo que ver las cinco fuerzas puede ayudar a mejorar la forma en que la EA soporta los requerimientos del negocio (aunque nunca esta de mas ver que esta haciendo la competencia), pero el diamante de competitividad seguro dará una visibilidad sobre las capacidades estratégicas de la empresa, y mapear eso hacia los activos de arquitectura podría ser muy útil. Por otro lado, el diamante de competitividad permite ver que hace falta para seguir en el mercado, lo que permite ver a que debe adaptarse la arquitectura.
  
• Métricas: Es importante que la EA sea medible y medida, publicando las resultados para ser conocidos por toda la empresa, y asi ganar apoyo. Algunos ejemplos de métricas de EA que sería util mostrar para demostrar la alineación EA-Negocio: Reutilización de activos de EA (lo que redunda en mejora en el time to market), % adopción a arquitectura de datos por los sistemas (lo que redunda en menor acoplamiento, por ende mas adaptabilidad), % de adopción de estándares de integración, tiempo de implementación de proyectos EA compliance VS non EA compliance.
• Modelar en base al negocio. La velocidad con la que cambia el negocio, y la lentitud que IT tiene para adaptarse, hace que la EA deba adelantarse a los requerimientos. Lo que la EA debe hacer es tener la capacidad de visualizar la estrategia de negocio, tal vez observando que es lo que pasa en otros mercados (por ejemplo, en telecomunicaciones ver los mercados europeos o brasilero es bueno para ver que puede llegar a pasar en uno o dos años en Argentina), y mapear los futuros requeriemientos utilizando una estrategia de modelado orientada al negocio, como la que se nombra en BusinessModelAlchemist.
• Finanzas. La EA debe tener en cuenta como las soluciones serán soportadas por el presupuesto asignado. Tener conocimientos básicos de manejo de finanzas es importante para soportar la EA. Conocer los flujos de fondos, o la gestión de un presupuesto o forecast sirve para que las soluciones propuestas sean "vendidas" al negocio.
• Negociación+Coaching. La negociación es otro punto importante a la hora de establacer una EA, para poder llevar a cabo la estrategia IT definida para dar soporte al negocio. Todo, sumado a un coaching activo en las áreas de IT.
  

Como se ve en los puntos anteriores, el enfoque propuesto para la nueva EA tiene poco que ver con aspectos técnicos, sino que tiene mucho que ver con aspectos de negocio, entendiendo como funciona la empresa donde se desea establecer una estrategia de EA, para ver como definir el camino a seguir. Es por eso que concuerdo con la nota de InfoQ, y veo que los frameworks existentes para EA se quedan cortos con el soporte que se necesita. Van solo a como se mapean los activos de negocio contra los activos IT, pero no a como alinear la arquitectura al negocio. Es necesario "ablandar" la arquitectura empresarial para que sea un éxito.

Leer mas