Actualidad

Que es Arquitectura Empresarial

No comments

Algo que se hace a la organización o es un quehacer de la organización.

En muchas publicaciones y sitios de internet figuran diversas definiciones de la arquitectura empresarial, personalmente cuando inicie el recorrido en este tema, quede despistado ante la variedad de las definiciones y explicaciones de para qué es la Arquitectura Empresarial, incluso algunas de ellas se complementaban, otras se contradecían y provenían de diversas fuentes de profesionales y de agremiaciones como la asociación de todos los arquitectos de TI (IASA), o de consorcios de la industria del software como el Open Group.

El ánimo de este artículo, más que agregar una definición más a ese diverso conjunto, o entrar a juzgar,  discrepar o ser dogmático, es compartir el entendimiento que he ido articulando sobre el tema a lo largo de estos años, pues me ha sido útil en la experiencia práctica de consultoría en Arquitectura Empresarial.

Una de las preguntas que me surgieron en este proceso fue: ¿hay un estándar de Arquitectura Empresarial?, pues en la ISO hay estándares para requerimientos de software, para seguridad de la información, habrá alguno de Arquitectura Empresarial?.  Lo que encontré es que no existe un estándar específico de Arquitectura Empresarial por lo menos en la ISO.

La otra pregunta que me surgió es que envergadura tiene el aval de alguien como la IEEE?, la IASA, o incluso la misma ISO?

Empiezo por responder esta última.

Envergadura de la IEEE: http://www.ieee.org/ Qué significa IEEE? Institute for Electrical and Electronics Engineers. Originada en los 1884 en los Estados Unidos con la AIEE y LA IRE que convergen formando la IEEE en 1963 con más de 150.000 miembros, al cierre del 2014 asociados alrededor de 426.000 en más de 160 países y con el 50% de ellos fuera de los Estados Unidos. Tiene más de 1.300 estándares activos.

Envergadura de la IASA: http://iasaglobal.org/  Qué significa IASA? International Associaton for Software Architects, hoy llamada Iasa Global, para asociar a todos los arquitectos de IT. Establecida en el 2002, asociados alrededor de 80.000, en 50 países diferentes, como tal no tiene estándares, lo que tiene es la compilación de las mejores prácticas en el llamado ITABoK (IT Architect Body of Knowledge)

Envergadura de la ISO: http://www.iso.org/iso/home.html . Qué significa ISO? Organización Internacional para la Estandarización, es una federación de alcance mundial integrada por cuerpos de estandarización nacionales de 153 países, uno por cada país.
Es una organización no gubernamental establecida en 1947. La misión es promover el desarrollo de la estandarización y las actividades con ella relacionada en el mundo con la mira en facilitar el intercambio de servicios y bienes, y para promover la cooperación en la esfera de lo intelectual, científico, tecnológico y económico.

Todos los trabajos realizados por la ISO resultan en acuerdos internacionales los cuales son publicados como Estándares Internacionales.

Entonces respecto a la Arquitectura Empresarial hay un estándar? Lo que halle es que no hay UN estándar de arquitectura empresarial. Lo que hay es un estándar de arquitecturas de sistemas por parte de la ISO.

El estándar de arquitectura existente en la ISO es el 42010:2011.

Este estándar tiene su origen desde el año de 1995 en la IEEE, con la creación del comité de estándares de ingeniería de software donde luego de cinco años y revisdado y aprobado por 130 revisores internacionales se publica IEEE-1471:2000. Luego de seis años más es adoptado por la ISO, la cual lo publica en el 2007 como ISO 42010:2007 y su última revisión, a la fecha de este escrito, es en el año 2011. ISO 42010:2011: Systems and software engineering—Architecture description.

Que establece este estándar de arquitectura?

El estándar direcciona la creación, análisis y sostenibilidad de las arquitecturas de sistemas a través del uso de descripciones de arquitectura. Establece un modelo conceptual de las descripciones de arquitectura. Especifica el contenido requerido de una descripción de arquitectura. Introduce los puntos de vista de arquitectura, los frameworks de arquitectura y los lenguajes de descripción de arquitectura para codificar las convenciones y las prácticas comunes de la descripción de arquitectura. Especifica el contenido requerido de los puntos de vista de arquitectura, los frameworks y los lenguajes de descripción.

Del estándar de arquitectura enfatizo los siguientes elementos:

Definición de arquitectura: Los conceptos o propiedades fundamentales de un sistema en su ambiente embebidos en sus elementos, relaciones y en los principios de su diseño y evolución.

Definición del hacer arquitectura (Architecting): El proceso de concebir, definir, expresar, documentar, comunicar, certificar la apropiada implementación de, mantenimiento y mejora de una arquitectura a través de un ciclo de vida del sistema.

