Из разработчика в архитекторы. Практический путь. Евгений Сергеевич ШтольцЧитать онлайн книгу.
части и могут объять реализацию всего приложения, могут получить экспертизу у более узких членов их команд, когда их экспертизы не хватает. Если речь идёт о 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 преподносится как архитектурный фреймворк требующий адаптации и выбора необходимых элементов, а не готовый процесс и свод правил описания и следованию плану. Что с одной стороны дискредитирует идею его как серебряной пули в необходимый набор из сотни документов (артефактов) связанных общим правилом применения (архитектурным