Una rosa con otro nombre puede terminar como un repollo

Tiempo atrás escuche algunas personas decidir que necesitan más capas en su arquitectura. Estaban en lo correcto, como es el caso; pero mirando un poco más atrás. Ellos intentaban crear un framework que contenía lógica de negocio. Pero en lugar de centrarse en resolver los problemas concretos empezaron con la idea de que querían un framework que envolviera la DB y produjera objetos. Y que se debe usar un ORM, y mensajes, y webservices y todo tipo de cosas interesantes.

Desafortunadamente, el no tener claro exactamente qué tipo de cosas interesantes podría hacer, llevo hacia una pequeña competición para sugerir un nombre. Y este es el punto, en el cual puede empezar a reconocer que usted tiene un problema: Si no sabe qué nombre poner, usted no sabe lo que es, si usted no sabe lo que es, no debería empezar a escribir código.

En este caso en particular, un vistazo rápido por el historial del control de versiones del código, puso en manifiesto la gravedad del problema. Por su puesto, había muchas implementaciones vacías de interfaces! Y lo realmente divertido es que habían cambiado de nombre tres veces sin haber escrito código real. Cuando empezaron le llamaron ClientAPI – el “client” se refiere a los clientes de la empresa, no cliente como en “client-server” – la versión final fue llamada ClientBusinessObjects. Un gran nombre: Vago, amplio y engañoso.

Está claro, un nombre es solo un puntero. Una vez que todos los involucrados saben que el nombre es solo un nombre y no una metáfora de diseño, entonces todo puede pasar. Sin embargo, si no hay acuerdo en un nombre lo suficientemente específico para saber cuando está mal, entonces podrá tener alguna dificultad, incluso para empezar. El diseño de un producto tiene que intentar cumplir con las intenciones – Ej.: Rápido, barato, flexible – y los nombres deben transmitir o reflejar las intenciones.

Si no se puede poner un nombre, no se puede escribir. Si se cambia de nombre tres veces, entonces se debe parar hasta que tenga claro que es lo que va a construir.

Autor Sam Gardiner

Versión original : A rose by any other name will end up as a cabbage

---

Algunas veces, en alguna que otra organización, grupo de personas o comunidad, se suelen identificar a la misma cosa (idea, concepto, aplicación, programa...) con distintos nombres, que, dependiendo de su audiencia se le puede identificar con un significado o proposito distinto, y en ese punto es donde pueden empezar muchos problemas.

Lo ideal en estos casos es identificar a todas las personas relacionadas, juntarlas y alinearlas (esclarecer los objetivos de la aplicación, sus usos, normalizar los términos a utilizar...) para que, entre otras cosas, todos hablen el mismo idioma, ese, es un buen punto de inicio para el éxito de cada aplicación.

Emmerson

---

-FIN -

Que es Business Driver ?

He aqui otra de las frases que traducidas literalmente provoca dolores de cabeza al intentar comprender un texto escrito en Inglés, en este caso "Business driver".

Buscando por internet he encontrado las siguientes aproximaciones de su significado:

Son las personas, la información, las condiciones, las tareas y actividades que apoyan o impulsan el cumplimiento de un(os) objetivo(s) de negocio.

En el caso de las personas asesoran a la empresa tratando de evitar las trampas y convertir los errores imprevistos en buenas lecciones para el futuro éxito y la sostenibilidad.

También se puede decir que es cualquier factor que impulsa y aumenta las ventas de la empresa, su participación en el mercado, etc.

Toda solución que construimos se basa en un modelo de negocio, y también solemos decir que una aplicación nunca se termina, pues esta en constante cambio debido a que el negocio cambia.

Un negocio tiene que ser constantemente actualizado y conducido a estar a la par con sus competidores y estar en sintonía con las últimas tendencias en tecnología del negocio y del mercado que cambian a veces inesperadamente.

No esta demás recalcar que los "Business drivers" son parte de los elementos que tenemos que tener en cuenta, algunos como atributos de calidad, otros como factores de riesgo ... etc; al momento de elegir la tecnología con la cual se implementaran las soluciones de nuestros clientes, así como también para el diseño de las aplicaciones/soluciones a construir y su ecosistema.

- FIN -

Como se puede usar CMMI-DEV con otros frameworks como TOGAF ?

En InfoQ se acaba de publicar una interesante entrevista a Mike Konrad, miembro de SEI; de la cual me ha llamado la atención la pregunta de la cual he puesto como título en este post, ya que llevo una temporada relacionado con CMMI y TOGAF; así que a quien no le interese la mejora de los procesos en la construcción de software y el alineamento entre los recursos IT con la visión de negocio de una empresa ya puede dejar de lado este post ;-)

Frameworks como TOGAF son usados para definir una arquitectura que alinie los activos/recursos de una TI para dar soporte a las necesidades y procesos clave del negocio a todos los implicados, pero las aplicaciones individuales, las capacidades/habilidades/facultades, servicios, redes y otros activos TI, asi como su infraestructura aún tienen que ser adquiridos, desarrollados o sostenidos. Los tres modelos de CMMI como son CMMI-ACQ, CMMIDEV y CMMI-SVC dan covertura respectivamente a la adquisición, el desarrollo y los servicios; proporcionando un gran abanico de prácticas que pueden ayudar a abordar estas necesidades.

