El martes tengo que dar una conferencia para clientes de mi empresa sobre integración. Es de un nivel técnico comercial. No es fácil plasmar un mensaje claro para estos dos segmentos de audiencia.

La audiencia técnica, suele descalificar de entrada a todos los comerciales y gente que hace presentaciones. En su pragmática mente, cualquier persona que no sepa hacer no es un interlocutor válido. Además muchas veces su visión es consumida por sus actividades del día a día, por lo que no pueden enfocarse en las necesidades futuras del negocio.

La audiencia comercial, no entiende nada del cómo hacer las cosas y no quieren que los agobien con complejidad. Esperan que sus problemas de negocio se resuelvan de manera “transparente” para ellos, y sólo participar el las felicitaciones del final del proyecto.

Ambos tipos de audiencia son válidos, lo difícil es hablarle a los dos en una misma conferencia y que todos se vayan a su casa contentos.

La arquitectura orientada a servicios no es una tecnología, sino una forma de hacer negocios. Ella podrá incluso modificar la forma en que se hacen negocios.

Moverse hacia SOA le constará tiempo y dinero, por lo cual el “driver” por el cual usted toma la decisión de hacerlo debe estar muy bien fundamentada. SOA incrementará su agilidad y eventualmente disminuirá sus costos de desarrollo de sistemas.

Para poder llevar adelante este cambio, y hacer lo correcto, usted debe hacer que la gente de IT cambie su forma de ver el negocio. Esto fuerza a que la gente del lado de negocio postergue oportunidades de corto plazo versus objetivos de largo plazo. Por otro lado la gente de IT debe cambiar su forma de ver los sistemas, pensando ahora en niveles de servicios y reusabilidad.

Definición de SOA

En palabras simples, SOA trasforma las funcionalidades de las aplicaciones en piezas de Lego. Toma una pieza de software con una interfaz bien definida y la pone a disposición de diferentes aplicaciones a través de un contrato de uso. Lugo usted puede construir nuevas aplicaciones como construye nuevas figuras de Lego, uniendo las piezas.

Esto suena a juego de niños, sobre todo la parte Lego de los servicios. Debemos ser escépticos, SOA no soluciona todos los problemas ni es tan simple como suena.

La tecnología es dura, pero el staff es peor

Los precursores de SOA en una organización tienen claro que no será fácil cambiar la inercia de “la forma como hacemos las cosas”. Por eso la mejor aproximación es tomar pequeños procesos de negocio de alto impacto y llevarlos a SOA. Siempre la decisión de que pieza del proceso de negocio será transformada, se debe tener en mente el riesgo y retorno de la inversión.

Lo que se espera como resultado inmediato es que la pieza llevada a SOA reduzca la complejidad de integración y mantención. Esto impacta directamente los costos operacionales del sistema.

Hola,

Un cliente me preguntó ¿Tienes Links de buenas prácticas?

Yo dije “…por supuesto, miles de millones..”

Así que me puse a googlear, no fue nada fácil. Todo el mundo habla de las mejores prácticas pero nadie las explica, clasifica, desarrolla etc.

Así que hablando con diferentes personas y consultando en foros llegué a esta lista de mejores prácticas para ASPNET.

Poderosa recopilación de links

http://weblogs.asp.net/Varad/archive/2005/09/25/425938.aspx

Buenas prácticas organizadas como el ciclo de vida (10 eventos) de ASPNET.

http://www.aspfree.com/c/a/ASP.NET/ASP.NET-Life-Cycle-and-Best-Practices/

Para aplicaciones escalables y rápidas

http://msdn.microsoft.com/msdnmag/issues/05/09/SessionState/default.aspx

http://www.codeproject.com/useritems/ASPNET_Best_Practices.asp

http://www.codeproject.com/csharp/effective1.asp

Mejores prácticas de PAG, diferentes guías.

http://msdn.microsoft.com/practices/guidetype/Guides/default.aspx

Cuando escribí el post sobre “Arquitectos que andan a 10.000 metros”, lo hice para promocionar una conferencia para Developer que bajaba la propuesta de arquitectura en capas a directivas de diseño para Developer.

Diegum, ex arquitecto de Microsoft Chile lo tomó muy en serio y escribió un POST de comentario sobre el mío. No era mi intención pero creo que esto está siendo muy positivo porque genera dialogo sobre el verdadero rol de un arquitecto de software.

Primero,  creo que el concepto de arquitecto de software está sobre utilizado. Es algo similar al titulo de ingeniero, en Chile existe ingeniería en Marketing o ingeniería comercial, por ejemplo.

Coincido con diegum en su definición de Arquitecto cómo “El arquitecto de software es un administrador de la complejidad, lidia con ella todo el tiempo”. Ahora, en clases de arquitectura de software, en la universidad es posible encontrar cursos de cualquier cosa, me dijo mi profesor que la arquitectura de software “habla del software que se va ha hacer” y que el diseño “baja como esa arquitectura se implementa”.

Ahora, revisando la lista de tareas que nos propone diegum para los arquitectos de software tenemos:

• Descomponer la aplicación en capas, al menos, lógicas
• Descomponer cada capa lógica en componentes
• Seleccionar tecnologías y/o frameworks de implementación
• Realizar una Prueba de Concepto (Proof of Concept o PoC) de la arquitectura
• Brindar algunos casos de uso de referencia

Si un Arquitecto de software hace eso, me sentiría muy contento. Ahora creo que esa felicidad sería máxima si agregamos lo siguiente:

En “descomposición lógica en componentes” apoyaran a los diseñadores dando directivas claras de cómo bajar la arquitectura del sistema a un diseño de software codificable por Developer.

Ocurre que muchas veces no existen diseñadores de software, por lo que nadie hace este trabajo. Esa es mi principal observación a los arquitectos  de "coloquios de café".

Yo no creo que sea importante para un Arquitecto de Software saber programar en la tecnología que se use en estos momentos, si es impórtate que tenga experiencia y habilidades de comunicación que le permitan hacer un “puente de plata” entre el negocio, Driver de toda empresa, y el equipo de desarrollo.

PD:

Como siempre, saber programar y gustarme mucho hacerlo, me trae problemas 😉

La semana pasada, junto con David, dimos una conferencia técnica de un tema que no es de visión sino fundamental. Repasamos los conceptos necesarios en el desarrollo de aplicaciones en capas.

Nuestra apuesta es que todo el mundo habla en alto nivel de este tema pero que no existe un real entendimiento entre los Developer. Esto no por falta de interés o capacidades sino porque los Arquitectos de Software cercanos tienen facilidad para hacerse entender con los Stakeholder pero muy poca práctica en bajar en diseños concretos sus ideas hacia los Developer.

En esta conferencia mostramos una herramienta muy buena para generar código llamada CODESMITH (http://www.codesmithtools.com/ ). En particular el Script http://www.nettiers.com/  para generar un modelo ORM a partir de una base de datos.

Algunos de los links recomendados en la conferencia son los siguientes:

·         Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios

http://www.microsoft.com/spanish/msdn/arquitectura/das/guias/AppArchCh1.asp

·         Designing Data Tier Components and Passing Data Through Tiers

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

·         .NET Data Access Architecture Guide

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp

·         3-tier architecture in C# By Rahman Mahmoodi
http://www.codeproject.com/csharp/three_tier_architecture.asp

Enjoy