http://www.microsoft.com/windows/windowsmedia/player/11/default.aspx

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Prueben de agregar a estos dos contactos en su MSN Messenger, ambos responden a preguntas y hasta son capaces de mantener una conversación.

 

BTW: estoy probando MSN Messenger 8 + info en: http://spaces.msn.com/members/messengersays/PersonalSpace.aspx

 

 

 

 

Hace unos tres meses intercambiando ideas con Diego (Dagum) y Roberto (Schatz) nos planteamos armar un Newsletter sobre temas de Arquitectura que fuese útil en este contexto en el que nos vemos desbordados por la cantidad de artículos, noticias, posts en los blogs y webcasts, en definitiva información que proviene de distintas fuentes y en distintos formatos.

 

La pregunta a responder era: ¿cómo ayudar a los interesados en temas de arquitectura a tener un buen resumen mensual de artículos y noticias?

 

Así fue que nos abocamos a crear un newsletter breve, mensual, con una selección de artículos, noticias, links de referencia y artículos escritos localmente (por colaboradores de la comunidad y por nosotros mismos). Martín (Cabrera) fue quien rompió el hielo escribiendo el primer artículo exclusivo para el newsletter, gracias Martín!

 

Por otro lado, nos propusimos que el diseño fuese simple, agradable a la vista y distinto a los estilos tradicionales de los Newsletters de Microsoft. El diseño es 100% responsabilidad de Ale (Alejandro Gozalves), un artista, uno de esos pocos dichosos que tienen el gen de excelente desarrollador y también el de excelente diseñador gráfico… sí, sí, existen quienes pueden hacer las dos cosas, y bien!.

 

La pasada semana lanzamos el 2do número con un artículo de Gux (Gustavo Larriera) - otro de nuestros gurúes –, un Webcast de Diego (Dagum) y las novedades y artículos recomendados del mes. Adicionalmente en este segundo número agregamos una encuesta para entender cuáles son los principales temas de interés y profundizar en éstos.

 

Créannos que armar esto con periodicidad mensual es todo un desafío, más aún con el objetivo de mejorar la calidad número a número. Gracias Gonzalo (Laguna) por el apoyo en la coordinación de la recolección de contenidos!

 

La invitación: es a todos aquellos que quieran participar como redactores a que lo hagan! (mail to: arnewssc@microsoft.com)

 

Todos los números estarán publicados en: http://spaces.msn.com/members/architecturesc/; para suscribirse: suscribirme al newsletter

 

El pasado viernes (11/11) tuve la oportunidad de participar y presentar en el SimpoCIO, un evento de dos días organizado por CIOs de las principales empresas de la Argentina en el que entre otras sesiones invitan a proveedores de tecnologías para presentar temas que son de su interés.

 

Compartí una sesión con IBM, Oracle y SAP (30 minutos de presentación cada compañía y luego 60 de preguntas y respuestas) en la que cada uno dimos nuestra visión y propuesta tecnológica respecto a las tendencias de:

·          Service Oriented Architecture

·          Business Process Management

 

La sesión fue introducida y liderada por Silvio Szostak, CIO de Quilmes, quien presentó al comienzo los principales conceptos de SOA y BPM y los cuadrantes mágicos de Gartner referidos a dichas tendencias para luego dar lugar a las 4 presentaciones (IBM, Microsoft, Oracle y SAP –en orden alfabético-); para cada una de las presentaciones Silvio hizo un breve resumen de lo expuesto y luego organizó la sesión de preguntas y respuestas.

 

Por IBM participó Alberto Arciniega - VP Websphere IBM Américas, de NY/US -, por SAP Jason Wolf – SVP New Product Induction, de California/US -  y por Oracle no recuerdo su nombre L - de India -.

 

Con Jason en particular tuvimos la oportunidad de hablar un buen rato dado que fuimos los dos puntuales que llegamos 8:02 minutos (la invitación decía Recepción de 8 a 9hs J). Hablando de nuestras presentaciones vimos que teníamos varios puntos de coincidencia, más allá de la propuesta tecnológica, coincidencia en la forma de abordar soluciones SOA o BPM: tecnología + procesos/metodología (aspecto que se vio claramente diferenciado con las propuestas de IBM y Oracle). También teníamos para coincidir hablando de la integración entre nuestras tecnologías: Microsoft BizTalk Adapter para SAP y Mendocino (Microsoft Office como cliente de SAP), tecnologías de a las que ambos hicimos referencia en nuestras respectivas presentaciones.

 

En las cuatro presentaciones hubo varios puntos de coincidencia como:

- confirmar que vemos dichas tendencias

