четверг, 11 января 2018 г.

Архитектурные принципы: разработка и проектирование

Максимально раннее тестирование

Формулировка
Разрабатываемые компоненты должны тестироваться как можно раньше и это обычно гарантирует более высокое качество.
Основная причина
Тестирование разрабатываемых компонентов должно быть включено в процесс разработки. Эта практика ведёт не только к улучшению качества компонентов, но и гарантирует поставку в срок бизнес функциональности.
Следствия/выводы
·         Разрабатываемые компоненты должны включать unit-тесты к ним;
·         Unit-тесты должны покрывать все операции компонентов.

Переиспользование

Формулировка
Архитектура, инфраструктура и дизайн должны поддерживать переиспользование активы (например, программные компоненты).
Основная причина
Переиспользование – это фундаментальный принцип, который способствует гибкости и экономии затрат. Переиспользование должно быть предусмотрено вначале проектирования и разработки.
Следствия/выводы
·         Все активы, которые могут быть переиспользованы, должны быть внесены в репозиторий для максимизации их потенциального переиспользования;
·         Архитектура должна позволять переиспользовать компоненты.

Управление изменениями

Формулировка
Изменения активов должно осуществляться контролируемым образом, что поддерживает эволюции активов и восстановление активов (если потребуется)
Основная причина
Управление изменениями – это одно из ключевых факторов в поддержке и эволюции систем. Могут появляться новые бизнес-требования, которые потребуют создание новых версий компонентов и управление ими.
Следствия/выводы
·         Все активы должны быть версионированы;
·         Оценка изменения активов должны проводиться до выполнения изменения актива;
·         Все потребители должны планировать переход на последнюю версию активов;
·         Версия кода и конфигурации не должны изменяться между окружениями.


Поставки и развёртывание компонентов

Формулировка
Компоненты должны быть собраны в поставки используя стандартные подходы с целью улучшения гибкости, переиспользования и автономного выполнения.
Основная причина
Применение автоматизированных поставок ускоряет и облегчает развёртывание, а также уменьшает влияние «человеческого фактора».
Следствия/выводы
·         Библиотеки и компоненты в поставке не должны иметь дубликаты;
·         Общие библиотеки не должны быть в составе поставки с компонентами (может быть отдельная поставки общих библиотек, которые будут использоваться многократно для поставок компонентов);
·         Любой компонент, который может быть скомпилирован должен быть скомпилирован;
·         Библиотеки платформы не должны быть в составе поставки;
·         Поставки должны соответствовать стандартам наименований и структурой принятыми у Заказчика;
·         Система должна быть протестирована на аналогичном по конфигурации промышленному окружении до развёртывания на промышленном окружении;
·         Компоненты, развёрнутые на промышленном окружении должны быть теми же, что были протестированы на тестовых окружениях. Не протестированные или частично протестированные поставки не должны разворачиваться на промышленном окружении.

вторник, 9 января 2018 г.

Архитектурные принципы: интеграция

Интеграция, базирующаяся на стандартах

Формулировка
Интеграция между системами должна базироваться на стандартах (протоколы, форматы и т.п.)
Основная причина
Интеграция, базирующаяся на стандартах, улучшает интероперабельность (т.е. способность продукта или системы, интерфейсы которых полностью открыты, взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации) не только с существующими системами, но и с системами, которые будут внедрены в будущем. Это облегчает целостное управление и мониторинг, а также увеличивает стоимость поддержки и усложняет развитие интеграции между системами.
Следствия/выводы
·         Поддержка промышленных стандартов таких как SOAP, REST, JMS, MQ и т.п.
·         При разработке избегать подхода в интеграции «точка-точка», т.к. этот подход имеет тенденцию становиться негибким и более дорогом в поддержке и развитии. См. принцип «Избегать интеграции по принципу Точка-Точка»

Логическая модель данных

Формулировка
Сообщения и форматы данных должны базироваться на логической модели бизнес объектов вместо нативных структур данных конкретных приложений
Основная причина
Основная цель сервис-ориентированной интеграции – это способствовать созданию композитных приложений. Распространение форматов данных специфичных конкретным приложениям негативно влияют на возможность композиции.
Следствия/выводы
·         Архитектура должна предоставлять возможность создания и использования логической модели данных
·         Формат данных должен базироваться на логической модели бизнес-сущностей

Нормализованные форматы данных

Формулировка
Трансформация данных «из» и «в» нормализованные форматы данных.
Основная причина
Нормализованные форматы данных способствуют композиции и снижают количество трансформаций, которые должны быть созданы и поддерживаться.
Следствия/выводы
·         Если нормализованных форматов данных нет, то они должны быть созданы;
·         Архитектура должна предоставлять возможности по трансформации данных из одного формата в другой.

Избегать интеграции по принципу Точка-Точка

