Arquitectura SharePoint

Creo que para todos los que nos movemos en proyectos que involucran a la plataforma SharePoint, teniendo en mente proyectos de un tamaño mediano a grande. Es un hecho la necesidad de tener una arquitectura y una planificación en general de lo que va a ser la solución en términos de los requerimientos del negocio. Con SharePoint 2010, los elementos de arquitectura a considerar siguen siendo los mismos básicos de la plataforma empresarial 2007. Pero cuando uno revisa en detalle la nueva versión, comienza a encontrar elementos que han sido totalmente rediseñados, y es muy importante tener elementos de donde poder arrancar para poder establecer nuestras arquitecturas iniciales.

En el repositorio de Microsoft hay un gran número de documentos, artículos, gráficos, en fin, mucha información, que personalmente pienso debería haber sido organizada de otro modo, y ser un poco más descriptiva y práctica. Pero siendo eso lo que tenemos de primera mano para planear las primeras etapas de la arquitectura, no está demás arrancar por ahí. Lo que uno si nota es que al menos eso da una idea de los elementos primarios que uno debe considerar en una arquitectura de una solución SharePoint, por ejemplo: Planeación de sitios, Planeación de Seguridad, Planeación de Aplicaciones de Servicio (nuevo en SP 2010), y en general planeación de los elementos que van a impactar sobre las necesidades del negocio: gestión documental, gestión de contenido web, inteligencia de negocio, interacción social, entre otros.

Planning and Architecture

Específicamente cuando se va a realizar una planeación y arquitectura para un tema como Gestión Documental, en SP 2010 aparecen elementos muy importantes, que deberán tenerse muy en cuenta para implementar una verdadera solución de gestión documental con SharePoint. Aparecen aplicaciones de servicio como es la de Metadata Administrada. Esto habilita posibilidades que no existían en SP 2007, como por ejemplo poder tener verdaderas taxonomías de información. Almacenes de términos, sinónimos, centros de registros, tag sociales, conjuntos de documentos, IDs de documentos, HUBs de tipos de contenido, y muchos otros elementos, van atados a este nuevo servicio empresarial. Si realmente se requiere una solución de gestión documental lo suficientemente avanzada, un arquitecto mínimamente deberá entender todos los conceptos subyacentes y por supuesto tener idea cómo se implementan y usan en SP 2010.

Metadata Administrada

Otro elemento esencial en la planeación y arquitectura de una solución SharePoint es un Plan de Gobierno. Esto para muchas empresas llega a ser un tema nuevo, pero si la empresa es grande, tiene la plataforma SP y no tiene políticas y estándares para la misma implementados, antes de hacer nada debería iniciar a crear un Plan de Gobierno. Esto termina siendo un documento donde se consignan las "leyes" que absolutamente todo el mundo en la organización deberá respetar y cumplir.

Plan de Gobierno

Quiero hacer claridad en que no se debe desmeritar todo esto en soluciones más pequeñas, pero bueno, un arquitecto debe poner en la balanza, soluciones, presupuestos, tiempos, y en general los recursos de cada proyecto, para ver si ameritan contemplar todos estos elementos. Es lo ideal tener en cuenta todo esto, pero requiere tiempo y eso significa dinero.

Todo lo anterior es la globalidad de las cosas o elementos que las necesidades de negocio van a requerir de una solución SharePoint. Pero llegan a terrenos más personales, qué hay de la arquitectura de desarrollos .NET para SharePoint?

Lo primero que una Arquitecto SharePoint que tenga dentro de sus soluciones implementar elementos con la plataforma .NET para SharePoint debe conocer es lo que Microsoft ya ha preparado como una vista rápida de los elementos arquitectónicos que se deberán tener en cuenta para los desarrollos o personalizaciones sobre SharePoint 2010 específicamente, igual lo hay para las versiones anteriores.

Software development kit

SharePoint Guidance

Algo insólito, y pienso que no se hace en muchos casos es el uso de UML en proyectos .NET para SharePoint, al menos ningún libro, artículo, en general ningún "gurú" habla del tema. Más allá de los "monachos" UML, lo preocupante es la falta de propaganda de los patrones de diseño que una buena solución .NET para SharePoint mínimamente deberá implementar. Hablo de UML porque es nuestro lenguaje formal para dar a entender los patrones. De los cientos de libros de desarrollo que hay para SP 2010 y 2007, es ya aburridor y tentador para la hoguera, su insufrible repetición de lo mismo con distintas palabras de lo que todos ya sabemos: WebParts, receptores de eventos, listas, bibliotecas, en fin temas de desarrollo que realmente deberían subirse de categoría y mostrar soluciones más serias de ejemplo en estos relucientes libros de 500 a 1000 páginas.

Feliz Arquitectura