martes, febrero 27, 2007

Verbo o Sustantivo

Continuando con el tema de Arquitectura Empresarial, en estos días he continuado con la aplicación de la metodología de arquitectura empresarial. Coincidencialmente Oracle me invitó, junto con otros compañeros, a un curso de metodología SOA. Oracle afirma, y con el apoyo de Accenture, que los servicios se deben definir alrededor de las entidades de negocio.

Al principio, esta idea me causó sorpresa y hasta pensé que estaban totalmente equivocados. La razón es que cuando se establece un negocio se piensa en los procesos que se ponen en marcha para ofrecer servicios y productos. Como colateral, se obtienen entidades de negocio, que en una empresa con poca automatización se convierten en los formularios, las carpetas y las hojitas de Excel. De esta línea de pensamiento se desprende que para analizar las funcionalidades de un negocio y llegar a los servicios SOA se debe partir de los procesos de negocio, que eventualmente afectarán a las entidades, no al revés.

Ahora, durante la aplicación de la metodología de arquitectura empresarial con una estrategia top-bottom que incluye varias líneas de negocio, se llega a un listado de funcionalidades por cada línea de negocio. La gran pregunta es ¿cómo homologar las funcionalidades de diferentes líneas de negocio?

La primera estrategia es ordenar las funcionalidades alfabéticamente y comparar coincidencias. Este esquema tiene la ventaja de la efectividad. Es muy rápido, pero en su misma simpleza reside su problema: hay funcionalidades que se pueden llamar igual y que hacen cosas diferentes y hay funcionalidades que se llaman diferente y hacen cosas similares. Conclusión: esta estrategia sirve como filtro inicial.

La segunda estrategia consiste en que cada líder de línea de negocio compare sus funcionalidades con sus pares. Este es un proceso sumamente tedioso que puede generar resultados incompletos aunque mucho más aproximados. Su desventaja es la cantidad de esfuerzo que requiere y su ventaja es que resulta bastante aproximada, es decir, esta estrategia es más efectiva y menos eficiente.

Como decía un filósofo, en el centro está la virtud. Reflexionando sobre cómo mejorar la metodología decidí explorar en centro, es decir, incluir en el enfoque top-bottom el análisis de entidades de negocio y así obtener una correlación mucho más fuerte entre funcionalidades dispares de las líneas de negocio.

La idea es recorrer todas las listas de funcionalidades y aislar los sustantivos. De ahí se obtienen las listas de entidades por unidad de negocio. Después de este proceso se homologan las entidades (que resultan menos numerosas que las funcionalidades) entre las diferentes líneas de negocio. Este ejercicio tiene el beneficio directo de obtener la lista de entidades generales y un beneficio indirecto de hacer que las diferentes líneas de negocio verifiquen si no les ha faltado alguna funcionalidad importante que cubra entidades generales.

Terminado el procedimiento anterior, se seleccionan las entidades más reutilizadas en las líneas de negocio, haciendo un top-n, de acuerdo con las condiciones del proyecto. Con este top-n de entidades empresariales cada línea de negocio las relaciona con sus funcionalidades. De aquí se obtienen las operaciones que deben implementar los servicios.

En mi concepto esta estrategia de centro es más efectiva y eficiente. Efectiva porque se obtienen los servicios y sus operaciones, así como una verificación cruzada de completitud. Eficiente porque requiere menos esfuerzo que el cruce de funcionalidades de negocio entre líneas. En este caso resulta tan importante el verbo (funcionalidad) como el sustantivo (entidad), el uno sin el otro no completa su sentido.

En días próximos terminará el proyecto y obtendremos el resultado final, que es un portafolio de proyectos para la implementación y ajuste de servicios empresariales.

lunes, febrero 26, 2007

El Ingeniero y la dificultad del Método del Caso

Durante la estancia en España trabajamos en las clases con el método del caso. Este método consiste en presentar una base teórica y a continuación presentar un caso en el que se describe una situación, involucrando diversos ángulos y con información relevante, irrelevante y, a veces, contradictoria. Tal y como ocurre en la realidad.

