Архитектурные подходы

Несмотря на то что архитектура системы может идти разными путями и содержать различные подходы и методы, несколько ключевых принципов являются общими для успешных современных архитектурных проектов ArcGIS. Этот раздел Well-Architected Framework включает в себя несколько более традиционных архитектурных тем, связанных с разделением программного и аппаратного обеспечения, облачными критериями или подходами к интеграции. Однако широта охвата дополнительных тем показывает, насколько изменилась роль корпоративного или системного архитектора, а также изменились результаты архитектурной деятельности, что позволяет ожидать появления новых знаний, тем и соображений. Эти рекомендации направлены на то, чтобы обеспечить хорошую основу для подхода, а не конкретный набор шагов и результатов.

Во-первых, крайне важно использовать подход, ориентированный на бизнес. Что это означает на практике? По сути, это означает, что архитектура должна быть в первую очередь спроектирована для поддержки конкретных рабочих процессов, бизнес-возможностей или результатов, которые необходимо достичь организации. Вместо того, чтобы сосредотачиваться на таких областях, как производительность, доступность, технология развертывания или расширение продукта по отдельности, все эти решения должны основываться на том, что бизнес требует от этой конкретной возможности или функции. Такой подход, ориентированный на спрос, приводит к созданию систем, которые сначала поддерживают основные возможности, а затем эффективно развиваются для повышения отдачи и внедрения в масштабах всей организации.

Во-вторых, важно следовать методологии разработки архитектуры (ADM). Существует множество различных ADM, и не существует единого оптимального варианта, но там, где это возможно, следует согласовывать архитектурные проекты с методом, обычно используемым в вашей организации.Использование подходов, которые согласуются с тем, как устроены другие системы, упростит согласование системных требований, интеграцию других архитектурных рекомендаций и, в конечном итоге, завоюет одобрение и поддержку других подразделений организации. Это распространяется на привлечение ИТ-специалистов и бизнес-архитекторов из других подразделений организации, где это возможно.

В-третьих, сосредоточьтесь на проектировании для обеспечения гибкости, а не на идеальном размере оборудования или физическом разрешении. В то время как капитальные затраты на приобретение оборудования определяли стоимость проекта в течение многих лет (и до сих пор влияют в некоторых организациях), широкий доступ к виртуализации и облачным вычислениям сократил требования к оборудованию на этапе разработки архитектуры. Изменение вычислительных ресурсов, памяти или хранилища системы в настоящее время обычно более простое и значительно более экономичное, чем в более традиционных архитектурах, что говорит о том, что для большинства архитектур достаточно гибких, свободно определенных аппаратных профилей. Многие организации по-прежнему будут обращаться за настоятельными рекомендациями по первоначальному размеру системы, и эти системы или приложения по-прежнему несут ответственность за текущие расходы на эти системы. Подводя итог, можно сказать, что тщательный баланс между разумной первоначальной оценкой и потенциальными изменениями, вызванными ростом использования, новыми функциями или новыми сообществами пользователей, является важной задачей для архитектора.

Новые области требований повысили важность структурированного архитектурного подхода, такие как безопасность, корпоративная интеграция, суверенитет данных и другие темы, которые могли бы не быть актуальными в более традиционных случаях. Эти требования могут влиять на проектирование решения, выбор аппаратного обеспечения и общую философию управления проектом или системой и в равной степени важны для функциональных требований или требований, основанных на производительности, которые традиционно определяют выбор архитектуры.

Можем дать следующие дополнительные рекомендации по архитектуре систем ArcGIS:

• Будьте гибкими — с учетом меняющейся динамики, изменений в требованиях на этапе проектирования и после него, а также изменений в направлении ИТ-стратегии вашей организации.
• Будьте отзывчивы — регулярно обсуждайте успехи (и проблемы) архитектуры с заинтересованными лицами и предлагайте изменения, которые отвечают их запросам, будь то новая и улучшенная функциональность или изменения нежелательной функциональности.
• Будьте предусмотрительны — когда требуются изменения, четко определяйте влияние, время и воздействие на пользователей. Тщательная координация архитектурных изменений уменьшает путаницу, повышает доверие пользователей к системе и увеличивает шансы на успешные результаты.

