Arquitectura de un sistema empresarial prototipo

En las entradas anteriores establecimos que la gran mayoría del software empresarial se parece entre sí, y entre otros ámbitos de negocio semejantes. Lo que es diferente es la variabilidad de las características que se implementan, cuales son y de qué forma son implementadas.

Vamos a hacer un pequeño acercamiento a la arquitectura de un sistema empresarial prototipo básico. Se muestra un diagrama de bloques de dicho prototipo:

Nota: Debido a que este artículo se creó originalmente como parte del desarrollo de generador “CapicuaGen”, existe varias partes que hacen referencia a dicho generador llamadas “Posibles uso del generador en este contexto”, las cuales se encuentran en cursiva. Si no se está creando un generador de código, o si no es de interés, la parte relativa a “CapicuaGen”, se puede omitir.

Interfaz de usuario

En esta capa se define la apariencia y la interacción con nuestros usuarios y clientes, debe ser lo suficientemente sencilla para que la usen con facilidad, y lo suficientemente completa para que se sea útil. Posibles interfaces son:

Interfaces tradicionales para monitor (computadora)

• Interfaz de escritorio: Puede ser para un sistema de escritorio para Windows, Linux, Mac u otros.
• Interfaz web: Un sitio web tradicional. Aunque HTML y CSS nos garantiza homogeneidad entre los distintos navegadores, ocasionalmente hay pequeñas diferencias de visualizado, que tenemos que tener en cuenta al momento de desarrollar.

Interfaces móviles

• Aplicaciones: Son las aplicaciones nativas desarrolladas para cada dispositivo móvil. En este escenario tenemos que consideran distintas resoluciones de pantalla y tipos de dispositivo como tablet, o smart phones. Podemos desarrollar aplicaciones para Android, iOS y Windows entre otros.
• Interfaz móvil web: Es una interfaz Web diseñada explícitamente para dispositivos móviles (considerando el tamaño de su pantalla).

Posibles uso del generador en este contexto

La interfaz representa lo que puede "hacer" y puede "ver" nuestro usuario, y esto debería ser común para todas las plataformas, el generador debiera ser capaz de crear dicha funcionalidad, y una vez que cambie el negocio, rehacer el código automáticamente para que se adapten todas las interfaces a dichos cambios. Sería necesario contar con una característica generadora para cada plataforma deseada.

Interfaz de servicios

Representa la puerta de acceso a la funcionalidad del negocio. Es una fachada que expone la funcionalidad de forma que la pueda consumir apropiadamente la interfaz gráfica. De esta manera aislamos el negocio, de la forma en la que este es expuesto.

Por ejemplo puede exponerse el negocio de las siguientes formas (entre otras):

• Componentes
• Web Services
• Socket
• RPC
• HTTP

Posibles uso del generador en este contexto

Debido que es un mismo negocio el que se debe exponer y que solo cambia la forma de exponerse, el generador puede crear automáticamente cada fachada necesaria en base a dicho negocio.

Negocio

En esta capa está el problema que queremos resolver en nuestro sistema, representa, en forma de software, la solución a una necesidad a cumplir por la empresa con respecto al mercado.

En esta capa puede haber diversos elementos y diferentes enfoques de resolución, podríamos distinguir los siguientes elementos:

• Entidades de negocio: Son elementos que representan al modelo del negocio, la representación debe ser tanto de información (datos), como de comportamiento, aislar los datos del comportamiento, nos llevaría a un modelo de dominio anémico. [1]
• Flujos de operación: Son elementos que representan que entidades de negocio están vigentes y la forma en la que se convierten en otras. Pueden representar flujos de trabajo que no tengan una correspondencia en una entidad de negocio.
• Acceso a otros componentes: Representan el punto de entrada a componentes ajenos a nuestro software, pueden ser componentes empresariales o componentes externos a nuestra empresa, en cualquier caso esta funcionalidad está aislada, de forma que otros componentes de negocio u otra capa, ignoran el acceso a componentes externos.

Posibles uso del generador en este contexto

Esta parte es muy dependiente de como diseñemos el modelo del dominio de nuestra aplicación, en base a esto podemos crear elementos como:

• Entidades de negocio en base a otros elementos como un UML, o una base de datos.
• Agregar funcionalidad en base a diversas configuraciones.
• Agregar funcionalidad y comportamiento común de la empresa.

Persistencia

Esta capa se encarga gestionar el acceso a diversas fuentes de persistencia, desde donde obtener y guardar la información de nuestro sistema.

Interfaz de persistencia

Expone las funcionalidades de persistencia abstrayendo al negocio de conocer los detalles sobre la tecnología encargada de esta.

Posibles uso del generador en este contexto

Es posible crear las interfaces de los servicios de persistencia, siguiendo algún patrón de software o algo política empresarial sobre cómo deben persistirse los elementos de negocio.

Proveedores de Información

Son los mecanismos concretos por los que se persiste la información. Gracias a la interfaz de persistencia dichos mecanismo podrían ser cambiados por otros, sin afectar al negocio. Algunos de estos mecanismos son:

• ORM.
• Stored Procedures.
• Sentencias SQL.
• XML.
• Archivos de texto.
• Servicios RESTFul.

Posibles uso del generador en este contexto

La persistencia es una de las grandes oportunidades para los generadores de código [2]. Dependiendo de nuestro diseño puede convertir los modelos, en tablas y crear los puntos de acceso para dichas tablas, ya sea por SQL, Stored, o tecnologías ORM. Por otro lado si nuestro diseño comienza por la creación las tablas y procedimientos almacenados (cosa que en principio no es recomendable), se puede crear el acceso a la base de datos, y el modelo a través de ella.

Abstracción del acceso a datos

Mientras la capa anterior trabaja sobre la tecnología de persistencia, esta capa proporciona acceso a dicha tecnología, sin preocuparse donde esté ubicada “físicamente” dicha tecnología. Por ejemplo si el destino es un documento XML, dicho documento puede guardarse en un archivo, en una base de datos, o en cualquier otro tipo de repositorio. Si el destino fuera una base de datos, esta podría ser SQL Server, Informix, MySQL, SQLite, o cualquier otro. Esta capa sabría cómo comunicarse con cada uno de estos proveedores, con independencia de la capa anterior. Igualmente esta capa se encargaría de cualquier tipo de la configuración sobre conexiones y localización de archivos, acorde a las políticas de la empresa acerca del almacén y la seguridad de esta información.

Posibles uso del generador en este contexto

El generador puede ayudarnos a crear el código necesario para el acceso a los repositorios de información, y además puede generar distintos accesos, para simular diversos esquemas de persistencia en un ambiente de pruebas o de desarrollo.

Seguridad

Es una capa que afecta a todas las demás independientemente de lo profundas o externas que sean [3]. Los servicios que ofrecen la capa de seguridad son (entre otros):

• Autentificación: Garantiza que la persona que está usando el software es quien realmente está identificada ante el sistema.
• Autorización: Asegura que la persona autenticada, solo pueda realizar las tareas sobre las que tenga autorización.

Posibles uso del generador en este contexto

El generador puede crear distintos tipos de seguridad y agregarla en los puntos requeridos ya sea por programación orientada a aspectos, o cualquier otro mecanismo.

Políticas empresariales

Implica cualquier aspecto empresarial, que se pueda aplicar de forma vertical en cualquier punto de nuestro sistema. Pueden ser, entre otro:

• Reglas empresariales que deben cumplir todos los sistemas.
• Mecanismos de Cache
• Mecanismos y política de bitácoras y trazabilidad
• Inyección de código
• Gestión de dependencias
• Validación de datos
• Control de excepciones

Posibles uso del generador en este contexto

Dependiendo de qué tipo sea la política empresarial, el generador de código, puede ayudarnos a introducirlas en los lugares adecuados de nuestro software, y encargase de “replicarlas” en el caso que estas cambien.

Acerca de las arquitecturas empresariales

Si bien lo mostrado anteriormente es un ejemplo de una arquitectura empresarial prototipo, hay que tener en cuenta que debemos usar la arquitectura adecuada para resolver cada problema en concreto. No existe una arquitectura que sea indicada para resolver todas los necesidades de software a los que se enfrenta un empresa.