Definición de Stakeholder: Individuos, equipo, organización o clases de ellos que tienen intereses en un sistema.

Definición de Concern: Interés en un sistema relevante a uno o más de sus stakeholders.

Definición de punto de vista de arquitectura: Producto de trabajo que establece las convenciones para la construcción, interpretación y uso de las vistas de arquitectura para enmarcar concerns específicos del sistema.

Definición de vista de arquitectura: Producto de trabajo que expresa la arquitectura de un sistema desde la perspectiva de concerns específicos del sistema.

Enfatizo estos elementos pues desde este estándar, el hacer arquitectura es un proceso de concebir, es decir, crear algo que antes no existía, que requiere pensamiento creativo. Y se concibe para atender las necesidades manifiestas (concern) de unos interesados (stakeholders).

El estándar explícitamente manifiesta que no prescribe el proceso o el método a usar para producir las descripciones de arquitectura, que no asume ni prescribe métodos de arquitectura, modelos, notaciones o técnicas usadas para producir descripciones de arquitectura.

Y entonces la Arquitectura Empresarial que?

Respecto a la Arquitectura Empresarial no existe a la fecha de este escrito un estándar tipo ISO establecido para ello, lo que encuentro que hay son abordajes de la práctica de la arquitectura empresarial y dependiendo del abordaje existen interpretaciones del sentido, propósito y razón de ser de la práctica de la arquitectura empresarial.

Del conjunto de abordajes los categorizo en tres tipos que denomino ontológico, práctico,  y asesor tecnológico.

El abordaje de carácter ontológico está orientado a la descripción del “ser en cuanto ser” de forma que al tener todo el “mapa” desde la estrategia: misión, visión hasta la operación: cadena de valor, procesos, funciones de negocio,  y la tecnología: datos, aplicaciones e infraestructura de tecnología, será posible tomar mejores decisiones y ponderar si tecnología está alineada o no con el negocio. En este abordaje los términos AS-IS y  TO-BE son los típicos para esa descripción y evaluación del “ser” de la organización. El framework de Zachman tiene mucho de este abordaje.

El abordaje de carácter práctico, está orientado a establecer una “forma o manera de…”, es adherir una capacidad para hacer las cosas de una forma diferente. Este abordaje está muy en sintonía con el estándar ISO 42010:2011, pues lo que ofrece es una manera disciplinada y formalmente estructura de atender las necesidades  (concern) que tienen las organizaciones. Aquí tiene su razón de ser frameworks como el de TOGAF del Open Group, con su método ADM – Architecture Development Method, que es aplicable de manera genérica y adaptable para cada organización que lo quiera adoptar. En este abordaje los términos usados son BASELINE y TARGET los cuales articulan las arquitecturas desde la óptica del concern que se está atendiendo en el ejercicio de arquitectura empresarial.

El abordaje de asesor tecnológico, está orientado a proveer a la organización de aquellos proyectos de tecnología que apoyan, apalancan o impulsan el cumplimiento de la misión y la visión. El quehacer de la arquitectura es ofrecer esos proyectos con componente de tecnología, luego de haber recopilado, analizado y valorado la organización. En este abordaje estarían agremiaciones como la asociación internacional de arquitectos de software,  IASA con su recopilación de prácticas de arquitectura.

Considero clave para las organizaciones que están tomando en cuenta la arquitectura empresarial, definir de forma explícita el abordaje que asumen respecto a la arquitectura empresarial, que puede ser cualquiera de los tres catalogados, o incluso combinación o mezclas de ellos, pues de esa definición se derivan los elementos propios de la práctica misma de la arquitectura empresarial, sus roles, responsabilidades, alcance, gobierno de la arquitectura y la integración con otras prácticas como ITIL, COBIT, PMI.

Para finalizar reitero que el   ánimo de este artículo, más que agregar una definición más a ese diverso conjunto, o entrar a juzgar,  discrepar o ser dogmático, era compartir el entendimiento que he ido articulando sobre el tema a lo largo de estos años, y  fuera útil en la comprensión y la práctica de la Arquitectura Empresarial.

Bibliografía:

http://www.ieee.org/

http://iasaglobal.org/

http://www.iso.org/iso/home.html

http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508

ISO/IEC/IEEE 42010:2011:ISBN 978-0-7381-7142-5 STD97174 (PDF); © ISO/IEC 2011 – All rights reserved

 

 

 

adminQue es Arquitectura Empresarial
Ver más

Dificultades en el desarrollo de Software

En qué consiste la dificultad del desarrollo de software?

La complejidad del desarrollo de software en las siguientes causas raíz:

–          El software es un intangible difícil de visualizar su avance, en particular lo referente a arquitectura. Cuando se está mandando hacer una obra civil, sea una casa o un puente, como usuario puedo ver cómo está avanzando la estructura y la obra en sí. Si existe una relación o un cambio de estructura es más fácil de visualizar con todos los implicados. En software el avance es difícil de medir: una pantalla no necesariamente demuestra el avance o la dificultad que hubo en generarla.

–          El software está lleno de relaciones difíciles de controlar, por su cantidad o por su sutilidad. Los requerimientos están relacionados entre sí, de forma que es muy difícil de mantener en mente, ni mucho menos en la vista. El diseño está relacionado entre sí, y las líneas de código también tienen sus propias relaciones. Las relaciones son fuertes y sutiles, dando siempre la posibilidad que un cambio en requerimientos, diseño o código lleve a consecuencias que no se podían prever. Esto también causa dificultad para probar el software.

–          La base del desarrollo es la comunicación entre diferentes personas de distintos perfiles: cliente, usuarios, analistas de requerimientos, arquitectura, diseñadores y desarrolladores, probadores, analistas de pruebas, personas de soporte y operación. La comunicación tiene tanta variabilidad que hay posibilidad de ambigüedades y diferencias de interpretación dependiendo del paradigma que cada uno tenga en la cabeza.

–          El desarrollo es difícil de estimar por la cantidad de variables incluidas: interpretaciones de requerimientos, retos tecnológicos, cambios en los requerimientos por desconocimiento, por modificaciones en el negocio o por entendimiento del negocio.

–          La probabilidad de cambio de los requerimientos es muy alta, dado que los negocios son cambiantes lo que ocasiona que las prioridades y las características del software

Todo esto se agrava entre más grande sea un proyecto porque hay más requerimientos (con sus relaciones) y más personas involucradas.

 

Y las metodologías realmente ayudan?

Las metodologías recogen de forma organizada mejores prácticas demostradas en la industria para su correcta aplicación. No están hechas para llenar de formatos el proyecto, ni para certificar la empresa.

La correcta aplicación de una metodología significa llevar las mejores prácticas al día a día del proyecto, y hacer que mejore la satisfacción del usuario y el valor que el negocio recibe.

 

El desarrollo de software es un juego de equipo, con los retos que significa hacer que un equipo juegue de forma coordinada y con resultados. Haciendo la comparación con algún equipo deportivo, la metodología nos dice los roles de los jugadores, las posiciones de los mismos y que se espera de cada uno de ellos. Son diferente las jugadas y los roles de un equipo de microfútbol, a un equipo de futbol de campo, así como son distintos los roles para proyectos pequeños, a los medianos y los grandes.

Dentro de la misma cantidad de jugadores también es diferente la forma como se aproxima al triunfo del partido. Por ejemplo, en voleibol existen las técnicas de seis largo, la de seis corto, la de dos bloqueadores o la de uno solo. Dependiendo del conocimiento del equipo y sus habilidades, el técnico decide utilizar la forma más apropiada.

Pero no se puede esperar que con sólo una vez que el técnico “capacite” a sus jugadores, las personas sepan ya cómo es que deben interactuar entre ellos. Para que haya un buen equipo, hay que practicar, fallar, corregir y volver a practicar. Una jugada se practica y se corrige, hasta que salga adecuadamente. Además, las jugadas dependen del tipo de juego, del contrincante y del momento en el partido.

Posiblemente, en nuestros equipos de desarrollo de software no tenemos tanto espacio para practicar tantas veces. Pero es necesario practicar y corregir, sobre la misma técnica de jugada. Comúnmente, se inicia un proyecto con cierta técnica (metodología) y como el equipo no es productivo inmediatamente, entonces la metodología no funciona!!. ( Es como decir que la técnica de seis largo no funciona para el voleibol ) Y la conclusión es que se debe cambiar por la siguiente metodología de moda que está en la lista del momento, o simplemente dejar de intentarlo y seguir en el caos y la presión constante. Para la correcta implementación de una metodología se requiere de practica entre sus integrantes, que cada uno entienda su rol realmente, y entienda lo que se espera de él y de las otras personas. Cuando digo entender, no me refiero a tomar un curso o leer un libro, sino practicar hasta que quede aprehendido y se vuelva un hábito.

Una metodología funciona correctamente no cuando su documentación está con todos los formatos, sino cuando sus principios son llevados adecuadamente, cuando cada una de las personas del equipo realiza correctamente su rol, entiende lo que espera del resto de las personas y es clara la forma de comunicarse con ellas. No es que se necesite demasiado tiempo para su implementación, lo que se requiere es compromiso de parte de las directivas y también por el equipo.

El resultado es el aumento de productividad en muy buenas dimensiones

adminDificultades en el desarrollo de Software
Ver más