En el presente post, comparto un documento académico que hice con respecto al tema de referencia.
http://bit.ly/bfSKOR
El resumen de este documento fue posteado en
My Software Architecture Presentation
Mostrando las entradas con la etiqueta architecture. Mostrar todas las entradas
Mostrando las entradas con la etiqueta architecture. Mostrar todas las entradas
lunes, mayo 31, 2010
miércoles, marzo 10, 2010
My Software Architecture Presentation
En la actualidad no se concibe empresa grande sin soporte a sus negocios mediante el uso de las tecnologías de sistemas de información implementados dentro de la misma. Estos sistemas ayudan a manejar áreas tales como recursos humanos, ventas, compras, gestiones de procesos específicos del rubro, administración financiera, económica, tableros de comandos para la ayuda a la decisión de la gerencia etc.
Dada la criticidad de esos sistemas para el funcionamiento del negocio es imprescindible que sean construidos, implementados y mantenidos siguiendo estándares de calidad.
En este contexto se necesita un especialista que tenga una visión de negocio, habilidades técnicas y buena comunicación a los diferentes miembros del área de IT.
Estos sistemas muchas veces deben ser interconectados, es facultad del arquitecto garantizar la calidad del software desde el inicio hasta su implementación y mantenimiento.
En la siguiente presentación se resume el trabajo que analiza los aspectos relacionados con la arquitectura de software, su clasificación, el rol del arquitecto y metodologías recomendadas en pos de optimizar la integración entre sistemas.
Software Architecture Presentation
La documentación completa de esta presentación esta en el siguiente post.
Arquitectura de software, rol e integracion de aplicaciones
viernes, noviembre 06, 2009
Software Architecture and business objetives
El miercoles 4 de noviembre tuve la oportunidad de asistir a una conferencia del Phd Andres Diaz Pace (ADP) en donde presentó la metodologia del SEI para la documentación de arquitecturas de software. Al finalizar la presentación de Andrés varios panelistas hicieron sus comentarios y respondieron a preguntas de los asistentes.
A continuación voy a intentar resumir los aspectos relevantes del la presentación.
ADP comentó que hay muchas definiciones de Arquitectura de Software, entre ellas comentó la del SEI ("Software Architecture in Practice", Clements, 2008).
Entre los apsectos importantes que rescaté del seminario es que se tome en cuenta o no la arqteuictura de software siempre existe, en forma formal mediante procedimiento o informal o implicita. Es decir si no diseñamos arquitectura alguien en el proceso de desarrollo lo hará y de la mejor forma que pueda, con el peligro que ello acarrea.
Otro aspecto es el lugar de la arquitectura de software en el proceso de desarrollo, ADP mostró un proceso simplificado en donde se inicia por lso objetivos de negocios, luego los requerimientos funcionales, de allí la arquitectura de software y finalmente el sistema. Este es un proceso iterativo en donde del objetivo de negocio se deriva a especificaciones funcioanales de alli mediante diseño se contruye la arquitectura de software y luego el equipo de desarrollo la implementa.
Al grupo de arquitectura debe participar en todo el proceso de desarrollo de software teniendo mayor porcentaje de participación durante la etapa de elaboración del proceso, pero tambie´n requiere cierto grado de participación durante la etapa de incepción, transisión e implementación.
ADP considera incorrecto que el equipo se desvincule totalmente del proyecto luego de terminado el diseño arquitectónico, por eso es requerido un cierto grado de participación en la demás etapas.
Otro aspectos importante de mencioar es que el diseño arquitectónico permiti reducir los riesgos en el proyecto, pues se encarga de elicitar los atributos de calidad, validar la infraestructura, validar con áreas auxiliares (seguridad informatica, tecnología, stakholders etc). Cabe destacar que el disertantem comentó que involucrar a muchas áres implica un riesgo a la hora de documentar la arquitectura pues cada área tiene su propia visión del proyecto y puede querer incluir en la documentación aspectos que no son parte del diseño arquitectónico (tal vez si de documentación complementaria).
Se discutió sobre lo que NO es la arquitectura de software, y ADP dió algunos ejemplos como:
- No es la arquitectura del hardware.
- No es el modelo de datos.
- No es solo un diagrama de "cajitas" interconectadas.
De este último punto se desprende que por presiones varias los stakholders intentan reducir el tiempo de diseño para pasar rapidamente al momento de la implementación, por lo tanto la arquitectura dieñada tiene una visión muy general, no consdiera atributos de calidad, riesgos por el uso de tecnologías no estandares en la compañía etc.
Elicitación de atributos de calidad:
Estre los procesos recomendados por el SEI se comentó uno denominado QAW (Quality Atributte Workshop)http://www.sei.cmu.edu/library/abstracts/reports/03tr016.cfm
Este proceso tiene como fin comprometer a los stakholders para definir precisamente los atributos de calidad requeridos en el proyecto. Basicamente la técnica implica litar los atributos de calidad y leugo mediante votación se pondera cada atributos. Luego de eso se puede elimiar algunos meno prioritarios (o dejar su analisis para un posterior release) dejando solo los más importantes.
La técnica es simple, pero lo que no es simple conseguir que los stakholders se involucren en este aspecto, pues la visión de los atributos de calidad de cada uno puede diferir bastante.
Basicamente lso siguientes son los aspectos más importante de eta técnica:
- Centrado en el sistema.
- Focalizado en los stakeholders.
- Técnica implementada antes de definier la arquitectura.
Una sesión de QAW debería seguir los siguientes pasos, la misma está moderada por un facilitador, el manager del proyecto y el arquitecto. Es importante que tiene que tener un time frame definido y en la manera de lo poible obtener un consenco documentado.
1- Introduction to QAW (Manager)
2- Business Mision Presentation (Arquitecto).
3- Indetification of Architecture Drivers
4- Scenarios Bainstorming.
5- Scenarios priorization
6- Scenario refinemente
7- Return to 1.
Esta técnica permite concentrar el esfuerzo en el diseño de aspectos no funcionales para los atributos de calidad más relevantes para los stakholders del proyecto.
la técncia define que en la documentación de atributo de calidad se deben considerar los siguientes aspectos:
1- Estímulo: Es el evento de entrada.
2- Respuesta al estímulo.
3- Fuente del estimulo.
4- Condición del ambiente.
5- Medida de la respuesta.
Por ejemplo si el atributo de calidad es la performance una simplificación (hiper simplificada) para estos aspectos serían:
1- Estimulo: Request a una determinado servicio.
2- Respuesta al estímulo: Mesaje de respuesta en XML (especifica peso en Kb).
3- Fuente de estimulo: proceso X que corre en servidor Z.
4- Condición de ambiente: X% de CPU, Z Mb de memoria consumir por el servidor, I/O, Byterates etc.
5- Medida de la respuesta: Reqeust por segundo, %CPU y %memoria conumida por el proceso en cuestion etc.
En la documentaciónd el SEI existen tablas donde están tabulados varios atributos de calidad.
Consderaciones sobre documentación de arquitectura.
Debe tener un enfoque basado en vista. Cada vita mostrará difentes niveles de detalle de la arquitectura y representaciones para diferentes interlocutores (lógica, capas, implementación etc).
En la documentación se debe tener el trace entre una objetos de una vista y de otra.
Un mayor nivel de detalle reduce el tiempo dedicado al mentoring y el coaching a la hora de implementar la arquitectura. Esto no implica que se reduzca a cero pues el arquitecto participa en todo el proceso de desarrollo.
Por ejemplo en un vista en donde se quiera detallar aspectos de seguridad deber indicar zonas de seguridad, puntos de entrada, conexiones etc.
Si es por un tema de performance, incluiría vistas de procesos, interacción etc.
En la documentación del SEI se clasificar las diferentes vistas.
En resumen las vistas deben consdierar los siguientes aspectos:
1- Estructura del sistema en térmicos de unidades de código.
2- Interacciones en tiempo de ejecución.
3- Como se relacionan con estrucmturas no software.
4- Interfaces.
5- Comportamiento.
Tambien se puede ver desde tres perpectivas diferentes:
1- Módulos: Contrucción, analisis de impacto, pruebas etc
2- Componentes y conectores: performance , disponibilidad etc.
3- Asignación de responsabilidades: Diponiblidad , seguridad, performanceetc
Para evaluar la completitud de una vista hay que considerar la descripción de sus elementos constitutivos, mapeo entre vistas, deben existir diferentes vistas según perfil de stakholders, asegurarse que contengan información útil.
Evaluación de arquitecturas:
Luego de esta introducción el disertante comento sobre el proceso ATAM (Architecture Tradeoff Analysis Method) http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm
ATAM provee tendencias sobre la evaluación de la arquitectura, no aspectos precisos. Esta técnica ayuda a evaluar aspectos de la arquitectura como nivel de enfioque en el producto software, detección temprana de riesgos, prácticas de ingenieria de software, aspectos de calidad etc.
Dado qeu es un proceso complejo se sugiere efectuarlo luego de tener terminada la primera iteración de la documentación de arquitectura y luego de finalizada cada etapa de elaboración de las sucesivas iteraciones.
Un aspecto que comentó como introducción el disertante fue la técnica de diseño definida por el SEI, es la ténica ADD(Atribute-Driven Desing) http://www.sei.cmu.edu/library/abstracts/reports/06tr023.cfm
De eta descripción podrai resumir que la técnia ADD permite articular lso objetivos de negocio con la arquitectura, mitigar riesgos y se considera en todo el proceso de desarrollo.
Como conslusión ADP mencionó que en el futuro próximo es importante considerar istemas que requieran gran escalabilidad (ej Facebook) o gestionados con recursos no cetralizados (ej Eclipse).
Finalmente el SEI tiene su blog en donde la comunidad puede participar
Saturn Netwotk Blog
A continuación voy a intentar resumir los aspectos relevantes del la presentación.
ADP comentó que hay muchas definiciones de Arquitectura de Software, entre ellas comentó la del SEI ("Software Architecture in Practice", Clements, 2008).
Entre los apsectos importantes que rescaté del seminario es que se tome en cuenta o no la arqteuictura de software siempre existe, en forma formal mediante procedimiento o informal o implicita. Es decir si no diseñamos arquitectura alguien en el proceso de desarrollo lo hará y de la mejor forma que pueda, con el peligro que ello acarrea.
Otro aspecto es el lugar de la arquitectura de software en el proceso de desarrollo, ADP mostró un proceso simplificado en donde se inicia por lso objetivos de negocios, luego los requerimientos funcionales, de allí la arquitectura de software y finalmente el sistema. Este es un proceso iterativo en donde del objetivo de negocio se deriva a especificaciones funcioanales de alli mediante diseño se contruye la arquitectura de software y luego el equipo de desarrollo la implementa.
Al grupo de arquitectura debe participar en todo el proceso de desarrollo de software teniendo mayor porcentaje de participación durante la etapa de elaboración del proceso, pero tambie´n requiere cierto grado de participación durante la etapa de incepción, transisión e implementación.
ADP considera incorrecto que el equipo se desvincule totalmente del proyecto luego de terminado el diseño arquitectónico, por eso es requerido un cierto grado de participación en la demás etapas.
Otro aspectos importante de mencioar es que el diseño arquitectónico permiti reducir los riesgos en el proyecto, pues se encarga de elicitar los atributos de calidad, validar la infraestructura, validar con áreas auxiliares (seguridad informatica, tecnología, stakholders etc). Cabe destacar que el disertantem comentó que involucrar a muchas áres implica un riesgo a la hora de documentar la arquitectura pues cada área tiene su propia visión del proyecto y puede querer incluir en la documentación aspectos que no son parte del diseño arquitectónico (tal vez si de documentación complementaria).
Se discutió sobre lo que NO es la arquitectura de software, y ADP dió algunos ejemplos como:
- No es la arquitectura del hardware.
- No es el modelo de datos.
- No es solo un diagrama de "cajitas" interconectadas.
De este último punto se desprende que por presiones varias los stakholders intentan reducir el tiempo de diseño para pasar rapidamente al momento de la implementación, por lo tanto la arquitectura dieñada tiene una visión muy general, no consdiera atributos de calidad, riesgos por el uso de tecnologías no estandares en la compañía etc.
Elicitación de atributos de calidad:
Estre los procesos recomendados por el SEI se comentó uno denominado QAW (Quality Atributte Workshop)http://www.sei.cmu.edu/library/abstracts/reports/03tr016.cfm
Este proceso tiene como fin comprometer a los stakholders para definir precisamente los atributos de calidad requeridos en el proyecto. Basicamente la técnica implica litar los atributos de calidad y leugo mediante votación se pondera cada atributos. Luego de eso se puede elimiar algunos meno prioritarios (o dejar su analisis para un posterior release) dejando solo los más importantes.
La técnica es simple, pero lo que no es simple conseguir que los stakholders se involucren en este aspecto, pues la visión de los atributos de calidad de cada uno puede diferir bastante.
Basicamente lso siguientes son los aspectos más importante de eta técnica:
- Centrado en el sistema.
- Focalizado en los stakeholders.
- Técnica implementada antes de definier la arquitectura.
Una sesión de QAW debería seguir los siguientes pasos, la misma está moderada por un facilitador, el manager del proyecto y el arquitecto. Es importante que tiene que tener un time frame definido y en la manera de lo poible obtener un consenco documentado.
1- Introduction to QAW (Manager)
2- Business Mision Presentation (Arquitecto).
3- Indetification of Architecture Drivers
4- Scenarios Bainstorming.
5- Scenarios priorization
6- Scenario refinemente
7- Return to 1.
Esta técnica permite concentrar el esfuerzo en el diseño de aspectos no funcionales para los atributos de calidad más relevantes para los stakholders del proyecto.
la técncia define que en la documentación de atributo de calidad se deben considerar los siguientes aspectos:
1- Estímulo: Es el evento de entrada.
2- Respuesta al estímulo.
3- Fuente del estimulo.
4- Condición del ambiente.
5- Medida de la respuesta.
Por ejemplo si el atributo de calidad es la performance una simplificación (hiper simplificada) para estos aspectos serían:
1- Estimulo: Request a una determinado servicio.
2- Respuesta al estímulo: Mesaje de respuesta en XML (especifica peso en Kb).
3- Fuente de estimulo: proceso X que corre en servidor Z.
4- Condición de ambiente: X% de CPU, Z Mb de memoria consumir por el servidor, I/O, Byterates etc.
5- Medida de la respuesta: Reqeust por segundo, %CPU y %memoria conumida por el proceso en cuestion etc.
En la documentaciónd el SEI existen tablas donde están tabulados varios atributos de calidad.
Consderaciones sobre documentación de arquitectura.
Debe tener un enfoque basado en vista. Cada vita mostrará difentes niveles de detalle de la arquitectura y representaciones para diferentes interlocutores (lógica, capas, implementación etc).
En la documentación se debe tener el trace entre una objetos de una vista y de otra.
Un mayor nivel de detalle reduce el tiempo dedicado al mentoring y el coaching a la hora de implementar la arquitectura. Esto no implica que se reduzca a cero pues el arquitecto participa en todo el proceso de desarrollo.
Por ejemplo en un vista en donde se quiera detallar aspectos de seguridad deber indicar zonas de seguridad, puntos de entrada, conexiones etc.
Si es por un tema de performance, incluiría vistas de procesos, interacción etc.
En la documentación del SEI se clasificar las diferentes vistas.
En resumen las vistas deben consdierar los siguientes aspectos:
1- Estructura del sistema en térmicos de unidades de código.
2- Interacciones en tiempo de ejecución.
3- Como se relacionan con estrucmturas no software.
4- Interfaces.
5- Comportamiento.
Tambien se puede ver desde tres perpectivas diferentes:
1- Módulos: Contrucción, analisis de impacto, pruebas etc
2- Componentes y conectores: performance , disponibilidad etc.
3- Asignación de responsabilidades: Diponiblidad , seguridad, performanceetc
Para evaluar la completitud de una vista hay que considerar la descripción de sus elementos constitutivos, mapeo entre vistas, deben existir diferentes vistas según perfil de stakholders, asegurarse que contengan información útil.
Evaluación de arquitecturas:
Luego de esta introducción el disertante comento sobre el proceso ATAM (Architecture Tradeoff Analysis Method) http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm
ATAM provee tendencias sobre la evaluación de la arquitectura, no aspectos precisos. Esta técnica ayuda a evaluar aspectos de la arquitectura como nivel de enfioque en el producto software, detección temprana de riesgos, prácticas de ingenieria de software, aspectos de calidad etc.
Dado qeu es un proceso complejo se sugiere efectuarlo luego de tener terminada la primera iteración de la documentación de arquitectura y luego de finalizada cada etapa de elaboración de las sucesivas iteraciones.
Un aspecto que comentó como introducción el disertante fue la técnica de diseño definida por el SEI, es la ténica ADD(Atribute-Driven Desing) http://www.sei.cmu.edu/library/abstracts/reports/06tr023.cfm
De eta descripción podrai resumir que la técnia ADD permite articular lso objetivos de negocio con la arquitectura, mitigar riesgos y se considera en todo el proceso de desarrollo.
Como conslusión ADP mencionó que en el futuro próximo es importante considerar istemas que requieran gran escalabilidad (ej Facebook) o gestionados con recursos no cetralizados (ej Eclipse).
Finalmente el SEI tiene su blog en donde la comunidad puede participar
Saturn Netwotk Blog
miércoles, mayo 27, 2009
Microsoft Architecture Day
En el día de hoy se hizo la reunión de la Comunidad de Arquitectos de Microsoft. Fue una reunión muy interesante en la que gente de Microsoft y otra empreass presentaron sus experiencias en soluciones de sistemas utilizando las últimas tecnologías de Microsoft,también se presentaron nuevos feactures de tecnologias como Windows 7 , WPF , Siverligh etc. Los asistentes pudieron preserciar presentaciones como:
Andres Vetori y equipo de VMBC Caso de exito de un sistema con .Net 3.5 SP1, WCF, Retina.Net ,Geneva framework, AOP, IVR con Speech Server 2007 entre otra tecnologías. Fue un proyecto contruido utilizando la metodología Agile / Scrum.
Como herramientas de desarrollo utilizaron Team System con integración continua en base a Team Build y deploy con scripts de MSDeploy.
Conclusiones generadas del proyecto:
- Es deseable automatizar las implementaciones en producción
- Adaptar la metodología de desarrollo a las particularidades del proyecto.
- El merge continuo no es siempre justificable.
- Se debe tener un adecuado control de los builds y que objetos contiene cada iteración.
Recomendaciones para un exito de un proyecto de este tipo:
- Virtualización (Hiper-V).
- Equipo con buen señority.
- No reiventar la rueda (patrones, frameworks etc).
- No subestimar el test (automzatizarlo y controlar su correcta ejecución como entregable de la iteración).
- No olvidarse del monitoreo.
- Tener un adecuado procedimiento de control de cambios.
- Mantener una cultura de motivación para hacer las cosas bien hechas.
- Crear una cultura de calidad continua.
Diego Gonzales de lagash presentó una visió de las tendencias en arquitectura de software
- Arquitecturas elásticas
- Base de datos no relacionales.
- (des) orientación a servicios.
- Programación dinámica.
En el tema de arquitectura elástica se vió consideraciones sobre escalabilidad en ambientes Cloud, planificación de arquitectura y modelos de arquitectura.
Diego presentó el concepto de que las arquituras deben ser emergentes y no prescriptivas, es decir se deben diseñar en conjunto con el desarrollo del sistema.
Dentro del tema de escalabilidad horizontal existe el nuevo paradigma de Microsoft que es Azure y el sistema operativo Windows Azure, creado para aplicaciones distribuidas en infraestructura Cloud. La escalabilidad vertical ya está llegando a su límite.
Para scar provecho a este nuevo paradigma es necesario especialización en programación concurrente.
Respecto a la planificación de arquitectura Diego mencionó que en muchas ocaciones conviene que el diseño de la arquitectura sea emergente en vez de prescriptiva, haciendo participar al aquipo de desarrollo ensu definición, esto tiene la ventaja de motivarlos en la creación de la misma y el desarollo del sistema y permite un mejor refinamiento mientra se crea el sistema.
Planteó conceptos de modelado de arquitecturas que pueden ser centralizadas o satelitales.
Un tema que recordó es que por lo general es una desición por defecto que la base de datos a utilizar sea del tipo relacional, esto no siempre es una correcta elección, hay casos donde se requieren datos temporarios, no es tan exigible que sea transaccional en donde la RDBMS no resultan ser lo más apropiado. Ejemplos de uso de este tipo de base de datos son aplicaciones del tipo redes sociales como Facebook.
Las bases de datos no relacionales tienen entre otras las siguientes características:
- key-value db y document db.
- Buen soporte para lenguajes dinámicos.
- Facil cambio en la aplicación.
- Datos a-normalizados. etc.
Productos: SQL Services, Drizzle,Amazon WebServices etc.
Andres Vetori y equipo de VMBC Caso de exito de un sistema con .Net 3.5 SP1, WCF, Retina.Net ,Geneva framework, AOP, IVR con Speech Server 2007 entre otra tecnologías. Fue un proyecto contruido utilizando la metodología Agile / Scrum.
Como herramientas de desarrollo utilizaron Team System con integración continua en base a Team Build y deploy con scripts de MSDeploy.
Conclusiones generadas del proyecto:
- Es deseable automatizar las implementaciones en producción
- Adaptar la metodología de desarrollo a las particularidades del proyecto.
- El merge continuo no es siempre justificable.
- Se debe tener un adecuado control de los builds y que objetos contiene cada iteración.
Recomendaciones para un exito de un proyecto de este tipo:
- Virtualización (Hiper-V).
- Equipo con buen señority.
- No reiventar la rueda (patrones, frameworks etc).
- No subestimar el test (automzatizarlo y controlar su correcta ejecución como entregable de la iteración).
- No olvidarse del monitoreo.
- Tener un adecuado procedimiento de control de cambios.
- Mantener una cultura de motivación para hacer las cosas bien hechas.
- Crear una cultura de calidad continua.
Diego Gonzales de lagash presentó una visió de las tendencias en arquitectura de software
- Arquitecturas elásticas
- Base de datos no relacionales.
- (des) orientación a servicios.
- Programación dinámica.
En el tema de arquitectura elástica se vió consideraciones sobre escalabilidad en ambientes Cloud, planificación de arquitectura y modelos de arquitectura.
Diego presentó el concepto de que las arquituras deben ser emergentes y no prescriptivas, es decir se deben diseñar en conjunto con el desarrollo del sistema.
Dentro del tema de escalabilidad horizontal existe el nuevo paradigma de Microsoft que es Azure y el sistema operativo Windows Azure, creado para aplicaciones distribuidas en infraestructura Cloud. La escalabilidad vertical ya está llegando a su límite.
Para scar provecho a este nuevo paradigma es necesario especialización en programación concurrente.
Respecto a la planificación de arquitectura Diego mencionó que en muchas ocaciones conviene que el diseño de la arquitectura sea emergente en vez de prescriptiva, haciendo participar al aquipo de desarrollo ensu definición, esto tiene la ventaja de motivarlos en la creación de la misma y el desarollo del sistema y permite un mejor refinamiento mientra se crea el sistema.
Planteó conceptos de modelado de arquitecturas que pueden ser centralizadas o satelitales.
Un tema que recordó es que por lo general es una desición por defecto que la base de datos a utilizar sea del tipo relacional, esto no siempre es una correcta elección, hay casos donde se requieren datos temporarios, no es tan exigible que sea transaccional en donde la RDBMS no resultan ser lo más apropiado. Ejemplos de uso de este tipo de base de datos son aplicaciones del tipo redes sociales como Facebook.
Las bases de datos no relacionales tienen entre otras las siguientes características:
- key-value db y document db.
- Buen soporte para lenguajes dinámicos.
- Facil cambio en la aplicación.
- Datos a-normalizados. etc.
Productos: SQL Services, Drizzle,Amazon WebServices etc.
martes, mayo 19, 2009
¿Por qué es necesario un arquitecto de software?
“Architecture in an over used term and therefore doen’t mean anything anyway”
“Oh we don’t need training, we are Enterprise Architecture”,
“Help I need to hire architects but cannot define the role”, HR manager
“Why should I hire architects?, No one has ever made the case to me ”, CEO
“Architects just vision jockeys right?, We need coders no talkers”, developer manager
Estas frases fueron recolectadas de varias conferencias sobre arquitectura de software, encuestas y otros eventos de IT [Preiss Paul T, 2006, “Magician apprentice”] e indican en grado de confusión que existe respecto a la arquitectura de software, entonces como arquitectos es importante tener una buena respuesta a la siguiente pregunta: ¿Por qué es necesario un arquitecto de software?
Los sistemas de información soportados por aplicaciones informáticas son cada vez más comunes y en muchos casos imprescindibles para el funcionamiento del negocio de la empresa. En estas últimas dos décadas la evolución de esos sistemas fue exponencial y además los procesos son más complejos y la tecnología permite hacer más cosas en forma más sencilla y más rápida. Este aspecto tiene el riesgo de crear grandes sistemas en forma relativamente simple y rápida sin tener el adecuado control en la calidad, el costo de esto es grande a la hora de mantener el sistema, de solucionar errores y fallas y de evolucionarlo para agregar nuevas funcionalidades.
Standish Group en su “Chaos Report” describe un estudio realizado sobre mas de 175000 proyectos en donde los resultados no fueron nada alentadores. La siguiente tabla indica los valores promedios de sobre costo, exceso en tiempo y baja satisfacción de la funcionalidad del producto con los deseado.
Parámetro (exceso sobre los estimado) | % promedio |
Costo | 189% |
Tiempo | 222% |
Deficiencias en el producto final | 60% |
De los proyectos relevados solo el 12% terminó en tiempo y dentro del presupuesto asignado.
La investigación mencionada incluye el resultado de un encuesta entre algunos de los CIOs de esas empresas preguntando cuales serían los aspectos que se deberían mejorar para reducir estos indicadores en los proyectos. De esa encuesta surgió que los tres principales factores a mejorar fueron un mejor involucramiento del usuario, mejora en la administración del proyecto y tener requerimientos claros y bien documentados.
En cambio si consideraban que aspectos perjudicaban el éxito del proyecto se consideraron como prioritarios aspectos tales como malas de comunicación con el usuario, requisitos y especificaciones incompletas y cambios constantes en especificaciones y requerimientos.
De este análisis se describe que es muy importante tener una buena planificación, documentación de requisitos y especificaciones y fluída comunicación con el usuario para tener éxito en el desarrollo del software. Los cambios en las especificaciones y requisitos son imposibles de detener pues muchas veces son causa de cambios en el contexto del negocio que las crearon, por eso una buena planificación y requisitos bien documentados mitigan este riesgo, además si se trabaja con un entorno de trabajo estable, bien documentado que resuelva las tareas rutinarias, de mayor complejidad y administradas por la menor cantidad de roles posibles se mitiga en gran medida los riesgos en todas las etapas del desarrollo del software.
Por este último aspecto es que se necesito un grupo de arquitectura, pues interviene en como un grupo staff en todo el ciclo de vida del desarrollo, definiendo estándares, buenas prácticas, ofreciendo soporte, coaching al desarrollo y diseño, metodologías, frameworks (conceptúales y ejecutables): Participan también en definiciones o adopción de metodologías de desarrollo de administración de cambios que faciliten la tarea de los de más integrantes del equipo de desarrollo y de los stakeholder .
Por lo tanto necesitamos arquitectos para afrontar la complejidad de los sistemas, para ofrecer agilidad en los negocios, para reducir los costos en IT, para mejorar la alineación del área de IT en los negocios etc .
Como se habia mencionado las soluciones de software distribuidas sueles tener una alta complejidad, esa complejidad puede ser inherente a la tecnología y la especificación funcional del negocio o bien puede ser accidental. Muchos procesos de negocio presentados como complejos luego de una buen análisis se pueden simplificar, es importante recordar que los sistemas se basan en los procesos y no lo procesos a los sistemas, por lo tanto dedicarle tiempo a optimizar los procesos de negocios a ejecutar es fundamental en la etapa de inicio pues la construcción de los sistemas se basarán en esos procesos. El arquitecto debe tener la habilidad necesaria para entender el proceso, el problema y crear un modelo que se ajuste al mismo.
En cambio, la complejidad accidental está muy relacionado con las tecnologías y estilos de las arquitecturas elegidos. Una tarea muy importante que debe cumplir el arquitecto es la determinación de aspectos no funcionales de la arquitectura, tales como flexibilidad al cambio, mantenimiento, escalabilidad, reusabilidad, usabilidad, monitores, performance , seguridad etc.
Cuando se tienen definidos estándares de calidad no funcionales y restricciones tecnológicas impuestas por políticas de la compañía muchas veces la arquitectura puede ser más compleja porque se debe alinear a las mismas.
Además tiene que considerar políticas tales como restricciones debido a estándares externos, como por ejemplo SOX , internos de negocios , regulaciones gubernamentales etc.
El cumplimiento de estos conceptos permite reducir costos de IT, mejorar la satifacción del cliente interno proveyendo para el primer caso mejores herramientas que faciliten las tareas del personal de la empresa dedicada a la operatoria diaria del negocio y áreas relacionadas. Estas mejoras también benefician a los clientes externos puer les permite disponer de mayor control en sus pedidos, despachos de los productos adquiridos.
Suscribirse a:
Entradas (Atom)