Cuestiones sobre el diseño de soluciones en SharePoint (4)

Continuando con el tema de la organización, como ya he dicho las colecciones de sitios son un punto muy importante a tener en cuenta. Alguna de las limitaciones las podemos superar por medio de la instalación de soluciones y características a través de las cuales podemos hacer un despliegue más rápido sobre distintas colecciones de sitios.

A la hora de organizar, yo, personalmente tengo en cuenta dos cosas, que creo son muy importantes, la primera es el tema de la seguridad.

Seguridad

SharePoint cuenta con una serie de roles, grupos y acciones con las que hay que familiarizarse para poder desenvolverse correctamente.

Establecer a que información debe acceder cada cual, que puede ver y que puede editar, nos va a ayudar a tener una idea clara de cómo debemos organizar otras cosas.

Yo primero suelo hacer esto en dos pasos, en un primer paso repaso la información que va a contener la aplicación y los usuarios que van a acceder a ella; establezco una correspondencia creando una serie de grupos de usuarios. En un segundo paso, una vez tenemos clara la estructura que va a tener nuestra aplicación, colecciones de sitios, sitios y subsitios y la información que va a contener cada uno de ellos, vuelvo a ajustar los permisos.

Por ejemplo en el caso que comente anteriormente en donde teníamos el dilema de si establecer la jerarquía por Delegación o por Departamento, si hemos optado por establecerla por Delegación, tenemos que asegurarnos de que el jefe de almacén pueda acceder al departamento de almacén en cualquiera de las delegaciones, pero no podrá entrar en otros departamentos.

Cuando pensemos en la seguridad y los permisos de acceso también hay que tener en cuenta quien administrará los sitios ¿hay un departamento de sistemas encargado de ello? ¿Van a poderse crear nuevos subsitios? ¿Quién se va a encargar de mantener los permisos?

Existe también una jerarquía de permisos, de modo que podemos asignar permisos que se irán heredando en los distintos subsitios. Hay que recordar que los permisos no son como los de NTFS, es decir que no podemos heredar y tener permisos únicos al mismo tiempo, es o una cosa o la otra.

Acceso y Agregación de la información

La segunda cosa que suelo tener en cuenta es donde se va a localizar la información dentro de la aplicación, aspectos a tener en cuenta como el hecho de cómo se quieren agregar los datos y donde van a estar localizados los mismos son de vital importancia.

En MOSS disponemos del “Cotent Query Web Part” que nos va a permitir agregar datos de la misma colección de sitios, pero en WSS debemos hacerlo nosotros mismos, hay que tener en cuenta que información debemos agregar y como deseamos verla, para poder pensar cómo vamos a hacerlo.

Cuestiones que me han preguntado estos días

Bases de datos de Contenido

Como comente anteriormente cada aplicación web al menos contiene una base de datos de contenido, en ella se almacenará la colección de sitios principal y si lo deseamos otras colecciones. También una aplicación web puede tener más de una base de datos de contenido, que contendrán una o más colecciones de sitios, pero una colección de sitios no puede usar más de una base de datos.

Finalmente todo el almacenamiento de SharePoint recae en una base de datos, tenemos que tener en cuenta la capacidad de almacenamiento que esperamos tengan nuestras colecciones de sitios, no es lo mismo una aplicación web pública realizada con las características de CMS, que una intranet en donde vamos a almacenar miles de documentos de office.

Además y como es lógico debemos prever un plan de contingencias y de mantenimiento para nuestras bases de datos, pensad no es lo mismo una base de datos de 50GB que de 500GB, tiempo de respaldo, soportes necesarios, mantenimiento, horarios, etc…

Cuestiones sobre el diseño de soluciones en SharePoint (3)

Uno de los primeros puntos a tener en cuenta cuando se desarrolla una solución para SharePoint es cómo vamos a organizar el contenido y la información.

SharePoint nos ofrece distintas posibilidades que veremos a continuación, pero también hay que tener en cuenta algunos factores importantes.

Granjas, Aplicaciones Web, Colecciones de Sitios, Sitios y Subsitios

En primer lugar tenemos que comprender las opciones que nos brinda SharePoint para estructurar nuestra solución.

Debemos de tener claro que todos los datos de SharePoint son almacenados en distintas bases de datos en un servidor de SQL. Con lo cual desde el punto de vista del diseño de aplicaciones de SharePoint, tenemos que contemplar cuando menos un plan de contingencias y de mantenimiento de las bases de datos que conforman nuestra instalación.

Bases de datos de SharePoint 2007

