Проверка новой архитектуры

Проверка архитектуры вручную требует много времени и сил. Но с Lucidscale этот процесс гораздо проще и выполняется всего в три этапа: 

1. Импортируйте архитектуру в центр данных 

Откройте Lucidscale и на панели слева выберите опцию «Импортировать данные», чтобы загрузить метаданные поставщика облачных услуг и составить ясную картину своей архитектуры в текущем виде. Lucidscale работает с AWS, Azure и GCP. 

2. Создайте модель архитектуры в Lucidscale 

Автоматически сгенерируйте схему из импортированных данных. В Lucidscale вы можете применить к ней фильтры, настроить собственные режимы просмотра, показать привязанные ресурсы и не только. 

 

3. Сравните новую модель с первоначальной схемой 

Сопоставьте новую модель из Lucidscale с планом архитектуры в удобном для вас приложении для схематизации. Lucidchart — отличный сервис с умным функционалом для создания схем, а импортировать в него проекты из Lucidscale проще простого, ведь оба приложения входят в визуальный набор Lucid. Используйте разные режимы просмотра, чтобы отфильтровать отдельные ресурсы и сфокусировать внимание на конкретных группах. Скройте или покажите линии, чтобы удостовериться, что ресурсы правильно связаны между собой. Если в архитектуре обнаружатся расхождения с планом, вы можете выделить проблемные участки и вернуться к ним позже.

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

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

На этом этапе проект выходил из-под контроля облачных архитекторов, и они могли только догадываться, будут ли их изменения применены на практике. Точно так же, у них не было возможности узнать, если что-то пошло не так. 

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

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

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

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

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