Конспект ИТ-архитектора. Евгений Сергеевич Штольц
Чтение книги онлайн.
Читать онлайн книгу Конспект ИТ-архитектора - Евгений Сергеевич Штольц страница 3
![Конспект ИТ-архитектора - Евгений Сергеевич Штольц Конспект ИТ-архитектора - Евгений Сергеевич Штольц](/cover_pre912489.jpg)
* 9. Эволюционирующий дизайн. Система наращивает отростки в виде сервисов – обрастает ими, при этом не требуется изменение её структуры. Neal Ford и Rebeca Parsons в "Микросервисы как эволюционирующая архитектура" ориентируются на постоянные улучшения.
Бизнес-архитектура (Enterprise Architect) – это IT архитектура всей компании. Она оперирует абстракциями и сущностями на уровне бизнеса, это стратегии, бизнес-процессы, услуги и тому подобного. Системы и взаимосвязи, обеспечивающие работу бизнеса, именуют ИТ ландшафтом, потому что она содержит множество систем, не образующих единое целое, связанные бизнес-процессами, в которых они участвуют и которые не ограничиваются ими. Бизнес- архитектора (Enterprose Architect) работает на этом уровне, подстраивая текущий ландшафт под текущую потребности бизнеса. Зачастую, для традиционных компаний, которые развивались не в высокотехнологической сфере в синем океане, он привлекается когда ИТ ландшафт сложился и возникают сложности его развития и адаптации под изменившиеся условия, в технологический стартапах создаётся минимально способный продукт (MVP). Бизнес-архитектор корпоративного ИТ ландшафта должна решать проблемы с низкой скоростью внесения изменений (из-за невозможности локального тестирования, откладывания распределённых изменений, иском поломки после накатки распределённых изменений) – Time To Market, быстрой адаптаций к ожиданиям пользователей – Customer Experience и стоимость – Cost. Первая решается последовательными активностями архитектора по наведению порядка, снижая связанность и запутанность, что упрощает и ускоряет процесс внесения изменений и как и в любой наукоемкой сфере, где основной затратой является человеко-часы работников, уменьшает стоимость. Архитектору всё чаще и чаще не предоставляются требования, он подключается на самых ранних этапах их формирования, после его возможности сильно ограниченны. Для этого ему нужно активно участвовать в переговорах и собраниях, чтобы корректировать требования. Далее сформировать несколько возможных решений с разным уровнем сложности, от простого и быстрого, но не эффективного ("решения на коленке"), через оптимальное, и до масштабного и гибкого. Далее сформировать архитектурный комитет, на котором предложить решения для выбора и скорректировать выбор в сторону оптимального.
Изменение существующий архитектуры может осуществляться тремя способами: сопровождение текущей, полной заменой текущей, дополнение текущей. Замена текущей требует проведение долгого и длительного исследования функционала текущей системы, далее выяснения функционала, который на текущий момент востребован и проведения поиска отличий между текущем функционалом и ожидаемым, после этого рассчитывается стоимость и время разработки. При презентации, в большинстве случаев будет получен отказ в разработке системы, так как заказчику не нужно техническое обновление существующего функционала, а ему нужен новы и корректировка старого, и тем более не за время