Dicho esto tenemos que entender ahora 5 piezas fundamentales. No quiero extenderme más de lo necesario, a modo de resumen:

Una granja de servidores es un conjunto de servidores que trabajan en unidos, donde podemos dividir distintas responsabilidades entre distintos servidores. Podemos tener una granja de un único servidor donde todos los servicios funcionen sobre una única máquina (servidor web, búsquedas, Excel services, Forms services, SQL Server …) lo más lógico desde el principio es dividir en dos partes la granja, es decir dejar un servidor para el SQL Server y otro con el resto de servicios. Conforme van aumentando los clientes o la demanda de servicios podemos ir añadiendo servidores y establecer las nuevas funcionalidades de las cuales se ocuparan esos servidores, así por ejemplo podemos añadir un nuevo servidor a nuestra granja que se ocupe únicamente del servicio de búsquedas de modo que descargaremos a otros servidores de dicha responsabilidad.
En el caso de una granja pequeña en crecimiento, pongamos por ejemplo 3 servidores, los roles podrían ser los siguientes, servidor de SQL, servidor Web Front End, y un servidor que se ocupara del resto de los servicios, búsquedas, Excel services, Form Services, Shared Services etc…

En el caso de una instalación de Windows SharePoint Services, también es recomendable dividir siempre que sea posible al menos los roles de SQL Server y de Web Front End.

Obviamente todo esto pasa por un estudio de las licencias necesarias, para montar la infraestructura que deseemos, esto lo dejaremos al margen.

Una vez que tenemos clara la estructura de nuestra granja, tenemos todavía una importante labor, establecer cómo será la jerarquía de nuestros sitios.

En la terminología de SharePoint, tenemos otro punto importante, el de la aplicación web. Una aplicación web será el punto raíz de la estructura de una solución, cuando creamos una aplicación web, SharePoint crea un nuevo sitio de IIS en una dirección y un puerto de nuestra máquina, así como una base de datos en donde albergará el contenido de dicha aplicación web.

Una aplicación web, no es más que un vinculo o una dirección y una base de datos de almacenamiento con el objetivo de albergar cuando menos una colección de sitios. Es por esto que una vez creada una aplicación web a través de la administración central de SharePoint, lo siguiente es crear una colección de sitios que quedará enlazada con la raíz de la aplicación web.

Una aplicación web como mínimo contiene una colección de sitios, pudiendo a través de de la administración central fijar un punto de anclaje para nuevas colecciones de sitios.

En una granja de servidores podemos tener distintas aplicaciones web como una intranet, una extranet, o un sitio web publico), ahora bien, aunque podemos usar la misma dirección web, cada aplicación web deberá tener su propio puerto; no podemos tener dos aplicaciones corriendo sobre el mismo puerto.

Una colección de sitios, es como un árbol, del cual pueden colgar sitios y subsitios, una colección de sitios es el inicio de una jerarquía de sitios, y al igual que en árbol una colección de sitios tiene un sitio raíz. Todo esto es importante porque debemos de tener en cuenta diversos factores como veremos luego que afectan en su conjunto a una colección de sitios.

Antes de continuar, terminaré de matizar que es un sitio y que es un subsitio. Un sitio es un apartado o nivel en el cual encontraremos contenido (entender aquí, páginas, listas, bibliotecas de documentos, subsitios, etc…) y un subsitio es un sitio que tiene padre.

La importancia de las colecciones de sitios consiste en que dentro de una colección de sitios existen ciertos elementos y recursos comunes dentro de la colección y este es un aspecto muy importante a la hora de diseñar una solución de SharePoint.

Dentro de esos elementos comunes estan:

–    Flujos de trabajo
–    Tipos de contenido
–    Columnas de sitio
–    Seguridad por grupos
–    Ámbito de búsquedas (WSS)
–    Características (features)
–    Papelera de reciclaje
–    Informes de uso
–    Web Parts
–    Páginas maestras
–    Plantillas de sitios
–    Plantillas de listas
–    Quotas (limites de espacio)
–    Copias de seguridad

Para que quede claro, dentro de una aplicación web como he dicho anteriormente puede haber más de una colección de sitios, pero todos estos elementos son dependientes de la colección de sitios, de modo que en una colección podemos tener una plantilla personalizada para crear listas de tipo “Pedido” pero en la otra colección esta plantilla puede no existir.

Organización

Al igual que las empresas y corporaciones tienen una estructura determinada debemos establecer cómo queremos estructurar nuestras aplicaciones web en SharePoint. Esto aunque puede parecer sencillo, es sin duda una de las cosas más complicadas.

