Mostrando entradas con la etiqueta Arquitectura. Mostrar todas las entradas
Mostrando entradas con la etiqueta Arquitectura. Mostrar todas las entradas

lunes, 29 de abril de 2013

El vendedor de motos

El vendemotos, es otro de los integrantes de la fauna que podemos encontrar en cualquier empresa de software. El vendemotos no tiene porqué ser siempre el comercial de turno. Hay también vendemotos en otras categorías laborales, aunque suelen estar relacionados íntimamente con otro miembro de la fauna laboral: "el trepa". De éste hablaremos otro día.

El vendemotos te venderá (si es comercial) o tratará de que se use (si es técnico) la última moda tecnológica, supuestamente consiguiendo con ello la mejor eficiencia, mayor productividad, accesible desde el móvil, con soporte para la nube, etc, etc.

El comercial vende-motos

Si es un comercial, se lo ofrecerá al cliente, para mayor horror y desengaño del vilipendiado equipo de desarrollo, que se verá obligado a tratar de implantar tecnológicas poco probadas, de escaso impacto en valor real para el cliente, pero por supuesto, con un coste y un sobre-esfuerzo que pondrá al límite tanto al equipo de desarrollo como a la economía de la empresa. Claro, esto al cliente le dará igual, porque el precio cerrado conseguirá que esto no se le transmita al cliente, que sólo verá con horror como se producen retrasos en unas funcionalidades que para él eran triviales.

El técnico vende-motos.

Si el vendemotos es un técnico, se tratará de un miembro del equipo que tratará de influir en el resto, bien por categoría (analista, jefe de equipo o de proyecto), o bien por insistencia (el auténtico pesado que te está dando la paliza para que uses el nuevo hibernate-struts-mvc-loquesea). Claro, este técnico de pacotilla, auténtica piltrafa tecnócrata, trata de colocar estas novedades...¿pero por qué? Analicemos este punto:
  • Habrá leído unos días antes de las bondades de la nueva tecnología
  • Querrá impresionar a sus responsables o subalternos con estas novedades, atrayendo hacia sí una falsa sensación de profesionalidad.
  • Quizá se aburría, y busca una forma de desarrollarse a sí mismo y a su currículum a costa de sus compañeros y empresa actuales.
  • Quizá lo usó en otro proyecto, que no se parecía a este en nada, y lo que allí le salió bien (o vio a otro que le salió bien), cree que ahora puede encajar. Me encanta cómo se desprecia el valor de la experiencia y de un buen análisis que compruebe realmente lo adecuado de las cosas en relación a los objetivos buscados.  
Después de todo, para cuando se implante la tecnología, o bien le habrá dado tiempo a aprenderlo...o bien ni siquiera la termine implantando él (ya pringará otro), o bien ni siquiera estará ya él en la empresa/proyecto. Cuántos habré visto abandonar los proyectos que ellos mismos han empezado torpedeando con arquitecturas demasiado novedosas.

El mantenimiento, también se verá gravemente afectado. Las nuevas tecnologías, en cuanto maduran, empiezan a ser realmente mantenibles y productivas, pero pobres de los proyectos que las hayan implantado cuanto aún eran novedades tecnológicas: esos proyectos serán difícilmente mantenibles, porque las arquitecturas creadas alrededor de esas novedades para poderlas "sostener", serán reduntantes. Cuántas veces hemos visto implementar en los frameworks (struts, mvc, EF,...) funcionalidades que en sus primeras versiones se han tenido que implementar "a pelo" (es decir, con sufrimiento y dolor).

¿Quién pierde?

  • Pierde el cliente, que ve tirado a la basura su tiempo y dinero, y que con suerte ve una solución cara e inadecuada que podría haberle salido mucho más barata (a corto plazo por el precio, y a largo plazo por el mantenimiento que va a tener).
  • Pierde el equipo de desarrollo, que ve cómo sus horas se disparan al tratar de hacer funcionar cosas imposibles, complejas, bizarras. Sí, habrán aprendido mucho. Me encanta ver cómo los defensores de las novedades se escudan en el aprendizaje. Para aprender, vete a la autoescuela. Cuando sepas correr, coges el Ferrari. Los peatones te lo agradecerán.
  • Pierde la empresa, que ve cómo los costes se disparan al inicio del proyecto, y se tiene que comer con patatas el precio vendido. Al final, o pone a los recursos más baratos para no arruinarse, o todo el mundo a hacer horas extras.

