El Software Factory y la Investigacion

Muchas empresas hoy en día, quieren construir un software factory (fabrica de software) que les permita ser más competitivos y eficientes en la construcción de artefactos de software y cumplir con las tres variables: tiempo, costos y esfuerzo de forma óptima, y todo esto sin encarecer la calidad de sus productos.

Una vía para lograr estos objetivos gerenciales es contar con estándares, modelos de implementación, y productos generados a través de una profunda y constante línea de investigación. La investigación es muy necesaria, debido al dinamismo y el desarrollo constante de la ingeniería de software. Cada día surgen tecnologías, arquitecturas, estándares, especificaciones, componentes que mejoran y disminuyen en conjunto el número de líneas de código y el esfuerzo.

Las organizaciones deben adaptarse, y los arquitectos deben asumir su rol: mantenerse en constante vigilia tecnológica y permear esos conocimientos a todos los estratos tecnológicos.

La realidad, es que no todos los clientes están dispuestos a pagar la investigación. Ese es el gran problema, la mayoría de las empresas por lo general tienen métodos de desarrollo de software de muy bajo nivel comparado con las empresas que ven en la investigación un mecanismo para decrementar sus costos y proteger su inversion.

Hace poco, nuestro grupo desarrollo, creo un framework llamado Jerano, cuyo objetivo era implementar nuestro primer software factory. Hoy quiero hablar sobre nuestra experiencia en su realización y todos los inconvenientes que tuvimos que enfrentar.

En primer lugar tuvimos que seleccionar cuales eran las tecnologías Open Source que deberían ser parte de nuestro framework, quisimos seleccionar las tecnologías con mayor presencia en el area y una madurez comprobada.

Para armar un software factory, es importante en primer lugar establecer lineamientos de arquitectura de software, por ejemplo cuales son las capas que serán utilizadas y que tecnología debe implementar un servicio especifico. Decidimos utilizar spring como framework para la inyección de dependencias, el madurísimo Struts para el control de las capas de presentación, negocio y modelo (MVC). Unos de los problemas a los cuales nos enfrentamos en sobre el tema de seguridad. Acegi fue definitivamente el framework con mayores características y funcionalidades, además ya viene integrado con spring.

En la capa de presentación, utilizamos tecnologías Web 2.0 ajax, a traves de un framework llamado prototype.

Próximamente incluiré un marco de arquitectura mas detallado para contribuir con la comunidad.

Saludos Mijanautas!!!!.

Arquitectura, Mapa y un Blueprint

Uno de los problemas más comunes en la ejecución de proyectos de software, es la ausencia de arquitectos y documentos de diseño, que establezcan las políticas y lineamientos que deben ser adoptados durante todo el proceso.

El establecimiento de estas políticas, contribuye con la disminución de riesgos, y el control de brechas funcionales y no funcionales, que podrían impactar el proyecto en variables como el costo, el tiempo de despliegue y la productividad.

Dentro de este contexto, es vital, establecer un marco de arquitectura que permitirá gobernar el proyecto de forma eficiente, proporcionando las bases para el desarrollo de una arquitectura desacoplada, ágil, adaptable, y de tecnología neutral, la cual; no se vea afectada ante cambios de tecnologías.

Pero que significa gobernar?, gobernar significa establecer políticas claras para el inicio del proyecto, la comunicación, la gestión del proyecto, control, mantenimiento, adaptación, etc. del ciclo de vida del proyecto, en tiempo de diseño, ejecución y cambios.

Dentro de este contexto, el primer paso para iniciar un proyecto, es la creación de un documento de diseño, también denominado Blueprint. Un blueprint es un documento que establece los lineamientos, políticas, y estándares que deberían ser adoptados para asegurar una correcta implementación y disminuir los riesgos de su ejecución.

Para armar el blueprint es recomendable crear un árbol de ideas base que contengan todos los elementos o nodos que deben ser gobernados. Aquí les anexo un documento que contiene un árbol de ideas, con el cual podemos comenzar para armar el bluerpint.

Vamos ahora a describir algunos de sus nodos:

1. Ambiente: Se establecen los artefactos de software que seran necesarios, variables de ambiente, estructura de directorios y posibles dependencias.
2. Lineamientos: Los lineamientos pueden estar orientados en tres áreas: Control de Proyecto, diseño de la solución y las tecnologías.
3. Agilidad: La agilidad significa como el proceso de construcción de software debe ser ejecutado para proporcionar agilidad y buenas prácticas con el objetivo fundamental de mejorar la productividad, un ejemplo de ello es XP y TDD.
4. Modelo de Implementación: En este punto, se establecen un modelo de implementación que deberá incluir por ejemplo (modelo de dominio, capas, modelo de persistencia, modelo de pruebas, modelo de servicios, Reglas de negocio, patrones de diseño , etc. ).
5. Pruebas: En este nodo, se establecen los distintos tipos de prueba que deben ser considerados durante las fases de construcción y cambios.
6. Otros: Glosario y términos de negocio.

Espero haber contribuido con este modelo de referencia para la construccion de documentos de diseño. Cualquier comentario es bienvenidos.