Veamos un pequeño ejemplo, tomemos una organización dedicada a la fabricación de muebles, supongamos que tiene tres fábricas ó delegaciones en Madrid (central), Barcelona y Sevilla. Dentro de cada delegación, hay diversas divisiones  ó departamentos, Almacén, Fabricación, Ventas, Financiero y Postventa.

Podemos hacer una estructura por delegación

–    Madrid

o    Almacén
o    Fabricación
o    Ventas
o    …

–    Barcelona

o    Almacén
o    …

–    Sevilla

o    Almacén

O bien podemos hacerla por departamentos

–    Almacén

o    Madrid
o    Barcelona
o    Sevilla

–    Fabricación

o    Madrid
o    Barcelona
o    Sevilla

–    ….

Aquí empieza el dilema, ¿Cómo estructuramos nuestra aplicación web?.

Cada organización es muy particular, de modo que no existen formulas magistrales. Por proponer un comienzo, deberíamos analizar qué información es la que va almacenar cada sitio y que seguridad ha de tener cada elemento. ¿Los usuarios de Sevilla solo deben ver lo de Sevilla o pueden ver también lo de Barcelona y Madrid? ¿Deben los del departamento de Almacén ver los datos de Ventas? ¿Le interesan al departamento de Posventa los incidentes de las tres delegaciones?

¿Debo crear una colección de sitios por cada delegación? ¿Por cada departamento? ¿Debería una delegación ser un sitio y un departamento un subsitio? ¿Debería ser al revés? ¿Debería tener dos estructuras, por departamento y por delegación? ¿En colecciones de sitios diferentes o en la misma colección?

A la hora de desarrollar una solución debemos tener en cuenta un montón de aspectos, cuestiones como la seguridad, la información y su flujo, las búsquedas y los recursos con los que va a contar son algunas de las más importantes.

Debemos empezar haciendo un análisis muy cuidadoso de todos estos aspectos para no llevarnos sorpresas luego.

Cuestiones sobre el diseño de soluciones en SharePoint (2)

Como comentaba en el post anterior, me gustaría dedicar una serie de artículos a algunas de las consideraciones sobre el diseño de soluciones en SharePoint, el en titulo olvide mencionar que me voy a centrar básicamente en el área empresarial.

FeedBack

Uno de los aspectos que considero más importante es el feedback de los usuarios. Como mencione anteriormente muchos de sus problemas a veces se resuelven con imaginación y creatividad, siempre hay que estar atentos a lo que dicen los usuarios.

Por ello una de las partes principales de un desarrollo en SharePoint, puede comenzar por un simple foro de discusión en donde los usuarios puedan dejar sus opiniones tanto críticas como de mejora.

Evidentemente aquí no hay mucho de diseño, pero esto será un pilar fundamental si se hace un buen uso del mismo.

Para poder categorizar los temas que se tratarán en el foro, a la lista se le puede añadir un tipo de contenido o un campo que contenga los diversos asuntos a los que hace relación un post, así como otro campo que indique si el post es referente a una crítica o a una mejora.

En la mayoría de las organizaciones dinamizar un simple foro como este suele ser un problema si no existe una cultura de colaboración, en ocasiones a la gente le da vergüenza comentar cosas, pensando que lo único que van a decir son estupideces, bien, esto es una labor interna en la que hay que concienciar a la gente (y este es un buen punto de arranque) aludir a que jamás mejoraran las herramientas de las que disponen si ellos no hacen nada por mejorarlas; atacar ese pequeño orgullo que todos tenemos, tocar esa fibra, suele dar un buen resultado.

Esto tiene su contrapartida, si el usuario se expresa y pide cosas hay que dárselas (y rápido) si no toda labor anterior habrá caído en balde. Por parte del departamento de IT, habrá que valorar las peticiones de los usuarios y como mencione (y no dejaré de mencionar en lo sucesivo) deberemos realizar una valoración de dichas mejoras de modo que podamos encontrar quórum para llevarlas a cabo y que encajen en tiempo, coste y complejidad.

Según mi experiencia, el usuario tiende a pedir en ocasiones cosas como ¿no podríamos tener un botón aquí que hiciera tal o cual cosa?, nosotros tenemos que pensar en que es lo que el usuario quiere hacer realmente, ¿Por qué, quiere hacerlo?, ¿Qué ventajas encuentra en ello? Y de qué modo podemos ofrecerle algo que le ayude sin que ello suponga demasiada complejidad; Igual el botón no pude estar allí, pero tal vez podamos poner un hipervínculo aquí para hacer lo mismo o casi lo mismo.