¿Quién gana?

  • El dueño de la tecnología, que ve cómo se usa algo inmaduro y fuera de contexto, proporcionándole un beneficio a través de los vendemotos que han caído en la trampa.
  • El vendemotos, suele ganar, ya que su enorme habilidad de escaquearse, hace que no le afecten los negativos resultados de sus gestiones o falta de habilidad.

¿Y tú? ¿Has visto recientemente a algún vende-motos?

viernes, 30 de marzo de 2012

PRISM: un framework para WPF

El pasado Febrero de 2012, Microsoft liberó la versión 4.1 de Prism, un Framework pensado para facilitar la creación de aplicaciones con WPF y Silverlight. Sobre todo, permite afrontar de forma estructurada y según los últimos patrones, aplicaciones de visualización de datos con interfaces de usuario ricas y con un negocio complejo.

¿Qué permite Prism?

  •  Modularidad: particionar los componentes para crear aplicaciones a partir de módulos integrados pero independientes.
  • Interfaz de usuario: desacoplamiento de los componentes de UI con respecto al resto de la aplicación.
  • Servicios horizontales (log, authentication,etc)  separados de servicios verticales (business logic). Esto facilita la creación de capas realmente desacopladas.
Según Microsoft (y las características que aparecen así lo indican), las aplicaciones desarrolladas con Prism están hechas para durar mucho tiempo, y para aceptar con sencillez los cambios que sean necesarios.

Más información en este enlace, donde encontraremos:
  • Descargas
  • Guías
  • Enlaces de acceso a Foros y Blogs para más información y solución a problemas comunes
  • Documentación
  • Quickstarts

jueves, 8 de marzo de 2012

Top Mantra de los Arquitectos (II)

Este artículo es el segundo de una serie de dos. Para ver el anterior, clic aquí.

Tenía pendiente terminar este artículo que ya inicié hace algún tiempo. Vamos a ello. Estábamos hablando del Top 10 de los Mantras de un arquitecto de software. El post anterior repasaba los mantras del 1 al 5. Vamos a los números 6 al 10.

Mantra #6: ¿No estás en la capa de datos? Entonces no pongas SQL!
Tal y como establece SoC (Separation of Concerns), intenta poner cada cosa en su sitio, sin mezclar. Pon el código de acceso a datos y los detalles como connection strings, bien lejos. Tarde o temprano, tendrás que ocuparte de ellos, pero considera por separado las lógicas de negocio y presentación de cara a la persistencia. Siempre que sea posible, delega la persistencia en una herramienta ORM.

Mantra #7: la mantenibilidad es lo primero
A pesar de que ya hablé en mi post sobre los mitos de la mantenibilidad, Dino Exposito tiene más razón que un santo al establecer que si hay que elegir un atributo para el software, como arquitectos, ha de ser la mantenibilidad, por encima de la escalabilidad, seguridad, rendimiento y testeabilidad. Si código y la arquitectura son mantenibles, el resto se puede conseguir más tarde (no así al contrario)

Mantra #8: el input del usuario es pura maldad
Tal y como comenta Dino en su libro, si existe una forma en que los usuarios hagan algo mal, encontrarán la forma de hacerlo. Si te suena esta afirmación a la ley de Murphy: SI, así es.