Adelante Web 2.0 en la Empresa

Web 2.0 se ha convertido en la palabra de moda, en estos dias, pero que es Web 2.0?

Web 2.0 es una plataforma que aprovecha la inteligencia colectiva y el concepto de software como servicio. Este sistema esta basado en actividades colectivas que incentivan la creación de plataformas para la cooperación transparente. Este concepto es propicio para un modelo organizacional, donde puede distribuirse el conocimiento en tres areas fundamentales: Las Personas, los Procesos y Productos.

Esta definición de Web 2.0 que he orientado hacia la organización es muy atractiva, Web 2.0 puede fortalecer en primer lugar, los nexos existentes entre los empleados y la empresa, y proporcionar un mayor nivel de participación colectiva, en áreas estratégicas para la organización como por ejemplo la calidad, su identificación con la empresa, sus objetivos y metas.

Ahora, debemos conocer algunos principios de Web 2.0:

1. El Software no necesita ser distribuido sino ejecutado.
2. El Software debe tener la capacidad de recoger y de gestionar los datos de forma dinámica y especializada.
3. El sistema es: "poder e inteligencia Colectiva".
4. El Autoservicio del empleado es la base que sustenta la comunidad.
5. El servicio mejora mas, cuanto más se usa.

Para finalizar, de que manera las empresas, pueden comenzar a utilizar Web 2.0?

1. Los actores de una empresa pueden constituir conocimiento (Actividad Colectiva), como por ejemplo la Calidad. Se puede crear una red de hipervínculos, contenidos y sitios Web internos (intranet) entrelazados. De esta forma se disemina el concepto de calidad en la organización.
2. Realización de búsquedas, basado en una estructura de enlaces diseminados en diversos sites internos (intranet), proporcionan un valor incalculable de información y diseminación del conocimiento.
3. El desarrollo de un Wikipedia, con todos los conceptos del negocio de la organización, en la cual los empleados puedan contribuir con entradas (Confianza Radical) que pueden ser agregadas, desde diversos roles y responsabilidades (dominios).
4. Promoción de la inteligencia colectiva, para la generación de innovadoras propuestas de negocio como iniciativas de los empleados en la organización.
5. Ejecución de proyectos, basado en un proceso orgánico de adopción del software.
6. El desarrollo de portales como por ejemplo Drupal, darían poder de decisión al empleado, promoviendo un sistema de control y gestión de las personas, de los productos y de los procesos (Foros, Blogs, Wiki, etc.).

Para mas información:

• http://www.web2con.com/
• http://es.wikipedia.org/wiki/Web_2.0

Acción y Reacción: Bienvenido EJB 3.0!!!

En este momentos, según mi apreciación, esta comenzando la era de la simplificación en el desarrollo de soluciones empresariales. Cada vez más, las arquitecturas que soportan soluciones se simplifican, ahora los arquitectos deben seleccionar que tecnología es la más apropiada para un contexto de negocio determinado, basado en criterios como: la estandarización, la especificación, etc. La tecnología cada vez más esta distanciada del negocio.

Actualmente dos de las principales tecnologías para el desarrollo de soluciones empresariales son el framework Spring y EJB 3.0.

Que tecnología debemos seleccionar? Que criterios de comparación usar? . Los arquitectos y desarrolladores, saben que spring surge como reacción a un modelo EJB bastante distanciado de la simplificación, pero ahora, se ha lanzado la nueva especificación EJB 3.0, que contiene características muy similares a Spring. Ahora la especificación EJB 3.0 surge como reacción a Spring y a su éxito.

Estamos en un escenario donde las reacciones ante el éxito de tecnologías, son el motor de cambios importantes y cruciales para la simplificación.

Pero fuera del análisis de las reacciones, es interesante conocer las nuevas características técnicas de EJB, por ejemplo las anotaciones, el manejo opcional de descriptores de componentes, la simplificación del modelo de construcción de artefactos, la nueva especificación Java Persistence API (JPA), etc.

Para finalizar, los invito a conocer esta nueva especificación y a evaluar su uso dentro de un modelo de negocio.

En hora buena. Bienvenido EJB 3.0!!!

Bienvenidos!

Bienvenidos al Blog Mijao!

En Mijao nos dedicamos a innovar en el area de las tecnologias de informacion y comunicaciones. Nuestra meta es proporcionar a la comunidad hispanoparlante conocimiento para incentivar la innovacion en diversas areas de la ciencia moderna.

Escribiremos sobre nuestra experiencia en el area TIC, temas de actualidad, arquitecturas emergentes, y puntos de vista. En general aqui estan algunos temas que pensamos incluir en el blog: Arquitecturas Emergentes (SOA, Web 2.0, SAAS, ESB), MDA, NGOSS y las especificaciones para la industria de las Telecomunicaciones, Plataforma Java - J2EE - Java EE 5, Software Open Source, Software Libre, Robotica y Nanotecnologia, Energias Alternativas, Electronica, y otros temas de la ciencia moderna.

Esperamos que disfruten nuestro blog.

Como Instanciar SOA (Arquitectura Orientada en Servicios) en una organización

