miércoles, 22 de diciembre de 2010
Cerebro
"El cerebro es un órgano maravilloso. Comienza a trabajar apenas nos levantamos y no deja de funcionar hasta entrar en la oficina" (gracias Robert Frost)
domingo, 23 de mayo de 2010
Facebook chat a través de Pidgin
Facebook actualmente tiene soporte para el protocolo XMPP de chat, así que no es necesario agregar plugins ni nada por el estilo en Pidgin para conectarse a ese servicio de mensajería.
Los pasos pueden seguirse desde este link:
http://www.howtogeek.com/howto/12527/easily-add-facebook-chat-to-pidgin/
Tener en cuenta dos cosas:
1) Está en inglés
2) Tuve que deshabilitarle el requerimiento de SSL/TLS (al revés de como indica en los pasos) ya que el servidor responde que no admite cifrado (tener en cuenta por lo tanto que el intercambio de datos es sin cifrar).
Si no se desea seguir los pasos, simplemente basta tener en cuenta que se configura como una cuenta clásica XMPP y que el servidor es chat.facebook.com
Los pasos pueden seguirse desde este link:
http://www.howtogeek.com/howto/12527/easily-add-facebook-chat-to-pidgin/
Tener en cuenta dos cosas:
1) Está en inglés
2) Tuve que deshabilitarle el requerimiento de SSL/TLS (al revés de como indica en los pasos) ya que el servidor responde que no admite cifrado (tener en cuenta por lo tanto que el intercambio de datos es sin cifrar).
Si no se desea seguir los pasos, simplemente basta tener en cuenta que se configura como una cuenta clásica XMPP y que el servidor es chat.facebook.com
miércoles, 30 de diciembre de 2009
Backup
La gestión de backups o copias de seguridad es una actividad a planificarse a medida de la organización que la requiere a fin de obtener el objetivo esperado con el mínimo costo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
lunes, 19 de octubre de 2009
NO Cambio de hora en Argentina - Servidores Ubuntu
Gracias: http://www.vivalinux.com.ar/distros/parche-tzdata-argentina
Gracias: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/453165
Gracias Margarita Manterola.
Para ajustar en un servidor Ubuntu la configuración de daylight savings y "acate" :-) la última decisión en Argentina (17/10/09: NO hacer ajuste de hora para ahorro de energía) (me reservo los comentarios sobre "planificación cero").
El siguiente es un script que ajusta la configuración sin necesidad de actualizar paquetes (útil para el caso de una instalación estática de server, homologada como tal y cuyos binarios no pueden ser modificados bajo ningún concepto porque perdería la homologación): (asume caso timezone Buenos Aires)
1) wget http://www.bircherasociados.com.ar/soft/ArgentinaSinCambioHora
2) cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Argentina/backup_Buenos_Aires
3) cp ArgentinaSinCambioHora /usr/share/zoneinfo/America/Argentina/Buenos_Aires
4) cp ArgentinaSinCambioHora /etc/localtime
Gracias: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/453165
Gracias Margarita Manterola.
Para ajustar en un servidor Ubuntu la configuración de daylight savings y "acate" :-) la última decisión en Argentina (17/10/09: NO hacer ajuste de hora para ahorro de energía) (me reservo los comentarios sobre "planificación cero").
El siguiente es un script que ajusta la configuración sin necesidad de actualizar paquetes (útil para el caso de una instalación estática de server, homologada como tal y cuyos binarios no pueden ser modificados bajo ningún concepto porque perdería la homologación): (asume caso timezone Buenos Aires)
1) wget http://www.bircherasociados.com.ar/soft/ArgentinaSinCambioHora
2) cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Argentina/backup_Buenos_Aires
3) cp ArgentinaSinCambioHora /usr/share/zoneinfo/America/Argentina/Buenos_Aires
4) cp ArgentinaSinCambioHora /etc/localtime
miércoles, 16 de septiembre de 2009
Software Libre en las Empresas
¿Qué es el software libre?
Un software libre (SL) es una pieza de software cuyo autor lo transfiere para su uso a otra persona, otorgando una licencia que le da a este último la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.
Para más detalles ver por ejemplo: http://es.wikipedia.org/wiki/Software_libre
En inglés, software libre se dice "free software". Lamentablemente, "free" significa tanto "libre" como "gratuito", cuestión que origina una serie de confusiones con respecto a qué es y qué no es el SL.
Respecto a lo anterior, hay que tener bien en claro que el hecho de que se denomine libre, tiene que ver con el concepto de libertad y no con el concepto de gratuidad.
En el sitio de uno de los productos de software libre muy utilizados (GNU: http://www.gnu.org/philosophy/free-sw.es.html) pueden leerse estos detalles sobre el SL:
Los usuarios de programas tienen las cuatro libertades esenciales:
. La libertad de ejecutar el programa para cualquier propósito.
. La libertad de estudiar cómo trabaja el programa y cambiarlo para que haga lo que usted quiera. El acceso al código fuente es una condición necesaria.
. La libertad de redistribuir copias.
. La libertad de mejorar el programa y publicar sus mejoras y versiones modificadas en general, para que se beneficie toda la comunidad. El acceso al código fuente es una condición necesaria.
Más allá de estar de acuerdo o no con estos términos, lo cierto es que existen muchos tipos de licencia que otorgan estas libertades (y también agregan otros términos restrictivos o de más libertades). Los tipos de licencia más conocidos son: BSD (http://es.wikipedia.org/wiki/BSD_license), GPL (http://www.gnu.org/copyleft/gpl.html), Copyleft (http://www.gnu.org/copyleft) y Apache (http://www.apache.org/licenses/LICENSE-2.0)
Virtudes del SL
. Generalmente se utilizan estándares abiertos (imprescindible por ejemplo para que los datos sean propiedad del usuario del sistema y no del desarrollador del sistema). Por ejemplo, si en una empresa los datos están almacenados en un motor de base de datos propietario, con clave, encriptación y accesos no estándar, seguramente que la única manera de acceder a esos datos y a su plano de diseño es a través del desarrollador del software.
. Colaborativo: al hacer disponible una pieza de software a la comunidad, a la vez que alguien puede verse beneficiado por el producto, la misma comunidad puede detectar y generar mejoras, detectar y solucionar problemas, etc.
. Sujeto a auditoría: está permanentemente sujeto a auditorías imparciales, heterogéneas y multidisciplinarias.
. Seguro (no puede haber huecos de seguridad no documentados porque todo está documentado, en última instancia con el código fuente).
Empresas y SL. Derribando mitos
Una manera breve e introductoria para presentar el uso de software libre en empresas es analizando estos diez mitos del SL (con orientación a las Pymes):
1) El SL es gratuito: normalmente falso. Salvo que su autor lo haya otorgado como de dominio público, el SL no es gratuito. Es necesario muchos recursos, incluido dinero, para producirlo, mantenerlo y acompañarlo en todo su ciclo de vida. ¿Quién lo paga entonces? Quizá ciertos principales interesados, quizá algún paradigma comercial no basado en compraventa (inmensa escala de voluntarios aportantes, publicidad, etc).
El modelo de SL también traslada el enfoque económico desde un producto con un origen y con una licencia propietaria hacia un modelo de servicio orientado a la solución de problemas concretos.
La inversión en software que hace una pyme ahora no se paga a una empresa importante, centralizada y alejada de la realidad regional, sino que se paga a consultores regionales que utilizan piezas de SL genérico y la personalizan para cada necesidad (y es más barato).
Que no sea gratuito no impide que eventualmente una organización utilice de manera gratuita una pieza de software. De hecho, hay muchos casos en los que ocurre algo así:
Por ejemplo, sea un SL consistente en un sistema de base de datos. Una empresa multinacional hace un aporte importante de dinero efectivo, permitiendo financiar el proyecto de esa base de datos. El interés de esta empresa es que va a utilizar esa base de datos para integrarla con otros productos o servicios de su propiedad (hacer un sistema de base de datos desde cero de características similares le costaría exponencialmente más).
Como es una característica del SL, ese proyecto es publicado. Desarrolladores de software regionales (independientes, consultores o empleados de pymes) lo toman e instalan (quizá con ningún cambio) en sus clientes. Esos clientes son organizaciones pequeñas (de 1 a 50 empleados) que no pagan nada por ese producto, salvo a los desarrolladores regionales (por la solución completa).
Eventualmente los desarrolladores regionales pueden retroalimentar el proyecto de base de datos que fue publicado reportando su experiencia de uso o instalación, publicando mejoras o informando errores. Este último aspecto hace que en última instancia la empresa grande que hizo el aporte principal se ve beneficiada por muchos voluntarios que aportan a una mejora continua del producto.
2) El SL es amateur: falso. En muchos casos (y en la mayoría para los SL conocidos) hay un equipo profesional y multidisciplinario en el desarrollo y en el ciclo de vida del producto.
3) Se necesita Linux para usar SL: falso. Hay infinidad de piezas de SL independientes del sistema operativo o para plataformas específicas como Windows.
4) No pueden mezclarse en una pyme SL y software propietario: falso. Comenzar a utilizar SL no implica hacer un "salto" (normalmente al vacío :-) ) descartando todo lo que se utiliza hasta ahora y tomando todo software nuevo. Más bien es una decisión que debe tomarse con una planificación a mediano plazo y un plan gradual, incluso con objetivos que pueden no ser el reemplazo total del software existente. Gracias a que el SL siempre se encuentra sometido a estándares, es posible por ejemplo tener varios puestos de trabajo con un procesador de textos propietario y otros puestos con un procesador de textos basado en software libre.
5) Los "peces gordos" de la tecnología no hacen SL, sólo lo hacen comunidades independientes: falso. Actualmente quienes promueven más activamente al SL son las empresas más exitosas en los últimos años en su rubro (como IBM, Google, Sun, etc).
6) El SL no tiene soporte: falso. Sí tiene soporte: se puede contratar mesa de ayuda, soporte con asistencia remota. Se puede estar suscripto a bases de conocimiento o preguntas frecuentes (suscripciones que pueden ser gratuitas para el consumidor).
Hay que comprender que estamos presenciando el nacimiento de un nuevo paradigma en ciclo de vida del software, que no viene a reemplazar otro sino que viene a ocupar otro lugar:
Antes las empresas grandes cobraban su producido en software con licencias. Los usuarios debían adaptar sus procedimientos de trabajo a los dictados por ese software ya que los ciclos de vida con realimentación normalmente no tenían la agilidad esperada. No se está haciendo un juicio de valor sobre esta forma de trabajo. Simplemente se la presenta.
Ahora hay una alternativa: el desarrollo es más personalizado, se orienta más al servicio y a la solución de los problemas concretos. Las grandes empresas crean plataformas, marcos de trabajo (frameworks) o estándares de desarrollo sobre los que los regionales arman la solución.
7) El SL no puede tener un uso comercial: falso. Puede ser utilizado con cualquier propósito, principalmente como asistente a actividades comerciales, productivas, de investigación y entretenimiento. Incluso hay muchísimo SL cuyo ámbito principal de aplicación es el comercial.
8) Freeware y Shareware son lo mismo que SL: falso. Freeware significa gratis, y shareware con período de prueba gratis. SL (free software) es software libre.
9) SL es de menor calidad. falso. Cualquier software (libre o propietario) tiene la calidad que le da su equipo de trabajo y la que certifican los auditores expertos. Todo lo que hay que hacer es buscar la opinión de un grupo especialista en que se confíe: si ese grupo dice que un determinado SL es de la calidad esperada: adelante, a utilizarlo.
Habitualmente quien da la garantía a una pyme sobre un software es el consultor/desarrollador regional que se contrata.
Por ejemplo, si una pyme compra un servidor con sistema operativo Windows Server, la garantía de que va a funcionar correctamente va a estar brindada por el fabricante del software. Si en lugar de eso compra un servidor sin sistema operativo, su responsable de sistemas instalará un sistema operativo SL y será él mismo quien garantizará el correcto funcionamiento.
10) SL es de dominio público: falso. Dominio público pertenece a toda la humanidad, no tiene licencia. En última instancia el software de dominio público puede considerarse una variante dentro del software libre . El SL siempre tiene licencia, la cual hay que conocer y aceptar (y, de tener dificultades para entenderla, buscar soporte en alguien de confianza -personas, grupos, organizaciones- para recibir ayuda a interpretarla).
Los nombres mencionados son marcas registradas de sus respectivos propietarios.
Un software libre (SL) es una pieza de software cuyo autor lo transfiere para su uso a otra persona, otorgando una licencia que le da a este último la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.
Para más detalles ver por ejemplo: http://es.wikipedia.org/wiki/Software_libre
En inglés, software libre se dice "free software". Lamentablemente, "free" significa tanto "libre" como "gratuito", cuestión que origina una serie de confusiones con respecto a qué es y qué no es el SL.
Respecto a lo anterior, hay que tener bien en claro que el hecho de que se denomine libre, tiene que ver con el concepto de libertad y no con el concepto de gratuidad.
En el sitio de uno de los productos de software libre muy utilizados (GNU: http://www.gnu.org/philosophy/free-sw.es.html) pueden leerse estos detalles sobre el SL:
Los usuarios de programas tienen las cuatro libertades esenciales:
. La libertad de ejecutar el programa para cualquier propósito.
. La libertad de estudiar cómo trabaja el programa y cambiarlo para que haga lo que usted quiera. El acceso al código fuente es una condición necesaria.
. La libertad de redistribuir copias.
. La libertad de mejorar el programa y publicar sus mejoras y versiones modificadas en general, para que se beneficie toda la comunidad. El acceso al código fuente es una condición necesaria.
Más allá de estar de acuerdo o no con estos términos, lo cierto es que existen muchos tipos de licencia que otorgan estas libertades (y también agregan otros términos restrictivos o de más libertades). Los tipos de licencia más conocidos son: BSD (http://es.wikipedia.org/wiki/BSD_license), GPL (http://www.gnu.org/copyleft/gpl.html), Copyleft (http://www.gnu.org/copyleft) y Apache (http://www.apache.org/licenses/LICENSE-2.0)
Virtudes del SL
. Generalmente se utilizan estándares abiertos (imprescindible por ejemplo para que los datos sean propiedad del usuario del sistema y no del desarrollador del sistema). Por ejemplo, si en una empresa los datos están almacenados en un motor de base de datos propietario, con clave, encriptación y accesos no estándar, seguramente que la única manera de acceder a esos datos y a su plano de diseño es a través del desarrollador del software.
. Colaborativo: al hacer disponible una pieza de software a la comunidad, a la vez que alguien puede verse beneficiado por el producto, la misma comunidad puede detectar y generar mejoras, detectar y solucionar problemas, etc.
. Sujeto a auditoría: está permanentemente sujeto a auditorías imparciales, heterogéneas y multidisciplinarias.
. Seguro (no puede haber huecos de seguridad no documentados porque todo está documentado, en última instancia con el código fuente).
Empresas y SL. Derribando mitos
Una manera breve e introductoria para presentar el uso de software libre en empresas es analizando estos diez mitos del SL (con orientación a las Pymes):
1) El SL es gratuito: normalmente falso. Salvo que su autor lo haya otorgado como de dominio público, el SL no es gratuito. Es necesario muchos recursos, incluido dinero, para producirlo, mantenerlo y acompañarlo en todo su ciclo de vida. ¿Quién lo paga entonces? Quizá ciertos principales interesados, quizá algún paradigma comercial no basado en compraventa (inmensa escala de voluntarios aportantes, publicidad, etc).
El modelo de SL también traslada el enfoque económico desde un producto con un origen y con una licencia propietaria hacia un modelo de servicio orientado a la solución de problemas concretos.
La inversión en software que hace una pyme ahora no se paga a una empresa importante, centralizada y alejada de la realidad regional, sino que se paga a consultores regionales que utilizan piezas de SL genérico y la personalizan para cada necesidad (y es más barato).
Que no sea gratuito no impide que eventualmente una organización utilice de manera gratuita una pieza de software. De hecho, hay muchos casos en los que ocurre algo así:
Por ejemplo, sea un SL consistente en un sistema de base de datos. Una empresa multinacional hace un aporte importante de dinero efectivo, permitiendo financiar el proyecto de esa base de datos. El interés de esta empresa es que va a utilizar esa base de datos para integrarla con otros productos o servicios de su propiedad (hacer un sistema de base de datos desde cero de características similares le costaría exponencialmente más).
Como es una característica del SL, ese proyecto es publicado. Desarrolladores de software regionales (independientes, consultores o empleados de pymes) lo toman e instalan (quizá con ningún cambio) en sus clientes. Esos clientes son organizaciones pequeñas (de 1 a 50 empleados) que no pagan nada por ese producto, salvo a los desarrolladores regionales (por la solución completa).
Eventualmente los desarrolladores regionales pueden retroalimentar el proyecto de base de datos que fue publicado reportando su experiencia de uso o instalación, publicando mejoras o informando errores. Este último aspecto hace que en última instancia la empresa grande que hizo el aporte principal se ve beneficiada por muchos voluntarios que aportan a una mejora continua del producto.
2) El SL es amateur: falso. En muchos casos (y en la mayoría para los SL conocidos) hay un equipo profesional y multidisciplinario en el desarrollo y en el ciclo de vida del producto.
3) Se necesita Linux para usar SL: falso. Hay infinidad de piezas de SL independientes del sistema operativo o para plataformas específicas como Windows.
4) No pueden mezclarse en una pyme SL y software propietario: falso. Comenzar a utilizar SL no implica hacer un "salto" (normalmente al vacío :-) ) descartando todo lo que se utiliza hasta ahora y tomando todo software nuevo. Más bien es una decisión que debe tomarse con una planificación a mediano plazo y un plan gradual, incluso con objetivos que pueden no ser el reemplazo total del software existente. Gracias a que el SL siempre se encuentra sometido a estándares, es posible por ejemplo tener varios puestos de trabajo con un procesador de textos propietario y otros puestos con un procesador de textos basado en software libre.
5) Los "peces gordos" de la tecnología no hacen SL, sólo lo hacen comunidades independientes: falso. Actualmente quienes promueven más activamente al SL son las empresas más exitosas en los últimos años en su rubro (como IBM, Google, Sun, etc).
6) El SL no tiene soporte: falso. Sí tiene soporte: se puede contratar mesa de ayuda, soporte con asistencia remota. Se puede estar suscripto a bases de conocimiento o preguntas frecuentes (suscripciones que pueden ser gratuitas para el consumidor).
Hay que comprender que estamos presenciando el nacimiento de un nuevo paradigma en ciclo de vida del software, que no viene a reemplazar otro sino que viene a ocupar otro lugar:
Antes las empresas grandes cobraban su producido en software con licencias. Los usuarios debían adaptar sus procedimientos de trabajo a los dictados por ese software ya que los ciclos de vida con realimentación normalmente no tenían la agilidad esperada. No se está haciendo un juicio de valor sobre esta forma de trabajo. Simplemente se la presenta.
Ahora hay una alternativa: el desarrollo es más personalizado, se orienta más al servicio y a la solución de los problemas concretos. Las grandes empresas crean plataformas, marcos de trabajo (frameworks) o estándares de desarrollo sobre los que los regionales arman la solución.
7) El SL no puede tener un uso comercial: falso. Puede ser utilizado con cualquier propósito, principalmente como asistente a actividades comerciales, productivas, de investigación y entretenimiento. Incluso hay muchísimo SL cuyo ámbito principal de aplicación es el comercial.
8) Freeware y Shareware son lo mismo que SL: falso. Freeware significa gratis, y shareware con período de prueba gratis. SL (free software) es software libre.
9) SL es de menor calidad. falso. Cualquier software (libre o propietario) tiene la calidad que le da su equipo de trabajo y la que certifican los auditores expertos. Todo lo que hay que hacer es buscar la opinión de un grupo especialista en que se confíe: si ese grupo dice que un determinado SL es de la calidad esperada: adelante, a utilizarlo.
Habitualmente quien da la garantía a una pyme sobre un software es el consultor/desarrollador regional que se contrata.
Por ejemplo, si una pyme compra un servidor con sistema operativo Windows Server, la garantía de que va a funcionar correctamente va a estar brindada por el fabricante del software. Si en lugar de eso compra un servidor sin sistema operativo, su responsable de sistemas instalará un sistema operativo SL y será él mismo quien garantizará el correcto funcionamiento.
10) SL es de dominio público: falso. Dominio público pertenece a toda la humanidad, no tiene licencia. En última instancia el software de dominio público puede considerarse una variante dentro del software libre . El SL siempre tiene licencia, la cual hay que conocer y aceptar (y, de tener dificultades para entenderla, buscar soporte en alguien de confianza -personas, grupos, organizaciones- para recibir ayuda a interpretarla).
Los nombres mencionados son marcas registradas de sus respectivos propietarios.
lunes, 3 de agosto de 2009
Business Intelligence
Se denomina Business Intelligence (BI) al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización u empresa. (http://es.wikipedia.org/wiki/Business_intelligence)
Es el ámbito informático y la actual potencia computacional el lugar en el cual ese objetivo de crear conocimiento comienza a ser factible:
Dato e Información
Desde el inicio de la era de la automatización de la información, se ha hablado de “dato” como la mínima unidad o átomo de los sistemas: la fecha de un evento, el nro de cliente relacionado a una transacción.
Simultáneamente, agrupando los datos se hablaba y se continúa hablando de “información”: una factura (incluye y relaciona a esa fecha con ese cliente), una cuenta corriente, una conciliación bancaria.
Conocimiento
Actualmente, a ese par de conceptos se le agrega un tercero inaugurando una nueva dimensión: el conocimiento.
Así que ahora los rangos o jerarquías de valores en un sistema de información se componen de tres escalas: dato, información y conocimiento.
¿Cuál es la tendencia de nuestros consumidores en los últimos seis años? ¿Cómo se comparan las ventas de esta temporada con las anteriores? ¿Y si sólo se consideran ciertos rubros? ¿Y si se consideran todos los rubros? ¿Qué hay de las compras de los nuevos clientes comparadas con las de los más antiguos?
Se necesitan esas respuestas y se necesitan YA.
Por supuesto que la inteligencia del negocio ya existe en el mismo desde hace mucho tiempo, quizá desde su inicio. Lo nuevo acá es que su origen y consistencia se respaldan por una evidencia objetiva, que está disponible para todos los actores que se considere necesario, que se obtiene de una manera económica y confiable y que no se necesita ser un experimentado actor del negocio para deducirla con cierta incertidumbre.
Además, el conocimiento que va aflorando a través de estrategias de BI, puede deparar sorpresas: puede ocurrir que cierta percepción que se tenía del negocio, de repente se ve cuestionada por informes que muestran lo contrario.
Conocimiento, el último de la lista de prioridades
Lo habitual es que se tiendan a resolver con prioridad las cuestiones operativas: poner en marcha “el sistema” y que se pueda facturar rápido, comprar rápido, controlar el stock, etc.
A lo sumo y junto con esas cuestiones operativas resueltas, hay disponibles ciertos “listados”. ¿Pero qué ocurre cuando además de un “listado de ventas del mes” se necesitan cosas tan básicas como un gráfico para comparar datos estacionales, o un consolidado que abarque muchos años?
Lo que siempre se deja para “después” es la posibilidad de generar un tremendo valor agregado a todos esos registros que van quedando grabados.
Herramientas
Son muchas las herramientas y estrategias para generar conocimiento con BI.
Conceptualmente hablando y por mencionar ciertos términos que se están popularizando, se habla de la necesidad de “preparar” la información para que comience a ser más accesible (datawarehousing), de “cruzar” la información (olap) y de analizar la misma para encontrar patrones o tendencias (data mining).
Actualmente es muy común que las pymes tengan una gran cantidad de historia en archivos digitales: hasta 20 años de facturaciones, remitos, pagos, libros de banco, precios, costos, etc.
Todo ese volumen tiene mucho conocimiento “oculto”. Los datos están, la información está (son un hecho, se pueden ver), pero el conocimiento también está; sólo que requiere de herramientas y procedimientos para salir a la luz y ayudar a todos a tomar mejores decisiones (no sólo a puestos directivos y gerenciales sino también a posiciones operativas).
Las soluciones disponibles no se limitan al mercado de las grandes corporaciones. Actualmente es posible armar planes para poner en marcha BI con presupuestos acordes a pymes.
Es el ámbito informático y la actual potencia computacional el lugar en el cual ese objetivo de crear conocimiento comienza a ser factible:
Dato e Información
Desde el inicio de la era de la automatización de la información, se ha hablado de “dato” como la mínima unidad o átomo de los sistemas: la fecha de un evento, el nro de cliente relacionado a una transacción.
Simultáneamente, agrupando los datos se hablaba y se continúa hablando de “información”: una factura (incluye y relaciona a esa fecha con ese cliente), una cuenta corriente, una conciliación bancaria.
Conocimiento
Actualmente, a ese par de conceptos se le agrega un tercero inaugurando una nueva dimensión: el conocimiento.
Así que ahora los rangos o jerarquías de valores en un sistema de información se componen de tres escalas: dato, información y conocimiento.
¿Cuál es la tendencia de nuestros consumidores en los últimos seis años? ¿Cómo se comparan las ventas de esta temporada con las anteriores? ¿Y si sólo se consideran ciertos rubros? ¿Y si se consideran todos los rubros? ¿Qué hay de las compras de los nuevos clientes comparadas con las de los más antiguos?
Se necesitan esas respuestas y se necesitan YA.
Por supuesto que la inteligencia del negocio ya existe en el mismo desde hace mucho tiempo, quizá desde su inicio. Lo nuevo acá es que su origen y consistencia se respaldan por una evidencia objetiva, que está disponible para todos los actores que se considere necesario, que se obtiene de una manera económica y confiable y que no se necesita ser un experimentado actor del negocio para deducirla con cierta incertidumbre.
Además, el conocimiento que va aflorando a través de estrategias de BI, puede deparar sorpresas: puede ocurrir que cierta percepción que se tenía del negocio, de repente se ve cuestionada por informes que muestran lo contrario.
Conocimiento, el último de la lista de prioridades
Lo habitual es que se tiendan a resolver con prioridad las cuestiones operativas: poner en marcha “el sistema” y que se pueda facturar rápido, comprar rápido, controlar el stock, etc.
A lo sumo y junto con esas cuestiones operativas resueltas, hay disponibles ciertos “listados”. ¿Pero qué ocurre cuando además de un “listado de ventas del mes” se necesitan cosas tan básicas como un gráfico para comparar datos estacionales, o un consolidado que abarque muchos años?
Lo que siempre se deja para “después” es la posibilidad de generar un tremendo valor agregado a todos esos registros que van quedando grabados.
Herramientas
Son muchas las herramientas y estrategias para generar conocimiento con BI.
Conceptualmente hablando y por mencionar ciertos términos que se están popularizando, se habla de la necesidad de “preparar” la información para que comience a ser más accesible (datawarehousing), de “cruzar” la información (olap) y de analizar la misma para encontrar patrones o tendencias (data mining).
- Se necesita “preparar” la información ya que normalmente la misma se va almacenando (a medida que surge de las actividades operativas) de una manera que no es la mejor para analizarlos (ni aún los actuales sistemas computacionales tan potentes pueden procesar información que no se encuentre adecuadamente almacenada para los fines de generar conocimiento). Esto no necesariamente implica una demora en la disponibilidad. Actualmente se habla de preparar en un modo NRT (near real time o “casi en tiempo real”) de tal manera que los eventos operativos se registran y ya están aportando al conocimiento del negocio.
- Se necesita “cruzar” la información para que comience a “aflorar” el conocimiento (como casos simplificados pero accesibles, ver las tablas dinámicas de Excel, las referencias cruzadas de Access o el Piloto de Datos de OpenOffice).
- Se necesitan estrategias para “analizar” los reportes o listados de tal manera que se expliciten ciertas tendencias como parte del conocimiento.
Actualmente es muy común que las pymes tengan una gran cantidad de historia en archivos digitales: hasta 20 años de facturaciones, remitos, pagos, libros de banco, precios, costos, etc.
Todo ese volumen tiene mucho conocimiento “oculto”. Los datos están, la información está (son un hecho, se pueden ver), pero el conocimiento también está; sólo que requiere de herramientas y procedimientos para salir a la luz y ayudar a todos a tomar mejores decisiones (no sólo a puestos directivos y gerenciales sino también a posiciones operativas).
Las soluciones disponibles no se limitan al mercado de las grandes corporaciones. Actualmente es posible armar planes para poner en marcha BI con presupuestos acordes a pymes.
Suscribirse a:
Entradas (Atom)