Процесс создания архитектуры

При проектировании систем с помощью ArcGIS многие организации проходят через аналогичные этапы структурированного процесса, обычно зависящего от используемой методологии архитектурного развития (ADM). Чтобы предоставить дополнительный контекст, ниже приведены примеры этапов архитектуры с некоторыми деталями, специфичными для ArcGIS.

1. Создание структуры и принципов — это этап, на котором важно определить ADM, а также основные архитектурные принципы, которые будут определять дизайн, такие как акцент на соглашениях об уровне обслуживания (SLA), ожидание гибкого или каскадного подхода к проектам и т.д.
2. При определении концепции архитектуры определяются ключевые темы, которые будут направлять разработку архитектуры, такие как организационная инициатива «сначала облако», переход к другому поставщику баз данных или операционной системе, или желание быстро внедрить новые возможности в полученную систему. Это видение начинает подготавливать почву для решений и рекомендаций, которые принимаются на более поздних этапах процесса.
3. Фаза бизнес-архитектуры фокусируется на «бизнесе» — субъективном термине, который обычно означает повседневные операции и операторов организации, будь то учреждение государственного или частного сектора. На этом этапе основное внимание уделяется существующим и желаемым рабочим процессам и возможностям - какие компоненты на основе ArcGIS помогут выполнить поставленные задачи? Этот этап также включает нефункциональные требования, которые важны для бизнеса, такие как удобство использования, безопасность или производительность. Отделение функциональных требований бизнес-архитектуры (желаемых рабочих процессов и возможностей) от нефункциональных и архитектуры решения (логического решения или программного обеспечения и компонентов решения) является ключом к выявлению пробелов и областей потенциальных областей, в которых эти требования могут противоречить друг другу.
4. После определения этих рабочих процессов на этапе архитектуры данных и информационных систем основное внимание уделяется структурам, которые будут поддерживать рабочие процессы, как интерфейсам приложений (например, мобильным, веб-приложениям или настольным приложениям), так и структурам данных (схема, модель данных, хранилище), которые будут поддерживать сохраняемость бизнес-данных. На этом этапе могут быть выработаны конкретные рекомендации по использованию приложений, клиентских возможностей или шаблонов хранения.
5. Поскольку существует множество способов развертывания ArcGIS, этап технологической архитектуры фокусируется на решениях и различиях, которые приводят к фактической спецификации программного обеспечения или закупке. На этом этапе могут быть приняты решения о роли ArcGIS Online и ArcGIS Enterprise, или будет сделан определенный выбор, связанный с поставщиком базы данных, поставщиком облачных услуг или операционной системой, на которой будет размещено программное обеспечение.
6. Как только эта целевая картина станет более ясной, организация может приступить к планированию развертывания, возможностей и решений, сосредоточившись на шагах и изменениях, которые необходимо внести, чтобы сделать новую систему доступной для пользователей. Это может повлечь значительные организационные изменения, закупки или увеличение поддержки технического персонала, а также оценку технологий, позволяющих принять решение.
7. Когда существующая система уже используется для некоторых бизнес-процессов, что бывает часто, планирование переноса поможет обеспечить быстрый и эффективный переход пользователей на новую архитектуру. Это может включать в себя планирование управления изменениями, ориентированное на людей и процессы, а также технологическое планирование, чтобы интеграции, рабочие процессы и даже общедоступные ресурсы были плавно перенесены для обеспечения доступа к новой архитектуре и взаимодействия с ней.
8. Когда все это планирование завершено, часто обсуждаются дополнительные соображения, касающиеся управления. Они могут влиять на то, как используется новая система, как анализируются и контролируются изменения в данных или приложениях, а также как продвигается процесс проверки, пересмотра и внедрения, чтобы архитектура могла оставаться актуальной, адаптироваться к новым требованиям и реагировать на ожидания пользователей.

Благодаря структуре и хорошо спланированному процессу создания архитектуры, системы, как большие, так и маленькие, могут быть тщательно спроектированы, эффективно внедрены и эффективно поддерживаться в течение многих лет, а также изменяться для пользователей и аудитории.