SOA, ha surgido como una arquitectura emergente, un paradigma enfocado en el negocio y no en la tecnología. Sus beneficios, están orientados en necesidades de negocio como: protección de la inversión, disminución de costos en proyectos de integración, adaptabilidad ante un mercado TIC tan cambiante, etc. Esta visión la hace muy atractiva para los CIO (Gerentes) de las organizaciones.

Estas promesas de negocio, están sustentadas en la utilización del reuso como pieza clave, mientras mas reuso, menos recursos se dispondrán para el desarrollo de nuevas aplicaciones y funcionalidades en la organización, por ende; se disminuyen los costos, y hay un mayor nivel de proteccion en inversiones y recursos.

Por ejemplo, la organización A tendría un directorio de aplicaciones y funciones ya existentes, que están en cierto grado desacopladas de las aplicaciones que las alimentan. Este desacoplamiento es lo que permite que la compañía A pueda realizar un cambio en la aplicación proveedora sin que sus servicios expuestos sean afectados. Todos los servicios son reusables.

Cuando se pretende iniciar un proyecto SOA, es verdaderamente difícil buscar un equilibrio entre un modelo anterior de desarrollo de proyectos de integración y un modelo que ciertamente no representa una visión pragmática, pero a la larga son innumerable los beneficios que este tipo de arquitecturas proporciona.

Actualmente, en el mercado existen muchas empresas que están desarrollando proyectos bajo este nuevo modelo de arquitectura; la dificultad mas importante para su implantación, es la gran cantidad de especificaciones alrededor y las pocas empresas que las han adoptado dentro de sus soluciones de integración. Otro problema importante es la madurez de las especificaciones y sus implementaciones.

En conclusion, un modelo de agilidad operacional y totalmente desacoplado de las tecnologías, es un norte posible, pero se necesitan un conjunto de estrategias para asegurar el éxito. Basado en mi experiencia en proyectos de integración bajo SOA, les presento algunas recomendaciones para disminuir los riesgos y asegurar una implementación exitosa en su organización:

Recomendaciones:

1. Internalizar y comprender los conceptos detrás de SOA y transmitirlo a todos los niveles de la organización.
2. Crear un documento de diseño de alto nivel (Blueprint), antes de emprender un proyecto piloto, donde se incluya por ejemplo: modelo vertical, capas, formato de mensajes, protocolo de transporte, formas de interaccion (sincronía / asíncrona), reglas y políticas, atomimicidad transaccional, etc.
3. Alinear los servicios con los procesos de negocio, no hay que olvidar que la meta no es tecnología.
4. No es suficientes adoptar las tecnologías SOA, es importante conocer las mejores practicas para asegurar, la viabilidad, la visibilidad de las operaciones, y un mínimo esfuerzo ante los cambios.
5. Definir un lenguaje común para la organización, es decir un modelo de objetos que representen todos o un conjunto de los conceptos de la organización basado en un modelo canónico, por ejemplo “cuenta, debito, ajuste, etc.”.
6. Establecer conversiones de nombrado para la empresa: por ejemplo, como nombrar los servicios, interfaces, endpoint de sistemas legados, o cualquier otro componente que ayuden a los arquitectos, administradores, y desarrolladores en proporcionar servicios consistentes.
7. Definir las interfaces de servicios, las implementaciones después: Las interfaces de servicios web son más importantes que las implementaciones.
8. Establecer una categorización de servicios: Una organización debe decidir una taxonomia de servicios.
9. Categorizar las reglas (reglas de procesos versus reglas de negocio.
10. Definir estrategias de interoperabilidad para sistemas basados en plataformas heterogéneas.
11. Incluir estrategias para pruebas de carga, stress y monitoreo de recursos.
12. Para proporcionar mayor agilidad y propiedades de configuración, la utilización de un ESB y un UDDI es vital.

Albert Einstein: A proposito de la Crisis

iHola a todos mijanautas!, hace poco me conseguí con unas palabras sabias y llenas de reflexión, que quiero compartir con todos ustedes: “Sobre las crisis”.

Aquí les dejo las palabras del señor Albert Einstein:

"No pretendamos que las cosas cambien si siempre hacemos lo mismo. La crisis es la mejor bendición que puede sucederle a personas y países porque la crisis trae progresos. La creatividad nace de la angustia como el día nace de la noche oscura. Es en la crisis que nace la inventiva, los descubrimientos y las grandes estrategias. Quien supera la crisis se supera a sí mismo sin quedar "superado".

Quien atribuye a la crisis sus fracasos y penurias violenta su propio talento y respeta más a los problemas que a las soluciones. La verdadera crisis es la crisis de la incompetencia. El inconveniente de las personas y los países es la pereza para encontrar las salidas y soluciones. Sin crisis no hay desafíos, sin desafíos la vida es una rutina, una lenta agonía. Sin crisis no hay méritos. Es en la crisis donde aflora lo mejor de cada uno, porque sin crisis todo viento es caricia. Hablar de crisis es promoverla, y callar en la crisis es exaltar el conformismo. En vez de esto trabajemos duro. Acabemos de una vez con la única crisis amenazadora que es la tragedia de no querer luchar por superarla."