- los componentes básicos que debe incluir una solución de BPM: Workflow (en el que se puedan definir procesos por parte de quienes conocen el negocio, no necesariamente técnicos), Herramientas de Captura de Información, Soporte para la Integración y Automatización de aplicaciones y Monitores de Performance (de los procesos) y herramientas de Análisis.

- el valor de negocio de SOA, y la importancia de asegurarse de que lo tenga

 

De nuestra presentación, me interesa destacar:

-          Si habamos de SOA o BPM, ambas requieren: tecnología + procesos/metodología (no hay solución tecnológica mágica)

-          Las oportunidades que abren Windows Workflow Foundation (Workflow presente en cada server y en cada desktop) y Windows Communication Foundation

-          La importancia del front-end en una solución de BPM: Formularios ricos, Web, Win, Smart Devices, Office, etc.

-          DSI: el rol del management en estas soluciones

-          A la hora de hablar de SOA, debemos saber distinguir SOA de SO

 

Sobre las preguntas, destaco:

- ¿cuál es la forma para abordar una Arquitectura Orientada a Servicios?, para la cual nuestra repuesta fue comenzando con “un” proyecto y con un importante “trabajo” de arquitectura para definir los servicios y más importante aún: la arquitectura empresarial, en la que “ese” proyecto se verá inmerso, siendo el primero de varios más –aquí también coincidíamos con Jason-.

 

Un gusto participar de este evento.

 

Muy buenos hands-on the WPF

http://msdn.microsoft.com/windowsvista/building/presentation/hands_on_lab/default.aspx

 

250 horas, 200 sesiones: online at http://microsoft.sitestream.com/PDC05/

 

Enjoy it!

Recomiendo este Webcast:

 

MSF 4.0: Adaptación e Implementación de Guías de Proceso en Visual Studio 2005 Team System)

Visual Studio Team System provee entornos enriquecidos y soporte integrado para procesos de desarrollo de software. Más allá de que esta nueva plataforma de desarrollo incorpora dos procesos de desarrollo predefinidos, algunas organizaciones querrán incorporar su “fórmula secreta” para obtener ventajas competitivas. Esta presentación muestra, mediante demos, cómo modificar los procesos existentes, Microsoft Solutions Framework (MSF) para Desarrollo de Software Agil y MSF para Mejora de Proceso CMMI (Capacity Maturity Model Integration), de modo de incorporar su proceso de desarrollo de software en Visual Studio Team System. Presentado por Diego Dagum, Microsoft Architect Evangelist.

 

A pedido de varios… mi RSS Reader recomendado:

http://www.rssbandit.org/

Hace un par de años atrás, en el Encuentro Anual de la Comunidad GeneXus presentábamos con Wilson sobre "Arquitecturas para crear sistemas conectados", todo un desafío por aquellos tiempos (sólo dos años atrás:)). En aquel momento cerramos con tres conclusiones:

1) Heterogeneidad como un hecho

2) Interoperabilidad como una necesidad

3) Arquitecturar como un desafío

 

Hoy, dos años después, los dos primeros puntos están en nuestra agenda y en las decisiones de arquitectura de todos los días.

 

Sin embargo, el "arquitecturar" o el llevar adelante el "proceso de diseño arquitectónico" creo que sigue siendo un desafío, es más: uno de los desafíos más importante que tenemos que afrontar. Sobre este punto estaremos presentando esta tarde: "Arquitectura de Software puesta en práctica" en el XV Encuentro Internacional de GeneXus.

 

En uno de mis posts anteriores hablaba sobre la complejidad, la creciente complejidad de los Sistemas que debemos abordar, complejidad condicionada y consecuencia de los escenarios de negocio que éstos deben resolver. De ese post surgió un ida y vuelta de mails con gastón (Mousqués) sobre si la complejidad es realmente producto de "los escenarios de negocios" o es consecuencia directa de que las tecnologías son complejas de por sí. Para dar otra visión que aporta a la discusión, Diego habla en su blog sobre los ciclos de renovación de software y la evolución de las tecnologías, de lo cual comparto en varios de sus puntos y al que agrego: el rol de los Grandes Productores de Software <GPS>, Microsoft, IBM, SUN, Oracle, BEA, etc. es no sólo desarrollar y generar las tecnologías para resolver los problemas de hoy, sino que tienen la responsabilidad (es nuestro negocio y nuestro rol) de adelantarse, uno, dos o los pasos que sea necesario para generar tecnología y al mismo tiempo estar listos para una nueva evolución de "escenarios de negocios" a resolver y de Sistemas que los soporten, habiliten, agiliten y contribuyan al éxito de éstos.

Mi punto es aquí entonces: la complejidad de la tecnología como consecuencia de los escenarios de negocio de debemos resolver.