Para considerar una arquitectura software adecuada, esta debe cumplir lo siguiente:

• Que resuelva la necesidad de negocio de forma adecuada.
• Que sea sencilla de entender y de explicar.
• Que sea mantenible.

---

[1] El modelo de dominio anémico, es un antipatrón de diseño, en que se usa un modelo del dominio, sin lógica de negocio, lo cual rompe el paradigma de la orientación a objetos donde dichos elementos (información y comportamiento) van juntos en una misma entidad.

[2] Jack Herrington, expresa en su libro “Code Generation in Action”, que el principal motivo por el cual comenzara a usar generación automática de código, son las experiencias y dificultades que tuvo trabajando con capas de acceso a datos, como menciona el capítulo 6: “Teaching engineers how to use code generation for database work is my primary reason for writing this book. This motivation comes from some personal experiences with database work.”

[3] Principio “Defense in Deep”

Diseño de una fábrica de software

Analicemos los elementos necesarios que necesitamos para crear nuestra línea de producción de software , basado en un esquema de “Fabrica de software”, que se puede implementar dentro de nuestra empresa, ya sea que esta tenga un departamento de desarrollo de sistemas o que el giro de la empresa sea el desarrollo de sistemas en sí.

Estándares de programación: Es una colección de reglas de programación que define como debe crearse el software de nuestra empresa , es importante que todos los programadores los conozcan y respecten. De esta forma cualquier codificador del equipo podría asumir cualquier tarea de programación o mantenimiento con una curva mínima de aprendizaje. Deben de existir herramientas que validen de forma automática que los estándares se cumplan.

Metodologías adecuadas: Debemos trabajar de la forma correcta y que dicha forma sea conocida y cumplida por todos los integrantes del equipo. Debido a las características de nuestra línea de producción, en que muchos elementos serán generados automáticamente, puede utilizarse un enfoque ágil (como XP, o Scrum), en el que se presenten cada poco tiempo un prototipo que a la vez sirva para definir y acércanos más a la necesidad final del cliente (En las metodologías agiles se asume que el software va a cambiar y eso se valora como algo positivo).

Patrones de software : Es necesario que el equipo de desarrollo conozca los patrones de software y los sepa aplicar de forma adecuada, igualmente nuestro generador puede implementar automáticamente los patrones de software, para garantizar que se usen correctamente.

Consumo de framework de terceros: Es necesario identificar los componentes existentes en el mercado que nos pueden ayudar en nuestro desarrollo . Muchos de estos componentes resuelven problemas que a nosotros nos pueden resultar complejos o los más probable que estén fuera del ámbito del problema de negocio que queremos resolver (por ejemplo cuando creamos un portal web , no queremos crear un Framework MVC, por que ese no es nuestro objetivo real, por eso usamos alguno previamente existe como ASP.NET MVC o Apache Struts). Es importante encapsular los framework elegidos apropiadamente para no generar dependencias externas excesivas, para ello, nos será muy útil nuestro generador de código que puede crear las interfaces adecuadas hacia dichos frameworks (y cambiarlas si es necesario).

Desarrollo de framework empresariales propios: Se encapsularan los componentes y funcionalidades comunes que se hayan sido desarrollados dentro la empresa . Cualquier funcionalidad que pueda ser global, se convierte en una herramienta que podrá ser usada en cualquier futuro desarrollo . Nuestro generador puede administrar dichos componentes.

Control de versiones: En toda fábrica es necesario tener controlado el software generado, permitir "viajar" sobre distintas revisiones y sobre distintas ramas de un mismo producto , para ello podemos usar herramientas como SVN o GIT.

Generador de código: Es el encargado de generar la gran parte de nuestro sistema . Todo característica repetible, que se propague en dirección vertical u horizontal en nuestra aplicación, se convertirá en una parte de este generador , una característica a incluir en un catálogo común.

Un característica común repetible, no es un fragmento de código, ni una librería que se usa en varios lugares, sino una parte del desarrollo , que puede ser reusada en otros desarrollos, esto incluye la parte del análisis y del diseño, no solo del código. El código se generara automáticamente adaptándose a la circunstancia indicada para el sistema que se quiera hacer.

Por ejemplo si empresarialmente definimos que nuestros sistemas deben tener cierta arquitectura, existirá una característica (o conjunto de ella), que se encarga de generar el código que respecte dicha característica. El código por sistema será diferente pero se habrá generado automáticamente, en base a un análisis y diseño que se realizaron previamente. El código de la misma forma, podrá cambiar de arquitectura, si cambiamos la característica generadora, o podrá crearse simultáneamente para varias arquitectura, por ejemplo podríamos desear que se genere nuestro software para escritorio y para teléfono móvil (Android o iOS ). De esta manera para una misma lógica de negocio , se crearan diferentes arquitecturas de forma automática.

Hay que considerar que para resolver el desarrollo de un sistema no se puede usar cada uno de los elementos previamente mencionados como única solución (de hacerlo caeremos en el problema del martillo de oro ). Es necesario combinar adecuadamente todos los elementos, para conseguir un software estable y con escalable a futuro:

Los estándares y las metodologías por sí solo, nos dan las reglas y las buenas prácticas sobre cómo crear nuestro software , por otro lado los patrones de software deben usarse de la forma y en los lugares correctos.

El abuso de los frameworks externos nos genera una dependencia, tanto al nivel de arquitectura, como técnicamente. Cuando estamos muy atados a un framework, y este no resuelve un problema en concreto, la solución puede volverse tremendamente complicada y enrevesada, entorpeciendo el mantenimiento del producto .

Intentar resolver todos los problemas con framework propios tampoco es una solución idónea, puesto que caeremos en dos escenarios posibles para abarcar todas las circunstancias propias de nuestro negocio , o crearemos un framework muy abstracto, que no resuelva nada, o creamos un framework muy concreto, amplio y difícil de manejar y mantener.

Si solo usáramos nuestro generador de código de forma exclusiva, este crearía muchos elementos repetidos, y código innecesariamente largo, haciéndolo difícil de comprender su funcionamiento, y por lo tanto condenado a ir perdiendo su utilidad con el tiempo (por posibles mantenimiento y diagnósticos).

Por todo eso debemos combinar en nuestra línea de producción de software todos los elementos según las necesidades particulares de los sistemas a desarrollar, eso hará que sean sistemas con alta calidad , funcionales y escalables.

El manifiesto ágil indica que se debe valorar más la colaboración con el cliente sobre negociación contractual y respuesta ante el cambio sobre seguir un plan.

La expresión "Martillo de oro", hace referencia el refrán "Al que tiene un martillo, todo le parece un clavo". Se quiere evidenciar que es fácil creer que nuestra herramienta o tecnología, por buena que sea, puede resolver cualquier problema, aunque no sea apropiada para la tarea.

Dos años después

¡Cumplimos dos años en el blog! Este es el resumen de todo lo acontecido:

¿Cuántas publicaciones hemos hecho este año?, unas 13, de un total de 35.

¡Tenemos redes sociales!

Estamos en Facebook, Google+ y twitter en los siguientes enlaces:

Síguenos en Google+

Síguenos en Facebook

Síguenos en @joselbautistam

Suscríbete a nuestro canal

Programación

Temas que tienen que ver directamente con asuntos de programación y código

Swift: Variables, Opcionales (?), Opcionales Implícitamente Desempaquetados (!) y conversiones entre ellas (as, as? y as!)

Seguridad

Temas que tienen que ver con la seguridad en el desarrollo de software

Cuestión de confianza I: Criptografía

Cuestión de confianza II: Factores de autentificación.

Cuestión de confianza III: ¿Dónde están los malos?

Post relativos a reglas de software de la ingeniería de software

Es un conjunto de reglas o recomendaciones que nos ayudan a diseñar y construir software, con la intención de que aumentar nuestras posibilidades de éxito. Se han publicado las siguientes:

Regla N°10 de la Ingeniería de Software: Si no es sencillo está mal hecho

Ingeniera de software en la empresa

Artículos relativos al desarrollo de software en la empresa.

Diferentes estilos de liderazgo

El problema de "No somos una empresa de software"

CapicuaGen

CapicuaGen es un producto orientado a la generación automática de código, y a la construcción de software desde un enfoque generativo. ¿Qué quiere decir esto? Bueno básicamente que construiremos un software, cuya misión es construir otro software, o más exactamente el código de dicho software.

CapicuaGen: Proyecto de generador de codigo

Primera versión de CapicuaGen publicada

CapicuaGen: Desarrollo de software en la empresa, Parte I

CapicuaGen: Desarrollo de software en la empresa, Parte II

CapicuaGen: Acerca de la fabricación de software (Breve historia de los lenguajes de programación)

Y esto es todo en el segundo año, espero que os haya gustado :-)

CapicuaGen: Acerca de la fabricación de software (Breve historia de los lenguajes de programación)

Aunque tradicionalmente se nos indica en la ingeniería de software que este se construye, la verdad es que la tendencia desde finales de los años noventa es tender a la fabricación de software.

La diferencia entre construir y fabricar, es que cuando se construye algo, se analiza, se diseña y se construye por única vez y por proyecto, como por ejemplo “construir una casa”, sin embargo cuando algo es fabricado, se diseña y analiza una vez y, generalmente en cadena, es ensamblando con partes previamente fabricadas, generando una serie de productos por un costo reducido. Un ejemplo de esto es la industria automotriz.

Si vemos la evolución de los lenguajes y metodologías de programación, cada vez se basan más en reusar software creados.

Repasemos brevemente las circunstancias sobre cómo esta tendencia se ha ido dando. Analizando la historia de los lenguajes de programación vemos que estos se han ido simplificando desde sus inicios a la actualidad, para centrarse en conceptos cada vez más abstractos y alejándose de las instrucciones que realmente procesa una CPU.

Asm (ensamblador) con sus saltos de memoria y macros, dio paso a C, un lenguaje estructurado, diseñado para facilitar la programación, a un nivel más alto que ASM, sin embargo fácilmente traducible a este. C tiene un conjunto básico de librerías ampliable, se pueden usar "módulos" y estos son fácilmente insertados en otras aplicaciones y sistemas. A C, le siguió C++ "C con clases", que abstraía más la programación y la reusabilidad de componentes .

Debido a que asm, C y C++, se usaban en multitud de dispositivos (no solo computadoras, sino aparatos electrónicos programables en general), y que cada dispositivo parecía manejar su propia versión de estos lenguajes, era necesario generar un programa específico para controlar a cada uno de ellos, programas que prácticamente hacían los mismo, pero cuyo código era diferente, dificultando en exceso la portabilidad de los sistemas. Ante este problema, casi a mediados de los 90, surgió Java, un lenguaje pensado para programase exactamente igual en todos los dispositivos. Java está basado en C++, pero depurado de todas las funcionalidades confusas y peligrosas de este lenguaje, simplificando mucho la programación, a la vez que hacia posible que un mismo programa (compilado), funcionara en varias arquitecturas disparejas.