Por supuesto los modelos CMMI tienen un rol adicional: ayudar a madurar los procesos y capacidades/habilidades/facultades que una organización usa para desarrollar productos y servicios que satisfagan a sus clientes externos. Estos procesos y habilidades pueden, a su vez, ser algunos de los procesos claves de negocio, a los que la arquitectura empresarial, intenta dar soporte. En estas organizaciones, tanto CMMI, como TOGAF pueden tener una función dual y de gran apoyo.

Y existe una tercera vía, en la cual TOGAF y CMMI estan relacionadas: la versión 1.3 de CMMI-DEV contiene material de ingeniería y otras áreas de proceso (por ejemplo, Desarrollo de requisitos y Soluciones técnicas) que se ocupan de las arquitecturas modernas y la práctica de lineas de producto. Algunos de los métodos mencionados en el ejemplo como el ATAM (Architecture Tradeoff Analysis Method) pueden llegar a ser de valor en la arquitectura empresarial.

Enlaces relacionados:
Interview and Book Excerpt: CMMI for Development

- FIN -

Que es Governance ?

Recientemente leyendo las especificaciones de TOGAF me he encontrado con un término que está siendo usado desde hace ya algún tiempo en el sector, supongo que a todos les suenan las expresiones “SOA Governance”, “Data Governance”, “Architecture Governance” o “IT Governance”, pero ...

¿ Que es Governance ? o ¿De que trata?

Su traducción directa es “gobernabilidad” y en términos primarios se trata de dirigir y controlar los elementos del contexto en el que se aplica (SOA, IT …) con el fin de lograr buenos resultados, mediante la descripción de procesos que se deben aplicar para la coordinación de acciones individuales.

Governance describe la transformación sistemática de un sistema, utilizando un conjunto de reglas para ir en la dirección adecuada, juntando personas, procesos y tecnología para cambiar la forma en la que la información:

• se recoge,
• se gestiona,
• se mantiene,
• se convierte en información empresarial,
• se comparte en el contexto de la organización como conocimiento común.

Su intensión es:

• Centrarse en la conexión entre el negocio y la gestión IT.
• Mitigar el riesgo que la tecnología informática podría generarle al negocio.
• Asegurar que una organización produce un patrón/procedimiento para asegurar la obtención de buenos resultados y evitar situaciones de malas prácticas.
• Generar información que pueda ser explotada por la empresa para mejorar su rentabilidad.

En governance convergen conceptos como calidad, gestión de procesos de negocio y de riesgos.


- FIN -

La toma de decisiones (reflexiones en voz alta)

Normalmente tomamos decisiones a diario sobre cosas tan comunes como levantarse de la cama o no, desayunar o no, en fin ... son decisiones que se toman en un ambiente de certeza, ya que se conoce el problema y las posibles soluciones; pero también las hay en entornos de incertidumbre.

En un entorno de incertidumbre, no se posee información suficiente para tomar la decisión, ya que no se tiene control o información sobre una situación o contexto, pese a que se puede sugerir diferentes tipos de soluciones, estas raramente pueden ser medidas (de allí que se le llama "incertidumbre, sin probabilidad"); en otras palabras, lo que viene a ser el desarrollo software.

Pero para tomar una decisión se vuelve básico el poder conocer la naturaleza de un problema, comprenderlo, analizarlo y finalmente, elegir un camino de entre los posibles, en contextos tan variados como el familiar, sentimental, laboral... en este caso durante el diseño de una aplicación o la dirección de un equipo de trabajo.

Los pasos, a grandes rasgos, para la toma de decisiones son:

1. Identificar y analizar el problema
2. Identificar las alternativas y ponderarlas
3. Definir la prioridad para atender el problema
4. Generar alternativas de solución
5. Evaluar las alternativas
6. Elección de la mejor alternativa "bajo el contexto final deseado"
7. Aplicación de la decisión
8. Evaluación de los resultados

Metodologías como TOGAF utilizan análisis GAP para saber el punto actual (contexto del problema) y saber hacia donde se quiere ir (solución deseada). De esta manera, al saber lo que tenemos, y lo queremos, podemos iniciar un plan de acción para implementar la solución.

Para la implementación (entiéndase forma de trabajo y sus resultados) existen otras metodologías complementarias como SCRUM o TDD/BDD que ayudan a detectar fallos de implementación desde los inicios para poder reaccionar a tiempo en caso de problemas técnicos y de recursos.

Lo que mayormente marca la diferencia y la similaridad, es la forma como afrontamos y asumimos los resultados de las decisiones, los cuales cuando son correctos nos provocan satisfacción, pero cuando son fallidos, solo nos queda reconocerlos y aprender de ello.

- FIN -

Preparación SCEA - Gestión de riesgos

Uno de los puntos a tener en cuenta durante la fase 3 del proceso de certificación como arquitecto Java, es la gestión de riesgos, pero dado que las especificaciones de la asignación son vagas, un buen punto de referencia de como hacer las cosas puede ser la gestión de riesgos que se especifica en TOGAF 9; en mi caso aplique una elaboración más sencilla.

Enlaces relacionados:

Risk Management (TOGAF 9)


- FIN -