Búsqueda


6 de marzo de 2007

El Catálogo de Servicios y la Orientación a Objetos

Esta mañana, mientras me duchaba y estaba en esa zona de penumbra que separa el sueño de la vigilia, le daba vueltas a la cabeza a cómo le podría explicar los conceptos de ITSM a un grupo de programadores.

A esas horas de la mañana se me suele ir mucho la olla y mi cerebro genera un montón de ideas poco recomendables, pero de vez en cuando sale algo interesante, y así ha sido esta mañana, aunque en realidad lo plasmo aquí para que vaya madurando y quizás (con un poco de suerte) le pique el interés a alguno de los lectores y quiera añadir comentarios que mejoren la idea.

Si pensamos en el conjunto de actividades que se realizan en una organización como en un gigantesco programa desarrollado en un lenguaje de esos orientados a objetos (la verdad es que hace al menos 13 años que no programo, así que no se muy bien cómo han evolucionado estas cosas. Pero la base es la base), podemos entender que algunos de los objetos utilizados para el desarrollo son proporcionados por IT. Incluso , algunas de las áreas de la organización cogen objetos de los proporcionados por IT y los amplían y mejoran usando esas fantásticas técnicas de herencia múltiple.

En OOP cada clase se puede instanciar en varios objetos que mantienen propiedades similares, pero son instancias diferentes. En el mundo de los servicios TIC podemos tener exactamente lo mismo, servicios instanciados (por ejemplo) para diferentes clientes, o bien una única instancia del servicio para toda la organización.

Una clase queda definida por los atributos del objeto y por los métodos que se le pueden aplicar (perdónenme los exquisitos de la OOP por no utilizar el vocabulario 100% correcto!) y en un servicio tendremos los atributos que lo definen (descripcion, horario de soporte, etc) y las peticiones que los usuarios pueden realizar sobre este servicio.

Así mismo, hay algunos métodos que no son exportados (osea, que son internos del objeto y no se ven desde el exterior), que pueden ser relacionados directamente con las peticiones internas que cada una de las áreas de IT puede realizar sobre los servicios.

Por otra parte, a veces ocurre que quien ha desarrollado la librería de objetos que vamos a emplear la ha instrumentado, es decir, que disponemos de operaciones específicas para saber datos de rendimiento, volumetría de uso, profiling u otras propiedades al respecto del uso que se está dando de los objetos en nuestra aplicación... ¿Qué tal si eso lo relacionamos a nivel de explicación con el catálogo de métricas o conjunto de métricas disponibles para cada uno de los servcios?

Por último, en el ciclo de vida de nuestro paquete de clases definidas veremos que se van añadiendo nuevas funcionalidades (métodos), nuevos atributos, mejoras en el profiling y esto se corresponde directamente con los ciclos de maduración de nuestros servicios y de nuestro catálogo de servicios, que irá incluyendo cada vez nuevos atributos, ampliando las métricas por las que medimos y evaluamos los servicios y ampliando el abanico de peticiones que los usuarios pueden realizar sobre ellos.

A medida que avanzo en el post más me da la sensación de que una persona que ya sepa de qué va un catálogo de servicios puede considerar esta analogía como una "ida de perola", pero no olvidemos que el objetivo inicial era tratar de explicar estos conceptos a un grupo de programadores, acercándonos a su terreno. Con esta aproximación, casi que podríamos usar un buen JavaDoc para documentar y publicar nuestro catálogo de servicios, no?

¿Algún programador en la sala? :-)

13 comentarios:

Conejín dijo...

la verdad que me pase un año de mi vida con un programador recien licenciado de matematicas, explicandole lo que queria para mi empresa y el chaval me lo hizo muy bien. ahora esta en la empresa.
uyyyyyyy, pero esto no es lo qe yo hablo cada dia, contigo. Al final me vas a culturizar Antoni (jajajajaja). Esto es debido por entrar en estos blogs tan supertecnicos jejejeje
Besos de Petit Lapin

Fermín dijo...

Hola,
Le envíe tu post a un colega porque me parecía interesante y además coincidía con un comentarío que hicimos hablando de servicios. Su respuesta me sorprendió un poco pero me parece interesante. Te la envío por si quieres "comentarla".

Bueno, bueno…

Algunas dudas, seguramente, más filosóficas que de contenido.

¿Por qué tenemos que explicar a programadores, exactamente en su nomenclatura, en qué consiste la orientación a servicios?

¿Tan tontos los consideramos para que no puedan entender nada que no sea código, orientación a objetos, bucles…?