El vocabulario del usuario y el nuestro es distinto, hay que hacer un esfuerzo por entenderle, comprenderle y dar a entender lo que nosotros podemos hacer por él.

Una pequeña encuesta en donde los usuarios voten ó valoren las mejoras, puede ser de gran ayuda a la hora de determinar por dónde empezar, así como de tener una idea de a cuanta gente vamos a contentar y/o enfadar con la realización de los cambios.

Un escenario como este puede complicarse todo lo que uno quiera, pero en la práctica debe ser algo sencillo, empecemos dando algo con lo que todos podamos trabajar, un foro en SharePoint y dos o tres campos personalizados (diseño 0%, evangelización y concienciación sobre el uso 100%) pongámoslo en marcha y escuchemos a nuestros usuarios, ellos tienen cosas importantes que decir.

Vigilancia del Entorno

La rapidez con que una empresa sea capaz de reaccionar a los acontecimientos de su entorno, es una medida de los reflejos corporativos.

Sin duda es una parte muy importante, vigilar nuestro entorno; diseñar un portal de vigilancia del entorno dentro de una empresa es algo que aporta gran valor. Hace algún tiempo ayude a un amigo a realizar un portal de vigilancia del entorno y tuve la oportunidad de aprender algunas cosas importantes.

Gracias a internet tenemos a nuestro alcance una ingente cantidad de datos, muchos de ellos nos pueden ayudar a ver qué es lo que está ocurriendo en nuestro entorno, pero identificar la información que nos es útil entre tantos datos puede ser un problema.

Cuando mi amigo me pidió ayuda él había hecho gran parte del trabajo, el había buscado las fuentes de datos que consideraba más relevantes para el entorno de su empresa, clientes, proveedores, mercado, producto, marketing, competencia, tendencias y noticias del sector, incluso encontró algunos foros donde se mencionaba su empresa, todo ello estaba dentro de un site en donde había usado el web part de transformación de XSLT, para recuperar las feeds que él había considerado importantes y poderlas visualizar en varias páginas en función de las distintas categorías a las que hacían referencia.

El site, era útil, de un plumazo tenia agregadas muchas de las noticias que eran relevantes para la empresa, sin embargo la gran cantidad de noticias apabullaba a los usuarios; la gente entraba veía la ingente cantidad de noticias, leía una o dos y salía.

El site resolvía un problema, pero desde luego no lo hacía de la mejor manera posible, pero había algo por dónde empezar lo cual es como ya hemos comentado, bueno.

Le sugerí, que antes de hacer nada, hablara con los usuarios y les preguntará como se podría mejorar el site de vigilancia, tras unas cuantas sugerencias (feedback) por parte del personal de la empresa, había varios puntos en común, la focalización (o audiencia) de la información y la posibilidad de escalar noticias.

La focalización de la información hace referencia al hecho de donde se debe encontrar la información,  en vez de tener un site en donde concentrar toda la información, los usuarios opinaban que era mejor que cada web de departamento se viese un resumen de esas noticias, de este modo se orienta la información a una audiencia determinada.

En segundo lugar, debería existir un mecanismo de escalar las noticias importantes; cuando se cuenta con mucha información alguien debe poner está en su contexto, y valorarla de manera adecuada. En la empresa de mi amigo fabrican piezas con plásticos inyectados, de modo que la invención de un nuevo compuesto o mecanismo puede parecerle muy importante a la gente de producto pero a alguien de dirección un artículo más bien técnico puede parecerle intrascendente o un autentico coñazo. De modo que la información ha de ser valorada por alguien de las trincheras que la ponga en su contexto y le de la importancia que debe tener y luego la transmita dentro de su contexto al resto de la organización.

Eso dio pie a la creación de un site DAFO, (Debilidades, Amenazas, Fortalezas y Oportunidades).

Se hicieron los cambios necesarios para que cada departamento visualizara la información pertinente a su área, y como complemento de esa información con un simple click se podía llevar la información del agregador de noticias al sistema DAFO, con eso la noticia podía crear una alerta en el sistema, periódicamente se examina el site DAFO y se toman decisiones en función del contenido.

En un primer momento el sistema funcionaba de manera manual, es decir junto a cada noticia existía un enlace a la web DAFO, en donde el usuario debía crear un breve resumen de la noticia, el tipo de alerta Debilidad, Amenaza, Fortaleza o Oportunidad y un comentario personal de ¿Por qué? Se contempla la noticia como una alerta.

