Pull to refresh

Comments 10

UFO just landed and posted this here

Часть нынешних Enterprise-архитекторов это специалисты, которые ранее занимались системной архитектурой. Они постепенно передают Solution-архитекторам свои задачи в части детального описания решений и существенно больше взаимодействуют с бизнес-заказчиком — погружаются в клиентские пути, use-cases и функционал новых продуктов.


Часть людей переходят из крупных ИТ-компаний. Это специалисты, имеющие хороший опыт работы корпоративными архитекторами.


Уровень дохода в нашей организации озвучивать не могу в виду формальных ограничений. Но он соответствует среднему значению относительно крупных ИТ-компаний.

UFO just landed and posted this here
Из составов команд разработки выделили Solution-архитекторов. В большинстве своем это разработчики или аналитики. Solution-архитекторы декомпозируют задачу от Enterprise-коллег

У вас, получается, аналитики стоят уже после архитекторов, а не общаются с бизнесом «на первой линии»? Или всё же есть какие-нибудь Enterprise-аналитики для управления требованиями верхнего уровня?
Насколько я понял из текста, верхнеуровневые требования — вотчина enterprise архитекторов, которые ими сами и управляют, накладывая на существующий ландшафт, либо формируя новые части ландшафта для удовлетворения бизнес-требований.

Схема такая. Во-первых, Enterprise-архитекторы берут на себя большой объём работы в части бизнес-аналитики. В статье описано укрупнённо. На самом деле в рамках проработки Enterprise-архитектуры есть три этапа — сервис-дизайн, проектирование архитектуры бизнес-сервиса и проектирование концептуальной архитектуры решения. Вот первый и второй этапы это в основном бизнес-аналитика — в нашем случае это карта клиентского пути (CJM), uses-cases, Service BluePrint, sequence-диаграммы бизнес-процессов, детальные функциональные требования (UX в общем). А на этапе проработки Solution-архитектуры свой скоуп задач решает уже системный аналитик. Он декомпозирует архитектуру бизнес-сервиса. Описывает сценарии интеграционных взаимодействий, например.


Во-вторых, работа всегда носит совместный характер. И системные аналитики и разработчики при необходимости привлекаются для консультаций на этапе Enterprise архитектуры. Нет «конвейера» с четко разграниченными зонами участия специалистов. Этапность здесь скорее — про хронологию создания архитектурных артефактов (документов, схем). Сначала Enterprise-артефакты, затем Solution.

Поэтому первыми задачами центра Enterprise-архитектуры мы увидели:… «Формирование единого технологического стека;» — удалось решить задачу? На чём остановились в итоге?

Добрый день! В организационном плане это тодна из сложных задач. С одной стороны мы должны создавать новые решения на том, что сможем далее развивать, переключая или подключая разработчиков из других команд. То, в чем есть широкие компетенции (напр., Java, Kotlin, MySQL, Kafka и др.). С другой стороны мы должны осваивать новые версии средств разработки или технологические решения. То есть «бетонировать» техстек на века было бы неправильно. Поэтому определяем сейчас основной набор технологий, плюс реализуем менеджмент процесса расширения техстека (изучение, тестирование, пилотирование и утверждение новых решений).

Sign up to leave a comment.