Un ingeniero está acostumbrado a calcular un resultado con un conjunto de variables conocidas, con un grado de incertidumbre muy bajo o nulo, y con la información depurada. Existen muchos ejemplos de este modo de actuar, el más cercano a mí es la construcción de software. ¿Qué queremos antes de empezar a construir un software? Obviamente, que esté bien especificado. De hecho, cuando encontramos requisitos ambiguos o incompletos ponemos el grito en el cielo y hacemos que el proceso vuelva a arrancar. De alguna manera no toleramos bien la dualidad. Al parecer, no tenemos desarrollada la capacidad de leer entre líneas y obtener la información que realmente es útil.

En la solución de casos sentía algo de frustración pues la información que me entregaban era sumamente incompleta, contradictorio, irrelevante. Otros compañeros parecían capaces de interpretar las pequeñas pistas que estaban regadas y armar el rompecabezas. Con la práctica, entendí el mecanismo y fue capaz de resolver los casos mas o menos, afortunadamente.
Durante una capacitación dictada por Oracle, a la que asistimos unos 12 ingenieros compañeros de trabajo, presentaron varios casos. Inicialmente me tomó por sorpresa pero luego de leer por segunda vez recordé el método y la forma de abordarlo. Simultáneamente, algunos de mis compañeros fallaban miserablemente y se quejaban de que la información (¡adivinen!) era incompleta, irrelevante o contradictoria. Vaya sorpresa, mis compañeros tuvieron la misma reacción que yo tuve. Esta experiencia sirvió para recordar que los ingenieros solemos ser muy buenos para resolver problemas bien especificados, pero fallamos miserablemente cuando las variables no están bien identificadas y cuando hay un gran nivel de incertidumbre.

martes, febrero 06, 2007

Arquitectura Empresarial en la Práctica

Hemos iniciado el proceso de arquitectura empresarial. Aunque en la teoría todo suena muy lógica, especialmente el cruce entre funcionalidades y procesos, en la práctica las cosas se hacen bastante borrosas y empezar a diferencia entre servicio, procesos, actividades, flujos de trabajo, procedimiento, en fin, entre los diferentes niveles de abstracción se hace realmente difícil.

Otro punto interesante consiste en la identificación de “servicios” comunes. En este sentido hay solo dos alternativas prácticas: (a) plantear un pool de servicios de acuerdo con el conocimiento de la empresa (b) tomar los servicios de un conjunto pequeño (4, a lo sumo 5) procesos de gran valor para la compañía e identificar los servicios compartidos. De ahí en adelante identificar los procesos de negocio y verificar si hay oportunidad de reutilización.

Según la teoría hay dos maneras de enfrentar el reto: bottom-up o top-down. La primera alternativa requiere conocer cada una de las aplicaciones en detalle y mapear las funcionalidades a procesos de negocio. La segunda sugiere identificar todos los procesos de negocio, identificar sus funcionalidades y finalmente cruzar procesos, funcionalidades y aplicaciones.

En mi opinión estas estrategias funcionan en papel, en la práctica hay que ser muy ágiles y nos se puede ser demasiado estricto. A continuación mis observaciones:

Sobre la alternativa top-down

Procesos Documentados. El primer requisito de la teoría es que los procesos de negocio estén debidamente documentados, de lo contrario pueden ocurrir dos cosas: los participantes de la iniciativa se inventan los procesos de acuerdo a su conocimiento o se utiliza muchísimo tiempo de los líderes de negocio para la especificación de los procesos. Ambas cosas tienen problemas puesto que generalmente el área de tecnología tendrá una visión muy limitada del proceso y el líder del proceso tiende a plantear un proceso idealizado o futuro, no el proceso actual de negocio justo como se lleva a cabo.

Nivel de Abstracción. La teoría habla sobre utilizar los procesos de negocio, pero en la práctica hay varios niveles de abstracción para los procesos de negocio: desde la cadena de valor hasta los procesos de nivel tres que llevan a cabo un reducido número de personas. Un ejemplo concreto es El Proceso de Venta de cualquier negocio. Este, sin duda, será un proceso de negocio, sin embargo, analizándolo en detalle, es un proceso transversal a los de más procesos. No es demasiado concreto, pues en una empresa multi-canal, multi-producto, para cada combinación canal-producto, la implementación del proceso de venta tendrá variaciones considerables y por lo tanto funcionalidades muy diferentes que, sin lugar a duda, la arquitectura empresarial deberá tener en cuenta.

