Рабочий шаблон архитектурного решения / Хабр
Здравствуйте, меня зовут Денис Галушко, я зам. главного архитектора финансовой группы БКС. До этого работал архитектором, тимлидом, программистом. Периодически у себя в компании провожу митапы на тему «как делать архитектурные решения» и, конечно же, согласую тонны архитектуры. Далее идет вступление, которое можно пропустить, но в нем — мудрость!
Зачем мы делаем архитектурное решение
Зачастую разработчики делают АР только для формального согласования уже написанного кода. Если вы поступаете так же, ваш проект «грохнется» рано или поздно. Накопятся ошибки в проектировании, вырастет до небес техдолг, сменится поколение программистов и вот оно, приехали. В первую очередь, АР нужен для вдумчивого проектирования и обсуждения с коллегами. В процессе изготовления АР вся команда договаривается, как решать задачу. Под командой подразумевается не только команда разработки, но и бизнес-заказчик, согласующие из ИБ и Архитектуры, поставщики АПИ из других проектов, получатели и поставщики данных. В итоге, в АР фиксируются договоренности и происходит формальное согласование. В конце процесса в общем хранилище компании остаётся документ, который отвечает на вопросы: что хотели заказчики, как запланировали сделать, почему именно так, какие были варианты.
Опыт показал, что при нынешней текучке кадров, да и просто при современном темпе жизни, через год концов уже не найти. Настоящим спасением может стать база знаний в виде копящихся в Конфлюенсе архитектурных решений.
Почему не надо самореализовываться в формате документа
Еще раз про велосипеды
Архитектурное решение — стандартный документ. Не стоит начинать изготовление АР с попытки придумать свой вариант шаблона. Да, творческим людям, коими являются программисты и аналитики, свойственно изобретать что-то своё уникальное. Именно оно кажется наиболее подходящим здесь и сейчас. С опытом мы учимся меньше изобретать «велосипеды», начинаем больше использовать чужой опыт. Предложенный шаблон АР — это многолетний опыт департамента архитектуры приложений БКС. Шаблон «вылизывали» годами, и он готов к использованию как есть. А комментарии помогут понять, зачем каждый раздел появился в документе и как его заполнить. Постарайтесь заполнить все, что от вас требует шаблон. Во-первых, это поможет вам правильно структурировать своё собственное понимание задачи и задать себе необходимые вопросы. Во-вторых, это облегчит чтение документа, а значит его согласование. Облегчит потому, что тем, кому приходится читать много подобных документов, хочется найти все на своих местах, а не рыться в очередном «творении».
Представьте, что в вашем шкафу с инструментами кто-то каждый день все перекладывает. Жизнь сразу станет насыщенней, да? Так вот, этот шаблон – наш шкаф с инструментами, в котором мы заботливо разложили все по полочкам, и ждем, что так и будет, когда вернемся к нему в следующий раз.
Далее идет шаблон. Точнее, текст инструкции по его заполнению. Сам шаблон оформляется в виде шаблона Confluence. Пояснения в нем намного короче и оформляются в виде «инструкций», которые исчезают в сохраненном документе. Шаблон в виде файла можно найти здесь.
Название архитектурного решения
Название страницы д.б. : «АР Название» или «SAD Название» или «ARCH-XXX Название».
Шапка документа
Следующая таблица помещена внутрь макроса Confluence «Сводная таблица». В дальнейшем она попадает в виде строчки в сводные таблицы всех арх. решений компании. Confluence собирает их по тэгу «ар», которым ОБЯЗАТЕЛЬНО должен быть помечен каждый документ.
Колонна | Возможны значения: Банк, Сеть, Брокер, Капитал, Корп. центр |
Проект | Система/Проект |
Тема | Кросс-проектная активность, длительная активность, Эпик |
Статус | ЧЕРНОВИК |
Автор | Галушко Денис Владимирович — автор последней версии |
Дата | 12. 04.2019 — дата внесения последней правки в документ |
Задача | Ссылка на задачу или эпик в Джире |
ПЛАН — разработка документа запланирована в рамках проектной деятельности;
ТРЕБУЕТ ДОРАБОТКИ — по документу имеются открытые вопросы, требующие доработики документа;
СОГЛАСОВАНИЕ — идет согласование очередной версии документа по СЗ;
СОГЛАСОВАН — версия документа согласована по СЗ;
РЕАЛИЗОВАН — реализован и перенесен в спецификацию релиза;
ЧЕРНОВИК — версия документа, находящаяся в работе;НЕ АКТУАЛЕН — документ потерял актуальность, может быть удален.
История изменений
Правила хорошего тона требуют от нас отмечать значимые версии документа и описывать изменения, произошедшие в них. Так мы облегчаем жизнь читателям, которые понимают, что смотреть в первую очередь. Либо блок удаляем, но пишем комментарии при сохранении страницы и они попадают в выпадающий (блок под таблицей).
Версия | Дата | Описание изменений | Автор |
---|---|---|---|
начните с // | Что поменялось в этой версии | начните с @ | |
Здесь д.б. макрос истории изменения страницы помещенный в макрос "Раскрыть"
Участники проекта и согласователи
В таблице с участниками мы описываем команду проекта. Кто какие роли выполняет, к кому обращаться за информацией, с кем требуется согласование. Данное упражнение помогает в начале разработки понять к кому обращаться, кто входит в круг заинтересованных лиц. В дальнейшем именно эти люди будут согласовывать документ, либо должны быть поставлены в ознакомление.
Участник | Характеристика участия | Функция | |
1 | @ | Описываем не должность, но роль в проекте. Например: Руководитель проекта. | Cогласование/Утверждение/Ознакомление |
2 |
Оглавление
Здесь находится макрос оглавления, который я для краткости удалил.
1. Общие сведения о проекте
1.1 Глоссарий
Описание акронимов и терминов, применяемых в документе.
Если в документе все термины уже неоднократно описаны и общеизвестны, не надо их дублировать еще раз. Просто поставьте прочерк.
1.2 Описание проекта
Коротко описать какую проблему решает данное архитектурное решение, кто инициировал разработку.
Результат проекта должен обеспечить достижение следующих целей:
Перечислить цели.
Заказчиком работ выступает:
Основными потребителями результатов проекта будут:
Проект реализуется в следующих ограничениях:
Ограничения по данным, подразделениям, бизнесам, реализуемым процессам и т.д. Целевое/не целевое решение. Все ли поставленные задачи решает АР или только часть.
2. Бизнес-архитектура
Разделы, после прочтения которых не должно остаться вопросов, что требуется бизнесу.
Т.е. какие обстоятельства привели к возникновению данной задачи; какие требования были на входе; какой процесс разработан исходя из требований.
2.1 Обзор предметной области
Заполнение данного раздела не обязательно, но является правилом хорошего тона. Приводим полезные для понимания документа сведения. Может быть описанием предметной области. Или описанием потребностей пользователя в продукте, который мы будем переделывать. Стоит описать исторические предпосылки возникновения потребности или проблемы. В общем, пишем все, что облегчает погружение в суть проекта.
2.2 Требования
Если документа с требованиями еще нет, то требования ОБЯЗАТЕЛЬНО надо зафиксировать здесь. Если требования не зафиксированы, значит архитектор начал работу не имея необходимых входных данных. И результат работы будет соответствующий.
Копируем требования в этот раздел, либо делаем ссылку на конкретную версию документа, либо прикладываем файл документа в таблицу взаимосвязей.
2.3 Целевой бизнес-процесс
Раздел описывает процессы, которые изменяются или добавляются данным решением. Схема бизнес процессов является важнейшей частью функциональных требований. И вместе с не функциональными требованиями является входными данными для архитектора. За описание бизнес-процессов отвечает бизнес-аналитик. Сделайте ссылку на конкретную версию документа со схемами БП или скопируйте схему в АР с указанием первоисточника. Если БП есть в требованиях, то здесь делаем ссылку на документ БТ.
Если схемы нет, то архитектору рекомендуется описать процесс текстом в виде иерархического списка шагов (нумерованных пунктов). Классический подход предполагает описание бизнес-процесса в виде схемы BPMN 2.0. Но для архитектора — это избыточная работа. По моему опыту, простой список шагов достаточен для понимания задачи. Это быстро и не требует специальных знаний и инструментов.
Также можно оформить БП в виде сиквенс-диаграммы.
3. Описание архитектурного решения
Разделы, отвечающие на вопрос «как мы решаем задачу»
3.1 Описание предложенного подхода
Описание выбранного решения. Коротко в несколько предложений описываем автоматизацию. Описание отвечает на вопрос: как схемы ниже реализуют процесс из 2.3. Если говорить совсем простыми словами, надо описать как все это будет работать. Схема без всякого описания слишком сложна для непосвященных в проект.
Например: Фронтом для клиента будет БКС Мир Инвестиций. Процесс будет оркестрировать бизнес-сервис ХХХ. У него есть база, в которой будет хранится состояние процесса и такие-то данные. Для подписания поручений используем стандартный набор сервисов центральной команды. Данные скоринга будут загружаться раз в день из ХХХ. Поручения выполняем в асинхронном режиме, поскольку в процессе есть шаги, выполняемые в бэкофисной системе. И т.д.
Если релевантно, стоит упомянуть какие варианты были рассмотрены, их плюсы и минусы, и почему выбрано именно такое решение.
3.2 Информационная архитектура
Схема информационных потоков с описанием.
Как оформить схему
Стрелки на схеме — потоки данных. Каждая стрелка подписывается номером потока и коротким названием группы данных, которую он передает. Если схема с именами потоков получается слишком громоздкой, то в местах с большой плотностью рисунка допускается сокращение надписи до номера. Но, по возможности, названия потоков надо сохранять. Это сильно облегчает чтение схемы. Искать описание каждого потока в таблице под схемой утомительно и долго. Детали потоков раскрываются в таблице после схемы. Для сообщений MQ необходимо указать ожидаемый средний размер и кол-во в день. Для потоков http прогноз нагрузки тоже приветствуется.
Блоки на схеме — системы, модули или микросервисы. У нас принято микросервисы обозначать буквами МС в названии. Иначе не очевидно, что это именно микросервис, а не какой-то модуль или транспорт или еще что-то.
Не надо на схеме информационных потоков отдельными блоками рисовать транспорт. Лучше обозначить на стрелке, что это MQ(AMQP/Biz) или REST или еще что-то. Либо полупрозрачными блоками на пути стрелок, как на примерах ниже. Транспортные системы выделяются в отдельные блоки только, если они несут какую-то смысловую нагрузку: модифицируют данные или оркестируют потоки. Транспорт, т.е. технология передачи данных, раскрывается в разделе Системная архитектура.
Цветом выделяются потоки и системы, которые добавляются или меняются.
Цвет стрелки, системы | Значение |
---|---|
черный | без изменений |
красный | новый поток или система |
синий | доработка системы или потока |
серый | удаляется |
сиреневый | добавляется/меняется в рамках другого АР |
Альтернативная схема:
Цвет стрелки, системы | Значение |
---|---|
черный | без изменений |
красный | удаляется |
синий | доработка системы или потока |
зеленый | новый поток или система |
сиреневый | добавляется/меняется в рамках другого АР |
Мы поддерживаем три варианта схем инфопотоков: классический и расширенный, где сгруппированные потоки данных идут от источника к получателю, и запросный, где стрелки указывают направление запроса, и каждая стрелка — это отдельный запрос.
Классический
Стрелки идут от источника данных к получателю. Каждая стрелка — это группа данных, либо объединение нескольких групп. Группы данных перечисляются в надписи на стрелке.
Расширенный
На примерах ниже все потоки снабжены информацией, по какому протоколу они передаются, какие коннекторы используются. Это может показаться лишним на схеме информационных потоков. В классическом понимании — это так и есть, ведь в таблице после схемы все эта информация тоже есть. Но мы пришли к выводу, что протокол и вид коннектора не перегружают схему, но при этом делают ее самодостаточной. Становится понятно как работает вся схема: где поток синхронный, где асинхронный; какие промежуточные системы задействованы; какие будут особенности в каждом взаимодействии. И в расшифровку потоков приходится смотреть значительно реже.
Запросный
По сути, данный формат — это описание АПИ. Стрелки указывают направление запроса. Каждая стрелка — отдельный вызов АПИ, либо очередь MQ. Формат ближе к системному, но, тем не менее, таковым не является. Потому, что допускает упрощения, не показывает границы сегментов, кластеров и т.п. Поэтому, публикуем схему в разделе Информационная архитектура.
Информационные потоки:
Код (номер потока) | Объект данных | Источник | Получатель | Описание | Тип | Протокол | Нагрузка * | |
---|---|---|---|---|---|---|---|---|
1 | INF01 или 1 | Название потока/ сущность данных | Система 1 | Система 2 | Описание потока данных. | event-driven/ request-driven / scheduled | REST / Biz / Rabbit / Kafka | (10 — 12 KB) * 100 msg/day |
2 |
* — обязательно для сообщений MQ.
Информационные системы:
| Система | Назначение |
1 |
| Функциональное предназначение системы в предметной области данного АР. Характер участия в интеграционном взаимодействии. Описываем конкретику данного решения. Если система общеизвестна и в данном решении используется как обычно, без какой-то примечательной специфики, то систему можно не упоминать в данной таблице. Не надо каждый раз описывать общее предназначение Бэкофисной системы или CRM. |
2 |
|
3.3 Системная архитектура
Раздел описывает проект программного решения с точки зрения системных компонент, реализующих информационную архитектуру. Акцент делается на технологиях, расположение программных компонент по ЦОД-ам, кластерам и сегментам сети. Указываются протоколы, адаптеры, шины. В данной схеме инфопотоки делятся уже не по группам данных, а по протоколам и видам взаимодействия. Т.е. схема отражает физическое воплощение предлагаемого решения. Но это не схема развертывания. В ней нет конкретных устройств и IP-адресов. Отсутствие данной информации позволяет архитектору не тратить время на выяснение малозначимых с точки зрения проектирования деталей. А также снимает секретность со схемы. Ведь сетевая схема — лакомый кусочек для шпионов.
Схема помогает:
понять какие физические механизмы и системы задействованы в проекте. Их владельцев надо не забыть указать в доработках и согласователях;
специалистам по информационной безопасности оценить какие сегменты сети преодолевают чувствительные данные;
разобраться какие сетевые доступы надо запросить.
3.4 Схема развертывания
Если проект того требует, в этом разделе мы можем поместить deployment-схему. Если требуется сетевая схема с IP-адресами и конкретным оборудованием, то весь документ приобретает статус секретного, поскольку мы раскрываем пути проникновения в инфраструктуру предприятия. Поэтому, мы стараемся делать схему развертывания отдельным документом.
4. Реализация
4.1 Требования к реализации
Раздел описывает требования к реализации архитектурного решения: важные условия и ограничения, которые необходимо учитывать при реализации; требуемая модернизация инфраструктуры, и т.д.
4.2 Доработка систем
В этом разделе архитектор перечисляет доработки, которые необходимо сделать в системах для реализации решения. Смысл раздела в том, чтобы определить круг исполнителей. Это особенно актуально, если в доработках задействованы несколько систем, подразделений. Если все доработки делаются одной командой, то раздел можно опустить.
Детализация должна быть достаточной, чтобы определить системы и контактные лица. Детали доработок прорабатывают аналитики в системах.
Система | Описание | Ответственный за разработку | Кто будет поддерживать |
---|---|---|---|
система 1 | . | ||
система 2 | .. |
5. Информационная безопасность
5.1 Бизнес операции, подлежащие аудиту
Для микросервисов БКС — это операции, которые система будет писать в лог с пометкой AUDIT_LOG. Это лог, в котором остаются следы операций пользователей, которые потенциально могут привести к утечке чувствительных данных, раскрытию финансовой тайны и т.п. Т.е. если произойдет что-то нехорошее, в этот лог пойдут смотреть безопасники. По хорошему, автоматические скрипты должны инспектировать его регулярно.
Бизнес операция | Описание | Код операции | |
---|---|---|---|
1 | Смысловое название операции, производимой пользователем приложения. Например: чтение карточки клиента | Описание операции | Код операции. Текстовая метка, по которой потом можно отфильтровать данные операции. Например: READ_CLIENT_CARD |
2 |
5.2 Аутентификация пользователей
Короткое описание механизма аутентификации пользователей и модулей системы. Если механизм не относится к базовым — в случае БКС это KeyCloack и Kerberos -, то надо описать где хранятся учетные записи, как добавляются/изменяются/удаляются, как происходит аутентификация.
В случае KeyCloack обязательно указываем realm. Если микросервисы используют технические учетные записи для вызова друг друга, указываем, что они должны храниться в Vault.
5.3 Авторизация пользователей систем
Описание подхода к авторизации. Если в системе есть ролевой механизм, описываем его здесь. Если нет, пишем по каким принципам разрешается доступ к ресурсам системы. Описываем как пользовательские, так и межсервисные доступы.
5.4 Доступ к внешним данным
Здесь нужно прописать сетевые соединения, которые инициируют модули системы или микросервисы во внешнюю сеть. Под внешней сетью понимаются менее доверенные сегменты сети предприятия (DMZ, например) и Интернет. По этой таблице будет настроено сетевое окружение.
Namespace | Микросервис | Протокол | Target адрес | Target порт | |
---|---|---|---|---|---|
1 | |||||
2 |
6. Нефункциональные требования и дополнительная информация
N | Требование | Описание реализации |
---|---|---|
1 | Потребность в закупке лицензий ПО | Новые лицензии прикладного и системного ПО |
2 | Потребность в закупке железа | Сервера, системы хранения данных, сетевое оборудование и т. д. |
3 | Прогноз объема хранения данных при запуске и через год работы | |
4 | Требования по нагрузке | Количество обрабатываемых транзакций – всего в системе, среднее за день, в пике. Транзакцией может быть любой объект данных или операция, актуальные для данной системы. |
5 | Архивирование данных | Требования к архивации данных |
6 | Другие требования |
7. Открытые вопросы
Здесь пишем вопросы, которые не сразу удалось решить и потребовалась их фиксация, чтобы потом написать кто решил и как. Если документ оформляется в Конфлюенс, то это также способ назначить на кого-то задачу.
<Конец шаблона>
Архитектурные решения интерьера (АИ)
Архитектурные решения интерьера (АИ)
Дизайн-проекты бывают разной наполненности, начиная от базовых со стандартным набором чертежей, заканчивая премиум с максимально полной рабочей документацией, с большим количеством чертежей, развертками всех стен, ведомостями и спецификациями всех материалов.
Такой подход позволит избежать ошибок во время ремонта, так как в рабочей документации будет отражено всё по максимуму. Она нужна, как строителям, чтобы реализовать проект, так и заказчикам, чтобы заказывать встроенную мебель и контролировать работы ремонтной бригады. Также проверить результат на соответствие проекта (см. статью про развертки помещений).
Вкратце разберем полный дизайн-проект. Разные компании предлагают разный пакет чертежей, но мы выделим обязательные чертежи, без которых проект будет не полным:
Обмерочный план. Работа начинается с замеров квартиры, указываются все размеры и типы стен, высот потолка, дверных проемов, окон и подоконников. Также указывается расположение щитка, вент.шахт. По этим данным делаются остальные чертежи и многое другое.
План демонтажа. Обязательный чертеж, если планируется демонтировать перегородки. На этом плане также показывается демонтаж радиаторов, окон, дверей, если необходимо.
План монтажа перегородок. На данном чертеже показаны возводимые стены и перегородки, со всеми размерами, высотами и материалами стен. Это основной чертеж в проекте.
Функциональное зонирование. План расстановки мебели и техники, здесь наглядно видно, какая мебель и где расположена. Это окончательно согласованный с заказчиком план расположения мебели, с текстовыми выносками и примечаниями.
План отопления. Здесь показаны трассы отопления и расположение радиаторов.
План оштукатуривания стен. На данном чертеже указывается какой тип штукатурки к какой стене относится.
Схема укладки ЭППС. Показано расположение слоёв утеплителя и количественные характеристики (если необходимо дополнительная звукоизоляция или утепление пола под стяжку).
Устройство стяжки. Здесь видим какая стяжка и в каком объеме необходима для квартиры, также привязки профилей для маячков (при условии отсутствия стяжки от застройщика).
План каркасного потолка. На данном чертеже отмечается тип потолка, его уровни, привязки всех необходимых ниш, привязки потолочных профилей, расположение закладных и отверстий под светильники.
План наливного пола. План, показывающий в каких помещениях применяется наливной пол и его количественные показатели. Также присутствует схема укладки.
План раскладки теплого пола. Точное расположение теплого пола с необходимыми отступами и привязками.
План напольного покрытия. В рабочей документации по полам указывается, где и какое покрытие будет в квартире. Показывается раскладка плитки и направление. Если укладывается паркетная доска или ламинат — направление укладки. Также обязательно указаны высотные отметки и расположение плинтуса.
План отделки стен. Этот лист альбома дает информацию по финишной отделке стен, а именно где и какой цвет, материал применяется. Также здесь есть ведомость, показывающая сколько нужно той или иной краски, обоев и т.д.
Развертки. На развертках показаны все стены с отделкой и расположением мебели, сантехники и оборудования, места электровыводов, розеток, выключателей и привязок к ним.
План потолка с привязками светильников. План освещения со всеми осветительными приборами и привязками.
Управление освещением. На этом чертеже указывается расположение и тип выключателей с привязкой к осветительным приборам. Освещение показано вместе с мебелью, чтобы всем было понятно, где оно будет организовано.
Привязка электрооборудования. План расположения розеток с привязками, на фоне мебели и оборудования, чтобы понимать, где расположены розетки. Чтобы в квартире хватало розеток, необходимо основательно продумать их расположение.
Это основные чертежи. Также альбом дополнен листами со схемами, узлами, развертками (помещений, мебели) и ведомостями.
Мы располагаем листы в проекте в согласовании с планом работ.
Перечень всех чертежей в проекте:
0. Титульный лист
1. Общие данные
2. Обмерочный план
3. Подготовка к ремонту
4. Итоговые обмеры
5. План демонтажа
6. План монтажа перегородок
7. План отопления
8. Схема прокладки трасс кондиционирования
9. Схема подключения кондиционеров
10. Монтаж вентиляции
11. План потолка с привязками светильников
12. Управление освещением
13. Привязка электрооборудования
14. Итоговые обмеры инженерных сетей
15. Схема заделки штроб
16. Схема укладки ЭППС
17. Устройство стяжки
18. План каркасного потолка
19. Схема монтажа остекления
20. Схема монтажа входной двери
21. Схема утепления балкона. Отделка балкона.
22. План привязки подоконников к окну. Схема оштукатуривания оконных откосов
23. Монтаж гидроизоляции
24. План монтажа ГКЛ конструкций
25. Схема обшивки потолка
26. Схема подключения радиаторов
27. Малярный план
28. План раскладки теплого пола
29. План наливного пола. Схема укладки
30. Развертка СУ, укладка плитки
31. Развертка ванной, укладка плитки
32. Схема укладки фартука. Развертки
33. План напольного покрытия
34. План отделки стен
35. Функциональное зонирование
36. План монтажа дверей. Схема монтажа дверной коробки
37. Схема монтажа доборных элементов
38. Нумерация видов
39 — 52. Развертки стен
Нужны качественные чертежи?
Максимально полная рабочая документация для качественного ремонта
Заказать проект |
Статьи из блога
Щит ЭОМ в сборе
Разберем из чего состоит распределительный щит
Водоснабжение и канализация (ВК)
Необходим при ремонте квартиры, при замене труб водоснабжения и канализации. Это один из главных разделов инженерного проектирования.
Коллекторный узел в сборе
Из каких деталей компонуется коллекторный узел водоснабжения
Преимущество 3D тура
Наглядное сравнение 3D тура и статического изображения
История DIY брендов
DIY расшифровывается как Do It Yourself, что означает “сделай сам”. Это не просто лозунг, а девиз и возникшая в Штатах субкультура, объединяющая музыку.
Ошибки в визуализации
При проектировании важно учитывать любые детали, чтобы при реализации не возникло ошибок. Часто вовремя неисправленные оплошности могут стоить не только времени, но и больших затрат.
ДНК скандинавского стиля
Характерные особенности стиля
Согласование перепланировки: что нужно знать
Какие популярные проблемы и подводные камни перепланировки
История визуализации
От отмывки от руки в древние времена до современных технологий
Как проработать архитектурную концепцию IT-проекта с помощью Attribute-Driven Design
Архитектура IT-решения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании.
Помимо проектирования IT-архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы.
Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.
Именно IT-архитектор решает, как в конечном итоге будет выглядеть информационная система — в целом и в деталях. Ему требуется найти баланс между конкурирующими требованиями и ограничениями.
Если у вас есть детальное архитектурное решение, это позволит наиболее точно оценить сроки и стоимость реализации продукта. Кроме того, появляется возможность уже на старте определить характеристики системы, которая будет соответствовать бизнес-задачам. Среди критериев качества IT-архитектуры – гибкость для масштабирования, снижение рисков, скорость работы и возможность независимого выбора подрядчиков.
О том, как выглядит день IT-архитектора, и о наиболее требовательных к архитектуре проектах мы рассказывали ранее на Хабре и в нашем подкасте.
Требования и ограничения
Наша цель — спроектировать архитектуру программного обеспечения (ПО) систематическим, предсказуемым и экономически эффективным способом. Для этого нужно определить требования к продукту.
Как правило, техническое задание (ТЗ) на разработку продукта содержит требования, но не всегда они указаны в достаточном объеме. По этой причине в числе ключевых задач IT-архитектора – сбор и анализ требований, создание дизайна архитектуры и описание решения, его проверка, а также контроль и надзор во время разработки ПО.
Рассмотрим, что входит в список требований:
1. Цель проектирования
От цели зависит, что нам нужно на старте: детальная архитектура или приблизительное представление об устройстве системы, которое позволит оценить объем и стоимость работ.
2. Атрибуты качества, нефункциональные требования
Эти атрибуты определяют свойства системы, которые она должна демонстрировать — требования к производительности, доступности, безопасности, удобству использования.
Пример: система должна работать 24х7, допускается простой не более 30 минут в месяц.
3. Функциональные требования
Определяют действия, которые система способна выполнить.
Пример: возможность выгружать данные из файла и рассылать отчеты по email.
4. Системные требования
Возникают постепенно в процессе детализации и реализуются итеративно.
Пример: авторизация, ведение журнала действий, кэширование.
5. Ограничения
Не относятся напрямую к поведению системы и не поддаются нашему влиянию. Например, у клиента есть пожелания по разработке микросервисной, а не монолитной архитектуры. Также сюда относятся требования законодательства, например, в области хранения персональных данных.
Как правило, владелец продукта заранее не имеет полного списка требований к системе, поэтому архитектор непосредственно организует процесс их сбора и фиксации. Из всех требований к системе специалист обязан выделить архитектурно значимые, которые оказывают глубокое влияние на конечное решение.
Согласно методологии ADD, сбор требований – это первый этап работы. Его назначение:
- помочь оценить стоимость и график работ;
- выработать ключевые технологии;
- обеспечить достижение бизнес-целей в процессе разработки.
Далее рассмотрим остальные этапы проектирования.
Обзор методологии
1. Собираем требования
В качестве источника могут выступать результаты опросов стейк-холдеров, анализ бизнес-целей проекта и историй использования. При этом важно конкретизировать, что имеет в виду клиент. Например, не просто «безотказная работа сайта», а «допустимый период простоя – 30 минут в месяц».
Далее мы оцениваем важность требований по двум критериям:
- ценность для бизнеса;
- степень влияния на архитектуру.
Уровни важности оцениваем по шкале HML (high, medium, low — высокий, средний, низкий). Таким образом, каждое требование будет иметь двухбуквенное сочетание. Архитектурно значимые пункты имеют обозначения HH, HM, HL, MH, MM. Стоит отметить, что большое число требований HH означает высокие риски на проекте.
2. Проектируем архитектуру
Мы проектируем архитектуру ПО, исходя из наиболее значимых атрибутов качества.
Это рекурсивный процесс, в ходе которого система декомпозируется на более мелкие подсистемы.
ADD — первый метод, который концентрируется на атрибутах качества и способах их достижения. Важным вкладом ADD было признание того, что анализ и документация являются неотъемлемой частью процесса проектирования. Этот метод успешно применяется более 15 лет.
Сейчас актуальная версия ADD — 3.0, итеративная. Согласно ей, проектирование выполняется поэтапно в течение всего времени разработки системы, в каждом спринте. В ней по шагам описано руководство по тем задачам, которые необходимо выполнить в рамках каждой итерации.
Семь шагов ADD
Шаг 1. Проверка входных данных
Убеждаемся, что все необходимые данные и требования доступны, приоретизированы, корректны и выполнимы, а цель работы понятна.
Шаг 2. Определяем список требований к подсистеме
Ранжируем требования по важности для бизнеса и степени влияния на архитектуру, группируем в соответствии с оценкой HML, выбираем 5-6 приоритетных.
Шаг 3. Выбираем часть системы для проектирования
Исходим из риска и сложности реализации, ценности для бизнеса, критического пути и точности проработки требований. Строим работу на достижении требований, которые соответствуют целей итерации.
Шаг 4. Определяем лучший вариант из возможных
Самый сложный пункт. Анализируем все варианты, находим преимущества и недостатки.
Шаг 5. Конкретизируем компоненты выбранной концепции, определяем обязанности и интерфейсы
Как правило, в начале работы концепция формулируется в общем виде. На данном этапе мы определяем все элементы подсистемы и ответственность каждого, выбираем интерфейс, через который компоненты взаимодействуют между собой.
Шаг 6.
Делаем эскиз решения и краткое описаниеОформляем описание в наглядный документ, например, в виде UML-диаграммы или SFML. Нужно также зафиксировать все принятые решения, описать, на какие компромиссы мы пошли и какие альтернативы рассмотрели. Это поможет в дальнейшем оценить аргументы в пользу конкретной архитектуры и создать документацию.
Шаг 7. Проверка выполнения требований
На этом шаге методология рекомендует получить “второе мнение” других опытных коллег-архитекторов, для того чтобы подойти к процессу более объективно. Участие нескольких специалистов с их опытом и точкой зрения на архитектуру поможет оперативно выявить недочеты, если они есть.
Мы уточняем и конкретизируем требования, расставляем приоритеты и затем повторяем шаги со 2 по 7 в каждой итерации. Таким образом необходимо проработать все требования с высоким приоритетом, соблюдая все ограничения.
3. Отслеживаем прогресс
Чтобы вовремя выполнить перечисленные выше шаги, архитектору нужно наблюдать за прогрессом работы команды и оперативно откликаться на изменения. Авторы методологии советуют отслеживать выполнение шагов с помощью архитектурного бэклога в виде канбан-доски. В ее столбцы мы помещаем архитектурно значимые требования, ограничения и системные задачи. Они могут иметь следующие статусы:
-
Not Yet Addressed (Еще не рассмотрено)
-
Partially Addressed (Рассмотрено частично)
-
Completely Addressed (Рассмотрено полностью)
-
Discarded (Отброшено)
Рассмотрим на примере
В заключение расскажем о том, как закладывается архитектура по ADD, на примере одного из наших проектов.
Задача
К нам обратился зарубежный заказчик — владелец крупного хранилища данных, полученных из старинных газет (более 1 млрд отсканированных страниц). Заказчику потребовалось найти и собрать в единую базу знаний все брачные объявления, а также записи о свадьбах: кто, когда и на ком женился.
Чтобы обработать информацию и выделить нужные факты, мы использовали нейросеть. Инженеры заказчика ранее уже создали все необходимые модели TensorFlow, которые должны запускаться последовательно, образуя конвейер. На вход модели поступал результат работы предыдущей модели, преобразованный по определенному алгоритму. Модели работали с разной скоростью и имели разные требования к ресурсам (потребление оперативной памяти, нагрузка на процессор, потребность в GPU).
Чтобы выполнить проект в срок, мы определили, что в среднем нужно обрабатывать до 10 миллионов страниц в день. Запросы на обработку поступали неравномерно, в некоторые часы их количество было близко к нулю, в другие — составляло порядка одного-двух миллионов. Страница полностью обрабатывалась не позднее чем через час после поступления.
Заказчик планировал развернуть систему в облаке. Поэтому было важно оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду.
Варианты использования
Атрибуты качества
Ограничения
Архитектурные задачи
ID |
Описание |
CRN-1 |
Спроектировать и описать высокоуровневую архитектуру системы |
Процесс проектирования
После фиксации требований мы подготовились к тому, чтобы начать первую итерацию ADD.
Шаг 1. Проверка и анализ исходных данных
Первая итерация – это референсная архитектура и общая структура системы.
Шаг 2. Цель итерации
По завершении итерации нам нужно определить общую структуру проектируемой системы (CRN-1).
Шаг 3. Выбор элемента системы для проработки
Прорабатываем структуру всей системы.
Шаг 4. Выбор архитектурных концепций
Шаг 5. Конкретизация экземпляров архитектурных элементов, распределение обязанностей и определение интерфейсов
Шаг 6. Эскиз решения
Шаг 7. Анализ созданной архитектуры и прогресса
Цель итерации достигнута. Общая структура системы спроектирована. В качестве основы мы выбрали проверенный временем архитектурный стиль, подходящий под условия нашей задачи. В следующих итерациях следует подобрать технологии и детально описать, как будет обеспечиваться выполнение архитектурных требований.
Выводы
Если вы хотите оценить сроки и стоимость реализации проекта, бывает полезно уже на старте проработать детали его архитектурной концепции. Подход Attribute-Driven Design помогает при выборе архитектурного решения, инструментов и шаблонов, что в свою очередь позволяет снизить затраты на разработку.
Благодарим за внимание и надеемся, что наш пример был вам полезен.
Примеры эталонных облачных архитектур и рекомендации
AWS Well-Architected
- Концепция AWS Well‑Architected Framework
- AWS Well‑Architected Tool
- Направления AWS Well‑Architected
- AWS Well-Architected Labs
Эталонные архитектуры
- Аналитика и большие данные
- Вычисления, в том числе высокопроизводительные
- Базы данных
- Просмотреть все архитектурные диаграммы
Ознакомьтесь с нашим контентом
В Центре архитектурных решений AWS доступны схемы эталонной архитектуры, проверенные архитектурные решения, рекомендации Well-Architected, шаблоны, значки и не только. Эти рекомендации были предоставлены экспертами по архитектуре облака из AWS, включая консультантов AWS Professional Services, партнеров и архитекторов решений AWS.
Фильтр:
Отменить все фильтры
Фильтр
Фильтр
Close Apply FiltersФильтр
Фильтр
Close Apply FiltersПо выбранным критериям поиска ничего не найдено.
Категории технологий
Аналитика и большие данные
Создавайте надежные, безопасные и экономичные архитектуры обработки данных.
Вычисления (в том числе высокопроизводительные)
Узнайте, как разрабатывать, развертывать, запускать и масштабировать приложения.
Контейнеры
Узнайте самый безопасный и надежный способ использовать контейнеры с внушительными возможностями масштабирования.
Оптимизация затрат
Узнайте, как непрерывно оптимизировать затраты.
Базы данных
Выберите подходящую базу данных, учитывая сценарий использования и закономерности доступа.
Вычислительные возможности для пользователей
Создавайте архитектуры, которые позволяют отвечать на изменяющиеся потребности сотрудников.
Интернет вещей (IoT)
Узнайте, как подключать устройства, а также собирать, хранить и анализировать их данные.
Машинное обучение
Создавайте эффективные и продуктивные архитектуры машинного обучения.
Управление и администрирование
Узнайте, как быстрее и надежнее выполнять сборку и доставку продуктов с помощью AWS.
Microsoft
Ознакомьтесь с рекомендациями по созданию и запуску приложений Microsoft.
Миграция
Узнайте, как переместить существующие приложения в AWS.
Сети и доставка контента
Узнайте, как подключать устройства, а также собирать, хранить и анализировать их данные.
Безопасность, идентификация и соответствие требованиям
Узнайте, как должным образом обеспечить безопасность и соответствие требованиям с помощью сервисов и инфраструктуры AWS.
Бессерверные технологии
Научитесь создавать и запускать приложения и серверные сервисы без серверов.
Хранилище
Создавайте надежные и безопасные архитектуры хранения данных с возможностью масштабирования.
Вам помогла эта страница?
Да
Нет
Обратная связь
Close
Благодарим вас за обратную связь
Мы рады, что эта страница вам помогла. Вы готовы рассказать подробнее, чтобы поддержать наше стремление к совершенствованию?
Обратная связь
Close
Благодарим вас за обратную связь
Нам жаль, что эта страница вам не помогла. Вы готовы рассказать подробнее, чтобы поддержать наше стремление к совершенствованию?
Обратная связь
Вход в Консоль
Подробнее об AWS
- Что такое AWS?
- Что такое облачные вычисления?
- Инклюзивность, многообразие и равенство AWS
- Что такое DevOps?
- Что такое контейнер?
- Что такое озеро данных?
- Безопасность облака AWS
- Новые возможности
- Блоги
- Пресс‑релизы
Ресурсы для работы с AWS
- Начало работы
- Обучение и сертификация
- Портфолио решений AWS
- Центр архитектурных решений
- Вопросы и ответы по продуктам и техническим темам
- Отчеты аналитиков
- Партнерская сеть AWS
Разработчики на AWS
- Центр разработчика
- Пакеты SDK и инструментарий
- . NET на AWS
- Python на AWS
- Java на AWS
- PHP на AWS
- JavaScript на AWS
Поддержка
- Связаться с нами
- Работа в AWS
- Обратиться в службу поддержки
- Центр знаний
- AWS re:Post
- Обзор AWS Support
- Юридическая информация
Amazon.com – работодатель равных возможностей. Мы предоставляем равные права представителям меньшинств, женщинам, лицам с ограниченными возможностями, ветеранам боевых действий и представителям любых гендерных групп любой сексуальной ориентации независимо от их возраста.
Поддержка AWS для Internet Explorer заканчивается 07/31/2022. Поддерживаемые браузеры: Chrome, Firefox, Edge и Safari. Подробнее »
Пять примеров работы с промышленной архитектурой в бюро АСД
English versionАлексей Иванов рассказывает о своем опыте работы с объектами промышленной архитектуры на пяти примерах, различных сюжетно и функционально.
Архитектор:
Алексей ИвановМастерская:
Архстройдизайн АСД0
«Радуюсь я – это
мой труд вливается
в труд моей республики».
В. Маяковский
1.
Промышленная архитектура:
реновация «как у всех».
Реконструкци здания РБO на ул. Тимура Фрунзе. Реализация, 2005 © Архстройдизайн
«Десять лет назад мастерская выполнила проект- реконструкции фасадов одиннадцатого корпуса комбината «Красная Роза» на улице Тимура Фрунзе. Этот пример мы рассматриваем как наиболее распространенный в практике последних 50 лет (как европейской, так и постсоветской) реновации промышленных территорий по причине вывода производства из города или его закрытия. Такая реновация, чаще всего, заключается в переоборудовании бывших промышленных корпусов под жильё, офисы, выставочные залы, музеи – то есть во всё то, что не касается производства.
В ходе обсуждения проекта с Заказчиком мы определили три основные задачи. Первая – сохранить вид по Зубову переулку на усадьбу Всеволожских. На нее раскрывалась красивая видовая ось от Садового кольца, поэтому любое тотальное закрытие территории комплекса было исключено. Второе – мы хотели показать особенности современной трактовки промышленной архитектуры. И последнее – мы хотели добиться эффектной «развертки» красно-кирпичных корпусов по улице Тимура Фрунзе.
Для решения первой задачи предложили стеклянный забор, который не закрывает вид на усадьбу. Для модернизации внешнего вида здания к торцу установлена стеклянно-металлическая «табуретка» обозначившая главный вход в будущий банк. Поиск решения третьей задачи оказался наиболее интересным в данном проекте. Наружные стены были покрашены и для воссоздания единого комплекса нескольких промышленных красно-кирпичных корпусов – краску сняли. Здание оказалось беззащитным перед осадками, кладка требовала ремонта. Ремонт стены провели используя кирпичную смесь на основе боя старого кирпича, но заплаты выделялись на общем фоне. После долгих поисков удалось выбрать гидрофобный состав, позволяющий скрыть разницу между старыми и новыми участками стены. Кладочные швы решили не выявлять, сохранив их совпадения по уровню с поверхностью стены. Таким образом, потеряв некоторую тектоничность, стена приобрела современный образ плоскости-ограждения. Этим объектом мастерская отдала дань общепринятому подходу к работе с промышленной архитектурой – переоборудование и реновация, то есть «как у всех».
***
2.
Котельная как популярный арт-объект
Здание котельной. Реализация, 2008 © Архстройдизайн
«В работе над проектом котельной в Павшинской пойме, заказчик поставил задачу сделать арт-объект, потратил денег в три раза больше, чем от него бы потребовалось, если бы работа велась исключительно над функцией как это принято для подобных объектов. Результат – действительно фотогеничный арт-объект, привлекающий киношников и телевизионщиков. На её фоне уже снято несколько эпизодов разных фильмов, к примеру, в 2014 году там снимали фильм Анны Меликян «Звезда». Неожиданно котельная стала настоящем возбудителем творческой активности.
Съемка фильма Анны Меликян «Звезда» на фоне котельной, 2014 © Архстройдизайн
Технически подход к этой работе оказался достаточно простым. Сегодняшнее оборудование котельной, как и двести лет назад, очень красиво само по себе – чугунные, а теперь стальные котлы с трубами из нержавеющей стали, переплетения мостов и лестниц. Это оборудование уже кажется экспонатом современного дизайна, именно это мы и решили использовать. Для каждого котла мы установили своё окно-витрину, а для диспетчера создали офис, завершённый огромным круглым окном. Для придания драматизма композиции здание облицовано красным и темно-коричневым бельгийским кирпичом ручной формовки, который создает флёр старого промышленного объекта, будто бы пережившего тяжелые времена».
Здание котельной. Реализация, 2008 © Архстройдизайн
***
3.Промышленная архитектура как городской квартал
Административно-офисное здание с водогрейный котельной в г. Одинцово. Вид со стороны ул. Западная. Проект, 2015 © Архстройдизайн
«Спустя семь лет тот же заказчик обратился с предложением сделать котельную на улице Садовая в г. Одинцово. Наша идеология отношения к технологии как к произведению искусства сохранилась, но всё-таки в этот раз целью стала задача создания нового образа промышленного здания, как естественной части жилой среды. Участок опять оказался в центре района, и, соответственно, нужно было придумать адаптируемый образ.
Для того, чтобы снять присущую промышленному объекту агрессивность по отношению к жилью, мы перевели котельную вглубь участка, выставив перед ней другой дополнительный объем и попробовав, таким образом, создать образ жилого квартала с внутренним двором. При этом общий план раскрывается в сторону стеклянного портала котельной, за которым снова видно оборудование.
Административно-офисное здание с водогрейный котельной в г. Одинцово. Проект, 2015 © Архстройдизайн
Административно-офисное здание с водогрейный котельной в г. Одинцово. Проект, 2015 © Архстройдизайн
Административно-офисное здание с водогрейный котельной в г. Одинцово. Проект, 2015 © Архстройдизайн
Административно-офисное здание с водогрейный котельной в г. Одинцово. Проект, 2015 © Архстройдизайн
Генплан во многом был продиктован требованиями технологий – объездные дороги, закопанные резервуары, необходимые расстояния от них до административных помещений или парковок – всё это привело к функциональной схеме, которая, тем не менее, оказалась достаточно живой. Внутренний двор превратился в ресторан. То, что мы называем диспетчерской, по нормам может быть переоборудовано в офисное здание с фитнесом и другими административными помещениями.
Оказалось, что в этом случае котельная с дополнительными корпусами превратилась в гибкий архитектурный объект, который мы можем трактовать как музей, как жилой квартал, как офисный центр – как что угодно типично городское».
Административно-офисное здание с водогрейный котельной в г. Одинцово. Проект, 2015 © Архстройдизайн
Административно-офисное здание с водогрейный котельной в г. Одинцово. Генеральный план. Проект, 2015 © Архстройдизайн
***
4.
Котельная как городской парк
ЦТП в Одинцово © Архстройдизайн
«Здесь речь идёт снова о городе Одинцове и переоборудовании котельной под тепловой пункт в составе двадцатиэтажного здания. Снова расположение котельной было центральным – она замыкала видовую ось улицы Маршала Бирюзова. Здесь напрашивалась доминирующая вертикаль на пересечении пешеходных путей. Занимаясь освоением участка, мы поняли, что невозможно не затронуть детский парк, то есть необходимо каким-то образом привязать его к нам. За ним есть ещё один парк с церковью, а рядом расположен центральная площадь, тоже похожая на парк – уникальный объект благоустройства: подобный есть в Зеленограде, в Ижевске, что-то похожее на корбьюзеанскую площадь со свободным расположением городских общественных объектов, находящихся в окружении зелёных насаждений и водоема.
ЦТП в Одинцово. Генеральный план © Архстройдизайн
Котельная послужила своеобразным катализатором создания единой парковой зоны в центре города. К сожалению, в проекте удалось не всё: мы пробили оси, но, не имея возможности проходить сквозь здания, пришлось их огибать. Мы воспринимаем это как упражнение – неожиданно промышленный объект превращается в узловой пункт для развития паркового хозяйства.
К сожалению, нам не удалось реализовать этот проект, он остался «в ящике» мастерской».
***
5.
Промышленная архитектура для формирования ансамбля
Реконструкция кондитерско-булочного комбината «Простор». Проект, 2015 © Архстройдизайн
«Конкурс по реконструкции части помещений и фасадов комбината «Простор», который мы выиграли в команде с архитекторами бюро Manipulazione Internazionale в 2015 году, на стадии проектной документации перерос в проект масштабной реконструкции зданий с пристройкой нескольких новых сооружений.
Основной задачей конкурса была идея приведения фасадов в соответствие с внутренним высокотехнологическим производством. Предложение по фасадам сделали архитекторы Manipulazione Internazionale, но когда конкурс перерос в проект полного переустройства промышленного комплекса, мы занялись внедрением в технологию транспортного обслуживания и освоением территории.
Итак, это промышленный объект, полностью сохранивший свою первоначальную функцию. Мы учитывали, что в отличие от общественного, такой объект впускает в себя только триста человек, работающих там. Поэтому архитектура может работать здесь исключительно внешней стеной. Чтобы не мешать производству, правильнее возвести пару новых зданий в глубине двора, на месте складов, нежели вторгаться в действующее предприятие. Так на южной границе участка появился бытовой корпус, вместивший общежитие для сотрудников и технические помещения. Было спроектировано здание морозильного склада и склада упаковочных материалов.
Реконструкция кондитерско-булочного комбината «Простор». Въездная группа. Проект, 2015 © Архстройдизайн
Основные изменения затронули прямоугольный в плане производственный цех переменной этажности с перепадом от одного до четырёх этажей. Здесь надстройки появились, – над складскими помещениями. Со стороны двора на новых фундаментах возвели дополнительную шестиэтажную пристройку с производственной и складской функциями. По внешнему периметру в первых этажах разместился профильный магазин.
Главный вывод из опыта работы с промобъектами состоит в том, что поэт оказался прав: проектировать производство – занятие благородное. Вне зависимости от архитектурного результата – результат всегда положительный».
Реконструкция кондитерско-булочного комбината «Простор». Фасад бытового и производственного корпусов. Фасад. Проект, 2015 © Архстройдизайн
Реконструкция кондитерско-булочного комбината «Простор». Фасад бытового и производственного корпусов. Фасад. Проект, 2015 © Архстройдизайн
Реконструкция кондитерско-булочного комбината «Простор». Генеральный план. Проект, 2015 © Архстройдизайн
***
Архитекторы:
Архитектор:
Алексей ИвановМастерская:
Архстройдизайн АСДПохожие статьи
Мнение
Пользы не сулит, но выглядит безвредно Мы попросили Марию Элькину, одного из авторов обнародованного в августе 2020 года письма с критикой законопроекта об архитектурной деятельности, прокомментировать новую критику текста закона, вынесенного на обсуждение 19 января. Вывод – законопроект безвреден, но архитектуру надо выводить из 44 и 223 ФЗ.Мнение
Буян и суд Новость об отмене парка Тучков буян уже неделю занимает умы петербуржцев. В отсутствие каких-либо серьезных подробностей, мы поговорили о ситуации с архитекторами парка и судебного квартала: Никитой Явейном и Евгением Герасимовым.Мнение
Григорий Ревзин об ЭКСПО 2020: Европа и отказ от формы Рассматривая тематические павильоны и павильоны европейских стран, Григорий Ревзин приходит к выводу, что «передовые страны показывают, что архитектура это вчерашний день», главная тенденция состоит в отсутствии формы: «произведение это процесс, лучшая вещь – тусовка вокруг ничего».Мнение
Григорий Ревзин об ЭКСПО 2020: Россия и Америка Следующий пост Григория Ревзина из серии об ЭКСПО 2020 посвящен сравнению павильонов США и России. Оно получилось в пользу России.Мнение
Григорий Ревзин об ЭКСПО 2020: «страны с проблематичной. .. Продолжаем публиковать тексты Григория Ревзина об ЭКСПО 2020. В следующий сюжет попали очень разные павильоны от Белоруссии до Израиля, и даже Сингапур с Бразилией тоже здесь. Особняком стоит Польша: ее автор считает «играющей в первой лиге».Мнение
Григорий Ревзин об ЭКСПО 2020: арабские страны Серия постов Григория Ревзина об ЭКСПО 2020 на fb превратилась в пространный, остроумный и увлекательный рассказ об архитектуре многих павильонов. С разрешения автора публикуем эти тексты, в первом обзоре – выставка как ярмарка для чиновников и павильоны стран арабского мира.Мнение
Помпиду наизнанку Ренцо Пьяно и ГЭС-2 уже сравнивали с Аристотелем Фиораванти и Успенским собором. И правда, она тоже поражает высотой и светлостию, но в конечном счете оказывается самой богатой коллекцией узнаваемых мотивов стартового шедевра Ренцо Пьяно и Ричарда Роджерса, Центра Жоржа Помпиду в Париже. Мотивы вплавлены в сетку шуховских конструкций, покрашенных в белый цвет, и выстраивают диалог между 1910, 1971 и 2021 годом, построенный на не лишенных плакатности отсылок к главному шедевру. Базиликальное пространство бывшей электростанции десакрализуется практически как сам музей согласно концепции Терезы Мавики.Мнение
Спасение Саут-стрит глазами Дениз Скотт Браун Любое радикальное вмешательство в городскую ткань всегда вызывает споры. Джереми Эрик Тененбаум – директор по маркетингу компании VSBA Architects & Planners, писатель, художник, преподаватель, а также куратор выставки Дениз Скотт Браун «Wayward Eye» на Венецианской биеннале – об истории масштабного проекта реконструкции Филадельфии, социальной ответственности архитектора, балансе интересов и праве жителей на свое место в городе.Мнение
Победа прагматиков? Хроники уничтожения НИИТИАГа НИИ теории и истории архитектуры и градостроительства сопротивляется реорганизации уже почти полгода. Сейчас, в августе, институт, похоже, почти погиб. В недавнем письме президенту РФ ученые просят перенести Институт из безразличного к фундаментальной науке Минстроя в ведение Минобрнауки, а дирекция говорит о решимости защищать коллектив до конца. Причем в «обстановке, приближенной к боевой» в институте продолжает идти научная работа: проводят конференции, готовят сборники, пишут статьи и монографии.Мнение
Есть ли места на Олимпе? Сексизм и «звездность» в архитектуре «Есть ли места на Олимпе? Сексизм и «звездность» в архитектуре» Дениз Скотт Браун – это результат личного исследования вопросов авторства, иерархической и гендерной структуры профессии архитектора. Написанная в 1975 году, статья увидела свет лишь в 1989, когда был издан сборник «Architecture: a place for women». С разрешения автора мы публикуем статью, впервые переведенную на русский язык.Мнение
Пять главных больных тем охраны наследия В преддверии фестиваля «Архитектурное наследие» публикуем несколько мнений – Ирины Крымовой, Ирины Маркиной и Петра Черненко – об актуальных российских проблемах в области охраны наследия.Мнение
ВХУТЕМАС versus БАУХАУС Дмитрий Хмельницкий о причудах историографии советской архитектуры, о роли ВХУТЕМАСа и БАУХАУСа в формировании советского послевоенного модернизма.Мнение
Архитектурный протекционизм по-шведски Башни-близнецы бюро OMA в Стокгольме не получили главную архитектурную награду Швеции: это не просто каприз жюри, объясняет Елена Волкова.Мнение
Еще одна история Рассказ Феликса Новикова о проектировании и строительстве ДК Тракторостроителей в Чебоксарах, не вполне завершенном в девяностые годы. Теперь, когда рядом, в парке построено новое здание кадетского училища, автор предлагает вернуться в идее размещения монументальной композиции на фасадах ДК.Мнение
Игорь Каширин: «Давайте раздвигать границы, а не сужать. .. Архитектор Игорь Каширин – о проекте закона об архитектурной деятельсноти.Мнение
Михаил Бейлин: «Закон даёт архитекторам призрачные… Соонователь CITIZENSTUDIO – о законопроекте об архитектурной деятельности.Мнение
Закон об архитектурной деятельности: ответ Николая. .. Публикуем текст письма президента САР и СМА Н.И. Шумакова – ответ на письмо архитекторов о проекте Закона об архитектурной деятельности, обнародованное недавно.Мнение
Феликс Новиков: ответ Сергею Кузнецову Ответ на ответ главного архитектора Москвы, опубликованный на прошлой неделе.Мнение
Сергей Скуратов: «Школа должна была стать жемчужиной. .. Говорим с Сергеем Скуратовым о результатах конкурса на здание в центре комплекса, которым архитектор занимается с 2006 года. Показываем не победивший конкурсный проект и делаем попытку изучить случай.Мнение
О недостроенном Новокировском проспекте и недостроенной… Воспоминания Феликса Новикова об истории одного из его ключевых, но многострадальных проектов.Мнение
К проблеме хронологии сталинской архитектуры Дмиртий Хмельницкий – о том, что советский конструктивизм последних лет был, на самом деле, сталинской архитектурой: «по социальному смыслу, типологии и функциональному содержанию».Мнение
Арки, ворота, окна, проемы, пустоты, дырки В архитектуре АБ «Остоженка», особенно в крупных комплексах, значительную роль играют арки, организующие пространство и массу: часто большие, многоэтажные. В публикуемой статье Александр Скокан размышляет о роли и смысле масштабных цезур, проемов и арок.Мнение
Вавилонская башня культуры? Реконструкция ГЭС-2 для Фонда V-A-C по замыслу Ренцо Пьяно в центре Москвы – яркий пример глобальной архитектуры, льстящей заказчику, но избежать воздействия сложного контекста этот проект все же не может.Мнение
Миф о советском ар-деко Или как называть сталинскую архитектуру?Мнение
WAF 2019: в ожидании финала Говорим c авторами проектов, вышедших в финал премии WAF: об их взгляде на фестиваль, о проектах и вероятных способах презентации.Мнение
Проект Россия 88/89: архитектура вокруг человека Главный редактор журнала Проект Россия Юлия Шишалова объясняет, почему номер, посвященный общественным интерьерам, получился двойным и почему добрая пятая часть журнала посвящена теме НЭР.Мнение
Архитектор об архитектуре и архитекторах Тезисное изложение лекции Александра Скокана. Авторский подзаголовок – субъективная попытка рассказать о профессиональных проблемах.Мнение
Пять вредных вопросов Интернет-издание Fast Company попыталось выяснить, какие вопросы лучше не задавать самому себе, чтобы не растерять свой творческий потенциал. К разговору о проблеме подключились специалисты, которые исследуют творчество или работу мозга.Мнение
Недостройка XX века Феликс Новиков – о том, как достроить дворец пионеров.Мнение
Оценённый «своими», но ненужный большинству Дом-призёр RIBA в Лондоне хотят снести из-за «ужасного» внешнего вида и недовольства соседей.Технологии и материалы
5 правил типового проекта загородного дома – практикум… Как архитектору создать успешный типовой проект и избежать ошибок?На примере барнхауса из керамических блоков Wienerberger рассказываем ключевые идеи нового практикума в «Школе проектировщика» Шесть общественных комплексов, реализованных с применением. .. Технологии КНАУФ АКВАПАНЕЛЬ® давно завоевали признание в отечественной строительной отрасли. Особенно в области общественных зданий, к которым предъявляются особые требования по безопасности, огнестойкости, вандалоустойчивости. При этом, технологии «сухого строительства» значительно сокращают монтажные работы. Кирпич плюc: с чем дружит кладка С какими материалами стоит сочетать кирпич, чтобы превратить здание в архитектурное событие? Отвечаем на вопрос, рассматривая знаковые дома, построенные в Петербурге при участии компании «Славдом». «ОртОст-Фасад»: старт Национального исторического… Компания «ОртОст-Фасад» закончила работы по отделке фасадов Детского художественно-эстетического центра «Школа искуств» – первого объекта в масштабном комплексе Национального исторического парка Херсонес 5 октября 2022
Государственный музей архитектуры… Для архитекторов, проектировщиков, застройщиков, девелоперов Pipe Module: лаконичные световые линии Новинка компании m³light – модульный светильник из ударопрочного полиэтилена. Из такого светильника можно составлять различные линии, подчеркивая архитектуру пространства Быстро, но красиво Ведущий производитель стеновых ограждающих конструкций группа компаний «ТехноСтиль» выпустила линейку модульных фасадов Urban, которые можно использовать в городской среде.
Быстрый монтаж, высокие технические показатели и новый уровень эстетики открывают больше возможностей для архитекторов. Фактурная единица Завод «Скрябин Керамикс» поставил для жилого комплекса West Garden, спроектированного бюро СПИЧ, 220 000 клинкерных кирпичей. Специально под проект был разработан новый формат и цветовая карта. Рассказываем о молодом и многообещающем бренде. Чувство плеча Конструкция поручней DELABIE из серии Nylon Clean дает маломобильным людям больше легкости в передвижениях, а специальное покрытие обладает антибактериальными свойствами, которые сохраняются на протяжении всего срока эксплуатации. Красный кирпич от брутализма до постмодернизма Вместе с компанией BRAER вспоминаем яркие примеры применения кирпича в архитектуре брутализма – направления, которому оказалось под силу освежить восприятие и оживить эмоции. Его недавний опыт доказывает, что самый простой красный кирпич актуален.
Может быть даже – более чем. Стекло для СБЕРа:
свобода взгляда Компания AGC представляет широкую линейку архитектурных стекол, которые удовлетворяют современным требованиям к энергоэффективности, и при этом обладают превосходными визуальными качествами. О продуктах AGC, которые бывают и эксклюзивными, на примере нового здания Сбербанк-Сити, где были применены несколько видов премиального стекла, в том числе разработанного специально для этого объекта Искусство быть невидимым Архитекторы Александра Хелминская-Леонтьева, Ольга Сушко и Павел Ладыгин делятся с читателями своим опытом практики применения новаторских вентиляционных решеток Invisiline при проектировании современных интерьеров. «Донские зори» – 7 лет на рынке! Гроссмейстерские показатели российского производителя:
93 вида кирпича ручной формовки, годовой объем – 15 400 000 штук,
морозостойкость и прочность – выше европейских аналогов,
прекрасная логистика и – уже – складская программа!
А также: кирпичи-лидеры продаж и эксклюзив для особых проектов Дома из Porotherm
на Open Village 2022 Компания Wienerberger приглашает посетить выставку
Open Village с 16 по 31 июля
в коттеджном поселке «Тихие Зори» в Подмосковье. Этим летом вы сможете увидеть 22 дома, построенных по различным технологиям. Вопрос ребром Рассказываем и показываем на примере трех зданий, как с помощью системы BAUT можно создать большую поверхность с «зубчатой» кладкой: школа, библиотека и бизнес-центр. HPL – панели Fundermax Individualdecor это новое слово в дизайне… HPL-панели Fundermax сочетают в себе все самые актуальные свойства отделочных материалов и предлагают максимальную свободу для творчества и дизайна. Тульский кирпич Завод BRAER под Тулой производит 140 миллионов условного кирпича в год, каждый из которых прослужит не меньше 200 лет. Рассказываем, как устроено передовое российское предприятие. Стильная сантехника для новой жизни шедевра русского… Реставрация памятника авангарда – ответственная и трудоемкая задача. Однако не меньший вызов представляет необходимость приспособить экспериментальный жилой дом конца 1920-х годов к современному использованию, сочетая актуальные требования к качеству жизни с лаконичной эстетикой раннего модернизма. В этом авторам проекта реставрации помогла сантехника немецкого бренда Duravit. Своя игра «Новые Горизонты» предлагают альтернативу импортным детским площадкам: авторские, надежные и функциональные игровые объекты, которые компания проектирует и строит уже больше 20 лет. Устойчивость.
Путь материализации. Кирпич АРХ-Москва 2022: Компания КИРИЛЛ представляет
инсталляцию НЕБО и ЗЕМЛЯ из 20-ти видов российского кирпича ручной работы брендов Донские зори, ModFormat, Edelhaus klinker
Сейчас на главной
Премия
Зодчество: лауреаты 2022 В пятницу в Гостином дворе вручили награды фестиваля Зодчество 2022. Хрустальный Дедал достался ЖК Veren Village архитекторов АБ «Остоженка». Татлин, премию за проект, решили не присуждать. Рассказываем, кого наградили, публикуем полный список.Объект
Школа на деревянной подкладке Коллеж имени Жана Ростана со спортивным залом в Орлеане. Авторы проекта – бюро archi5.send.project
Школа как сообщество Лондонское бюро AdjoubeiScott-Whitby Studio превратило здание Александровского училища в Калуге в уникальную школу на 150 учеников. Здание начала XX века адаптировали под британскую образовательную систему – как в программном смысле, так и в архитектурном.send.project
Пена дней В интерьере ресторана Sparkle бюро Archpoint переосмысляет эстетику винных погребов и обращается к образам, связанным с игристым вином – пузырькам, пене и жизнелюбию.Объект
Небоскреб с оазисами В Сингапуре завершено строительство небоскреба по проекту архитекторов BIG. Управляющим системами здания искусственным интеллектом и другими цифровыми компонентами занималось бюро CRA – Carlo Ratti Associati.Репортаж
Королевство зеркал На XXX по счету Зодчестве столько решеток и зеркал, что эффект дробления реальности на кусочки многократно усиливается. Только ради этого ощущения стоит посетить фестиваль. Но кроме того выставка богата, разнообразна и работает как хорошо отлаженная машина по всем направлениям: губернскому, студенческому, арт-объектному, круглостольному и прочим. Делать бы и делать такие фестивали.Репортаж
Градсовет Петербурга 28.09.2022 Эксперты градсовета нашли проект жилого комплекса на проспекте Маршала Казакова серым и монотонным, как пасмурный день в Петербурге.send.project
Руин-бар Нижегородский бар, спроектированный Fruit Design Studio, совмещает эстетику запустения с дворцовой роскошью, созданной из черновых материалов – бетона, армированного стекла и грубого металла.Интервью
Александра Кузьмина: «Я с нетерпением жду реализации… Московская область есть отражение всей страны – так стенд МО на «Зодчестве» будет раскрывать тему фестиваля. Покажут 42 проекта. Говорим с главным архитектором области о специфике и тенденциях.Премия
Обещания и надежды Объявлены шесть лауреатов Премии Ага Хана 2022. Они обещают лучшее будущее людям, демонстрируют новаторство и заботу о природе.send.project
Оазис в дождливом городе Бюро MAD Architects разработало интерьер первого в Петербурге коворкинга сети SOK. Его отличительная черта – обилие зелени и элементов биофильного дизайна, характерная для города колористика и отсылки к литературному наследию.Объект
Катализатор инноваций Проект OMA для здания нового института в Университете штата Иллинойс в Чикаго.Обзор
Зодчество: шесть событий Уже в среду в Гостином дворе стартует юбилейное, тридцатое «Зодчество». Рассказываем о том, что в этом году будет на фестивале.Интервью
KOSMOS: «Весь наш путь был и есть – поиск и формирование. .. Говорим с сооснователями российско-швейцарско-австрийского бюро KOSMOS Леонидом Слонимским и Артемом Китаевым: об учебе у Евгения Асса, ценности конкурсов, экологической и прочей ответственности и «сообщающимися сосудами» теории и практики – по убеждению архитекторов KOSMOS, одно невозможно без другого.Премия
Глядя в небо В Саратове названы победители фестиваля короткометражных любительских роликов, посвященных архитектуре. Фильм, приглянувшийся редакции, занял 1 место. Размышляем о типологии, объясняем выбор, «показываем кино».Объект
Заплыв за книгами Водоем на кровле у библиотеки в провицнии Гуандун сделал ее «подводной»: читатели как будто ныряют туда за книгами. Авторы проекта – 3andwich Design / He Wei Studio.send. project
Мои волжские ночи Павильон для кинопоказов и фестивалей на набережной Саратова: ажурные стены, пропускающие речной простор, и каннская атмосфера внутри.send.project
Японский дворик Концепция благоустройства жилого комплекса у Москвы-реки, вдохновленная модернистскими садами и японскими традициями: гравюры Кацусика Хокусай, герои Хаяо Миядзаки и пространства для созерцания.Объект
Лекции отменяются Новый корпус Амстердамского университета прикладных наук рассчитан на новый тип образования: меньше лекций, больше проектной работы.Результаты конкурса
Дружелюбная простота Публикуем проект IND Architects и Do buro, победивший в конкурсе на концепцию общественного центра «Прокшино».Объект
Лаборатория для жизни Здание Лаборатории онкоморфологии и молекулярной генетики, спроектированное авторским коллективом под руководством Ильи Машкова («Мезонпроект»), использует преимущества природного контекста и предлагает пространство для передовых исследований, дружественное к врачам и пациентам.Объект
Индустриальная романтика Atelier Liu Yuyang Architects превратило заброшенный корпус теплоэлектростанции и часть территории набережной реки Хуанпу в Шанхае в атмосферное городское пространство, романтизирующее промышленное прошлое территории.Премия
Архивуд–13: Троянский конь Вручена тринадцатая по счету подборка дипломов премии АрхиWOOD. Главный приз – очень предсказуемый – парку Веретьево, а кто ж его не наградит. Зато спецприз достался Троянскому коню, и это свежее слово.Работы студентов
Судьбы агломерации Летняя практика Института Генплана была посвящена Новой Москве. Всего получилось 4 проекта с совершенно разной оптикой: от масштаба агломерации до вполне конкретных предложений, которые можно было, обдумав, и реализовать. Рассказываем обо всех.send.project
Твой морепродукт Пожалуй, первая в истории Архи.ру публикация, в которой есть слово «сексуальный»: яркий и чувственный интерьер для рыбного ресторана без прямых линий и прямолинейных намеков.Объект
Каньон для городской жизни В Амстердаме открылся комплекс Valley по проекту MVRDV: архитекторы соединили офисы, жилье, развлекательные заведения и даже «инкубатор» для исследователей с многоуровневым зеленым общественным пространством.send.project
Интерьер как пейзаж Работая над пространствами отеля в Светлогорске, мастерская Олеси Левкович стремилась дополнить впечатления, полученные гостями от природы побережья Балтийского моря.send.project
Законченный образ Каркасный дом с тремя спальнями и террасой, для которого архитекторы продумали не только технологию строительства, но и обстановку – вся мебель и предметы быта также созданы мастерской Delo.Объект
Обучающее пространство Начальная школа Фуцян в Шэньчжэне по проекту People’s Architecture Office.Результаты конкурса
Золотая капитель 2022 Рассказываем об итогах архитектурного рейтинга «Золотая капитель», который прошел в Новосибирске в 26-й раз. Главная награда – у архитектурного бюро ГОРА.О заполнении шаблона описания архитектуры решения – Архитектура ИТ-решений
Описание архитектуры ИТ-решения не самая простая практика. И уж точно не следует приступать к её освоению с заполнения шаблона описания архитектуры. Тем не менее, такого рода шаблоны существуют и кто-либо из представителей заказчика информационной системы не редко требует описать архитектуру. Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором, и потому я возьму на себя смелость дать несколько рекомендаций о том, как это следует делать. Обычно, в качестве шаблона используются производные от RUP-овского Software Architecture Document скачать который можно, например, здесь. Существенно реже можно встретить TOGAF-овский Architecture Definition Document и уж вряд ли вам попадется ISO-шный Architecture description. Поэтому ориентироваться будем на первый шаблон. Разделы такого документа кроме введений и определений включают следующий набор архитектурных представлений:
- Use-case view
- Logical view
- Process view
- Deployment view
- Implementation view
- Data view (optional)
В общем, все в строгом соответствии с моделью архитектуры «4+1 architectural view model» от Philippe Kruchten (Иногда к перечисленным разделам добавляют описания программных интерфейсов. Я же люблю дополнять этот документ разделом «Открытые вопросы и предположения».) Казалось бы, все просто. Берем книжку по UML и начинаем рисовать картинки. Сначала UML диаграмму вариантов использования, потом диаграмму классов и т.д… А вот и ни разу не так!
Замечание 1. Разработка архитектуры решения – это процесс, состоящий, как минимум, из следующих этапов:
- Анализ и структурирование в виде моделей требований и прочей проектной информации. Кстати, для значительного количества моделей, полученных в ходе структурирования проектных данных, раздела в шаблоне не найдется. Это не значит, что их не надо включать в описание архитектуры.
- Выбор варианта реализации.
- Описание варианта реализации.
- Согласование предложенной архитектуры.
Это надо учитывать при планировании и оценке трудоемкости. Кроме того, каждый этап требует различных действий. На первом этапе мы не собираем требования. Сбор требований – задача аналитика и в том или ином виде они должны быть. Мы внимательно их читаем, уточняем, задаем вопросы и структурируем их в виде моделей. Это может быть итеративный процесс внесения структуры в поток требований, но такой поток должен быть. Нет требований – нет архитектуры. Далее. Выбирать и согласовывать вариант реализации лучше до того, как мы плотно займемся его описанием. Меньше придется переписывать. Непосредственно проектирование, т.е. придумывание из головы чего-то нового, занимает незначительную часть времени. Как правило, за нас все уже придумали и потому:
Замечание 2. Традиционный процесс проектирования не подходит для большинства проектов. Обычно в проектах используются уже готовые системы, так называемые COTS (Commercial off the shelf ) или уже существующие ИТ-решения. И потому все перечисленные модели надо основывать на описании уже существующих приложений. Правда, частенько, таких документов не существует и вот их приходится собирать(создавать заново). Тем не менее, вы не можете придумать заново ни свою модель данных, ни компонентную структуру системы, ни варианты использования. Все что вы можете сделать, так это «вписать» требования в существующие решения. Иначе, в худшем случае ваша архитектура нанесет непоправимый вред существующей системе, нарушив её концептуальную целостность, а в лучшем – вашу архитектуру просто выкинут и сделают по-своему. С данными ситуация не самая сложная. Все сущности, которые вы хотите реализовать в системе, должны являть частными случаями уже существующих сущностей. В каком-то смысле это напоминает отношение наследования в диаграмме классов. Но не всегда архитектура используемой системы позволяет реализовать отношения наследования. Чаще работа заключается в том, что вы берете существующую модель данных и придумываете набор типов (стереотипов) для того, что вам нужно на этой модели создать: создаете список типов обращений, придумываете поля заявок и workflow их обработки и т.п. С компонентами – хуже. В принципе, готовая программная платформа должна поставлять вам узлы(nodes, говоря языком UML) для создания и развертывания ваших новых компонент. SQL server(узел) служит для того, чтоб вы создавали собственные компоненты со стереотипами таблица, отношение, хранимая процедура и т.д., BPMS – для моделей процессов, джава-портал – для создания портлетов и т.п. Но когда речь заходит не о программных платформах, а о бизнес-приложениях все становиться загадочным и туманным. Готовое решение, вроде бы есть, но достоверных данных о том, как его следует использовать, что и где на ней нужно создавать и развертывать нет. Это не правильно. Я бы воздержался от использования таких систем.
Замечание 3. На каком уровне детализации остановиться? Безусловно, ответ на этот вопрос зависит от целей разработки описания архитектуры. Обычно, мы делаем описание архитектуры решения для проекта. Для того, чтоб распланировать фазу «реализация», успешно произвести разработку(доработку) ИТ-систем, осуществить их развертывание и ввод в эксплуатацию. Потому и детализация должна быть достаточной для решения этих задач. Каждый квадратик с архитектурных рисунков превращается в строчку проектного плана, а стрелочки показывают взаимозависимость работ. Практически как на UML диаграмме развертывания. Зависимость одного компонента от другого говорит о том, что нет смысла приступать к его разработке не дождавшись хотя бы спецификации программного интерфейса от второго компонента. Вообще, все эти квадратики нужны для того, чтоб можно было выделить набор работ, которые можно будет вести параллельно, не таская всех участников проекта на многочасовые совещания. Наличие архитектуры помогает сохранить доверие между командами или индивидуумами, позволяя им действовать независимо друг от друга. Как правило, в отдельный набор задач можно вынести закупку лицензий и оборудования и разработку ПО. Описание процессов позволяет разделить разработку с подготовкой и согласованием инструкций и регламентов. Внутри разработки одна команда идет писать базу данных, другая бизнес-логику, третья – отчетность четвертая интеграцию с внешними источниками и т.д. Если кто-то настаивает на излишней детальности архитектурного описания и не может ответить на вопрос – зачем это нужно, то данного персонажа следует вежливо послать. Можно использовать и более миролюбивую модель процесса проектирования – каждый создает свой раздел документа, а архитектор сводит все в единое целое. В общем, конечно, замечания довольно поверхностные. Кому-то они могут показаться банальными (но тогда возьмите и допишите в эту заметку свой раздел). Но, если не следовать хотя бы этим рекомендациям, смысла в проектировании ИТ-решений будет не много
Ссылки по теме:
- Роль ИТ-архитектора в организации
- Интеграция новых приложений в корпоративный ИТ-ландшафт
- Software product management (3) Change management
- О вреде проектного управления
Картинка взята с сайта: http://www.uml-diagrams.org/
Опубликовано Автор Максим СмирновРубрики Software architectureМетки 4+1, UMLПрактический пример — Solutioned
СОДЕРЖАНИЕ
- Введение
- Архитектура решений
- Стратегический уровень
- Бизнес -слой
- Данные и прикладные уровни
- .
Это вторая статья из серии из двух частей, в которой рассматривается пример того, как принципы архитектуры предприятия соотносятся с вымышленным бизнесом. В первой части основное внимание уделялось эталонной архитектуре с уделением особого внимания обсуждению уровней мотивации и стратегии. Эта статья расширяет предыдущую работу и фокусируется на архитектуре решения. В нем будет более подробно рассмотрена практическая реализация в технологии стратегий, рассмотренных как часть эталонной архитектуры в предыдущей статье. Примечательно, что в эталонной архитектуре определены четыре (4) бизнес-процесса, которые способствуют реализации стратегии: машинное обучение и анализ данных, управление инфраструктурой, информационная безопасность и разработка программного обеспечения. Однако для краткости в этой статье будет рассмотрена архитектура решения только для одного (1) из четырех (4), а именно для машинного обучения и анализа данных.
Как и в предыдущей статье, для иллюстрации дизайна мы будем использовать вымышленную кадровую компанию Demo Staffing Company Inc. Кратко напомним, что бизнес-модель Demo Staffing Company Inc. основана на предоставлении талантливых кандидатов крупным корпоративным клиентам. Клиенты обратились бы к компании со своими потребностями, и компания использовала бы свою сеть, чтобы соответствовать этим потребностям с кандидатами. Для роста своего бизнеса компания должна максимально удовлетворять своих клиентов, чтобы укрепить свой бренд в высококонкурентной отрасли. Машинное обучение и анализ данных — это один (1) из четырех (4) бизнес-процессов, которые компания определила как ключевые для достижения своей цели.
Архитектура решения
Что это такое и почему вас это должно волновать?
Архитектура решений — это дисциплина архитектуры предприятия, целью которой является определение и описание конкретных систем. Это может быть система, состоящая из систем, или она может подробно описывать одну систему. Например, он может отображать элемент дизайна, обозначенный как «вычислительный кластер», который по определению представляет собой систему систем. Кластер может быть частью более широкой архитектуры решения. В качестве альтернативы, дизайн может быть расширен за счет компонентов одного сервера, одной системы, которая является частью кластера, чтобы показать детали ее оборудования, сети, физического местоположения, ее операционной системы, программного обеспечения и так далее.
Архитектура решения отличается от эталонной архитектуры, которая стремится описать более широкую точку зрения и обычно более тесно связана с бизнес-мотивациями, целями и стратегиями более высокого уровня. Считайте эталонную архитектуру подробным описанием, связывающим бизнес-цели с технологиями, а архитектуру решения — узким и конкретным описанием того, как внедрять технологии для достижения указанных бизнес-целей.
Вы должны заботиться об архитектуре решения, потому что ее ценностное предложение подробно показывает, как системы взаимодействуют, чтобы обеспечить практическую и измеримую ценность для вашего бизнеса. Он обеспечит достаточный уровень детализации реализации, чтобы служить пособием для технических ролей (таких как ученые, разработчики и инженеры), ответственных за оснащение и поставку системы. Это облегчит регулярную коррекцию курса во время внедрения, чтобы смягчить расползание области. Он будет служить справочным документом для партнеров и заинтересованных сторон. Разработка проверенной, надежной архитектуры решения перед началом проекта гарантирует, что ваш бизнес не тратит ценные и, вероятно, дорогостоящие циклы, двигаясь в неоптимальном направлении при развертывании.
Определив архитектуру решения, давайте теперь посмотрим на наш пример, пройдя через уровни стратегии, бизнеса, данных и приложений, а также технологии проектирования. Проекты, показанные ниже, выполнены с использованием языка моделирования ArchiMate.
Уровень стратегии
Рис. 1. Уровень стратегии, показывающий ресурс ИТ-организацииПри обсуждении архитектуры решения для бизнес-процессов машинного обучения и анализа данных мы очень кратко рассмотрим уровень стратегии. Слой мотивации, который обычно предшествует слою стратегии, не будет включен, но вместо этого подробно обсуждается в эталонной архитектуре. Уровень стратегии здесь сильно сокращен, показывая только один (1) ресурсный элемент. Это делается исключительно для того, чтобы показать, какой ресурс назначен обсуждаемому бизнес-процессу в этой архитектуре решения. Другие элементы (также включенные в эталонную архитектуру), такие как направления действий и возможности, которые имеют отношения назначения и реализации соответственно, снова удалены для краткости.
Бизнес-уровень
Рис. 2. Бизнес-уровень, показывающий роль и связанный с ним процессКак и на уровне стратегии, наше рассмотрение бизнес-уровня будет кратким. Он показывает только бизнес-процесс, на котором мы сосредоточимся, и назначенную ему бизнес-роль специалиста по данным. Кроме того, бизнес-уровень имеет отношения назначения с вышестоящим уровнем стратегии. То есть бизнес-роль специалиста по данным отводится бизнес-процессу машинного обучения и анализа данных. Этот бизнес-процесс, в свою очередь, назначается ресурсу ИТ-организации.
Уровень данных и приложений
Рис. 3. Уровень данных и приложений, показывающий элементы, характерные для машинного обучения и аналитикиУровень данных и приложений — это место, где мы можем начать более подробное обсуждение архитектуры решения. Этот уровень и следующий за ним технологический уровень составляют основу архитектуры решения. В приведенном выше примере показано событие приложения, процесс, служба, совместная работа, компоненты и объекты данных. Они связаны отношениями реализации, агрегации, обслуживания и доступа. Мы отмечаем, что он показывает процесс, управляемый событиями, который начинается с отправки резюме через веб-сайт и завершается сервисом данных и приложений, который предлагается вверх на бизнес-уровень. По сути, приведенное выше показывает поток данных и приложений, который обслуживает бизнес-процесс компании по машинному обучению и анализу данных.
Давайте подробно рассмотрим, как служба приложения доставляется в бизнес-процесс.
- Поток начинается с подачи заявки в форме подачи резюме на веб-сайте Demo Staffing Company Inc. Это триггерное событие, указывающее на то, что кандидат заинтересован в поиске подходящей должности у одного из клиентов компании.
- Событие запускает процесс приложения, который обслуживается службой приложения под названием «Выбор кандидата и роли».
- Выбор роли кандидата осуществляется путем совместной работы, состоящей из двух компонентов – «Анализ данных о роли должности» и «Предсказание оптимального соответствия роли должности». Эти компоненты выполняют два различных действия. Сначала для анализа имеющихся данных, а затем для использования этого анализа для оптимального подбора должностных ролей.
- Оба вышеперечисленных компонента зависят от наличия данных о доступных кандидатах, частью которых будет вновь представленное резюме, и доступных должностях, предоставляемых клиентами, которые необходимо заполнить.
Эти шаги будут прозрачными для бизнес-уровня, который просто будет понимать описанный выше поток как интерфейс службы, который он использует. Однако это все еще концептуальный поток. Как это на самом деле оборудовано с точки зрения аппаратного и программного обеспечения? Здесь обсуждение перейдет к технологическому уровню.
Технологический уровень
Рис. 4. Технологический уровень, показывающий инструментирование в облакеПоследним уровнем в этом примере архитектуры решения является технологический уровень. В частности, это вообще не было включено в эталонную архитектуру, поскольку оно явно сосредоточено на реализации. Обычно названия продуктов и технологий находятся на уровне данных и приложений, а также на технологическом уровне. Однако для целей этой демонстрации мы будем использовать в основном общие имена.
Сразу видно, что подобно тому, как уровень данных и приложений предлагает услуги бизнес-уровню, технологический уровень, в свою очередь, предлагает услуги уровню данных и приложений. Услуга «Наука о данных» фактически состоит из двух подуслуг: «Инфраструктура как услуга (IaaS)» и «База данных как услуга (DbaaS)». Они реализуются посредством двух (2) технологических коллабораций: «Управляемые вычисления в облаке» и «Управляемые контейнеры в облаке». Сообщение здесь состоит в том, что оба эти элемента представляют собой множество систем, сотрудничающих для предоставления одного технологического элемента.
Совместная работа над управляемыми вычислениями упрощена, чтобы показать поперечное сечение одного узла, «Вычислительного сервера обработки данных». Это то, что на самом деле делает работу по предоставлению услуг по науке о данных. Разворачиваем элементы, из которых состоит этот узел. Начиная с вершины стека и двигаясь вниз, мы видим язык программирования R, работающий на Apache Hadoop, который, в свою очередь, работает на Linux. Управляемые вычисления также предоставляют некоторые технологические функции, которые могут быть полезны компании. К ним относятся высокая доступность, автоматическое масштабирование и распределенные вычисления по требованию. Сообщение от этого сотрудничества заключается в том, что компания может предоставить вычислительные возможности, управляемые поставщиком, который предоставляет полезные встроенные функции, которые ей не нужно развертывать и управлять ими самостоятельно.
Наконец, совместная работа контейнеров управляемой базы данных показывает облачную реляционную базу данных с несколькими технологическими функциями, предоставляемыми поставщиком. К ним относятся высокая доступность, репликация, система управления, распределенное хранилище, бессерверные возможности и автоматизированное резервное копирование. Как и в случае совместной работы над управляемыми вычислениями, компания получает выгоду от того, что ей не нужно самостоятельно программировать, развертывать и управлять этими услугами.
Основной вывод из технологического уровня, как показано здесь, заключается в том, что компания использует общедоступное облако для снижения эксплуатационных расходов на локальную инфраструктуру.
Собираем все вместе
Как и в случае с эталонной архитектурой, давайте теперь представим полный проект, обсудив составные части. Опять же, это только один (1) из четырех (4) бизнес-процессов, которые стали бы архитектурами решений из эталонной архитектуры. Подобно эталонной архитектуре, здесь показаны отношения, существующие между самими слоями.
Рис. 5. Полная архитектура решения для машинного обученияСпасибо за внимание.
Ссылки
- https://pubs.opengroup.org/architecture/togaf91-doc/arch/index.html
- https://www.gartner.com/en/information-technology/glossary/enterprise-architecture -ea
- https://www.opengroup.org/togaf
Нравится:
Нравится Загрузка…
Простой метод создания полезных диаграмм архитектуры решения | Туан Ле
Будучи архитектором решений в течение последних 15 лет, я действительно понимаю ценность полезной схемы архитектуры решения как эффективного визуального средства для определения и описания архитектуры системы, поставляемой в контексте конкретного решения в соответствии с Википедия.
По моему мнению, убедительная диаграмма архитектуры решения должна быть в состоянии передать бизнес-ценности ключевым заинтересованным сторонам и технические детали разработчикам. Поэтому он не должен быть слишком техническим, чтобы заинтересованные стороны бизнеса могли его понять; тем не менее, он по-прежнему должен обеспечивать практический план решения высокого уровня для последующей разработки. Другими словами, вы должны попытаться найти правильный баланс между техническими аспектами и бизнес-контекстом при создании схемы архитектуры решения.
Повидав и создав довольно много диаграмм архитектуры решения в своей сфере деятельности, я сформулировал простой метод создания диаграмм архитектуры решения, описанный в этой статье. Я ни в коем случае не утверждаю, что я разработал этот метод. Я просто синтезировал свои наблюдения и импровизации в набор условностей, чтобы сформировать повторяемый процесс, которому могут следовать другие.
Существует несколько подходящих инструментов для построения диаграмм, как онлайн, так и оффлайн, Visio, LucidChart, Gliffy, Creately и многие другие. Однако я бы рекомендовал использовать Microsoft PowerPoint в качестве основного инструмента по следующим причинам:0003
- Повторное использование : Если вы создадите полезную диаграмму, другие захотят повторно использовать ее в том же проекте для других целей или в других проектах. Предоставление общего доступа к архитектуре вашего решения в формате PowerPoint значительно упростит редактирование другим пользователям, поскольку PowerPoint — это универсальное продуктивное программное обеспечение, которое есть у каждого.
- Краткость : Вместо того, чтобы иметь неограниченный холст для рисования, вам нужно будет ограничить свою диаграмму одним слайдом с помощью PowerPoint. Таким образом, вам нужно будет выбрать правильный уровень детализации для архитектуры решения, что заставит вас сосредоточиться на сути вашего решения.
- Гибкость : PowerPoint дает вам возможность использовать любые формы и изображения, которые вам нужны. Обычно я использую стандартные фигуры PowerPoint вместе со значками/логотипами, загруженными из Интернета. Эти изображения могут удобно вписаться в диаграмму, если они имеют прозрачный фон, что можно быстро сделать с помощью функции волшебной палочки в Paint.NET (бесплатный редактор изображений).
По сути, работа архитектора решений заключается в анализе бизнес-требований и разработке технологического решения, отвечающего этим требованиям. Бесспорно, архитектура решения закладывает прочную основу для всех успешных проектов разработки.
Архитектура решения помогает воплотить в жизнь то, как различные аспекты бизнеса , информации, и технологии объединяются в конкретном решении. Поэтому диаграмма архитектуры решения должна визуализировать три критических элемента таким образом, чтобы это было полезно как заинтересованным сторонам бизнеса, так и разработчикам.
В этом разделе я познакомлю вас с каждым элементом, используя архитектуру решения электронной коммерции B2C. В качестве примера я выбрал электронную коммерцию, потому что это более простое решение по сравнению с корпоративным решением. Тем не менее, он достаточно сложен, чтобы доказать важность полезной схемы архитектуры решения.
Бизнес-требования для решения электронной коммерции B2C относительно просты. Клиент просто хочет иметь сайт электронной коммерции, где потребители могут видеть свои продукты и совершать покупки онлайн. Они также хотят сделать продукты доступными в поиске Google и иметь возможность ремаркетинга потребителей через платформу Criteo, чтобы привлечь больше трафика на сайт. И, конечно же, они настаивают на том, чтобы новый сайт электронной коммерции был интегрирован с существующей ERP, CRM и системой автоматизации маркетинга.
В контексте решения для электронной коммерции давайте рассмотрим три важнейших элемента архитектуры решения: бизнес, информация и технологии.
Бизнес
Говоря о бизнес-аспектах, архитектор решений должен исследовать две вещи: пользователей и функциональные возможности.
Иконки пользователейПользователи решения для электронной коммерции — это не только потребители, совершающие покупки в Интернете, но и все бизнес-пользователи, работающие на сайте электронной коммерции. Например, менеджер по электронной коммерции, который наблюдает за всей операцией, мерчендайзеры, которые делают продукты привлекательными с привлекательными изображениями и проводят рекламные акции, или агенты по обслуживанию клиентов, которые отвечают на запросы потребителей. На схеме архитектуры решения для обозначения этих пользователей можно использовать различные значки, найденные в Интернете.
Обозначения для функциональных возможностейФункциональные возможности, включенные в диаграмму архитектуры решения, должны быть критическими вариантами использования вашего решения, поскольку невозможно включить все отдельные функциональные требования. Поэтому вам нужно будет выбрать правильные, чтобы продемонстрировать, что предлагаемое решение действительно обеспечивает необходимые функции для удовлетворения бизнес-требований. Вы можете обозначить эти функции как стрелки, соединяющие пользователей и соответствующие системы. Стрелки должны указывать наружу от пользователей для случаев использования, когда пользователи активно что-то выполняют. И стрелки должны идти в другую сторону, когда пользователи пассивно что-то потребляют из систем. Вы также должны аннотировать каждый вариант использования коротким текстом, начинающимся с глагола.
Информация
Обозначения потока данныхВ архитектуре решения информация относится к данным, передаваемым между различными строительными блоками. Сначала вам нужно определить важные объекты данных в вашем решении. Например, в решении для электронной коммерции это каталог продуктов, цены на продукты, запасы, данные о клиентах и заказы. Опять же, вы можете использовать стрелки для обозначения данных, следующих за аннотированными именами объектов данных. Эти стрелки должны указывать направления потоков данных из одной системы в другую. Эти перемещения данных помогут вам определить требования к интеграции.
Технология
Системные обозначенияИ последнее, но не менее важное: вам необходимо включить технологические составляющие вашего решения в диаграмму архитектуры решения. Эти строительные блоки включают как новые, так и несуществующие компоненты. В нашем примере решение для электронной коммерции будет состоять из
- самой системы электронной коммерции B2C.
- Внутренняя ERP, CRM и система автоматизации маркетинга, как указал клиент.
- И другие внешние системы, включая систему логистики, платежный шлюз и Google Analytics, Google Shopping и Criteo.
Вы должны обозначить эти строительные блоки технологий как прямоугольники. Вы можете использовать логотипы известных систем, чтобы сделать вашу диаграмму более привлекательной.
Теперь, когда мы определили, что включить в диаграмму архитектуры решения, давайте обсудим, как их объединить.
Шаги
Я обычно сначала рисую все системы, а затем потоки данных, пользовательские значки и сценарии использования. Практически невозможно разместить каждый элемент в нужном месте с первой попытки. Поэтому вы должны сначала нарисовать то, что вам нужно, а затем переставить их в подходящие места. Поначалу это может показаться немного утомительным, но как только вы освоитесь, создание следующей диаграммы станет намного проще.
Компоновка
Эмпирическое правило гласит, что наиболее важные системы должны быть в центре, так как большинство потоков данных и вариантов использования будут касаться их. Другой аспект заключается в том, что вы должны размещать очень взаимозависимые строительные блоки близко друг к другу. Таким образом, вы можете сэкономить немного времени, пытаясь избежать рисования стрелок, пересекающих друг друга.
Кроме того, вы должны попытаться разместить всех внутренних пользователей с одной стороны, а внешних пользователей — с другой, вместо того, чтобы размещать значки пользователей повсюду. Это соглашение облегчит вашей аудитории следование вашей диаграмме, поскольку ключевые заинтересованные стороны обычно уделяют больше внимания бизнес-контексту.
Оптика
На диаграмме архитектуры вашего решения довольно много вещей; следовательно, если вы не обращаете внимания на оптику, архитектура вашего решения может выглядеть очень грязно. Вот несколько советов:
- Шрифт : Используйте одинаковый шрифт и размер шрифта на диаграмме. Никогда не смешивайте шрифты и не используйте разные размеры шрифтов для одинаковых элементов.
- Цвет : Вы должны использовать наиболее заметный цвет, например красный, для наиболее важных систем и другие цвета для других систем. Функциональность и стрелки потока данных также должны наследовать системные цвета для повышения удобочитаемости.
- Выравнивание : Вы должны попытаться выровнять тексты и блоки, когда это возможно, так как правильное выравнивание может сделать вашу диаграмму менее беспорядочной и более читабельной.
Артефакт
Ниже приведена примерная схема архитектуры решения для нашего примера, где элементы бизнеса, информации и технологии объединяются. Архитектура решения — сложная тема; следовательно, диаграмма архитектуры решения по своей сути выглядит занятой, но если вы расположите их аккуратно в правильном порядке, аудитория сможет понять, что находится в предлагаемой вами архитектуре решения.
Диаграмма архитектуры решения электронной коммерции B2CВ разработке программного обеспечения унифицированный язык моделирования (UML) является стандартным способом визуализации проекта системы. Архитекторы программного обеспечения и технические архитекторы широко используют UML для моделирования системы, независимой от языка платформы.
Однако в области архитектуры решений я не встречал какого-либо стандартизированного метода визуализации проекта решения. Кажется, что у каждого архитектора решений есть свой способ рисовать диаграммы архитектуры решения. Видя в прошлом как хорошие, так и не очень хорошие, я считаю, что этот простой метод поможет архитекторам решений создавать полезные диаграммы архитектуры решений более последовательно и эффективно.
Для меня, как для архитектора решений, самые приятные моменты — это когда ключевая заинтересованная сторона похлопывает меня по плечу и искренне говорит: «Я верю, что вы хорошо разбираетесь в этом» в конце презентации, в которой представлена полезная архитектура решения. диаграмма в качестве фокуса для обсуждения. Я считаю, что этот простой метод помогает мне создавать возможности для наслаждения многими из этих моментов.
Отказ от ответственности : Этот отказ от ответственности информирует читателей о том, что взгляды, мысли и мнения, выраженные в тексте, принадлежат исключительно автору, а не обязательно его работодателю, организации, комитету или другой группе или лицу.
Архитектор решений: роль и обязанности
Время чтения: 12 минут
В быстро меняющейся технологической среде организации сталкиваются с необходимостью преобразования своих процессов и систем в соответствии с новыми требованиями бизнеса. Эта цифровая трансформация требует специальных знаний и набора практических методов, позволяющих согласовать бизнес-направление с технологическими решениями.
Архитектура решения принадлежит к списку наиболее важных практик, выполняемых перед началом разработки любого технического решения. В этой статье мы обсудим, что такое архитектура решения, опишем роль архитектора решения и объясним, как использование этого опыта может помочь в решении бизнес-задач.
Кто такой архитектор решений?
Архитектура решения — это практика проектирования, описания и управления разработкой решений, чтобы они соответствовали конкретным бизнес-задачам. Например, защита данных клиентов в соответствии с GDPR и другими правилами конфиденциальности — это проблема бизнес-уровня. Архитектура решения определяет, как эти требования будут преобразованы в то, как работает данное программное обеспечение.
Архитектор решений отвечает за руководство практикой и представление общего технического видения конкретного решения.
Хотя практикой можно управлять внутри компании, есть компании, которые предоставляют консультации по архитектуре решений в виде определенного набора услуг.
Каждый из этих терминов включает несколько аспектов, которые мы обсудим в статье. Если вы хотите быстро узнать все подробности, посмотрите наше видео о роли архитектора решений.
Что такое архитектор решений и чем эта роль отличается от архитектора программного обеспечения и архитектора предприятия (а также подпишитесь на наш канал, так как мы продолжим выпускать обучающие видеоролики)
Архитектор предприятия, архитектор решений и технический архитектор
Архитектура решения — это сложный процесс со множеством подпроцессов, который устраняет разрыв между бизнес-задачами и технологическими решениями. Его цели:
- Найти лучшее техническое решение для решения существующих бизнес-задач.
- Опишите структуру, характеристики, поведение и другие аспекты программного обеспечения заинтересованным сторонам проекта.
- Определение функций, этапов разработки и требований к решению.
- Предоставьте спецификации, в соответствии с которыми решение определяется, управляется и доставляется.
Однако есть еще две должности уровня архитектора, которые часто путают: архитектор предприятия и архитектор программного обеспечения. Уточним основные отличия.
Архитектура решения в контексте предприятия и технической архитектуры
Кто такой архитектор предприятия?
Корпоративная архитектура, которую мы рассмотрели в специальной статье, ориентирована на построение сложных корпоративных экосистем и решение стратегических задач высокого уровня. Архитектура предприятия определяет стратегические направления бизнес-архитектуры, что затем приводит к пониманию того, какие технологические средства необходимы для поддержки этой архитектуры. Другими словами, архитектор предприятия определяет, что должно быть сделано, а архитектор решений затем решает, как это сделать.
Архитектор предприятия имеет самое широкое представление о текущем состоянии архитектуры и целей компании. Именно этот эксперт отвечает за создание стратегического плана внедрения технических изменений. Этот человек тесно сотрудничает с руководителями высшего звена и лицами, принимающими решения, поскольку он или она демонстрирует им коммерческую ценность предлагаемых технических инициатив.
Кто такой программный или технический архитектор?
Программный или технический архитектор в основном отвечает за инженерные проблемы и архитектуру программного обеспечения. У нас есть подробная статья, описывающая роль архитектора программного обеспечения и важность этой должности для успеха компании.
В отличие от архитектора решений, архитектор программного обеспечения обычно не занимается финансовыми и организационными вопросами. Этот человек фокусируется на всех аспектах, связанных с разработкой программного обеспечения в конкретном проекте, то есть на разработке, внедрении, обслуживании, поддержке и развитии. Архитекторы программного обеспечения тесно сотрудничают с командами разработчиков и контролируют весь процесс разработки. Итак, продолжая предыдущий пример, архитектор программного обеспечения определяет, что именно нужно сделать и как сохранить результат.
Кто такой архитектор инфраструктуры?
Архитектор инфраструктуры очень похож на технического архитектора, но с упором на корпоративный локальный сервер или облачные системы, используемые организацией. Это означает, что специалист по инфраструктуре помогает развивать и поддерживать производственную часть экосистемы корпоративного программного обеспечения, а не саму разработку программного обеспечения. Эти специалисты контролируют существующие ИТ-системы и сети, а также изучают и интегрируют новые, следя за тем, чтобы они соответствовали всем требованиям в отношении отказоустойчивости, безопасности, производительности, доступности и т. д.
В конечном счете, технические архитекторы определяют, как должно быть спроектировано программное обеспечение, а архитекторы инфраструктуры следят за тем, чтобы это программное обеспечение было успешно развернуто и хорошо работало. И все же технический архитектор может отвечать и за инфраструктуру. Таким образом, границы между этими двумя ролями стираются.
Архитектура решения описывает, как различные компоненты бизнес-, информационной и технологической архитектуры используются в конкретном решении. Поскольку архитектура решения в большей степени ориентирована на детали и технологии решения для решения конкретной бизнес-задачи, она обеспечивает канал между архитектурой предприятия и технической архитектурой. Последний ориентирован только на технические вопросы. Эффективным подходом для компаний является объединение действий по архитектуре предприятия с действиями по архитектуре решений и технической архитектуре.
Архитектура решения и ее основные процессы
Хорошо построенная архитектура решения помогает командам разработать продукт вовремя и в рамках бюджета и гарантирует, что он решает проблему, для решения которой он был разработан. Итак, какие задачи на самом деле решает архитектура решения?
Согласование решений с корпоративной средой
Обычно у компаний уже есть операционные системы, информационный контекст и требования к интеграции. Архитектура решения помогает гарантировать, что новая система будет соответствовать существующей корпоративной среде. Для выполнения этой задачи архитектор решений должен понимать, как все части бизнес-модели работают вместе, включая процессы, операционные системы и архитектуры приложений. Понимая эти аспекты, они смогут разработать конкретное решение, которое лучше всего подходит для окружающей среды.
Удовлетворение требований всех заинтересованных сторон
Одной из наиболее важных задач разработки программного продукта является удовлетворение требований заинтересованных сторон. Обычно у продукта есть ряд заинтересованных сторон, которые являются как техническими, так и нетехническими специалистами. Цель архитектуры решения — обеспечить учет всех их требований. Заинтересованные стороны должны регулярно информироваться о процессах разработки продукта, затратах и бюджетировании. Эти задачи обычно выполняются архитектором решений, который переводит технические детали проекта на язык, понятный руководству и заинтересованным сторонам, не являющимся техническими специалистами.
Учет ограничений проекта
Каждый проект имеет свои ограничения, обычно называемые ограничениями. К ним относятся:
- технология
- риски
- прицел
- стоимость
- качество
- время
- ресурсов
Например, продукт создан с использованием технологий, которые должны соответствовать требованиям его конкретных модулей. Объем проекта — это часть документации по программному обеспечению, определяющая конкретные цели, задачи, возможности и функции. Все проекты также имеют выделенный бюджет.
Хотя эти аспекты сами по себе являются ограничениями, у каждого из них есть свои ограничения. Архитектор решения должен понять все эти ограничения, сопоставить их, а затем принять ряд технологических и управленческих решений, чтобы согласовать эти ограничения с целями проекта.
Выбор стека технологий проекта
Важнейшей частью создания архитектуры решения является выбор технологий для разработки продукта. Стратегия технической архитектуры будет напрямую зависеть от выбранного стека технологий. Существует множество различных практик, связанных с платформами, языками программирования и инструментами. Функция архитектуры решения здесь состоит в том, чтобы найти, какие из них будут наиболее подходящими для конкретного проекта. Это не обычная задача, требующая оценки и сравнения технологий.
Соответствие нефункциональным требованиям
Все программные проекты должны соответствовать ряду нефункциональных требований, описывающих характеристики системы. Они также известны как атрибуты качества. Хотя точный список нефункциональных требований зависит от сложности каждого отдельного продукта, наиболее распространенными из них являются безопасность, производительность, ремонтопригодность, масштабируемость, удобство использования и надежность продукта. Роль архитектора решения заключается в анализе всех нефункциональных требований и обеспечении того, чтобы дальнейшая разработка продукта соответствовала им.
Поскольку мы обсудили общие цели внедрения архитектуры решения, давайте разобьем их на конкретные обязанности и базовые наборы навыков.
Описание роли и обязанностей архитектора решений
Работа архитектора решений сосредоточена на принятии решений на уровне решения и анализе их влияния на общие бизнес-цели и результаты. Подобно архитектору в строительной отрасли, создающему генеральный план будущего здания, человек на этой должности должен обладать глубокими знаниями доступных технологий, чтобы предлагать наилучшее решение в соответствии с поступающими требованиями и существующей средой. Итак, можно сказать, что продуктом работы архитектора решений является набор технологических решений и стратегия их реализации.
После разработки стратегического технического видения продукта архитектор решения участвует в оценке бюджета и представлении его заинтересованным сторонам. После того, как все согласовано, он или она контролирует процесс разработки и информирует заинтересованные стороны о прогрессе.
Обязанности архитектора решений непосредственно вытекают из процессов на практике:
- Анализ технологической среды
- Анализ специфики предприятия
- Анализ и документирование требований
- Настройка структуры сотрудничества
- Создание прототипа решения
- Участие в отборе технологий
- Управление разработкой решения
- Поддержка управления проектами
Несмотря на то, что большинство этих обязанностей требует от архитектора решения руководящей роли, этот человек просто поддерживает деятельность по управлению проектами, чтобы обеспечить соответствие ресурсов, распознавания рисков и планирования целям решения.
Набор навыков и опыт архитектора решений
Если вы уже осознали важность архитектуры решения в своих проектах, следующим шагом будет найти и нанять человека на эту роль. Мы рассмотрели основные навыки, которыми должен обладать хороший архитектор решений.
Распределение ролей архитектора решений
Техническое образование и опыт
Чтобы предоставлять управленческим и инженерным группам технические консультации, архитектор решений должен иметь техническое образование и не менее восьми лет опыта работы в одной или нескольких областях ИТ. включая, но не ограничиваясь:
- ИТ-архитектура, инфраструктура и разработка облачных вычислений
- Проектирование инженерной и программной архитектуры
- Бизнес-анализ
- DevOps
- Управление проектами и продуктами
Отличные коммуникативные навыки
Важнейшей частью компетенции архитектора решений является общение. Учитывая, что эта роль предполагает ведение переговоров с заинтересованными сторонами, понимание потребностей всех сторон, управление рисками и поставку продукта, отсутствие навыков общения может стать настоящим узким местом. Эта должность требует тесного сотрудничества с архитекторами предприятий и программного обеспечения, бизнес-аналитиками и проектными группами. Итак, опытный архитектор решений должен уметь слушать, советовать, сопереживать и объяснять.
Глубокие аналитические способности
Разработка решения требует понимания того, как различные части бизнеса работают вместе. Архитектор должен признать корпоративную стратегию и реализовать все бизнес-процессы, которые определяют, как компания достигает своих стратегических целей. Но архитектор должен также понимать техническую специфику. В результате архитекторы решений постоянно занимаются аналитической работой и перемещаются между различными бизнес-уровнями.
Навыки управления проектами и ресурсами
Хотя архитектор решений не принимает непосредственного участия в управлении проектом, учет сроков и предоставленных ресурсов неизбежен. Архитекторы решений должны иметь возможность принимать решения о том, какие решения выгодны, а какие бесполезны в данной ситуации. Они должны быть ориентированы на бизнес-результаты и понимать, как их достичь в соответствии с заданными сроками и ресурсами.
Кроме того, важно, чтобы архитекторы решений рассматривали проект с точки зрения долгосрочной перспективы и понимали, что решение может нуждаться в масштабировании и адаптации к возможным изменениям в будущем. Таким образом, будучи теми, кто знает конечную цель, они соответствующим образом направляют процесс разработки.
Сертификация архитекторов решений
Сертификации предназначены для проверки навыков и опыта архитекторов решений. Они оценивают свои знания, способности и опыт. Таким образом, наличие одной или нескольких учетных данных доказывает владение экспертом определенными навыками.
Большинство сертификационных платформ, помимо самого экзамена, предлагают учебные курсы, учебные материалы и практические тесты. Другие ресурсы также могут быть полезны для подготовки и практики, например Udemy, Coursera или MeasureUp. Однако экзамен можно сдавать и без предварительной подготовки — все, что требуется, — это глубокое знание архитектурных концепций и принципов и большой практический опыт работы в отрасли.
Существует множество доступных сертификатов ИТ-архитекторов, большинство из которых относятся к конкретным поставщикам, т. е. ориентированы на освоение конкретной технологии. Вот краткий обзор самых популярных из них.
Сертификация архитектора решений AWS
Программа AWS Certified Solutions Architect предлагает сертификаты младшего и профессионального уровней в зависимости от вашего опыта. Оба они нацелены на архитекторов, которые работают с технологиями AWS для создания и развертывания приложений и систем.
Экзамен AWS Certified Solutions Architect — Associate занимает 130 минут и стоит 150 долларов США. Amazon рекомендует кандидатам иметь не менее 1 года практического опыта перед сдачей теста. Вот список основных предметных областей этого экзамена:
Список основных предметных областей и их веса, источник: Руководство по экзамену
Сертифицированный архитектор решений AWS — профессиональный экзамен предназначен для старших архитекторов с 2 или более лет опыта и удостоверения младшего специалиста. Это занимает 180 минут и стоит 300 долларов. Вот схема содержания:
Список основных доменов контента и их веса, источник: Руководство по экзамену
Сертификаты AWS действительны в течение 3 лет, после чего обладатели учетных данных должны пройти повторную сертификацию, чтобы подтвердить свой постоянный опыт и знание новейшие технологии и лучшие практики AWS.
Сертификация архитектора решений Azure
Корпорация Майкрософт имеет различные учетные данные для архитекторов решений, наиболее известным из которых является сертификат Microsoft Certified: Azure Solutions Architect Expert. Это для кандидатов, специализирующихся на решениях, работающих в Microsoft Azure, и обладающих глубокими знаниями об инфраструктуре Azure.
Сертификацию эксперта по архитектуре решений Azure можно получить после сдачи экзамена: AZ-305: Проектирование инфраструктурных решений Microsoft Azure. Цена зависит от страны, в которой проводится экзамен (165 долларов США для США).
Вот обзор навыков, измеряемых этими тестами. Вкратце, AZ-305 ориентирован на технические задачи, такие как:
- внедрение и мониторинг инфраструктуры Azure,
- внедрить решения по управлению и безопасности,
- реализуют решения для приложений, а
- внедрять и управлять платформами данных.
Содержание АЗ-305 оценивает такие навыки как:
- контроль проектирования,
- дизайн и безопасность,
- хранилище проектных данных,
- проектирование непрерывности бизнеса и
- проектная инфраструктура.
Сертификация ITIL
ITIL — это признанный в отрасли набор квалификаций, включающий 5 уровней. Высшей квалификацией является ITIL Master для тех специалистов, которые работают в области управления ИТ-услугами и имеют большой опыт работы с практиками ITIL. Это не совсем ролевая сертификация специально для архитекторов решений, но, поскольку ITIL является популярной структурой управления, человек, усвоивший ее принципы, будет ценным активом на любой управленческой должности.
В описании указано, что для получения сертификата вы должны быть в состоянии « объяснить и обосновать, как вы лично выбрали и применили ряд знаний, принципов, методов и методов из ITIL Framework и поддерживающих методов управления для достижения желаемого бизнеса. результаты одного или нескольких практических заданий. ” Таким образом, для этого экзамена не существует учебного курса или фиксированной программы, поскольку каждый кандидат будет проверен в рамках своего уникального опыта.
Наличие сертификата ITIL Expert является необходимым условием для получения этих учетных данных. Кандидат также должен иметь более 5 лет опыта работы на руководящих, управленческих или консультативных должностях высокого уровня. Как только эти условия будут выполнены, претендент должен будет зарегистрироваться в PeopleCert (утвержденный экзаменационный институт Axelos), заполнить заявку и представить свое резюме. Затем необходимо представить предложение по улучшению бизнеса вместе с рабочим пакетом, демонстрирующим практические навыки кандидата в применении принципов ITIL в реальных бизнес-кейсах. После этого соискатели должны будут успешно пройти собеседование с оценочной комиссией, где им будет задан вопрос об их опыте.
Стоимость как экзамена, так и учебных курсов зависит от местоположения.
Сертификация облачного архитектора Google
Google также предлагает ряд сертификатов на основе ролей. Professional Cloud Architect предназначен для экспертов, которые используют технологии Google Cloud в своих решениях. Опять же, это не только для архитекторов решений, но и для любого специалиста, имеющего дело с облачной архитектурой Google.
Экзамен длится 2 часа, регистрационный взнос составляет 200 долларов США. Google рекомендует иметь как минимум 3 года опыта, прежде чем пытаться пройти тест. Также важно помнить, что требуется переаттестация каждые два года. Доступно руководство по экзамену (а также учебные материалы и примеры вопросов), в котором перечислены 6 аспектов экзамена:
- Проектирование и планирование архитектуры облачных решений;
- Управление и предоставление инфраструктуры решения;
- Разработка для обеспечения безопасности и соответствия требованиям;
- Анализ и оптимизация технологий и бизнес-процессов;
- Управление внедрением; и
- Обеспечение надежности решений и операций.
Когда компании требуется консультация по архитектуре решения
Архитектура решения может быть внедрена в корпоративную структуру организациями, предоставляющими технологические консультации, если процесс интеграции новых программных систем не является систематическим. Кроме того, нет необходимости иметь архитектора решения для каждого отдельного проекта. Если вы внедряете один технический модуль, который доказал свою работоспособность в аналогичных контекстах, вам не нужен архитектор решения. Как только проекты по разработке программного обеспечения усложняются и влекут за собой большее количество процессов и рисков, лучше рассмотреть консалтинговые услуги по архитектуре решения.
Давайте рассмотрим случаи, когда рекомендуется консультация по архитектуре решения:
Вы не знаете, какое решение лучше всего подходит для корпоративной экосистемы. Вам необходимо наладить связь между существующей архитектурой предприятия и конкретным проектом. Архитекторы решений гарантируют, что решение соответствует стандартам среды вашей компании. Например, если вы перемещаете ряд существующих бэк-офисных процессов в облако, архитектор решения должен проанализировать несколько вариантов и предложить наиболее подходящие с точки зрения технологий, человеческих и финансовых ресурсов.
Вы запускаете проект цифровой трансформации. Цифровая трансформация требует от компаний пересмотреть либо то, как они обеспечивают ценность для своих клиентов, либо то, что они в конечном итоге предоставят. Невозможно ответить на эти вопросы, не связывая технологии и бизнес-перспективы, что находится прямо в рулевой рубке архитектора решений.
Вы сталкиваетесь с множеством рисков. Архитектор решений необходим для проектов, в которых присутствует множество технологических рисков, могут появиться неопределенные требования, необходимо внедрить несколько продуктов одновременно или базовые технологии еще не утверждены.
Вы должны представить инвесторам дорожную карту продукта. Если вам необходимо представить будущий продукт инвесторам и заинтересованным сторонам, архитектор решений предложит технологии, которые будут соответствовать требованиям к продукту, и сообщит аргументы в простых и ясных деловых терминах.
Вам необходимо наладить связь между заинтересованными сторонами и инженерами. Архитектор решений поможет восполнить пробел в общении между техническими и нетехническими специалистами. Кроме того, сотрудничая с командой управления проектом, архитекторы решений покрывают риски несоответствия продукта требованиям заинтересованных сторон и обеспечивают соответствие решения поставленной цели.
В проекте задействовано множество команд. У вас может быть большой проект, который требует, чтобы кто-то руководил командой дизайнеров, технических или бизнес-архитекторов, чтобы получить качественный технический результат проекта.
Архитектура решения является основой любого ИТ-проекта, независимо от того, применяете ли вы эту практику на самом деле или нет. Преднамеренно внедряя архитектуру решения, вы создаете структуру, которая согласовывает технологии, ресурсы и навыки с определенными бизнес-целями.
Прежде чем рассматривать архитектуру решения, мы рекомендуем изучить структуры архитектуры предприятия, которые сочетают в себе уровни решения и предприятия.
Традиционно малый и средний бизнес не считает ни практику архитектуры решения, ни соответствующую роль оправданной. Решение проблем с архитектурой решения делегируется и распределяется между другими ролями в группе разработчиков. И это жизнеспособный вариант для небольших проектов с предсказуемыми результатами. Однако, если у вас сложная архитектура предприятия, которая вводит несколько программных продуктов в функционирующую экосистему, вам необходимо полностью перестроить унаследованное ПО или принять комплекс стратегических технологических решений, актуальность выделенного специалиста очевидна.
Примеры эталонной архитектуры и рекомендации
AWS Well-Architected
- AWS Well-Architected Framework
- Инструмент AWS Well-Architected
- Объективы AWS Well-Architected
- Лаборатория AWS Well-Architected
Эталонные архитектуры
- Аналитика и большие данные
- Вычисления и высокопроизводительные вычисления
- Базы данных
- Просмотреть все схемы архитектуры
Ознакомьтесь с нашим контентом
Центр архитектуры AWS предоставляет эталонные схемы архитектуры, проверенные архитектурные решения, рекомендации Well-Architected, шаблоны, значки и многое другое. Это экспертное руководство было предоставлено экспертами по облачной архитектуре из AWS, в том числе архитекторами решений AWS, консультантами по профессиональным услугам и партнерами.
Фильтровать по:
Очистить все фильтры
Фильтр
Фильтр
Закрывать Применить фильтрыФильтр
Фильтр
Закрывать Применить фильтрыЭлементы, соответствующие выбранным критериям, не найдены.
Категории технологий
Аналитика и большие данные
Создавайте безопасные, надежные и экономичные архитектуры обработки данных.
Compute & HPC
Узнайте, как разрабатывать, развертывать, запускать и масштабировать свои приложения.
Контейнеры
Узнайте о наиболее безопасном, надежном и масштабируемом способе запуска контейнеров.
Оптимизация затрат
Узнайте, как постоянно оптимизировать свои расходы.
Базы данных
Выберите базу данных, соответствующую вашему варианту использования и схемам доступа.
Вычисления для конечных пользователей
Создавайте архитектуры, которые помогут вам реагировать на изменяющиеся потребности вашей рабочей силы.
IoT
Научитесь подключать устройства и собирать, хранить и анализировать данные устройств.
Машинное обучение
Создавайте эффективные и действенные архитектуры машинного обучения (ML).
Управление и управление
Узнайте, как быстрее и надежнее создавать и доставлять продукты с помощью AWS.
Microsoft
Ознакомьтесь с рекомендациями по созданию и запуску приложений Microsoft.
Миграция
Узнайте, как перенести существующие приложения в AWS.
Работа в сети и доставка контента
Научитесь подключать устройства и собирать, хранить и анализировать данные устройств.
Безопасность, идентификация и соответствие требованиям
Узнайте, как достичь целей безопасности и соответствия требованиям с помощью инфраструктуры и сервисов AWS.
Serverless
Научитесь создавать и запускать приложения и серверные службы без серверов.
Хранение
Разработка надежных, масштабируемых и безопасных архитектур хранения данных.
Помогла ли вам эта страница?
Да
Нет
Отзыв
Закрыть
Спасибо за отзыв
Мы рады, что эта страница помогла вам. Хотите поделиться дополнительной информацией, чтобы помочь нам продолжать совершенствоваться?
Отзыв
Закрыть
Спасибо за ваш отзыв
Нам жаль, что эта страница вам не помогла. Хотите поделиться дополнительной информацией, чтобы помочь нам продолжать совершенствоваться?
Отзыв
Войдите в консоль
Узнайте об AWS
- Что такое AWS?
- Что такое облачные вычисления?
- AWS Разнообразие, равенство и инклюзивность
- Что такое DevOps?
- Что такое контейнер?
- Что такое озеро данных?
- Облачная безопасность AWS
- Что нового
- Блоги
- Пресс-релизы
Ресурсы для AWS
- Начало работы
- Обучение и сертификация
- Портфолио решений AWS
- Архитектурный центр
- Часто задаваемые вопросы по продуктам и техническим вопросам
- Аналитические отчеты
- Партнеры AWS
Разработчики на AWS
- Центр разработчиков
- SDK и инструменты
- . NET на AWS
- Python на AWS
- Java на AWS
- PHP на AWS
- JavaScript на AWS
Помощь
- Свяжитесь с нами
- Подайте заявку в службу поддержки
- Центр знаний
- AWS re: Сообщение
- Обзор поддержки AWS
- Юридический
- Карьера в AWS
Amazon является работодателем с равными возможностями: Меньшинства / Женщины / Инвалидность / Ветеран / Гендерная идентичность / Сексуальная ориентация / Возраст.
- Конфиденциальность
- |
- Условия сайта
- |
- Настройки файлов cookie
- |
- © 2022, Amazon Web Services, Inc. или ее дочерние компании. Все права защищены.
Поддержка AWS для Internet Explorer прекращается 31. 07.2022. Поддерживаемые браузеры: Chrome, Firefox, Edge и Safari. Узнать больше »
Как создавать важные архитектурные решения
Бывают случаи, когда проектировщики увлекаются процессом создания решения, не задумываясь заранее о том, действительно ли это решение необходимо. Это эквивалентно трате большого количества времени и усилий на неправильный путь, который приводит к дизайнерским решениям с небольшой пользой или положительным эффектом. Таким образом, крайне важно действительно вникнуть в основную проблему вашего проекта. Найдя и решив эту основную проблему, вы будете проектировать с максимальной эффективностью, потому что, когда вы решите коренную проблему, вся система здания укрепится. И наоборот, если вы решаете только второстепенную проблему, то система здания пострадает, потому что основная проблема (которая является самым слабым местом) останется и не позволит остальной части системы здания реализовать свои положительные преимущества.
Используйте свои усилия для предварительного анализа проблем проектирования
Становится важным спросить себя не только о том, как спроектировать для нужд жильцов, но и почему эти потребности являются наиболее важными. Кроме того, полезно изучить, чего может достичь ваш проект, когда обнаружена конкретная основная проблема и найдено решение. Это убережет вас от ненужной траты времени и усилий на решение не той проблемы или неправильное проектирование ключевой проблемы.
Конечно, архитектурный проект должен инновационно решать и повышать качество жизни, решая множество потребностей и проблем в рамках дизайнерского проекта. Тем не менее, они часто возникают из-за коренных проблем, которые создают «симптомы», которые сами проявляются как проблемы.
Важность проектирования для основной проблемы
Недавно я столкнулся со всем этим в банке. Видите ли, я зашел в банк и понял, что в большой комнате, которая выполняла множество функций, было много акустических перекрытий. Кассиры с одной стороны, большой телевизор с рекламой банков с другой, клиенты, ожидающие очереди к кассе, и разговоры между банкиром и клиентом — все это конкурировало за то, чтобы быть услышанным. Вместо этого в результате получилась «мешанина» звука. В этом примере основная причина проблемы со звуком заключалась в том, что все эти функции происходили в этом большом банковском пространстве одновременно, создавая пространство, в котором почти ничего не было слышно.
Одно из решений проблемы с акустикой в банке — создать отдельную, но примыкающую комнату, куда банкиры и клиенты могли бы прийти для обсуждения. Однако это решение одного из банковских «симптомов» корневой проблемы. Это решение не решает основной проблемы, когда все сотрудники банка должны работать в неудобном пространстве. Как видите, оформление отдельной и смежной комнаты — не верный дизайнерский путь. Вместо этого, если кто-то спроектирует корень проблемы, банк сможет функционировать на значительно улучшенных уровнях сотрудников и клиентов.
Раскрытие потенциала вашего дизайна
Когда вы потратите время на поиск и решение основной проблемы в своем проекте, потенциал вашего дизайна возрастет. Ваш дизайн принесет большую пользу тем, кому он служит. Для этого убедитесь, что вы ясно видите проблемы проекта. Часто проблемы, которые являются симптомами, могут привести к основной проблеме. И именно здесь ваш дизайн может повысить свой потенциал, если ваш дизайн укрепит самую слабую часть вашей системы проектов. Именно здесь находится рычаг, и с его помощью вы можете извлечь максимальную выгоду из своих дизайнерских решений. Другими словами, ваш архитектурный проект решит действительно важную проблему действительно важным способом. И в этом вся разница.
Изображение предоставлено: © stockpics | Fotolia
Ваш следующий шаг:
Подпишитесь на MLL StudioWorks Insider , чтобы получить доступ к инсайдерским технологиям, обучению, новым источникам вдохновения, последним произведениям искусства, книжным публикациям и предстоящие выставки.
ПРИСОЕДИНЯЙСЯ СЕЙЧАС
7 образцов эталонной архитектуры для инфраструктурных проектов
Опубликовано: 11 мая 2022 г. | | по Эрик Д. Шабелл (Навигатор, Red Hat)
Изображение
Фото Шейна Раунса на Unsplash
Инфраструктура остается основной инвестицией для большинства организаций, как в локальной среде, так и в облаке. Вы вложили значительные средства в инфраструктуру, приложения, процессы и политики. Несмотря на то, что вам нужно внедрять новые платформы и технологии, вы не можете просто выбросить свои существующие активы. Вы должны сбалансировать новые технологии и подходы с поддержкой и модернизацией существующих критически важных систем.
В течение последних нескольких лет команда Red Hat Portfolio Architecture занимается разработкой эталонных архитектур на основе реальных сценариев использования клиентов в различных отраслях. У нас есть несколько критериев для разработки и проверки коллекции архитектур перед ее публикацией, которые вы можете прочитать в моей вводной статье о портфолио архитектуры.
Мы публикуем эти архитектуры для всеобщего использования в нашем Red Hat Portfolio Architecture Center и репозитории примеров портфолио архитектуры.
В этой статье представлены семь инфраструктурных архитектур. Я дам краткий обзор каждого из них и позволю вам изучить их более подробно самостоятельно.
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)В репозитории GitHub каждой из этих архитектур вы найдете оглавление с описанием используемых технологий, несколько примеров схематических диаграмм с пояснениями и ссылку для открытия диаграммы непосредственно в онлайн-инструменты в вашем браузере.
От облака до периферии
Архитектура от облака до периферии охватывает вариант использования, обеспечивающий согласованную работу инфраструктуры от облака до периферии и использование современных контейнерных приложений на периферии.
(Примечание: этот проект представляет собой новую архитектуру и в настоящее время находится в разработке. Я делюсь одной из схематических диаграмм архитектуры, и вы можете следить за обновлениями этого проекта по мере его завершения.)
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Этот вариант использования обеспечивает облачные возможности в периферийных местоположениях.
[ Узнайте, как модернизировать ИТ с помощью управляемых облачных сервисов. ]
Центр обработки данных до периферии
Архитектура от центра обработки до периферии охватывает вариант использования, когда инфраструктурные компании в сфере энергетики и коммунальных услуг работают на обширной географической территории, которая соединяет буровые операции вверх по течению с переработкой топлива и доставкой клиентам вниз по течению. Этим компаниям необходимо следить за состоянием трубопроводов и другой инфраструктуры для обеспечения эксплуатационной безопасности и оптимизации.
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Вариант использования приближает вычисления к периферии за счет мониторинга потенциальных проблем с газопроводами на периферии.
Гибридное управление несколькими облаками с помощью GitOps
Гибридное управление несколькими облаками с архитектурой GitOps обеспечивает стабильную и простую контейнерную платформу для разработчиков и инженеров, которая безопасна, поддерживает гибридную среду и работает в нескольких облачных решениях. Он использует автоматизированный подход «инфраструктура как код», который управляет версиями и обеспечивает развертывание в соответствии с предоставленными конфигурациями.
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Вариант использования управляет жизненными циклами гибридных и многооблачных кластеров, безопасными конфигурациями и учетными данными. Он использует GitOps для подхода «инфраструктура как код». Он также обеспечивает межкластерное управление и управление жизненным циклом приложений.
[ Узнайте больше, загрузив управляемую событиями архитектуру для гибридного облака. ]
Модернизация интерфейса SCADA
Архитектура модернизации интерфейса SCADA (диспетчерское управление и сбор данных) нацелена на поставщиков электроэнергии в Северной Америке, стремящихся обеспечить соответствие нормам Североамериканской корпорации по обеспечению надежности электроснабжения (NERC) путем модернизации интерфейсов между их бизнес-приложениями и их системами SCADA. Эта модернизация также обеспечивает лучшее потребление информации, которое можно сочетать с искусственным интеллектом (ИИ), машинным обучением (МО) и инструментами управления решениями для удовлетворения потребностей клиентов.
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Вариант использования обеспечивает интерфейсы с системами SCADA, соответствующие требованиям NERC, создавая различные уровни шлюзов API для защиты бизнес-сервисов в зависимости от сетевых зон.
Архитектуры 5G
5G — это новейшая разработка в области беспроводных мобильных технологий, целью которой является предоставление пользователям возможностей полного погружения и сверхнадежная связь между устройствами с малой задержкой. В основе каждой сети 5G лежит ядро 5G (5GC).
[ Чтобы узнать больше о 5G, прочитайте статью Расширение 5G с помощью архитектуры 5G Open HyperCore. ]
Ядро Telco 5G: локально
Архитектура ядра 5G Telco (локально) представляет 5G Core как набор дезагрегированных облачных приложений, которые взаимодействуют внутри и снаружи через четко определенные стандартные интерфейсы. Каждый компонент 5GC реализован как приложение на основе контейнера и называется облачной сетевой функцией (CNF).
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Вариант использования — сверхнадежный, иммерсивный опыт для людей и объектов, когда и где это наиболее важно.
Telco 5G с гиперскейлерами
Архитектура Telco 5G с гиперскейлерами описывает решение 5G, основанное на технологиях с открытым исходным кодом, которое работает на любом гиперскейлере.
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Вариант использования — создание адаптируемых инфраструктурных услуг по требованию для 5G Core, которые могут предоставляться в различных сценариях использования с минимальными капитальными и эксплуатационными расходами (CAPEX и OPEX).
Telco 5G: сети радиодоступа
Архитектура сетей радиодоступа Telco служит сценарию использования, основанному на том факте, что цифровая трансформация мобильных сетей ускоряется, а облачность увеличивается. Решения для сетей радиодоступа (RAN) теперь используют преимущества облачных вычислений.
Изображение
Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)Подробнее
Это семь из многих эталонных архитектур, уже опубликованных архитекторами портфолио Red Hat, и мы продолжим добавлять новые по мере их завершения.