Llegamos a ustedes gracias a:



Columnas de opinión

Los retos de administrar proyectos SaaS

Por: Gary Hamilton, arquitecto técnico de CRM en Acumen Solutions, una firma de consultoría de negocios y tecnología.

[16/11/2009] Incluso desarrolladores experimentados pueden encontrarse en problemas desarrollando e implementando aplicaciones personalizadas para plataformas de software como servicio, debido a que los fabricantes de SaaS no siempre adoptan los procesos corporativos aceptados para construir, probar y lanzar. El truco es adaptar sus procesos de manejo de la configuración para satisfacer los retos de SaaS.

SaaS es popular, en parte, porque las aplicaciones pueden ponerse disponibles sin el largo ciclo de implementación, típico del desarrollo propietario. Así que un nuevo reporte puede ser entregado inmediatamente, o un nuevo campo puede ser añadido al vuelo en una forma de entrada de datos.
Pero en tanto las ofertas de SaaS como Salesforce.com han madurado en plataformas completas de desarrollo, la complejidad de las aplicaciones ha crecido dramáticamente. Una aplicación de salesforce.com puede tener características tales como integración de servicios web en tiempo real, correo electrónico automatizado y suministros web, e integración de batch a los sistemas operacionales. Esto aumenta el riesgo de que un menor cambio pueda impactar en procesos críticos de negocios o quebrar la aplicación.
Es generalmente desafiante aplicar las mejores prácticas a la administración de configuración en los ambientes SaaS. Esto debido a que:
La aplicación podría estar soportada por negocios, no por TI.
Los administradores de SaaS podrían no estar familiarizados con la configuración y las prácticas de administración de lanzamientos.
Las herramientas de implementación de SaaS aún están madurando.
Implementar una aplicación generalmente requiere pasos manuales y automatizados.
Las integraciones de SaaS requieren lanzamientos de sincronización con los sistemas heredados.
El código, la configuración, los scripts de implementación y las listas manuales, necesitan ser revisadas en el repositorio de código fuente.
Considere el desarrollo de una aplicación de Salesforce.com desde un punto de vista de desarrollador tradicional, con el objetivo de administrar el desarrollo en la manera más controlada para asegurar su confiabilidad.
La plataforma Force.com, una plataforma personalizada de desarrollo de Salesforce.com, está basada sobre el paradigma Modelo-Vista-Controlador. Este paradigma puede ser definido como:
* Modelo: Representa la estructura de la base de datos. Esta es configurada a través del menú de configuración que permite a los administradores añadir campos personalizados a los objetos de datos CRM estándares, como registros y cuentas, o crear nuevos objetos de datos con sus propios campos personalizados. Tan pronto como un campo es definido o modificado, puede ser consultado a través de SOQL, el Salesforce.Com Object Query Language, o SOSL, el Lenguaje de Búsqueda de Objetos de Salesforce usado para búsquedas de texto de forma libre.
* Vista: Representa la interfase de usuario. Salesforce.com tiene un editor de formularios integrado para diseños de página que están asociados con objetos de datos. Las páginas también pueden ser desarrolladas en Visualforce, el lenguaje de marcas de salesforce.com que está estrechamente integrado con el código Apex, el lenguaje de programación de Force.com que, a su vez, está basado en Java.
* Controlador: Representa la lógica de negocios y de la aplicación. Las reglas para la validación de campos, flujos de trabajo y acciones de los botones son configuradas a través del menú de configuración. La lógica de negocios personalizada es desarrollada a medida que el código Apex es asociado con disparadores, la versión de Salesforce.com de procedimientos almacenados, controladores de Visualforce, o como librerías de clase compartidas.
El desarrollo de Force.com utiliza prácticas que deberían ser familiares para la mayoría de desarrolladores web. Salesforce.com permite copiar el ambiente de producción u org a un sandbox, justo como si copiara el modelo y código de producción de datos a un servidor de desarrollo. Un sandbox puede hospedar una copia completa de los datos de producción, códigos y configuración, o solo la configuración.
El desarrollo es hecho usando el ambiente de desarrollo integrado Force.com, un complemento para Eclipse que permite a los desarrolladores crear un proyecto vinculado a un org de desarrollo, un org de producción o un sandbox. Un proyecto puede ser sincronizado con un repositorio de código, permitiendo el ingreso y salida de código.
Apex tiene una estructura de prueba de unidades integrada, que requiere 75% de cobertura para todo el código Apex antes de que pueda ser implementado. El IDE Force implementa código desde un proyecto a un org de producción.
Cómo abordar la auditoría, seguridad y continuidad de negocios de manera directa
La administración de la configuración tradicionalmente ve la configuración de producción y código como una línea de base, identifica cambios que serán lanzados, y los incorpora en una nueva y auditable línea de base una vez que la entrega es validada. Asegurar la confiabilidad para la empresa involucra:
*Limitar qué usuarios tienen un perfil de administrador de sistemas, y definir sus responsabilidades de administración de la configuración.
*Establecer procedimientos para asegurar que el código, la configuración y los datos para la producción sean registrados en el repositorio de código y archivados (esto podría requerir tomar imágenes instantáneas manuales de las reglas para compartir, la jerarquía de roles, etcétera).
*Crear scripts de instalación manuales o automatizados.
*Asegurarse de que hay un plan para respaldar los cambios de producción si fuera necesario.
*Implementar a un sandbox para pruebas y QA.
*Repetir la implementación para producción.
*Validar la implementación en producción.
Los tropezones
Incluso los desarrolladores senior pueden perderse en la maleza tratando de resolver cómo una característica puede ser, o podría haber sido implementada, en Force.com. Los típicos tropezones incluyen:
*Con numerosas opciones de configuración y poderosas herramientas de programación hay muchas formas de implementar las mismas características. Los expertos en configuración y desarrolladores corren el riesgo de reinventar la rueda, si no colaboran de manera cercana en el diseño de la solución.
*Las herramientas de implementación de Force.com no soportan actualmente ítems críticos como reglas para compartir datos, campos de listas de elección sobre objetos de datos estándares, procesos de registro y ventas, y la jerarquía de administración de roles.
*Las pruebas de unidad de Apex son impactadas por datos org reales, de modo que el código que pasa los requerimientos de los exámenes de unidad en el sandbox podrían no implementar. Por ejemplo, las consultas de datos sobre objetos con más de 100K de datos requieren consultar un campo ID externo. Las pruebas de unidad que pasan en un sandbox pueden fallar en la producción, matando su implementación.
El éxito está todo en el plan
Tener la administración de la configuración bajo control es mucho más fácil si los equipos de desarrollo y pruebas están en la misma página desde el primer día. Mientras tanto, un típico ciclo de construcción/lanzamiento luce así:
* Registrar código.
Compilar código.
Correr scripts de bases de datos e implementar código para probar.
Correr pruebas/inspecciones
* Implementar a preproducción/producción
* Validar la implementación.
Las siguientes tareas necesitan ser adaptadas para el desarrollo en Salesforce.com:
Registrar código y configuración desde el desarrollo.
Registrar la lista de tareas para cambios manuales en el repositorio de código.
Implementar cambios manuales de código/configuración para probar.
Correr la implementación automatizada de Eclipse/Ant para probar.
Correr inspecciones de prueba.
Implementar usando el mismo proceso a preproducción/producción.
Validar implementación.
Las plataformas de desarrollo de software SaaS, como Salesforce.com, requieren una mezcla de configuración y desarrollo personalizado que puede confundir a los desarrolladores y ser difícil de implementar. Esto puede ser abordado adaptando su proceso de administración de la configuración para los proyectos SaaS.
Aunque las ofertas de SaaS están diseñadas para limitar el tiempo que se dedica al desarrollo tradicional, se requiere alguna manipulación para poder integrarlas completamente con los sistemas corporativos. Una vez que entiende cómo la programación estándar y las prácticas de administración de configuración aplican a una aplicación SaaS, se vuelve más fácil enfrentar al enfoque tradicional.
Network World (US)
Gary Hamilton es un arquitecto técnico de CRM en Acumen Solutions, una firma de consultoría de negocios y tecnología.