Читать книгу Из разработчика в архитекторы. Практический путь - Евгений Сергеевич Штольц - Страница 6

Зачастую в маленьких организациях DevOps это единственный человек, понимающий устройство на всех уровнях, и как системный администратор инфраструктуру и устанавливаемые приложения, и как программист разрабатываемую прикладную программную часть, и как автоматизатор – бизнес процессы разработки. Позиция архитектора в крупных компаниях предполагает знакомство с методологиями управления архитектурой:

* TOGAF (The Open Group Architecture Framework) c программой Archimade

* Zachman Framework

* DoDAF

* ARIS (Architecture of Integrated Information Systems) с программой ARIS Express

Для DevOps важны общие концепции процесса создания продукта и его внедрения, поэтому возьмём общее из популярных. Если в компании есть специалист занимающийся реализации, в качесве которого обычно выступает или Tex-Lead, или Team-Lead, который в деталях видит как будет устроенна и создаваться его приложение его командой, то он может выполнять роль Application Application. Эта частая практика и необходимое условие, так как приложение является сильно взаимосвязанным, и нужен человек, который знает в деталях как оно устроенно и как изменения в одной его части повлияют на другие. Если же такой экспертизы найти не получается, приложение необходимо делить на части и фиксировать связи интерфейсами. Для деления проекта на части нужно разделить саму команду, разрабатывающую его, на части в соответствии с законом Конвея ("Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации"). При такой организации, когда приложение всё ещё остаётся одним, но разделённым на части, Tex-Leid и Team-Lead имея понимание в каждой части и могут объять реализацию всего приложения, могут получить экспертизу у более узких членов их команд, когда их экспертизы не хватает. Если речь идёт о Software Architect или Technology Architect, то ныне эту роль берёт унификации, соответственно, в виде контейнеров и виртуальных машин. Если же речь идёт о системе приложений, то необходимо оперировать более высоким уровнем проектирования, таким как Information Architect (System Architect и Solution Architect), при котором не получается совмещать проектирование и реализацию, так как необходимо спроектировать группу систем, который будут разрабатывать разные команды. Если взаимосвязи простые, а это решается при согласовании лидов этих отделов и архитектор не требуется. Архитектор нужен, когда разрабатывается система целиком и требуется в текущей системе заменить на несовместимый с текущей сисетмой компонент, когда нужно изменить организацию компонентов, а экспертизы специалиста занимающегося реализаций не хватает тогда нужно видении всей системы целиком, формированием которого и занимается архитектор. Для него крайне важно понимать различные программы, и как они могут взаимодействовать между собой, при этом глубокой экспертизы во всех областях и текущей ситуации обстановки в командах трудно достичь, но для этого имеются лиды этих команд. Раз было решение производить столь масштабные изменения и критические изменение, архитектору необходимо плотно взаимодействовать с бизнесом (заинтересованными сторонами), чтобы новая система удовлетворяла возложенным ожиданиям, а переход был не столь болезненным. Начиная с 1962 "Master Plan for Information System" предлагала определение необходимой инфраструктуры, анализ текущей, выявление различий, составления плана перехода и реализация перехода. Следование плану и его детального описания является ключевым требованием для успешности перехода и достижения конечного состояния системы. Из-за разнородности природы реализации в 1988 году Stategic Information Planing разделяет архитектуру на технологическую, системную, функциональную и архитектуру данных. В 1992 году появись слои в EAP детализации: планирование, бизнес слой, информационны ( данные, приложения и технологии) и слой реализации и миграции, что позволило говорить с бизнесом и ИТ на их языке. Далее, в 1995 для уменьшения рисков изменений и устаревания требований к конечной системе TOGAF предлагает разделить весь процесс на части ("циклы"), каждый из которых будет представлен отдельным проектом реализации для отдельного менеджера и объединены в "программу проектов", за которую отвечает уполномоченный менеджер. Сама интерактивность архитектурного цикла близка к спиральному походу в разработке и также требует неизменность результата в проекта. На текущем итеративном цикле нельзя принимать изменения от заинтересованных лиц, но можно их учитывать на следующей итерации этого цикла. Важным моментом, является то, что TOGAF преподносится как архитектурный фреймворк требующий адаптации и выбора необходимых элементов, а не готовый процесс и свод правил описания и следованию плану. Что с одной стороны дискредитирует идею его как серебряной пули в необходимый набор из сотни документов (артефактов) связанных общим правилом применения (архитектурным циклом), а с другой стороны показывает его гибкость как сродни набор программ в Linux. С переходом к облачной инфраструктуре, даже если компания не планирует использовать публичные облака, часто стремится сделать у себя приватное для стандартизации управления и применения. Таким образом, из разработке решений на базе облака физический (сети, сервера) и технологический (виртуальные мшаны, контейнера) переносятся из приложения в экосистему облака, оставляя бизнес уровень, ИТ уровень и уровень для миграции. Архитектор защищает свой проект перед бизнесом для получения бюджетирования на его реализацию.