Mantra #9: Optimización Post-Mortem
Tal y como indica Dino (y estoy totalmente de acuerdo), empezar a diseñar un sistema con la optimización en mente es un error. Yo voy a ir un poco más allá: es un signo de inmadurez. Y me refiero a inmadurez profesional, a falta de experiencia. Tratar de que un sistema crezca siendo óptimo desde el principio es una buena forma de perder el foco de lo que realmente es importante. Es mucho más importante (ver mantra #7) que sea mantenible, ya que ante cualquier cambio, podemos optimizarlo. Un software muy optimizado desde el principio, seguramente no será mantenible y por tanto, ante cualquier cambio (que los habrá, no os preocupéis), dejará de ser óptimo. Y por desgracia, en esa situación, ya poco habrá que hacer.

Mantra #10: La seguridad y testeabilidad, han de estar "por diseño".
Aquí poco hay que decir. Es tan radicalmente cierto, que incluso hay un estándar de la International Organization for Standardization (ISO) que explícitamente, lo establece. Un sistema, por mantenible que sea, es muy complicado (y por tanto caro) que sea seguro a base de hacer cambios. Lo mismo la testeabilidad. Si no empiezas diseñando para que sea testeable, con sus pruebas unitarias, con la arquitectura adecuada...no podrás de repente implantar la testeabilidad.

Y nada más. Que os recomiendo encarecidamente este libro. Es de los pocos, junto con los del eterno Steve McConnell, que merecen la pena comprarse y leerse más de una vez. ¡Ah, y no me llevo comisión por decir esto, eh! Más info del libro:

by Dino Esposito and Andrea Saltarello
Microsoft Press. (c) 2009

Microsoft .NET: Architecting Applications for the Enterprise

lunes, 5 de marzo de 2012

AADL: un lenguaje de modelado para Arquitectos de Software

Hoy voy a hablar del AADL, un lenguaje para nada nuevo, y que sin embargo es bastante poco conocido. Vamos a revisar algunas de sus características generales:
  • Existe como estándar internacional desde 2004.
  • Nació como lenguaje orientado a entornos de aviónica, pero actualmente su alcance es mucho más amplio.
  • Está promovido por el SEI
  • Pretende estandarizar en un lenguaje de modelado, el diseño de arquitecturas (hardware y software).
  • Nació para sistemas embebidos, por lo que admite hardware y software.
  • Es un lenguaje textual y gráfico.
  • Incluye un formato de intercambio XML/XMI que permite interoperabilidad con herramientas del mercado
  • Dispone de una extensión para el modelado de sistemas resistentes/tolerantes a fallos.
Puede utilizarse para modelar:
  • Sistemas empotrados, como arquitectura de sistema basada en componentes.
  • Las interacciones de los componentes mediante flujos, llamadas de servicio y de acceso compartido.
  • Ejecución de tareas, sincronización exacta de comunicaciones.
  • Plataformas de ejecución, application binding, modelos operativos y configuraciones tolerantes a fallos.
Hay muchos otros lenguajes de modelado, pero éste me ha parecido curioso y me apetecía echarle un vistazo y compartirlo.

Ejemplo.
A continuación, un ejemplo sacado de la página de AXLOG:


system system1
end system1;

system implementation system1.impl
    subcomponents
        p1: process process1.impl;
        p2: process process2.impl;
    connections
        cn: data port p1.outport -> p2.inport;
end system1.impl;

process process1
    features
        outport: out data port;
end process1;

process implementation process1.impl
    subcomponents
        t1: thread thread1.impl;
    connections
        cn: data port t1.outport -> outport;
end process1.impl;

process process2
    features
        inport: in data port;
end process2; process implementation process2.impl
    subcomponents
        t2: thread thread2.impl;
    connections
        cn: data port inport -> t2.inport;
end process2.impl;

thread thread1
    features
        outport: out data port;
end thread1;

thread implementation thread1.impl
end thread1.impl;

thread thread2
    features
        inport: in data port;
end thread2;

thread implementation thread2.impl
end thread2.impl;


Os dejo con unos enlaces en los que podréis ampliar información:
http://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language (Nota: para ser Wikipedia, la verdad es que la información que da es bastante pobre a fecha 5 de Marzo de 2012)
http://www.sei.cmu.edu/dependability/tools/aadl/
http://www.axlog.fr/aadl/presentation_en.html (este enlace sí que tiene bastante información, ya que AXLOG es una firma miembro del comité de estandarización de AADL).

viernes, 9 de diciembre de 2011

Top Mantra de los Arquitectos (I)


Estaba leyendo uno de mis autores favoritos (Dino Esposito), con su "Microsoft .NET: Architecting Applications for the Enterprise", y entre otras muchas perlas que conviene leer y que os recomiendo encarecidamente, contiene un pequeño resumen de 10 magníficas perlas (mantras en su libro), que no por sencillas, son menos importantes en nuestro trabajo. Vamos a darles un repaso:

Mantra #1: "Depende". Ademas de ser una respuesta socorrida para aquellos que no tienen ni idea, por desgracia es también una respuesta de los más experimentados. Pues sí, depende. Depende de la situación, del contexto. Las decisiones arquitectónicas son sólo eso: decisiones basadas en la experiencia y en el conocimiento del proyecto, del cliente y del equipo de desarrollo. Basándose en los tres anteriores, hay que elaborar la lista de soluciones para cada una de las facenas de nuestra solución arquitectónica.

Mantra #2: "Los requisitos son Dios". He querido explícitamente no hablar de ellos en el mantra anterior, y es que los requisitos, aun formando parte de la especificación del proyecto, son mucho más importantes que el proyecto en sí para el arquitecto. No es fácil adaptar las cosas al equipo (si es que conseguimos un equipo estable de trabajo), como tampoco lo es adaptar la arquitectura al cliente (si es que conseguimos la colaboración del cliente, y si dicha colaboración es fructífera). Al final, los requisitos son la verdadera guía del proyecto. Cambiarán, por supuesto que cambiarán. Pero al final, es la labor inicial de análisis y el enfoque acertado de dichos requisitos, lo que marcará el éxito del proyecto. Los arquitectos sólo se limitarán a proporcionar la infraestructura tecnológica, las decisiones de comunicación, etc., para adaptarse a dichos requisitos.

Mantra #3: "Programar una interfaz". De nuevo, los requisitos (en este caso de interfaz), van a ser la directriz principal de los desarrolladores. Sin interfaces, el código no tiene forma de prosperar. Serán sólo líneas de código sin un objetivo (como echar ladrillos al aire con la esperanza de que formen la pared tal y como se proyectó).

Mantra #4: "Hazlo simple, pero no simplón". Aquí es donde un arquitecto se la juega. Las soluciones complejas, en las que el arquitecto pretende mostrar su conocimiento (cuando realmente se le ve el plumero de que le falta experiencia), nos llevan de forma inexorable al fracaso. Donde realmente se ve a los mejores profesionales brillar, es con soluciones simples y efectivas. Por desgracia, hay una débil frontera que hace que una solución simple, no se pueda simplificar más sin caer en lo absurdamente simple y escaso.

Mantra #5: "Herencia es sobre polimorfismo, no reutilización"
La herencia constituye un elemento fundamental de la programación orientada a objetos. Que la herencia permite reutilización, es correcto. Pero la reutilización como objetivo, es un gran error. Dicho de otra forma, es mejor escribir una nueva clase específica para la tarea concreta, que heredar de otra que no lo está. Es mejor reescribir de forma enfocada a la solución concreta, que tratar de reutilizar todo formando una oscura maraña de dependencias que de seguro llevará al fracaso (y complicará la vida a los pobres programadores que osen completar la aplicación, y luego mantenerla).

Y bueno, hasta aquí la primera parte de los 10 Top Mantra de los arquitectos. El próximo día...más.

jueves, 29 de septiembre de 2011

Cacheitis: otra enfermedad común del desarrollo software


Hoy hablamos de otra enfermedad habitual en el mundo del desarrollo software. Relacionada con las enfermedades "arquitectónicas", está especialmente relacionado con desvaríos de los arquitectos de software a la hora de implantar soluciones que por su ineficiente diseño, producen un mal rendimiento. Entonces la definición de Cacheitis vendría a ser algo así: "desorden transitorio del arquitecto o diseñador de software por el cual el uso inadecuado de la caché provoca como resultado una solución ineficiente".

¿Y cuál es la primera solución que se les ocurre? Sí señoooor: más caché. Caché por todos lados. Vamos a cachear todo lo cacheable.

En otras ocasiones, es al reves. Se parte con un exceso de caché desde el inicio del diseño, y esto deriva en un mal rendimiento. Para solucionarlo: como no...más caché.

Rodrigo corral en su blog ya hablaba de este problema, y aporta algunas buenas prácticas:
  • Asume que no puedes cachearlo todo. Esto es viejísimo: ya es harto conocido por ejemplo, que en el mundo de las bases de datos es absurdo tratar de indexar todo en la búsqueda del rendimiento. Pues esa mala práctica, la cacheitis la extiende al uso de la cache.
  • El cacheo temprano no es bueno. A menudo cuando diseñamos una arquitectura establecemos mecanismos de cacheo que luego son utilizados hasta el abuso. El peligro subyacente al cacheo temprano es que comencemos a cachear sistemáticamente elementos que nos parecen costosos sin tener evidencia de que realmente son los mejores candidatos para su cacheo. De nuevo, podemos establecer la comparación con el uso excesivo de índices en las bases de datos.
  • Tener en cuenta las otras cachés. Hay que recordar que existen muchos niveles de caché. El motor de base de datos, el servidor web, ADO.Net, etc, etc.
  • Una colección estática o global no es una caché: los desarrolladores noveles, y a veces los no tan noveles, utilizan datos estáticos o globales para simular el uso de la caché. Por desgracia, esto es una burda imitación de las múltiples características que deben incluirse en un mecanismo de caché como: acceso frecuente a los datos, políticas de refresco e invalidación, liberación de recursos de uso infrecuente, etc.
¿Qué es lo que hay que hacer? Pues recordar que somos ingenieros, y tratar de aplicar el sentido común (por desgracia, no el más común de los sentidos hoy día). Para ello, hay que relajar el usar la caché en las etapas tempranas del proyecto, y dejar para las etapas de optimización un uso combinado e inteligente de:
  • Optimización mediante caché
  • Optimización del acceso a datos mediante índices, su propia caché, vistas, datos calculados, etc.
  • Minimizar los accesos a servicios web, WCF, y a otras capas de la aplicación, de forma que las operaciones no hagan "excesivos viajes" para obtener la misma información.
De hecho, al final, no es sino hacer uso de los más básicos principios ágiles: simplicidad desde el diseño.

lunes, 19 de septiembre de 2011

La importancia del análisis

Un análisis (funcional o técnico), es un punto importante, en el que el analista de turno "se moja" y decide implementar los requisitos de una forma implementable. El problema, como se ejemplifica a la perfección en la imagen siguiente, es que hay que tener antes la experiencia suficiente para (entre otras cosas), saber identificar si hay componentes o incluso sistemas enteros que implementan nuestra misma solución.



Fuente: http://www.nosololinux.com/2009/03/27/la-nosolotira-grandes-ideas/

domingo, 4 de septiembre de 2011

Desarrollar sin programar

Imaginaos un futuro en que se pudiese crear software sin programar ni una sola línea de código (ojo, no he dicho sin saber programar, aunque tampoco quiero decir con ésto que sea obligatorio saber programar para crear este tipo de software).

Imaginaos un futuro en que con sólo conocer el proceso de negocio, la interacción con el usuario y otros sistemas/procesos/bases de datos, se pudiese crear complejas aplicaciones.

Imaginad que en ese futuro, en el desarrollo, se abstrajesen de forma totalmente transparente al usuario desarrollador:
  • lenguaje de programación
  • sistema operativo destino
  • arquitectura (MVC, N-tier, etc)
  • acceso a datos (ODBC, dataset, entidades POCO, etc).

Imaginad en ese futuro, que las aplicaciones fuesen fáciles de mantener, y estuviesen actualizadas a las últimas tecnologías del mercado.

Pues este tipo de software existe ya hoy. De hecho, existe ya desde hace muuuchos años. Además, uno de los entornos de desarrollo de los que me gustaría hablar se creó en su versión 1.0 en el año 1989! Me ha sorprendido, porque yo lo había oido hablar desde hace algo menos, los 14 o algo más de años que llevo en esta profesión. De hecho, me ha tocado trabajar con alguno de estos entornos (y ni siquiera es de los conocidos, pues es una plataforma para soluciones bancarias).

Pues nada, a ver si saco un rato, y dedico un par de entradas en el blog a este mercado de aplicaciones, y a la que más me suena y conocía desde unos añitos.