Problemas Impíos (Wicked Problems) y SharePoint

Por esas cosas del trabajo, los últimos tiempos me he tenido que enfrentar a montañas de Problemas Impíos. La verdad, no se me ocurre una mejor traducción a «Wicked Problems»… mirando un diccionario veo que se podría traducir como «Problemas Maliciosos» o «Problemas de Broma», pero la cosa es demasiado seria (por lo menos personalmente), por lo que lo dejo en Impío…

Wicked Problems, según la explicación de la Wikipedia (http://en.wikipedia.org/wiki/Wicked_problems), es una frase usada en planificación social que describe un problema que es entre difícil e imposible de solucionar porque sus requerimientos son incompletos, contradictorios o constantemente cambiando. Peor aún, las acciones encaminadas a solucionar Wicked Problems conducen muy probablemente a la creación de nuevos Wicked Problems, por lo que el asunto se reproduce como las cabezas de Medusa…

En realidad, no tengo ninguna idea de planificación social, así que no se me ocurre como llegue al nombre. Pero pensando en cómo describir el asunto de una forma sencilla, se me vino el nombre a la cabeza. Volviendo a la Wikipedia, Jeff Conklin (no me pregunten quien es, no tengo ni idea, pero su nombre está escrito allí mismo) nos indica que hay cuatro características que definen un Wicked Problem:

1 – El problema no se entiende hasta después de formular una solución
2 – Participantes en el problema lo ven de formas radicalmente diferentes
3 – Limites y recursos para resolver el problema cambian constantemente
4 – El problema nunca se soluciona completamente

Veamos a que me refiero. En el proyecto en el que estoy trabajando actualmente, la primera implementación fue hecha como un piloto para saber cómo se podría utilizar SharePoint en la empresa. Como piloto, es utilizado por solamente una fracción (3.000) del número de usuarios finales (50.000), y en una sola sucursal de la empresa (finalmente será utilizado en 14 países en dos continentes). Por lo tanto, el primer diseño fue sencillo: una Aplicación Web con una Colección de Sitios. Nada en contra, para ese número de usuario iníciales SharePoint se muere de la risa por la carga, esta 90% del tiempo haciendo nada y el diseño es más que valido.

Cuando comenzamos a hacer el diseño definitivo, lo primero que hicimos fue distribuir la información lógicamente en diferentes «contenedores» o Aplicaciones Web (una para Portal, otra para Colaboración, otra como Record Center, etc.). Y dentro de algunos de los contenedores, una distribución más granular por medio de Colecciones de Sitios. Esto nos garantiza poder crecer de una forma organizada en el futuro, manteniendo la información separada tanto lógica como físicamente (diferentes Bases de Datos que no crezcan más de lo necesario y se puedan hacer BackUps y Restauraciones en tiempos decentes). Y aquí empiezan los Wicked Problems…

Según la definición que les comentaba anteriormente, nos encontramos con el primer punto: hasta después de formular la solución (separar la información en diferentes Aplicaciones Web y Colecciones de Sitios), no resulto que no entendíamos el problema: los usuarios del sistema Piloto se habían acostumbrado a agregar información a lo largo y ancho del sistema utilizando la WebPart de Content Query (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=3&itm=681 y http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=3&itm=685) y, por supuesto, querían seguir trabajando de la misma manera con el nuevo sistema. Como recordará, con esta WebPart es muy fácil «arrejuntar» listas y mostrar manzanas junto con naranjas, pero tiene un problema pequeñito: solo puede agregar información presente dentro de la misma Colección de Sitios.

Y aquí llegamos al segundo punto de la definición: nosotros, tecneutas, vemos el problema de una forma muy diferente a como lo ven los usuarios. Nosotros queremos dividir la información de una forma lógica, usando lo que nos ofrece SharePoint para hacerlo. Los usuarios quieren ver información regada por todas partes en un solo sitio, el problema es visto desde perspectivas completamente diferentes…

Por supuesto el tercer punto se ve venir de inmediato: el usuario quiere regresar al sistema antiguo cambiando los limites, luego cambia de opinión para regresar al nuevo diseño, luego viene con las ideas mas alrevesadas de este mundo y el otro… pero eso sí, el sistema tiene que ser operativo en la fecha determinada de antemano… limites y recursos cambian constantemente…

Finalmente llegamos al cuarto punto: el problema no se soluciona nunca completamente. A final de cuentas hay que buscar el compromiso en el que todo el mundo consigue una parte del botín, pero nadie se hace rico de verdad… Un par de Colecciones de Sitios por aquí, y otro par por allá, pero no más de un cierto número limitado… el cliente contento porque puede hacer algunas de las cosas que hacia anteriormente, nosotros contentos porque podemos separa de una forma (imperfecta, pero separar al fin y al cabo) la información de una forma lógica. El cliente descontento porque no puede tener todo como lo tenía anteriormente, nosotros descontentos porque nos han quitado una buena parte de flexibilidad en el diseño…

En fin, es un caso recursivo que supongo todos ustedes se han encontrado más de una vez en la vida. Lo malo del asunto es que, por definición, Wicked Problems no tienen una solución satisfactoria y, como veíamos al principio, si un Wicked Problem se acerca a una solución, tiene la tendencia a crear nuevos Wicked Problems… ya veremos que nos trae el futuro en este proyecto…

Gustavo – http://www.gavd.net
Escriba un Comentario que me haga reir…

Todos a comprar SharePoint: compre uno y llévese dos…

Microsoft ha anunciado la semana pasada un recorte entre 15 y 25% de los precios en sus productos empresariales (http://www.microsoftincentives.com/ ), entre los que cae SharePoint Server. Se ha preguntado alguna vez cuánto costaría una instalación, digamos mediana tirando a chiquita, de SharePoint? Pues si ha intentado meterse por entre la maraña de precios, tipos de licencias, CALs y demás, le deseo mucha suerte y paciencia, y le aseguro que terminara simplemente llamando a Microsoft para que le envíen una oferta…

Veamos:

– WSS es gratis… bueno, gratis, gratis, nada es gratis en esta vida, así que por lo menos tendrá que comprar Windows 2008 server para poderlo instalar
– MOSS 2007 vale $4.400 dólares
– MOSS 2007 Standard cuesta $8.200 dólares, y el motor de búsqueda le permitirá buscar a través de Colecciones de Sitios, pero con un límite de documentos de hasta 500Kb
– MOSS 2007 Enterprise le cuesta algunos centavos más, exactamente $57.670 dólares, pero le va a dar el motor de búsqueda completo, el Catalogo de Datos Empresariales, servidor de Excel y de InfoPath y demás

Y luego tenemos las licencias por usuario:

– Licencia por cada usuario para la versión minima o Standard vale $94 dólares
– Para la versión Enterprise tiene que comprar la licencia Estándar MAS la empresarial que vale $75 dólares

Todo el esquema de precios lo puede encontrar en http://office.microsoft.com/en-us/sharepointserver/FX102176831033.aspx?ofcresset=1 y lo que cada uno de los servidores puede hacer en http://office.microsoft.com/en-us/sharepointserver/FX101865111033.aspx (o en http://office.microsoft.com/search/redir.aspx?AssetID=XT102011901033&CTT=5&Origin=HA101978031033 si esta dispuesto a leerse un documento infinitamente aburridor).

Así que pensemos que tenemos una instalación sencillita (la versión minima) para una empresa de 1.000 empleados, algo que SharePoint puede hacer con los ojos cerrados, cuanto tendríamos que pagar? Pues bien, digamos que ponemos dos servidores de SharePoint (no por que necesitemos dos, sino por eso de que si uno saca la mano el otro pueda seguir funcionando), y no le ponemos un servidor dedicado a búsqueda (lo que no es tan malo si no hay excesiva carga de documentos, lo que no es de esperar con 1000 usuarios). De igual manera usamos dos servidores de SQL, por lo de que más vale prevenir que curar. Cuánto vale el asunto en licencias (sin hardware)?

2 MOSS 4.424 x 2 8.848
1000 licencias para usuarios de SharePoint 94 x 1.000 94.000
2 SQL Standard 5.999 x 2 11.998
4 Windows Server Standard 999 x 4 3.996
1000 licencias para usuarios de Windows 400 x 1.000 400.000
Total   518.842

Todo en dólares

Supongo que ya se va enterando por donde va el negocio: la cuestión no es vender a SharePoint o SQL, el negocio se trata de vender licencias de Windows. Del precio total de 520.000 se puede decir que 20.000 son para SQL, 100.000 para SharePoint y 400.000 para Windows.

Y bien, volviendo al principio, apúrese a comprar a SharePoint ahora mismo, pues la promoción de precios es solo tiempo limitado: ¡ la instalación de que hemos estado hablando le va a costar la fabulosa suma de 505.000 dólares en lugar de 520.000! rápido, rápido, antes de que Microsoft se arrepienta…

Nota: el descuento no es válido para Windows, por supuesto… que se estaba creyendo, que Microsoft iba a matar la gallina de los huevos de oro?

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

A correr, a correr… SharePoint 14 está llegando…

Lo llamarán SharePoint 14, SharePoint 2010, ni idea como, pero está llegando a pasos agigantados. En cualquier caso este año tendremos por lo menos un beta; cuando? Tampoco ni idea, pero me atrevería a apostar que será hacia finales del año: septiembre? Muy probablemente antes del congreso de SharePoint de octubre.

Pero más importante de cuándo es que nos traerá la nueva versión. Es mucho lo que se ha especulado, y muy poco lo que se sabe con seguridad. Microsoft, como de costumbre en este tipo de cosas, se ha escondido detrás de barreras y mas barreras para impedir que los que algo saben puedan contar lo que saben. Pero eso no nos impide hablar a los que no sabemos, así que veamos (aunque sea parcialmente) que nos ofrecerá la nueva versión de nuestro servidor favorito.

– La información sobre el Service Pack 2 de WSS que está por salir nos da algunas pistas. Por ejemplo, los Tipos de Contenido de WSS próxima versión estarán basados en XSLT, no en CAML. La información la puede encontrar en el articulo «The customFieldType rule in Pre-Upgrade Checker… bla-bla-bla…» (http://support.microsoft.com/kb/956451/) . En realidad el articulo nos cuenta lo que NO será soportado en la próxima versión, pero la conclusión de que SI será soportado se puede extraer fácilmente

– Vistas de Listas serán creadas con XSLT en lugar de CAML. De nuevo la información se puede encontrar en el articulo «The CustomListView rule in Pre-Ugrade Checker… bla-bla-bla…» (http://support.microsoft.com/default.aspx?scid=kb;EN-US;956450)

– FAST integrado con el motor de búsqueda de SharePoint. Esto no es una sorpresa, y es conocido desde hace tiempo. Revise el blog de Microsoft Enterprise Search (http://blogs.msdn.com/enterprisesearch/ ) y lo verá por todos lados (http://blogs.msdn.com/sharepoint/archive/2009/02/10/microsoft-unveils-new-enterprise-search-road-map.aspx )

– Uso de autorización «Claim-Based». Modificaciones en la forma de autenticación podrán cambiar, por ejemplo, el uso de «Claim-Based» para mejorar la integración con AD y hacer el servicio de autenticación más flexible (http://www.networkworld.com/news/2007/101607-microsoft-switching-sharepoint.html)

– «Master Data Management» estará presente en SharePoint 14 (http://blogs.zdnet.com/microsoft/?p=728 ). Para más información sobre que es MDM, mire el articulo http://geeks.ms/blogs/gvelez/archive/2009/01/04/el-manejo-de-datos-maestros-master-data-management-y-sharepoint.aspx

– Posibilidades de hacer Listas Relacionales, o sea, crear relaciones entre listas, como se puede hacer con tablas de Bases de Datos. También mejoras en rendimiento para superar los problemas de renderización cuando hay más de 2.000 elementos en una lista: http://sharepointsolutions.blogspot.com/2008/03/sharepoint-and-office-14-looks-like-i.html

– SharePoint será de 64 bits únicamente. También conocido desde hace tiempo. Lo puede encontrar inclusive en el documento que describe el Service Pack 1 de SharePoint 2007 (http://go.microsoft.com/fwlink/?LinkId=105704&clcid=0x409)

– Inteligencia de Negocios (BI) para las masas… sea lo que sea lo que eso signifique (http://www.microsoft.com/presspass/features/2009/jan09/01-27KurtDelbeneQA.mspx )… probablemente tiene que ver con PerformancePoint

– Mejoras en la integración entre SharePoint y Groove (http://blogs.msdn.com/bowerm/archive/2008/04/22/the-future-of-groove-and-sharepoint.aspx )

– Visual Studio por fin va a darle un buen soporte a SharePoint (http://blogs.msdn.com/somasegar/archive/2009/01/10/office-client-developer-enhancements-with-vs-2010.aspx)

Bien, apenas se vaya conociendo más información, seguiremos hablando al respecto por estos lados… y por todos lados… Vamos a ver con que sorpresas viene la nueva versión…

Nota: toda la información discutida aquí es públicamente conocida desde hace bastante tiempo, y se puede encontrar regada por internet. Por si las moscas, no he contado nada que no sea del dominio público, y que no se pueda encontrar googleando por un par de minutos…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Para continuar riendo: SharePoint y NTML

Continuando con la serie para reír o llorar, esta semana nos hemos encontrado con un problema bastante divertido en el proyecto en el que estoy trabajando en el momento.

Como ya vamos entrando en la fase final del asunto, hemos comenzado a hacer pruebas de rendimiento, para poder determinar con más precisión en donde hemos metido las de andar. En una de las pruebas, en la que hemos introducido latencia («Latency», la demora que ocurre en la conexión entre un pedido del computador cliente y la respuesta del servidor) nos hemos encontrado con un problema interesante: sin latencia, es decir, teniendo el cliente y el servidor uno al lado del otro teníamos tiempos de respuesta no muy malos, pero cuando introducíamos latencia para simular tráfico entre Europa y Asia, por ejemplo, los tiempos de respuesta se nos crecían de forma muy poco decente.

Para tratar de ver porque era el problema, en las pruebas hemos introducido traceadores para ver qué ocurriría en la «conversación» entre el cliente y el servidor. Para nuestra sorpresa nos hemos encontrado con cantidades de errores 401, es decir acceso denegado; inclusive usando cuentas de administrador de la granja, con todos los permisos del mundo, los 401 seguían apareciendo.

Haga la prueba siguiente: un servidor recién instalado de MOSS, con un sitio de publicación completamente por defecto. Llame la pagina inicial por unas cuantas veces para establecer una conexión estable con el servidor. Limpie el cache del navegador y llame la pagina inicial de nuevo. Ahora revise los logs de IIS: no encontrara ningún error 401. Refresque la pagina inicial (con F5, por ejemplo). Revise los logs de nuevo: encontrara entre 16 y 20 errores 401. Explicación? Ninguna. Es reproducible? Completamente y tantas veces como desee.

Entre otras cosas, para hacer pruebas de este tipo puede utilizar herramientas como HttpWatch (no gratis) o Fiddler (gratis). Ah, y otra cosa, la autorización es NTML. Yendo más adentro en el análisis, si intercepta los paquetes de comunicación entre el cliente y el servidor, vera que el handshake entre los dos ocurre más o menos de la siguiente forma:

1 – Cliente envía al servidor: GET (y otras cosas)
2 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM
3 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 1)
4 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM (mensaje 2)
5 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 3)
6 – Servidor devuelve al cliente: 200 Ok
Mensaje 1 contiene el nombre del host y el nombre del dominio NT del cliente
Mensaje 2 contiene el «desafío» («Challenge») del servidor
Mensaje 3 contiene el nombre del usuario, del host, del dominio y dos «respuestas» al «desafío»

Y esto ocurre para cada elemento en la pagina que necesita autorización. O sea que se podrá imaginar, cada ida y venida, para cada elemento y todo multiplicado por 300 milisegundos de latencia, los tiempos de respuesta son de todo menos bonitos.

Es posible de evitar este fenómeno? Probablemente no, es algo que está enterrado profundamente en el protocolo del handshake. Lo único que se puede hacer es utilizar Kerberos. Para ver más información sobre Kerberos, revise el articulo en http://www.gavd.net/servers/sharepoint/sps_item.aspx?top=0&itm=292 y para ver como cambiar la autorización en SharePoint de NTML a Kerberos el articulo http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=4&itm=397. Es algo de lo que tiene que preocuparse? No, de ninguna manera si sus usuarios están al lado de los servidores de SharePoint en una intranet local; SI, con toda seguridad si los usuarios están repartidos por todo el mundo y los servidores están regados por tres continentes.

En cualquier caso, si lo que necesita es hacer que los tiempos de respuesta disminuyan rápidamente sin gran esfuerzo, cambie de NTML a Kerberos, y vera incrementos inmediatos (dependiendo, por supuesto de la latencia… y contra la latencia no podemos hacer nada, es simplemente un hecho físico: que tan rápido puede viajar una señal entre dos puntos). El problema de Kerberos es, por supuesto, que necesita tener un servidor para mantener las claves, pero eso se puede solucionar fácilmente.

Y sobre todo, continúe sonriendo… esta vez no de una de esas «características no documentadas» SharePoint, sino de algo muy particular de IIS…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…