SQL Server 2008… ya disponible!!

Para variar gracias a El Bruno me entero que al fin esta disponible la version oficial de SQL Server 2008, concretamente la edicion RTM (Ready To Manufacture) ya se puede descargar desde las cuentas de Technet y MSDN Subscriptions, que es lo que he hecho esta mañana. Me imagino que la version “en cajita” todavia debera esperar unas semanas.

Ahora toca desinstalar la version beta que tenia y seguir trabajando con mi gestor personalizado de MP3, ya veremos que tal se comporta recuperando el respectivo backup.

Gracias a un correo de las Communities de Avanade que recibi esta mañana tengo las nuevas caracteristicas para desarrolladores que incluye esta version:

– Mejoras en SQL Management Studio incluyendo IntelliSense.
– Nuevos Tipos de Datos para solo fechas o solo horas (se acabo el almacenar la hora cuando solo necesitabas la fecha)
– Nuevo soporte a datos jerarquicos.
– Nuevas funciones de Agrupamiento.
– Nueva funcion Merge que permite una semantica de insert/update para mantener multiples fuentes de datos en sincronia
– Nuevo atributo FileStream attribute que permite incluir archivos que son almacenados en el sistema de archivos, pero que pueden ser manejados por SQL Server
– Nuevos tipos de datos y soporte para Geodata y geometria
– Nuevo soporte para optimizar las columnas o filas “vacias” mediante la palabra reservada “sparse”

Pues nada.. a actualizar se ha dicho!!

Anclados al pasado tecnologico….

Hace como 12 años en una clase de Ingenieria de Software en la PUCP el profesor comentaba que esa epoca era una buena oportunidad para empezar las cosas bien, ya que como muchos bancos se estaban creando se podia arrancar con plataformas recientes y no dependientes en mainframes y el COBOL. Muy pocos años mas tarde hablando con una amiga me conto que su trabajo consistia (entre otras cosas) en la integracion de plataformas para uno de esos bancos mediante C y acceso a COBOL, debo reconocer que entonces me sorprendio mucho pero resulto que la razon era muy simple para que no se cumplieran las afirmaciones de mi profesor, resulta que al instalarse dichos bancos como venian de una matriz chilena decidieron que lo mas sencillo era utilizar como base toda la tecnologia usada en las matrices…. conclusion.. una oportunidad perdida.

Y esa es una constante que veo a nivel global… una resistencia al cambio sobre todo si estas muy dependiente a tecnologias antiguas como el COBOL y los mainframes, las excusas son clasicas “llevan buen tiempo funcionando”, “el mainframe es solido”, “te arriesgarias a que esto dejara de funcionar?” y cosas asi, pero al final es inevitable que las necesidades de negocio evolucionen y por lo tanto surja la necesidad de exponer la informacion en mas plataformas (Windows para cliente final institucional, Web para tu publico) por lo que terminamos desarrollando capas y mas capas para enmascarar el acceso a estas plataformas y poder integrarlas con las herramientas actuales. Que si.. luego diran “ya ves como funciona?” si, pero mas por merito de los equipos de desarrollo que por merito de la herramienta, que ahi esta ..lanzando sus tramas… sin transacciones.. sin integridad referencial, y dale nosotros a mapearlo a XML o a alguna trama de datos mas actual.

Me diran que no hay que ser un loco de la tecnologia y mucho menos en una empresa, que no hay razon para tener que estar siempre a lo ultimo y tienen razon, las decisiones tecnologicas deben ser un proceso razonado de cara a lo que la organizacion espera, siendo los sistemas de informacion quienes deben alinearse a los objetivos de la empresa, asi que si los requisitos que nos exige el entorno cambian se debe pensar que tanto nos tira para atras los parches que hay que hacer para que el sistema legado siga encajando en la organizacion.

Es muy probable que organizaciones que tengan BD relacionales de 10 años de antiguedad no tengan necesidad de cambiarla, lo cual me parece muy valido puesto que los entornos de desarrollo actuales proveen mecanismos de integracion con esta clase de sistemas de manera muy transparente, con lo cual es mas o menos sencillo la renovacion de aplicaciones utilizando tecnologias nuevas sin necesidad de actualizar todas las BD, pero justamente dicha transparencia esta ausente en los sistemas legados que vienen desde los 80s y antes, lo digo por experiencia propia ya que en un proyecto para Web se actuaba contra una plataforma mainframe, y como se decidio usar XML como mecanismo para el pase de informacion entre capas, el detalle es que para esto se tuvo que inventar una arquitectura que permitiera esa integracion ya que de por si el mainframe no era capaz (ni habia upgrades que lo permitieran) de generar XML por su cuenta, por lo que buena parte del tiempo de desarrollo en esa empresa correspondio al modelamiento del medio antes que en los procesos de negocio en si.

En cierta forma las aplicaciones hechas en xBase,VB6/4/5,Delphi y PowerBuilder tienen un ciclo de vida diferente que permita una evolucion menos traumatica, lo cual nos permite tomar las cosas con calma y ver que su presencia no es tan lastre, pero definitivamente considero que una evolucion estrategica del departamento de IT de una empresa deberia plantearse el como progresivamente ir librandose de plataformas que obligan a cantidad de malabares tan solo para lograr un medio de integracion en lugar de permitir ir directamente a la solucion de los problemas de negocio. Hagamonos un favor y limpiemos progresivamente de COBOL a las organizaciones.

Es interesante leer: Habilidades informaticas muertas o agonizantes(a que no adivinan cual es la primera?)