jueves, 5 de septiembre de 2013

Introducción a la arquitectura empresarial


La Arquitectura Empresarial es una disciplina que busca integrar de manera armónica la estrategia de la empresa, los procesos de la empresa, y las aplicaciones e infraestructura tecnológica que los soportan. En esta disciplina la empresa es considerada un sistema, y como tal, tiene una arquitectura (ver http://arquitecturati.rainconcept.com/2013/06/que-es-arquitectura-de-sistemas-de.html) que puede ser documentada, planeada y utilizada para la construcción y evolución del sistema.

Las empresas que adoptan iniciativas de Arquitectura Empresarial generalmente desean tener un proceso planeado y controlado para hacer cambios estructurales en su operación y estrategia, o un proceso controlado para planear su evolución y crecimiento soportado en la tecnología.

Marcos de trabajo para arquitectura empresarial


En general los dos grandes motivadores del surgimiento de una disciplina de arquitectura empresarial fueron:

- La complejidad de los sistemas información que crecía de manera exponencial.
- La falta de alineación entre los sistemas de información y las necesidades de la empresa.

A finales de los 80 ya eran evidentes los problemas derivados de estas dos realidades y es así como en 1987 aparece la primera propuesta de arquitectura empresarial, con el Marco de Zachman[08], que es una taxonomía que permite clasificar diferentes artefactos de arquitectura (los artefactos son los documentos, modelos, análisis o un entregable tangible en la documentación de la arquitectura). Posteriormente, en  1994, surge, impulsado por el gobierno de U.S., el "Technical Architecture Framework for Information Management" (TAFIM) [09], que era una marco de trabajo para arquitectura empresarial. Este marco de trabajo motivó al congreso de U.S. a institucionalizar una disciplina de arquitectura empresarial para racionalizar, planear y ordenar las inversiones en tecnología en las diferentes agencias del gobierno federal.

En 1998, se remplazó el TAFIM por el Federal Enterprise Architecture Framework [10] (FEAF). TAFIM luego fue entregada al The Open Group, que la retomo, y creó el The Open Group Architectural Framework [11] (TOGAF), que actualmente se mantiene como uno de los frameworks más populares para arquitectura empresarial. Por otro lado, FEAF evolucionó en el Federal Enterprise Architecture (FEA) que es mantenido por the Office of Management and Budget (OMB) de U.S.

A partir de estas propuestas las agencias del gobierno estadounidense adoptaron iniciativas de Arquitectura empresarial con resultados en gran proporción fallidos (ver [1,2,3,4]) y múltiples críticas han surgido sobre los resultados y enfoque de estas iniciativas (http://itknowledgeexchange.techtarget.com/total-cio/two-it-gurus-face-off-on-value-of-enterprise-architecture-frameworks/). En mi opinión muchos de los problemas que han surgido con las implementaciones se debe al enfoque exclusivo en la documentación como eje central de los procesos de arquitectura. Esto ha dado cabida a que nuevas propuestas más pragmáticas hayan surgido. En particular, Gartner [05] promueve la arquitectura empresarial como un "verbo" y no como un sustantivo, indicando una aproximación práctica y basada en el conocimiento del negocio, y de las tecnologías de información.  De manera similar las propuesta de Ross, Weil y Robertson [06] se enfoca en utilizar la Arquitectura empresarial como un motor de la estrategia empresarial.

A pesar de los resultados ambiguos de estás técnicas, es claro para mi que a medida que los sistemas se vuelven más complejos, es necesario adoptar mecanismos de planeación y control para poder mantenerlos, evolucionarlos y explotarlos de manera efectiva. Así, a medida que las empresas crecen necesitarán mejores herramientas para la planeación, diseño y evolución. Por esto, creemos firmemente que todas las empresas  se beneficiarán de una disciplina de arquitectura empresarial.

Conclusiones y lectura sugerida

En este artículo se introduce a los lectores a la disciplina de la arquitectura empresarial, mostrando cómo es utilizada, su evolución histórica y discutiendo su efectividad según lo reportan diferentes organizaciones que han realizado implementaciones. En el artículo motivamos la complejidad de los sistemas y la falta de alineación con las necesidades de negocio, como los dos principales motivadores para el surgimiento de la disciplina. Igualmente, argumentamos que las nuevas propuestas que tienen un enfoque más pragmático parecen más acertadas y direccionadas a la obtención de un valor real en la empresa.

Una introducción más detallada a la disciplina de arquitectura empresarial la pueden encontrar en "A Comparison of the Top Four Enterprise-Architecture Methodologies"[07] por  Roger Sessions (http://msdn.microsoft.com/en-us/library/bb466232.aspx).

Referencias:

   * [01] Information Technology: FBI Is Taking Steps to Develop an Enterprise Architecture, but Much Remains to Be Accomplished. GAO-05-363. September 9, 2005.
   * [02] DOD Business Systems Modernization: Long-Standing Weaknesses in Enterprise-Architecture Development Need to Be Addressed. GAO-05-702. July 22, 2005
   * [03] Homeland Security: Progress Continues, but Challenges Remain on Department's Management of Information Technology, Testimony Before Congressional Subcommittees, Randolph C. Hite, Director, Information Technology Architecture and Systems Issues. GAO. March 29, 2006
   * [04] Business Modernization: Some Progress Made Toward Implementing GAO Recommendations Related to NASA's Integrated Financial Management Program. GAO-05-799R. September 9, 2005
   * [05] James, Greta A., Robert A. Handler, Anne Lapkin, and Nicholas Gall. "Gartner Enterprise Architecture Framework: Evolution 2005." October 25, 2005. Gartner ID: G00130855
   * [06] Jeanne W. Ross, Peter Weill, and David C. Robertson. Enterprise architecture as strategy. Harvard Business School press. 2006.
   *  [07]Roger Sessions. A Comparison of the Top Four Enterprise-Architecture Methodologies.  (http://msdn.microsoft.com/en-us/library/bb466232.aspx). visitado el 5 de Septiembre de 2013.
   * [08] Zachman, J.A. "A Framework for Information Systems Architecture." IBM Systems Journal, Volume 26, Number 3, 1987.
   * [09] U.S. Department of Defense. Technical Architecture Framework for Information Management (TAFIM) Volumes 1-8. Version 2.0. Reston, VA: DISA Center for Architecture, 1994.
   * [10] The Chief Information Officers Council A04. Federal Enterprise Architecture Framework Version 1.1. September 1999.
   * [11] www.opengroup.org/togaf

miércoles, 26 de junio de 2013

¿Qué es arquitectura de sistemas de información?

La ambigüedad en la definición del rol del arquitecto y el rol de la  arquitectura en los proyectos de sistemas de información ha generado y  genera múltiples controversias, rechazos y mal entendidos. Es común, por ejemplo, encontrar controversias por la diferencia entre arquitectura y diseño de sistemas,  y por el valor del rol del arquitecto dentro de un proyecto de implementación. Muchas de las controversias se han dado por la visión que la industria ha creado del arquitecto como alguien alejado de las realidades de implementación de los proyectos, que solo se encarga de crear conceptos de alto nivel que luego no son aplicables.

En este artículo exploramos definiciones de la industria para estos conceptos y fijamos posiciones sobre el rol real que deben desempeñar los arquitectos de sistemas y su valor en los proyectos de implementación.

Arquitectura de sistemas

Para iniciar las discusión partamos de la definición de un sistema como un conjunto de componentes interconectados que interactuán para cumplir con un propósito. Esta definición, incluye los sistemas que tienen componentes de software, componentes de hardware, procesos y actores humanos o artificiales para llevar a cabo sus propositos. En este sentido un sistema se refiere a cualquier cosa natural o artificial en la que estemos interesados, por ejemplo, el cuerpo humano, una ciudad, la economía o un sistema de información.

A partir de esta concepción de sistema podemos parafrasear la definición de arquitectura que se da en el estándar IEEE 1471 (Este estándar fue luego remplazado por el ISO/IEC/IEEE 42010, sin embargo preferimos las definiciones originales encontradas en el 1471, porque las consideramos menos ambiguas), así la definición de arquitectura es la siguiente:

Arquitectura: es la organización fundamental de un sistema encarnada por: sus componentes, las relaciones entre estos y con su entorno, y los principios que gobiernan su diseño y evolución.

Esta definición presenta dos elementos importantes. el primer elemento, se refiere al uso de la palabra "sistema" de manera genérica para que sea remplazada luego por el sistema de interés, ya sea un sistema de software, un sistema de hardware , un sistema de sistemas o una empresa. El segundo elemento, es la separación directa de la arquitectura de un sistema y la descripción de esta arquitectura. Es decir, la definición plantea que todo sistema tiene una arquitectura, así esta no se haya documentado. Igualmente, es importante destacar que la definición claramente plantea que la arquitectura de un sistema incluye y determina los principios de diseño y evolución, así estos no estén documentados.

El rol del arquitecto

Ya que tenemos una definición de arquitectura pasamos a definir el rol del arquitecto. Tomamos como punto de partida  la definición de arquitecto obtenida del diccionario Merriam-Webster en línea:

"Definition of ARCHITECT
1 : a person who designs buildings and advises in their construction
2 : a person who designs and guides a plan or undertaking <the architect of American foreign policy>
...

Origin of ARCHITECT
Middle French architecte, from Latin architectus, from Greek architektōn master builder, from archi- + tektōn builder, carpenter — more at technical
First Known Use: 1563"

La definición anterior ya muestra elementos relevantes para encontrar una definición de arquitecto de sistemas. El primer elemento es que el arquitecto es el que diseña edificios y asesora en su construcción (insinuando una relación directa entre el diseño y la arquitectura). El segundo elemento es el origen etimológico de la palabra "arquitecto", el cuál viene de maestro constructor o maestro carpintero. Estos dos elementos nos dan pie a dar una definición concreta del rol de arquitecto de sistemas de información:

Arquitecto: Persona o grupo de personas formadas, capacitadas y licenciadas para planear, diseñar y supervisar la construcción de sistemas.

Esta definición se aleja de la visión del arquitecto de "alto nivel" y le da un rol activo en todas la etapas de implementación de un sistema de información. Igualmente, esta definición se aleja de la visión que le da un rol de generador de documentos que no son luego consumidos en los proyectos de implementación.

Es de anotar que un error muy común en los proyectos de implementación de sistemas de información es considerar al arquitecto como una persona. En nuestra experiencia el rol de arquitecto es completado por múltiples personas, entre las cuales hay gente del negocio, gerentes de proyectos e ingenieros de sistemas. Y es muy importante resaltar que el rol de arquitecto puede ser desempeñado  por un equipo.

Para terminar esta discusión sobre el rol del arquitecto mencionó una de las características que muchos autores han identificado como fundamental en el rol del arquitecto. Esto es la responsabilidad de encontrar un consenso entre múltiples interesados (stakeholders), ya sean de negocio, técnicos o externos al sistema.

Conclusiones y lecturas sugeridas

En este artículo discutimos el concepto de arquitectura y el rol del arquitecto. La arquitectura la definimos como una característica intrínseca de todo sistema que esta encarnada en sus componentes, sus relaciones y los principios que gobiernan su diseño y evolución. En la definición hacemos una separación de la arquitectura de un sistema y la descripción de esa arquitectura. Respecto al rol de arquitecto, aclaramos que en la mayoría de proyectos este rol se ejecuta por un equipo  y definimos el rol como la persona o grupo de personas formadas, capacitadas y licenciadas para planear, diseñar y supervisar la construcción de sistemas.

En el artículo adoptamos una visión práctica del arquitecto y de la arquitecta, buscando siempre describir conceptos que son fácilmente aplicables a la realidad diaria de proyectos de implementación de sistemas de información. Por esto, nos alejamos de la visión del arquitecto de "alto nivel" que todo lo controla y diseña, y adoptamos una visión más dinámica y comprometida con el éxito de los proyectos. Igualmente, nos alejamos de la visión del arquitecto documentador que tanto daño le ha hecho a la práctica del arquitecto de TI.

Para terminar les recomiendo un libro  y un artículo. El libro es "The Process of Software Architecting" de Peter Eeles y Peter Cripps (enlace del libro en amazon). El libro es escrito por ingenieros de IBM (™) con amplia experiencia, y evita muchas de las confusiones y discusiones inocuas que otros autores han generado por las descripciones ambiguas sobre la arquitectura y la documentación de arquitecturas. Respecto al artículo, es una reseña sobre una interesante discusión entre Vivek Kundra, el CIO de Estados Unidos en 2012,  y Zachman, el creador de un reconocido framework para arquitectura empresarial. El tema de la discusión es la documentación innecesaria e impráctica que algunos han asumido como rol de los arquitectos empresariales (enlace al artículo).

martes, 25 de junio de 2013

Bienvenida y presentación de nuestro blog


Para Rain Concept es un placer invitarlos cómo lectores de nuestro nuevo blog de Arquitectura de sistemas de información. Este blog discute temas relacionados con la planeación, especificación, arquitectura, diseño e implementación de sistemas de información. En particular nos enfocamos en describir nuevas tendencias y conceptos relacionados con la arquitectura de sistemas.

Los contenidos del blog corresponden a la experiencia y opiniones que los consultores de Rain Concept han obtenido de su trabajo en proyectos reales con sistemas empresariales.

A continuación encontrará una lista de los temas que tenemos planeados para las próximas semanas:

- ¿Qué es arquitectura de sistemas de información?. Este artículo discute la arquitectura de sistemas de información como disciplina, revisando, el rol del arquitecto, la definición de arquitectura y los usos prácticos de una disciplina de arquitectura.

- Introducción a la arquitectura empresarial. En este artículo se desmitifica la disciplina de "Arquitectura Empresarial", presentando una visión estratégica de la disciplina y describiendo que métodos utilizan las áreas de TI para adoptar esta visión estratégica.

- Del diseño a la arquitectura empresarial (una visión histórica). Se presenta una visión histórica de la evolución de nuestros métodos para la implementación de sistemas y el interés en sistemas cada vez más complejos.

- ¿Porqué fracasan los modelos de tercerización basados en fábricas de software?

- ¿Cómo estructurar un área de tecnología soportada en tercerización de procesos?

- Documentando arquitecturas de sistemas.

- Introducción a TOGAF y otros marcos de trabajo para la documentación de arquitecturas empresariales.

- Principios de diseño de sistemas de información.

- Arquitecturas de alta disponibilidad: De los sistemas RAID a las arquitecturas de alta disponibilidad en Amazon WS.

- Patrones de arquitecturas seguras para empresas que adoptan soluciones en la nube

Espero que disfruten los contenidos de este blog.

Bienvenidos!
Luis Daniel Benavides N,
CEO, Rain Concept SAS