Definición de procesos y de servicio. Diferenciar entre un servicio, un proceso y un servicio en el sentido SOA de la palabra a veces se convierte en una discusión bizantina. Por ejemplo, una persona puede argumentar que todo servicio será un proceso y por lo tanto el análisis de deberá llevar a cabo, no tiendo en cuenta los procesos de negocio, sino teniendo en cuenta los servicios. Bueno, aceptado, pero cual es el foco para acotar los servicio. Mi respuesta es que los servicios deberán ser aquellos que aporten valor al cliente, es decir, los servicios de cara al cliente. En este sentido, el servicio como tal se convierte en un proceso de negocio y la distinción entre servicio y proceso se torna irrelevante. Otra confusión a la hora de identificar servicios es que hay personas en tecnología que inmediatamente inicia el análisis se meten en la idea de un servicio como lo define SOA. Este puede ser un error, puesto que esa visión tiende a identificar solo servicios de lógica no funcional, por ejemplo el envío de mail, los sistemas de autenticación y autorización, la transferencia de archivos, etc. Si esto ocurre se habrá perdido la oportunidad de agregar valor al negocio y se seguirá con la visión táctica de TI.

Sobre la alternativa bottom-up

Visión limitada. Puesto que se parte de las aplicaciones existentes, es difícil considerar funcionalidad de negocio que no está automatizada. Es como construir un rompecabezas con piezas faltantes. A la larga la figura final tendrá muchos vacíos que a nuestros ojos no serán aparentes pero a los ojos de negocio serán muy evidentes. En este caso no podremos aportar nada o muy poco.

Dificultad en la ejecución. Pregúntese, cómo identificar las funcionalidades de 150 aplicaciones que su departamento de informática soporta. Lo primero que se les ocurre a muchas personas es identificarlas a través de sus especificaciones. Bueno, si tiene las especificaciones para las 150 aplicaciones realmente se merece un premio, y aun más, si mantiene las 150 especificaciones actualizadas se merece una certificación CMMI nivel 5!!!. Existen varias alternativas prácticas. La primera es que a través del conocimiento de un grupo de personas, se elabore una lista de las funcionalidades de más alto nivel de negocio y que cada analista dueño de aplicaciones indique si su sistema implementa dicha funcionalidad. La segunda alternativa es utilizar las opciones de los menús de las aplicaciones para identificar las funcionalidades. Esta última opción es muy poco productiva y puede conducir a errores.

Espero haber transmitido un poco de la realidad en la aplicación de la metodología de arquitectura empresarial. Como dije inicialmente, una cosa es la teoría y otra muy diferente son las lecciones que deja la práctica.

lunes, febrero 05, 2007

Gobierno en Línea

Hasta ahora he sido muy crítico de la ejecución de los programas relacionados con la exposición de información y de servicios estatales a través de Internet. Creo, firmemente que este es un canal de relación sumamente valioso y productivo para todos los ciudadanos, especialmente, para aquellos que no tiene un acceso “físico” a las entidades gubernamentales y que se encuentran, por ejemplo, más alejados de los centros de poder.

Realizando una investigación sobre la normatividad relacionada con la Telemedicina me llevé la grata sorpresa de encontrar sistemas de consulta como los del Archivo Nacional, el Ministerio de la Protección Social, el Sistema de Información Legislativa de Bogotá y el Departamento Nacional de Planeación (que incluso ofrece un sistema en FoxPro gratuito para la consulta de los indicadores de Colombia). No solo pude encontrar la información que estaba buscando sino que existían referencias a documentación relaciona, a sitios complementarios, a bibliotecas virtuales, a resoluciones, decretos y leyes.

Siento que en este aspecto, como en algunos otros, el programa Gobierno en Línea va por buen camino y ha acertado. Espero que se continúe profundizando aun más en este esfuerzo y que no solo el gobierno central ejecute el programa sino que los gobiernos departamentales y municipales participen activamente.

Entre otros muchos sitios interesantes.