Archivos Mensuales: mayo 2006

Diferentes intereses en una misma audiencia

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.

Anuncios

Integración: BizTalk mítica herramienta de integración.

Desde hace un tiempo hasta ahora, la integración es un tema de todos los días para los desarrolladores de software. Esto se debe a una evolución natural de aplicaciones aisladas de su entorno que es necesario hacer “conversar” con otras aplicaciones dentro de un proceso de negocio integrado END-TO-END.

 

Existen diferentes tendencias en el ámbito de la integración, muchos de estas tendencias tienen siglas de tres letras como SOA y  ESB.

 

Muchos se confunden respecto a que es Biztalk Server y cómo se usa. Es un gran desconocido que muchos ven en PPT de arquitectura, como responsable de integrar, dirigir procesos de negocio, explotar datos de negocio y muchas otras cosas. Si uno ve esas cantidad de cosas en una PPT piensa que es magia envasada en un producto de software.

 

Bueno, Biztalk Server hace muchas cosas relacionadas con la integración entre sistemas computacionales en escenarios de EAI y B2B. Además es capas de soportar la implementación de un ESB o SOA, como herramienta de trabajo.

 

Creo una buena idea que se muestre este producto en una conferencia para desarrolladores de software, así pueden borrar las ideas míticas y acotar el alcance de la herramienta. Paso fundamental para que pase a ser parte de futuros sistemas.

Arquitectura Orienta a Servicios (SOA). Vista de Negocios

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.

Mejores prácticas ASPNET

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

Arquitectura de Software, ¿Qué estamos discutiendo?

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 😉

Santiago Rock & Batuta

Presentan….

Santiago Rock Fest, Tributo al Rock, Este Viernes 12 de Mayo, realizaremos en  Batuta,  una nueva fiesta SANTIAGO ROCK. En esta ocasión presentamos un clásico: ARKHAM VS SWEET ROSE    METALLICA VS GUNS & ROSES.

La entrada tiene un valor de $5.000 y se pueden comprar en forma anticipada a través del sistema Ticketmaster o el mismo día en la puerta del local.

Jorge Washington 52, Pza. Ñuñoa, 23:00 Hrs.

Fundamental: Desarrollo en Capas

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