La gerencia de la empresa usa la web de DAFO de forma periódica en una reunión quincenal de seguimiento de diversos asuntos, se analizan todas las alertas y se hace un pequeño acta que se deja en ese mismo sitio.

Más adelante cuando el sistema demostró su utilidad, se mejoró sustancialmente incluyendo algo de programación y ahora permite que tras valorar la noticia, esta incluya un enlace a la fuente original, también el site DAFO cuenta ahora con una serie de gráficos y resúmenes quincenales de las alertas que se han producido así como una lista por cada departamento que permite introducir las fuentes desde donde cada departamento va a recibir las noticias así como los filtros que ha de pasar el contenido para ser agregado; de este modo se su pueden añadir y suprimir fuentes y filtros sin necesidad de programar absolutamente nada.

Cuestiones sobre el diseño de soluciones en SharePoint (1)

Una de las incuestionables capacidades de SharePoint, es la de poderse adaptarse rápidamente a muchas de las problemáticas que surgen en las empresas.

Sin embargo a la hora de diseñar estas soluciones no todo es tan sencillo, con esto me estoy refiriendo al hecho de que nos encontramos en innumerables ocasiones con problemáticas empresariales que no son excesivamente complejas pero que sin embargo a la hora de trasladarlas a SharePoint, se convierten en un verdadero infierno.

Durante estos años que llevo trabajando con SharePoint, me he encontrado con multitud de casos en los que cosas que parecían relativamente sencillas por que el 80% del trabajo ya estaba hecho, funcionalidades que de por sí contempla SharePoint el 20% restante ha supuesto una cantidad de trabajo terrible. Donde ese 20% has supuesto una cantidad de tiempo y un coste tan elevado que es casi imposible de justificar.

Vamos a dejar al margen las ocasiones en que el diseño de una solución debe ser estrictamente fiel a un procedimiento empresarial, y debe reflejar de manera completa y exacta dicho procedimiento; en este punto la postura es clara; tendremos que hacer lo que sea para que la solución cumpla al 100% los requerimientos del procedimiento.

En el resto de ocasiones, tenemos la disyuntiva de hasta qué punto debemos ser flexibles en el desarrollo de la solución. Según mi experiencia debemos ser flexibles y agiles.

Muchos de estos procesos requieren que seamos agiles, no podemos esperar meses a tener una herramienta para poder gestionar eficazmente. A esto debemos añadir el hecho de que muchos de estos procesos están vivos, es decir se empieza haciendo cosas de una manera, y tras evaluaciones sucesivas del procedimiento así como de la experiencia que se va adquiriendo del uso del mismo, se va optimizando, suprimimos, añadimos y cambiamos pasos, información y flujos de la información.

Tenemos que contemplar el diseño como una negociación Win-to-Win, en donde todos ganamos por una parte tendremos que adaptar los requisitos o los procedimientos para que estos sin perder en esencia su objetivo sean los menores para no tener que realizar complejos sistemas para sustentarlos. De esta manera y solo de esta manera seremos capaces de diseñar sistemas cuyo ROI, sea positivo desde el comienzo.

En esta negociación, se deben poner sobre la mesa los requerimientos y los recursos de que disponemos para trasladar estos a la plataforma.

Un sencillo ejercicio de ponderación, donde valoramos los requisitos de modo que los que más valor aportan tendrán una puntuación más elevada y los que menos valor aportan una puntuación inferior y del mismo modo, evaluamos la complejidad que entrama desarrollar cada una de las partes del sistema, valorando en términos de tiempo, coste y complejidad cada uno de los pasos necesarios para cumplimentar dichos requisitos.

A través de un ejercicio de esta índole, debemos suprimir todo aquello que en esencia sea superfluo y buscar alternativas a aquellas partes del sistema que por su tiempo, coste o complejidad vayan a ser cuellos de botella tanto en el uso como en el desarrollo de las mismas.

Otro punto importante, es el de la rapidez; cuanto antes demos a nuestros usuarios una herramienta y algo básico con lo que trabajar empezaremos a recibir feedback que deberemos tener en cuenta, muchas de las propuestas del usuario final son imaginativas y creativas (y generalmente más baratas).

En muchas ocasiones esto conlleva exprimir lo que tenemos al máximo, más adelante siempre tendremos oportunidades de realizar esas complejas partes que harán de nuestra solución una solución perfecta.

En próximos posts me gustaría comentar algunas experiencias tanto mías como de algunos colegas sobre el diseño de soluciones con SharePoint.

Cualquier comentario o aportación será bienvenido.