Otro actor importante en este juego es el ambiente de investigación académico, con el rol de generar la teoría , fundamentos y bases de las ciencias de la computación y sistemas de información; teorías que luego se "equilibrarán" con la práctica a través de las GPS y del uso de las empresas consumidoras de tecnología.

 

Hablamos de la complejidad en este contexto del desafío que implica el diseño arquitectónico, mi segundo punto es la dependencia en dos fases: la primera es la más clara y sencilla, dependemos que los sistemas funcionen dado que tenemos buena parte y cada vez más -sino todo- nuestro negocio funcionando sobre éstos. La segunda, no tan clara, es la dependencia de nuestras prácticas de ingeniería de software (dentro de las que incluyo el diseño arquitectónico): ¿cómo impacta nuestro negocio si nos atrasamos con un sistema del cual dependía un nuevo servicio para el cual ya está hecha toda la campaña de marketing?, ¿cómo impacta si el establecimiento de un nuevo canal de ventas o un nuevo servicio a nuestros clientes requiere un proyecto de meses?. Hablamos entonces de la dependencia de nuestra capacidad de estimar y ejecutar en tiempo, de lograr los niveles de calidad necesarios y de lograr sistemas que se adapten rápidamente al negocio para al fin del día ser más competitivos (o no menos que la competencia) a través de la tecnología cualquiera sea el tipo de negocio que desarrollemos.

 

La pregunta es entonces: ¿cómo afrontar la complejidad y la dependencia?

Mi respuesta en una frase es: "poniendo en práctica principios y prácticas de arquitectura de software".

Vale la aclaración de que los conceptos de "arquitectura de software" y de "arquitecto de software" en mi opinión están hoy en día sobre utilizados y algo desvirtuados (el concepto de "framework" sufre del mismo mal)... esto será motivo de otro post.

 

La caja de herramientas

Uno de los principales roles del arquitecto de software es: administrar la caja de herramientas. Ésta es el conjunto de los recursos con los que cuenta el arquitecto para ser o no utilizados, tan variados como: metodologías (XP, Scrum, RUP, MSF, etc.), prácticas (SAAM, Refactoring, etc.), patrones, modelos (MDA, UML, etc.), tecnologías (.NET, Java EE, etc.), estándares, herramientas, etc. Donde vemos desde elementos conceptuales como las metodologías hasta los más tangibles como las herramientas.

Y aquí viene la pregunta de quien se plantee "quiero ser un arquitecto de software", ¿tengo que aprender de cada uno de estas herramientas? Y mi respuesta es sí, con el nivel de detalles suficiente como para poder evaluarla a la hora de tomar una decisión; y aquí no hablamos de dominar una tecnología, sino de tener los elementos necesarios para poder incluirla en el árbol de decisiones.

 

He aquí EL punto: el árbol de decisiones y la forma de abordarlo (y en este punto es que con gastón alineamos nuestras visiones y el análisis del escenario).

 

El árbol de decisiones <ADD>: es la descripción ordenada de todas las opciones posibles de elementos de la caja de herramientas para un escenario particular.

 

La forma de abordarlo: el análisis de requerimientos no funcionales <ARNF> ("ilities", "Quality attributes"); desde mi punto de vista una de las prácticas menos realizadas y más importantes.

 

El ADD y el ARNF, un ejemplo práctico: a la hora de pensar en el desarrollo de un nuevo sistema de RRHH me podría plantear las siguientes dudas:

* Qué tipo de aplicación cliente voy a proveer a los usuarios? Web? Windows? Smart Client?

* Cómo voy a comunicar a las aplicaciones clientes con el servidor? Web Services?, Remoting?, RMI?, MQ?

* Usaré ORM (Object Relational Mapping)?

* Hasta qué punto usaré Stored Procedures?

* Cuál es la moda?, qué es lo último?

Y en estas últimas dos preguntas es que comenzamos a fallar en nuestro rol, sobre todo cuando habitualmente son las dos primeras y nos hacen olvidar las restantes, y no llegamos al ADD y menos aún al ARNF.

Antes de las preguntas anteriores deberíamos entender el escenario, los RNF:

* cuáles son las características de usabilidad requeridas

* requiere capacidad de procesamiento off-line

* con qué tipo de red cuento?, cuáles son las consideraciones de seguridad de ésta?

* qué cantidad de objetos y entidades voy a manejar?

* con qué recursos cuento?, personas, sw, hw, etc.

* etc. etc. etc.

Será en función de las respuestas a estas preguntas que armaremos y recorreremos nuestro ADD.

 