Формулировка
Интеграцию по принципу Точка-Точка следует избегать
Основная причина
Интеграция по принципу Точка-Точка негибкая и более дорогая в поддержке. Хотя существуют случаи, когда интеграция по принципу Точка-Точка необходима и такие случаи нужно считать исключениями. Пример исключений включает требования к производительности, которые могут быть достигнуты используя Точка-Точка и когда передаётся большой объём данных.
Следствия/выводы
·         Архитектура должна предоставлять средства для отделения (т.е. отсутствия жесткой связи) участников интеграция;
·         Архитектура должна предоставлять механизм для передачи большого объёма данных, когда это необходимо;
·         Следует избегать интеграции по принципу Точка-Точка.

Техническая оркестровка

Формулировка
Техническая оркестровка должна быть отделена от бизнес-процессов
Основная причина
Явное разделение между техническими и бизнес аспектами способствует улучшению поддержки и развития. Технические аспекты меняются, когда происходит изменение конкретной системы, а бизнес аспекты, когда меняется бизнес-процессы.
Следствия/выводы
·         Архитектура должна поддерживать оба вида процессов (техническая оркестровка и бизнес процессы)
·         В документации (руководства) должны быть описаны различия между технической оркестровкой и бизнес-процессами, а также возможные подходы к их реализации.

Выделение бизнес-сервисов

Формулировка
Бизнес-сервисы реализовывают бизнес уровень функциональности и данных
Основная причина
Бизнес уровень функциональности и данных необходим для создания ценных для бизнеса композитных приложениям, а также возможности реализации и поддержки бизнес-процессов подготовленными бизнес пользователями. Также могут быть низкоуровневые сервисы, которые переиспользуются в бизнес-сервисах.
Следствия/выводы
·         Сервисы должны быть созданы в соответствии с слоями архитектуры;
·         При разработке сервисов должно учитываться разделение сервисов на технические и бизнес;
·         Архитектура должны поддерживать бизнес-сервисы.

Доступ через сервисы

Формулировка
Доступ к данным или функциональности должен осуществляться через сервисы.
Основная причина
Сервисы предоставляют основу для гибкой композитной разработки.
Следствия/выводы
·         Архитектура должны предоставлять механизм для доступа к данным через сервисы;
·         Архитектура должна предоставлять механизм для доступа к функциональности через сервисы.

Непрозрачная реализация сервиса

Формулировка
Реализация сервиса не должна быть прозрачной для всех потребителей сервиса.
Основная причина
Потребители сервиса должны быть в состоянии успешно вызывать сервисы без необходимости понимания внутреннего устройства вызываемого сервиса.
Следствия/выводы
·         Интерфейс сервиса должен быть создан таким образом, чтобы детали реализации не были видны через интерфейс;
·         Архитектура должны поддерживать возможность непрозрачной реализации сервисов.

Версионность сервисов

Формулировка
Может быть одновременно несколько версий сервиса в промышленной эксплуатации.
Основная причина
Как правило, сервисы изменяются для подключения новых потребителей и расширения функциональности.
Следствия/выводы
·         Должна быть описана стратегия версионирования сервисов;
·         Архитектура должна поддерживать несколько параллельных версий сервиса.


понедельник, 8 января 2018 г.

Архитектурные принципы: инфраструктура

Внешний технологический мониторинг и управление

Формулировка
Функциональность технологического мониторинга и управления должна быть внешней и не встроенной в инфраструктурный компонент
Основная причина
Встроенная в инфраструктурный компонент функциональность технологического мониторинга и управления ухудшает гибкость, а также имеет ограниченные возможности (т.е. ограничена отдельным инфраструктурным компонентом)
Следствия/выводы
·         В сервисах не должны быть жестко закодированы правила и политики управления
·         Поддержка промышленных стандартов (например, SNMP)

воскресенье, 7 января 2018 г.

Архитектурные принципы

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

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

Принципы являются взаимозависимыми и должны применяться целостно. Обычно число принципов для реализации решения не превышает 7-8 (а лучше 4-5), это необходимо, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые не приносят пользы на практике.

Использование принципов при работе над архитектурой доказало свою эффективность. В следующих постах будут приведены примеры архитектурных принципов, а в этой статье начнём с принципов безопасности:

Принцип наименьших полномочий

Формулировка
Пользователи и потребители ресурсов должны иметь минимальные полномочия необходимые для выполнения действий (работы).
Основная причина
Когда пользователю и потребителю ресурса предоставлены большие полномочия, чем требуется, то риски в части безопасности возрастают.
Следствия/выводы
  • Пользователям должен быть предоставлен доступ к функциям и данным на основе их ролей в системе;
  • Должен предоставляться только минимально необходимый для выполнения функций доступ.

Также смотрите: