Arquitectura de Sistemas - Primera Parte - Introducción

La comunicación de ideas, conceptos o especificaciones de construcción, dentro de actividad de creación de software se vuelve cada vez más compleja debido a la cantidad de tecnologías existentes y tecnologías emergentes. Dentro de los términos más usados, pero cada vez con menos claridad están Arquitecto y Arquitectura. Definiciones existen muchas, lo importante es decidir su importancia o gravitación dentro del desarrollo de los proyectos, si es necesaria la definición como tal y cuales son los impactos de la misma.
Voy a publicar una serie de 7 articulos con respecto a ésto.

Arquitectura de Sistemas - Cuarta Parte

¿Que es Arquitectura? ¿Quien es el arquitecto? ¿Son necesarias estas definiciones? ¿Cuáles son las diferencias con el Diseñador?

El rol asignado para desagregar funcional y no funcionalmente la problemática y transformarla en una solución de negocio factible es [C1] usualmente es referido como el diseñador del sistema, el cual estructura las partes como un todo que debe responder unificadamente a los requerimientos.

El diseñador usa una abstracción o conceptualización bajo un conjunto de metodologías y herramientas técnicas, usadas para abordar un una problemática de negocio dada. Bajo este esquema, el rol de diseñador está definido para resolver las problemáticas siempre y cuando estas no trasunten ámbitos de negocio en los cuales la solución de la problemática requiera diferentes conceptualizaciones [C6], en cuyo caso interviene el arquitecto, que es una extensión natural al diseñador.

[C1] La descomposición presenta aspectos funcionales y no funcionales

Arquitectura de Sistemas - Tercera Parte

Un problema de negocio es un conjunto de restricciones o limitaciones que dentro de un ámbito o contexto organizacional impiden la realización de objetivos o metas de las entidades de negocios (a las cuales puedan asignarse objetivos).

Una problemática de negocio es la representación [C1] de ciertos aspectos [C2] de un problema de negocio.

Una solución técnica de negocio es una implementación en elementos de software a ciertas restricciones dadas por la problemática de negocio. La traducción de los requerimientos funcionales y no funcionales (mapeo de las restricciones de negocios entregadas en lenguaje no formal) generados por usuarios de negocio al conjunto de elementos de software que los satisfacen es llamada “desarrollo de software”. Este tipo de solución resuelve una problemática de negocio, usando técnicas o métodos basadas en modos de pensar [C4] estructurados y/o objetuales. Las problemáticas y las soluciones están sujetas a conceptualizaciones que descomponen el problema en una base de “divide y conquistarás”.

[C1] Usualmente referidos como piezas, componentes u objetos, cuya connotación es diferente en ciertos entornos, pero por simplicidad aquí son usados como sinónimos

[C2] La manera de descomponer el problema básicamente se resume en dos, estructurada u objetual

Arquitectura de Sistemas - Segunda Parte - Criterios de Definición

Las definiciones sobre arquitectura están basadas en los siguientes criterios

a) Cantidad y tipo de las estructuras tecnológicas manejadas por el arquitecto [1, 2, c1,c4],

b)Aspectos de gobierno tales como la ámbito de impacto y responsabilidades[c1,c2].

c)Complejidad funcional usando como base las coplejidades de las estructuras de software y los requerimientos [c5,c6].

El consenso no se produce dado los roles, tipos de tecnologías, estructuras conceptuales y las diferentes interpretaciones que se tienen de los anteriores conceptos. Si se toman como un todo los elementos anteriormente citados (ortogonales) es posible construir una definición que sirva para establecer las labores del arquitecto.

Cargo Cult : Siempre en guardia

Cargo cult science is a term invented by Richard Feynman to describe research that is conducted experimentally and appears to be scientific, but produces results of questionable significance due to nonscientific factors like expediency or institutional bias. Feynman introduced the phrase in a speech at Caltech in 1974 that was reproduced in the book Surely You're Joking, Mr. Feynman! : Adventures of a Curious Character (Norton, 1985) and on many web sites. He based the phrase on an existing concept in anthropology, the cargo cult. Feynman cautioned that to avoid becoming cargo cult scientists, researchers must be willing to doubt results and to investigate possible flaws in an experiment.

An example of cargo cult science would be any experiment in which another researcher's results are used in lieu of an experimental control. Since the other researcher's conditions might differ from those of the present experiment in unknown ways, different results might be unrelated to the independent variable under consideration.


http://clsdemo.caltech.edu/51/02/CargoCult.pdf