Como Arquitecto de Software: es nuestro rol evaluar las mejores herramientas (de la "caja") para un escenario y un problema particular.

 

En resumen, quiero destacar los conceptos de:

- El conocimiento de la "caja de herramientas"

- El Análisis de Requerimientos NO Funcionales

- El armado del árbol de decisiones

 

En el próximo post agregaré referencia bibliográficas y artículos en los que se pueden profundizar estos conceptos.

 

El tema da para mucho más, y se abre en varias direcciones, continuará...

Links de de referencia de las presentaciones que dimos hoy en el XV Encuentro Internacional de GeneXus.

 

En la JIAP (Jornadas de Informárica en la Administración Pública) -Uruguay-, tuve la oportunidad de realizar entre otras presentaciones una sobre Metodologías y Ambientes de Desarrollo. - El Tema Central de las Jornadas de este año era "Ambientes de Desarrollo" -

 

Mi presentación estuvo estuvo centrada en tres aspectos:

Quiero comentar ahora sobre los dos primeros puntos:

 

Y aqui me quiero detener sobre uno de los conceptos: complejidad

¿Cuál es el escenario de complejidad al que nos enfrentamos hoy?

Algunos ejemplos: ¿entre cuántas tecnologías debemos elegir a la hora de pensar en un nuevo sistema? -y hablo de tecnologías, no de proveedores-, ¿cómo las combino?, ¿cómo las conecto o integro con lo que ya tengo?, ¿cómo me puedo aproximar a una estimación de tiempos razonable?, ¿cómo aseguro la calidad? y podría seguir con una lista bastante más extensa.

 

Ahora, podríamos pensar que esta complejidad proviene de las tecnologías, de que éstas son complejas... sin embargo me inclino a pensar que éstas son complejas porque las situaciones de negocio que buscan resolver lo son.

 

Un buen ejemplo es el de los Web Services: hace 5 años antrás no los conocíamos ni estaban en nuestro árbol de decisión de tecnologías; hace 3 años atrás eran una fabulosa tecnología para invocar servicios a través de internet (Amazon exponiendo Web Services, Google su servicio de búsqueda por ese medio y Word realizando traducciones en línea vía Web Services)... ahora sólo meses después eso ya no fue suficiente, porque quisimos utilizar éstos Web Services entre bancos... para lo que necesitamos Seguridad, luego Mensajería Confiable y luego Transaccionalidad.- Y aquí en lo referente a evolusión de la tecnología los grandes productores de software tienen la  responsabilidad de preveer o responder rápidamente a éstas necesidades del mercado -... reflexionemos nuevamente que hace sólo 5 años los Web Services ni siquiera estaban como opción en nuestro árbol de decisión de tecnologías.

El árbor de desición de tecnologías crece con aceleración > 0.

 

Para concluir este punto, el escenerio de complejidad tiene n dimensiones, y aquí sólo comentamos algunas de éstas... lo que me gustaría remarcar es: la complejidad es creciente y requiere una respuesta de nuestra parate para afrontarla.

 

Metodologías: de procesos de desarrollo, de diseño arquitectónico, de codificación, de prueba, de distribución, etc. - y de aquí en adelante a todos estos puntos me referiré cuando hable de metodologías -

 

Éstas son en mi opinión partes de la respuesta al punto anterior: metodologías como un medio para abordar la complejidad.

 

Una nueva dimensión de la complejidad: la selección de una metodología... o aún más... la combinación de varias de estas para lograr la suma de mejores prácticas dado un proyecto, un tipo problema y un equipo de trabajo.

 

En resumen: la combinación de metodologías adaptadas a un caso particular como medio necesario para abordar la complejidad

Contexto: dado que el .iso de Windows Vista Setup es > a 2.x Gb, no es reconocido por VPC como tal

1) Utilizar un "emulador" de DVD que tome el .iso, por ejemplo: http://www.magiciso.com/tutorials/miso-magicdisc-overview.htm

Esto hace ver el .iso como una unidad de DVD en el PC.

 

2) Iniciar una VPC y setear que bootee del DVD

 

---

 

Windows Vista Beta 1 disponible para MSDN Subscribers:

 

Virual PC:

 

Hoy dimos una presentación con Martín (http://martincabrerablog.blogspot.com/) sobre Smart Clients para unos 40 alumnos y docentes en la Universidad ORT del Uruguay... replicamos con algunos upgrades la presentación que hicimos en abril/05 en el Microsoft Regional Architect Forum en Isla Margarita, Venezuela, aqui van los links:

 

Smart Clientes at MSDN:

 

WinFX (Avalon + Indigo) Beta 1 RC

 

Avalon blogs:

Lista de blogs sobre Avalon: