Planteamientos de arquitectura
Aunque la arquitectura de un sistema puede tomar muchas rutas e implicar otros planteamientos y métodos, algunos principios clave son comunes a todas las iniciativas modernas y correctas de arquitectura de ArcGIS. Esta sección del marco Well-Architected Framework incluye varios temas de arquitectura más tradicionales relacionados con la separación de software y hardware, consideraciones sobre la nube o planteamientos sobre la integración. Sin embargo, la amplitud de los temas adicionales ilustra cómo el rol de un arquitecto de empresa o de sistemas ha cambiado, y los resultados de las actividades de arquitectura también, para esperar nuevos conocimientos, temas y consideraciones. El objetivo de estas recomendaciones es proporcionar una buena línea base de planteamiento, no un conjunto específico de pasos y resultados.
En primer lugar, es fundamental adoptar un planteamiento centrado en la empresa. ¿Qué significa esto en la práctica? En esencia, esto significa que la arquitectura debe diseñarse principalmente para respaldar los flujos de trabajo específicos, las funcionalidades empresariales o los resultados que la organización necesita que se completen. En lugar de poner el énfasis en áreas como el rendimiento, la disponibilidad, la tecnología de implementación o las extensiones del producto de forma individual, todas estas decisiones deben basarse en cuál es la demanda empresarial de esa capacidad o funcionalidad. Este planteamiento basado en la demanda conduce a sistemas que respaldan primero las funcionalidades primarias y luego crecen eficazmente para aumentar el impacto y la adopción en toda una organización.
En segundo lugar, es importante seguir una metodología de desarrollo de arquitecturas (ADM). Existen muchas ADM diferentes y no hay una única opción mejor, pero en la medida de lo posible debería alinear los proyectos de arquitectura con el método más utilizado dentro de su organización. El uso de planteamientos que se alineen con la forma en que se arquitecturan otros sistemas facilitará la comunicación de los requisitos del sistema, la integración de otras orientaciones arquitectónicas y, finalmente, la obtención de la aprobación o el apoyo de otras partes de la organización. Esto se extiende a la implicación de los arquitectos informáticos y empresariales de otras partes de la organización siempre que sea posible.
En tercer lugar, céntrese en diseñar para la flexibilidad en lugar de hacer hincapié en un tamaño de hardware o una definición física perfectos. Mientras que el desembolso de capital de la adquisición de hardware impulsó el coste del proyecto durante muchos años (y aún lo hace en algunas organizaciones), el amplio acceso a la virtualización y a la computación en nube ha reducido la importancia de los compromisos precisos de hardware durante la fase de arquitectura. Cambiar el cómputo, la memoria o el almacenamiento de un sistema suele ser ahora más sencillo, y significativamente más rentable, que en las arquitecturas más tradicionales, lo que sugiere que unos perfiles de hardware flexibles y poco definidos son suficientes para la mayoría de las arquitecturas. Muchas organizaciones seguirán buscando una recomendación firme sobre el dimensionamiento inicial de un sistema, y estos sistemas o aplicaciones siguen siendo responsables de los costes continuos de estos sistemas. En resumen, equilibrar cuidadosamente una estimación inicial razonable con los cambios potenciales provocados por el crecimiento del uso, las nuevas entidades o las nuevas comunidades de usuarios es una tarea importante que debe tener en cuenta un arquitecto.
Nuevas áreas de requisitos han agregado importancia a un planteamiento arquitectónico estructurado, como la seguridad, las integraciones empresariales, la soberanía de los datos u otros temas que pueden no haber destacado en casos más tradicionales. Estos requisitos pueden repercutir en el diseño de la solución, las elecciones de hardware y la filosofía general de administración de un proyecto o sistema, y son igual de importantes que los requisitos funcionales o basados en el rendimiento que tradicionalmente han impulsado las elecciones de arquitectura.
Entre las prácticas recomendadas adicionales para la arquitectura de sistemas ArcGIS se incluyen:
- Ser ágil: con dinámicas cambiantes, cambios en los requisitos durante y después de la fase de diseño y cambios en la dirección de la estrategia de TI de su organización.
- Ser reactivo: consulte periódicamente con las partes interesadas los éxitos (y los desafíos) de una arquitectura y sugiera cambios que respondan a sus peticiones, ya sea para una funcionalidad nueva y mejorada o para cambios en una funcionalidad no deseada.
- Ser intencionado: cuando se requieran cambios, sea claro sobre el impacto, el tiempo y los efectos en los usuarios. Coordinar cuidadosamente los cambios de arquitectura reduce la confusión, mejora la confianza de los usuarios en el sistema y aumenta las probabilidades de obtener resultados correctos.
El proceso de arquitectura
En el diseño de sistemas con ArcGIS, muchas organizaciones siguen pasos similares en un proceso estructurado, que suele depender de la metodología de desarrollo de arquitecturas (ADM) que se esté utilizando. Para proporcionar un contexto adicional, se trata de ejemplos de fases de arquitectura con algunos detalles específicos de ArcGIS.
- Establecer un marco y unos principios es una fase en la que es importante identificar una ADM, así como los principios arquitectónicos básicos que guiarán el diseño, como un énfasis en los acuerdos de nivel de servicio (SLA), una expectativa de planteamientos de proyecto ágiles o en cascada, etc.
- Al definir una visión de la arquitectura, se identifican los temas clave que guiarán el desarrollo de la arquitectura, como una iniciativa organizativa «centrada en la nube», un cambio hacia otro proveedor de base de datos o sistema operativo, o el deseo de implementar rápidamente nuevas funcionalidades en el sistema resultante. Esta visión empieza a sentar las bases para las decisiones y recomendaciones que se tomen más adelante en el proceso.
- La fase de arquitectura empresarial se enfoca en «la actividad comercial», un término subjetivo que generalmente significa las operaciones y los operadores diarios de una organización, ya sea una institución del sector público o privado. Esta fase se centra en los flujos de trabajo y las funcionalidades existentes y deseadas: ¿cuáles son los componentes basados en ArcGIS que ayudarán a hacer las cosas? Esta fase también incluye los requisitos no funcionales que son importantes para la empresa, como la usabilidad, la seguridad o el rendimiento. Separar los requisitos funcionales de la arquitectura empresarial (los flujos de trabajo y las capacidades deseadas) de los requisitos no funcionales y la arquitectura de la solución (la solución lógica o los componentes del software y la solución) es clave para identificar las lagunas y las áreas potenciales en las que estos requisitos pueden entrar en conflicto entre sí.
- Una vez definidos estos flujos de trabajo, la fase de arquitectura de datos y sistemas de información se centra en las estructuras que respaldarán los flujos de trabajo, tanto las interfaces de aplicación (como las aplicaciones móviles, web o de escritorio) como las estructuras de datos (esquemas, modelos de datos, almacenamiento) que respaldarán la persistencia de los datos empresariales. Durante esta fase, pueden crearse recomendaciones específicas sobre qué aplicaciones, funcionalidades de cliente o patrones de almacenamiento utilizar.
- Dado que existen muchas formas de implementar ArcGIS, una fase de arquitectura tecnológica se centra en las decisiones y distinciones que conducen a una especificación o adquisición real del software. En esta fase pueden tomarse decisiones sobre el rol de ArcGIS Online y ArcGIS Enterprise, o se harán elecciones específicas relacionadas con el proveedor de base de datos, el proveedor de nube o el sistema operativo que alojará el software.
- Una vez que este panorama objetivo está más claro, una organización puede empezar a Planificar la implementación, las oportunidades y las soluciones, al mismo tiempo que se enfoca en los pasos y cambios que hay que hacer para que el nuevo sistema esté disponible para los usuarios. Esto puede implicar un cambio organizativo significativo, adquisiciones o aumentos del soporte técnico del personal, o evaluaciones de tecnologías que permitan tomar una decisión.
- Cuando ya se utiliza un sistema existente para algunos procesos empresariales, como suele ser el caso, la Planificación de la migración contribuirá a garantizar que los usuarios se cambien rápida y eficientemente a la nueva arquitectura. Esto puede implicar una planificación de la gestión de cambios centrada en las personas y en los procesos, pero también una planificación tecnológica para que las integraciones, los flujos de trabajo e incluso el contenido de cara al público se desplacen sin problemas para acceder a la nueva arquitectura e interactuar con ella.
- Una vez completada toda esta planificación, se discuten con frecuencia otras consideraciones para la Gobernanza. Éstas podrían influir en la forma en que se utiliza el nuevo sistema, en cómo se revisan y controlan los cambios en los datos o las aplicaciones, y en cómo avanza el proceso de examen, revisión e implementación, de modo que la arquitectura pueda seguir siendo relevante, adaptarse a los nuevos requisitos y mantenerse reactiva ante las expectativas de los usuarios.
Con una estructura y un proceso de arquitectura bien planificados, los sistemas tanto grandes como pequeños pueden diseñarse cuidadosamente, implementarse con eficacia y mantenerse eficientemente a lo largo de muchos años y cambios en los usuarios y el público.