Es un tema que veo de forma recurrente en nuestro sector. Se trata a los programadores (informáticos técnicos en general) como si fueran gente rara que no puede entender nada que no sea lo que trabajan habitualmente. Este trato, sobreprotección en algunos casos, infravaloración en otros, dificultará su progresión hacia nuevas áreas de conocimiento.

Estos profesionales deben ser capaces de adaptarse a la nueva gestión de las tecnologías de la información, y el hecho de darles tan masticado cualquier cambio, no les ayudará en absoluto a esta adaptación.

Puedo estar de acuerdo que hay gente que “vive en la cueva técnica” y que es difícil sacarlos. Seguramente éstos son cada vez menos, y no serán, para nada, los destinatarios de estos temas. Si son técnicos de cueva, son eso. Y si hay alguno de éstos que intenta sacar la cabeza de la cueva, él será nuestro objetivo para explicarle estos temas. Pero siempre, con la nomenclatura correcta, sin metáforas ni circunloquios.

En fin, de todas formas la comparación está bien.


Ya te digo que no es un comentario mio, aunque suene a aquello de "tengo un amigo que tiene un problema...". De manera que si hay "polémica", que no estaría mal, intentaré que sea él el que responda.

Saludos y gracias por este blog.

Moises dijo...

Buenos días, Antonio:
Sigo muy de cerca tu blog que me parece fantástico y aprendo muchas cosas...pero en esta ultima entrada coincido con el colega 'cursivo'
Hay que convencer a los tecnólogos desaforados que la gestión es un concepto imprescindible y no de 'burócratas'...
No obstante, cualquier ejercicio de aplicación de modelos procedentes de disciplinas distintas puede dar resultados interesantes.
Un saludo y muchas gracias por compartir tus conocimientos.

Antonio Valle dijo...

Apreciado "colega anonimo de Fermin": estoy contigo en que una persona, por el hecho de ser programador, no es tonto. Es más, sólo el hecho de ser programador ya revela que no lo es.

Esto que ves en mi post no es sobreproteccion "al colectivo de los programadores", sino que simplemente es un truco didáctico: ¿cómo consigo que un grupo de personas entienda un concepto que les quiero explicar? Usando metáforas, parábolas o analogías en un idioma próximo al suyo para que les sea fácil pillar el concepto.

No es que no lo puedan entender si no es en un idioma como el suyo, simplemente es que lo mapearán más rápido, me entenderán el concepto y yo podré explicarles más cosas aún.

No se, es una técnica que he utilizado siempre para explicarme, tanto como pintar dibujos en un papel, pizarra o similar... sin pintar no se explicar.

Para Moisés, solo decir que precisamente porque hay que convencerlos de estas otras "doctrinas" es que hay que explicarlo... :-)

gracias a todos por los comentarios y que siga la fiesta!!

Conejín dijo...

No todas las metaforas, sirven para explicar algo que nos interesa comunicar. Lo mejor, al pan pan y al vino vino, con alguna metafora por el medio. jejejeje
Petons Petit Lapin

An dijo...

:) me hierbe el cerebelo :P Saludos

Leicca dijo...

Es un secreto en la blogosfera, pero soy del sector técnico de toda la vida y conozco bien la cueva de la técnica... A los programadores hay que explicarles con mucha frecuencia muchas cosas en su propia lengua. COMO A TODO EL MUNDO. Nuevos conceptos, criterios y organizaciones mentales no tienen que ver con lo que se utiliza sino con algo fueray en la base. Hay algo que se llama reflexión que allí donde no se de ha de introducirse desde fuera.
No es un tema de técnicos exclusivamente, pero los informáticos no están salvados, ni mucho menos.

Discrepo con el cursivo, con conocimiento de causa.

:-D

Pero prefiero hablar de fotos y contrastes. O de filosofía. La programación orientada a objetos la inventó Platón, hace ya mucho tiempo. Un beso y tu click.

Conejin dijo...

este clinc esta programado. para el dia 8 de marzo de 2007. y sera efectivo a las 00,00 del dia 9 de marzo de 2007.
Petons colega

Leicca dijo...

todavía estoy contestnado comentarios por mi blog. darte las gracias por el apoyo que viste que faltaba. :-D
no sé dónde lo dirían.

un beso.

An dijo...

:D

Conejín dijo...

Hoy solo te puedo desear que pases un feliz fin de semana con tu familia.
Un saludo y un click.

Conejin dijo...

clinc, clonc, el de hoy era muy gordo. petons

chin dijo...

Hola

He llegado desde el blog de "An", "Paxaradas" y he dejado mi saludo.