A Java le siguió la contraoferta de Microsoft (que por aquel entonces tenía un compilador de C++, bastante popular y su IDE y lenguaje tradicional “Visual Basic”), creando su arquitectura .NET a principios de los años 2000. Dicha arquitectura, está inspirada en Java, simplificando aún más su uso, en C++, y buscando un enfoque de sencillez al momento de programar, en Visual Basic y Delphi (es de notar que Delphi y C#, comparte un creador común, El arquitecto principal del equipo encargado de Delphi (en Borland) y C# (en Microsoft) fue el danés Anders Hejlsberg.). Además .NET ofrecía programar en varios lenguajes (originalmente Visual Basic .NET, C# y J#), y posibilidad de usar componentes creados en unos lenguajes en otros.

Es curioso también señalar la relevancia que tuvo Visual Basic (versión 6 y anteriores), en los 90 y buena parte de los 2000, a pesar de ser un lenguaje poco práctico, muy poco escalable, y tener un gran número de problemas de fondo. Visual Basic enfoco el desarrollo a través de componentes que eran fáciles de desarrollar y de incrustaban de forma gráfica en los desarrollos, comunicándose con otros componentes en forma de eventos (mensajes que lanzaba el mismo componentes esperando a que un oyente que los interpretara). En estos casos realmente estamos “fabricando” software ensamblando distintas piezas, desde un catálogo disponible, de una forma sencilla y clara. Adema Visual Basic unifico el acceso a base de datos, enmascarándolo dentro de un esquema común (independiente del motor subyacente), de tal forma que se podía establecer comunicación, y ejecutar sentencias SQL, sin importar la base de datos.

Linus Torvald, creador de Linux, alabo en el 2006 a Visual Basic, diciendo que a pesar de no ser un gran lenguaje de programación hizo más por la programación que los lenguajes orientados a objetos, al introducir interfaces sencillas de conexión a base de datos. Si bien el comentario es muy discutible, es más que curioso por provenir de quien viene, la conclusión sobre esto, es que de todos los lenguajes se puede aprender algo.

Para la WWW, tenemos una evolución parecida. HTML comenzó con un conjunto de etiquetas pare definir formato y contenido, y se les fue añadiendo programación en forma de scripts, para añadirle funcionalidad. En la actualidad, está dividido en varias aspectos, el contenido que es definido por HTML, la presentación que lo define CSS, y la funcionalidad que es implementada a través de JavaScript. Es de espera que cada uno de estos elementos sean componentes independientes que se pueden separar y juntar, según convenga, por ejemplo un mismo contenido, se pueden mostrar de forma diferente en una pantalla de ordenador, y un dispositivo móvil. Igualmente para el desarrollo de las sitios web, se puede usar un amplio catálogo de framework y “librerías” para facilitar su desarrollo, como JQuery, Angular, o Bootstrap (nuevamente se reúsa y se ensamblan componentes para crear software ).

El enfoque de “Fabrica” es muy evidente en los productos que nos ayudan a crear sitios web automáticamente, un ejemplo muy claro es Blogger, que sin conocer nada de HTML, ni de desarrollo de software, podemos tener un blog completo solo dando instrucciones sobre cómo queremos que sea, y que elementos querernos que lo compongan.

La evolución hacia la reusabilidad también tomo el enfoque de componentes y servicios. Se comenzaron a crear librerías, cuya funcionalidad eran utilizada por diversos sistemas, posteriormente se realizaron componentes que podrían invocarse remotamente (RPC, CORBA, DCOM,…), y por ultimo servicios que exponen funcionalidad de una forma estándar y fácilmente consumibles por cualquier sistema en cualquier tecnologías (SOA, RESTFul,..). Muchas de estos componentes y servicios están expuestos públicamente para su uso de forma gratuita, por ejemplo para Ruby, Perl, C# y Java, tenemos RubyGem, CPAN, NuGet y Maven respectivamente, como repositorios donde obtener componentes, y como servicios tanto Google como Apple o Amazon, exponen multitud de ellos, los cuales podemos consumir desde nuestros sistemas.

Como vemos, la historia nos lleva a lenguajes, metodologías y ambientes en los que se tiende a lo siguiente:

• Lenguajes de programación cada vez más abstractos y enfocados a la manera de pensar de los programadores, no a la manera de operar de las maquinas.
• Sistemas que tienden a la reutilización del software, a crearse a través del ensamblado de componentes previamente desarrollados.
• Sistemas que delegan en componentes y servicios de diversas arquitecturas, de los que no se tiene conocimiento de cómo realizan su tarea, sino de la funcionalidad que realizan (Se sabe el “que” no el “como”).

Con respecto a este enfoque, podemos diseñar nuestra metodóloga de “Fabrica”, en la se creara una “Línea de producción”, que será configurada con los requisitos y características del software deseado y creara un sistema de la forma más automática que sea posible (Contra más característica tengamos disponibles en el catálogo de la fábrica, más funcionalidad podrá crearse de forma automática).

CapicuaGen: Desarrollo de software en la empresa, Parte II

Si bien las empresas pueden llegar ser muy diferentes entre sí, a nivel de software es más lo que se parece que en los que se diferencia. En cualquier de los enfoques anteriores, se dan dos constantes que hay tener en cuenta:

El software va a cambiar: Los cambios son necesarios para el negocio, estos cambios se darán de forma cada vez más frecuente y debemos poder responder a la necesidad de dicho cambio para que nuestra empresa siga vigente en el mercado de la forma adecuada.

El software se parece entre sí: Casi todo el software empresarial se parece entre sí, casi todas las empresas gestionan recursos de algún tipo (humanos, económicos, etc.) y generan un producto (dinero, servicios, o bienes de alguna naturaleza). Técnicamente hablando casi todas los sistemas software tienen características como acceso a datos, seguridad, interacción con el usuario o trazabilidad.

En el escenario donde una misma empresa fabrica su propio software, se deseara que este sea homogéneo entre los distintos sistemas que posee, para disminuir la curva de aprendizaje entre sus usuario y fomentar la imagen corporativa unificada.

En las fábricas de software, se deseara reusar los máximos componentes posibles entre desarrollos diversos, para optimizar el uso de recursos y reducir los costos de producción.

En el caso de la empresa que vende un producto de software, esta querrá vendérsela al máximo número de posibles clientes, con las mínimas y menos costosas personalizaciones posibles.

En cualquier de estas opciones, se tiende a desarrollar componentes y elementos software, que se reúsan en los diversos sistemas. Los sistemas a su vez, se parecen a otros sistemas con los que comparten una funcionalidad semejante, o tienen elementos técnicos semejantes como características y aspectos comunes. La parte que hace diferencia a un software, aunque en el producto final es la que más destaca, en proporción es la que menor código representa, con respecto a la parte de código que puede reciclarse.

Veamos una serie de ejemplos que muestren las constantes sobre el cambio y las semejanzas del software.

Si existe un mercado que evidencie la necesidad rápida de cambio de un software es el de la telefonía movil. En menos de 10 años se convirtieron en un elemento imprescindible, tanto en lo laboral, como en lo personal. Actualmente viene dominado por dos gigantes de la industria, Apple (con su teléfono iPhone) y Google (con Android), ambos ofrecen sistemas de funcionalidades idénticas, y llevan años en una carrera de cambios, que en el fondo son semejantes en lado y en el otro. La diferenciación entre ambos no se da en los que hace sus sistemas, sino en que Apple ofrece una experiencia ligada a su hardware y a un ecosistemas de productos completo, y Google a se basa en una interconexión de multitud de servicios, independientes del hardware. Anualmente estas compañías presentan cambios y novedades a sus sistemas, y siguen vendiendo teléfonos manteniendo al mercado interesado.

En el lado contrario tememos a RiM, el creador de la BlackBerry. BlackBerry fue el primero en entrar en el mercado de los teléfonos inteligentes con un gran éxito, pero se conformaron con tener un nicho seguro dentro del mundo empresarial, y perdieron de vista los cambios en la sociedad que solicitaba tener al alcance de su mano una forma diferente de servicios y conectividad global. Cuando emergieron los IPhone y los Android Phone, que si supieron entender las necesidades de cambio, se quedaron estancados y terminaron por casi desaparecer del mercado.

Microsoft, en cambio fue el último en entrar en este mercado, si bien entendió las necesidades, no lo hizo en el momento adecuado, sino en uno en que ya no podía competir con los dos grandes ya establecidos. Motorola y Nokia se enfocaron en sacar un producto para cada sector consumidor según sus estudios de mercado, pero no comprendieron que si bien, una persona necesita un teléfono para trabajar, también lo va a necesitar para otras actividades, así que hicieron muchos teléfonos mediocres en lugar de pocos que resuelvan un amplio aspecto de necesidades. Estos fueron ejemplos de empresas que no supieron adaptarse al cambio de una manera adecuada.

Si vemos a las empresas que tuvieron éxito, observamos las constantes que hemos mencionado:

• El negocio cambia, cambia frecuentemente, y la vigencia del producto viene definido por el cambio, y este debe estar sostenido un sistema software.
• Los sistemas se parecen entre sí, el software tiene más semejanzas que diferencias.

Si obtenernos el porcentaje del código de un sistema que se asemeja a otro código, en comparación al que es exclusivo de nuestra aplicación, descubriremos que el código semejante es mucho mayor que el que no es.

El problema es que se invierte más tiempo y recursos en desarrollar las partes semejantes (por su volumen) que en desarrollar las partes exclusivas de un sistema, sin embargo las partes exclusivas de un sistema son las que le dan su identidad, con lo que debieran ser en las que se dedique más recursos y tiempo.

Para poder invertir los mencionados recursos y tiempo en el lugar adecuados, necesitamos una herramienta que nos ayude a generar las características comunes del sistema con el mínimo esfuerzo. La herramienta nos debe permitir escoger dichas características de un catálogo general común para una empresa, para un ámbito de negocio, o para un aspecto de nuestro software en particular e implementarla de forma automática en el sistema.

En base a esto se puede construir una línea de desarrollo de productos de software con un enfoque generativo.

CapicuaGen: Desarrollo de software en la empresa, Parte I

Es un hecho que cualquier empresa, sea cual sea su tamaño, necesita un ambiente software adecuado que facilite su negocio, y le ayude en los cambios, constantes y rápidos que se dan en cualquier industria, más aun en la época de globalización e interconectividad en la que vivimos actualmente.

Los escenarios en los que se crean software empresarial son muy variados, vamos a enunciar principalmente tres de ellos:

Empresas con un departamento de desarrollo de software: En este escenario la empresa considero que es más factible para ella, tener un equipo que se dedique a construir el software que necesita en lugar de adquirirlo por medio de un ente externo. Este equipo puede tener más o menos madurez, además tener un tamaño variable.

Las ventajas de este enfoque, es que el equipo de desarrollo, tiene un solo “cliente” (la misma empresa) y debido a la cercanía, entre empresa y desarrollo, el conocimiento y las necesidades son más cercanas entre los unos y los otros, generalmente tiene un costo fijo al basarse principalmente en nóminas.

La desventaja es que no siempre se consigue la madurez necesaria para construir software lo suficientemente escalable para permitir al negocio crecer de manera adecuada. Frecuentemente se mantiene un mismo software durante años, haciéndole los mínimos cambios posibles, porque cada cambio tiene un gran impacto, haciendo sus sistemas difíciles de mantener. Al pasar del tiempo, es necesaria una restructuración completa del sistema software de la empresa, que muchas veces viene impulsara por cambios en el personal del mismo equipo de desarrollo.

Fábricas de software que son contratadas para tal efecto: En este enfoque la empresa contrata recursos externos para construir el software que necesite para para su negocio, puede ser para la creación de un producto, o otros eventos desarrollo y construcción en particular.

Las ventajas de este enfoque es no se debe invertir en recursos de construcción de una forma constante, solo cuando es necesario un desarrollo.

El problema es que posiblemente la fábrica tendrá más de un cliente, con lo que su atención hacia la empresa puede no ser la más adecuada, fases de análisis y diseño se pueden alargar en lo que la fábrica conoce las necesidades de la empresa y por ultimo cualquier cambio en los requisitos (que sin duda se darán en las revisiones de los productos) generada un costo adicional para la empresa.

Empresas de software que vende uno o varios productos: En este caso la empresa busca a otra empresa que venda o proporcione un producto adecuado a sus necesidades.

La ventaja de este enfoque es que generalmente se busca un producto que ya está realizado y construido, con lo que podría decirse que el problema se reduce a la puesta en producción de este.

La desventaja de este acercamiento, es que la empresa debe adaptarse al producto, y no lo deseable, que es que el producto se adapte a las necesidades de la empresa. En cualquier caso es muy posible que el software deba comunicarse con otros sistemas de la empresa, con lo que habrá que desarrollar una serie de interfaces para permitir la comunicación, perdiendo la ventaja de obtener un software completo y funcional desde el primer momento.

Nuestras Redes sociales

Estoy actualizando las redes sociales del blog. Hace unas semanas que tenemos twitter, y recientemente abrimos un canal de Youtube para poder subir algunos videos y tutoriales.

Síguenos en Google+

Síguenos en Facebook

Síguenos en @joselbautistam

Suscríbete a nuestro canal