Comments 23
Базы Данных: реляционные (MySQL, PostgeSQL и тд) и нерялиционные/NoSQL(MongoDB, Apache Cassandra, Neo4j и тд);
Даже интересно, во сколько такую ошибку оценит ваш работодатель.
И как тогда выглядит рабочий день? Диаграмма "Рабочий день архитектора решений".
Интересно, только я вижу, что вы дважды на диаграмме написали "Передача экспертизы" самыми темными цветами?
И очень прошу расставить запятые. Я понимаю, что текст уникально-самописный, но любой бесплатный сервис вам в помощь.
50% времени на встречи, такое возможно только на старте проекта.
И по собственному опыту могу сказать, что при выяснении требований бизнеса не менее важно то, о чем бизнес молчит или даже не задумывается, (например, не функциональные требования, необходимость учесть тенденции развития индустрии и пр.)
50% времени на встречи, такое возможно только "в одном из крупных российских банков". Потому что все боятся ответственности и играют исключительно в ИБД.
Задачи архитектора, и следовательно, его рабочий день сильно зависят от компании/организации, от фазы проекта и многих других факторов (например, выделен архитектор на один проект или шарится между несколькими). Правда об этом в статье не говорится.
Отлично сформулировано! В статье я не стал сильно подробно раскрывать подноготную общения с бизнесом. В целом я это и имел в виду, когда подмечал, что очень важно уметь задавать вопросы.
По поводу времени на встречи: безусловно опыт индивидуален и зависит от многих условий, как отлично подметил @leonidv. Данные примечания я добавил в статью.
В первую очередь я отталкивался от своего опыта, а также спрашивал нескольких коллег, в том числе из других отраслей(не только банковских). Но как вы понимаете ни о какой статистической достоверности здесь речи не идет)
Такое ощущение, что статью писал junior solution architect. В целом идея зон ответственности близка принятой у нас в компании (и лично мне), но очень много неточностей и ошибок. Visio это инструмент рисования, а не проектирования/моделирования, в TOGAF нет паттернов проектирования ПО и т.п.
Спасибо за комментарий!
В целом так и есть. Я относительно недавно в роли. После Вашего комментария понял, что это важно отразить для формирования контекста, что и сделал в начале статьи.
По остальным моментам тоже согласен. Спасибо, что заметили. Также внес исправления в статью.
Про TOGAF только хочется сказать, что да, это нельзя назвать паттерном. Это скорее набор "бест-практисов" и фреймворк. Просто показалось не нужным выделять их в отдельный раздел.
За годы работы с разными организациями я понял, что от архитекторов всегда спрашивают за ДЕНЬГИ. Задача архитектора - дать обоснование финансирования с учетом рассмотренных альтернатив и организовать сохранение намеченной выгоды. Если ему еще дают роль ГИПа, то спрашивают за эффективное использование вверенного ресурса. Все остальное типа встреч, документации, тушения пожаров чего-то там еще направлены именно на достижение этих задач.
Интересно на самом деле. Это тоже зависит от организации по большей степени.
Я лично с вопросами бюджета напрямую не сталкиваюсь вообще. С этим работает тех(ИТ) лид проекта.
+ далеко не всегда выбор реализации зависит от прямых экономических факторов. Есть также история про соответствие стандартам корп архитектуры и возникающий тех долг в случае отрицательного ответа. А тех долг в свою очередь обязателен к исправлению в рамках какого-то своего горизонта планирования. (опять же говорю про конкретный кейс)
Есть вполне устоявшееся название Solution Architect, зачем это переводить?
Кажется, что это все таки устоявшееся название и перевод это разные вещи)
Таким образом можно сказать про каждый термин.
Ну и плюсом ко всему просто для сравнения: если вбить в поиск вакансий на том же hh, то получите 130+ вакансий с упоминанием "solutions architect" против 1800+ вакансий с упоминанием "архитектор решений".
Поэтому по сколько статья написана на русском языке и предназначена для русскоязычного читателя, то считаю более корректным использовать все таки "архитектор решений"
Наверное затем, что если в русском есть полный синоним, то как раз использовать англосицизмы совсем необязательно и даже вредно, если нет желания превратиться в ужасное месиво из русско-английской солянки, которой сейчас больше, чем хотелось бы, встречается на пути. Многие не согласятся и посчитают я не прав - ведь это "эффективный способ коммуникаций". Это ваше мнение. У меня же мнение - у кого все в порядке с русским никаких сложностей использовать вместо ужасно звучащих "трекшн", "оунер"," реквайрмент" и т.д русские слова-синонимы.
Спасибо за статью! :)
Это так похоже на БА + СА в одном лице. В чем разница?
Разница в том, что в организации, в которой работает автор, принято все навешать на одного человека и назвать его архитектором. А, например, в организации, где работаю я, за общение с клиентом отвечают только аналитики, а вот именно архитектурой как раз и занимается архитектор решений.
Поэтому, на мой взгляд, статья содержит ошибочные утверждения, вызванные неправильным разделением ролей у его работодателя.
за общение с клиентом отвечают только аналитики
А кто клиенту опции предлагает по удешевлению цены проекта или наоборот удорожанию? Ну что там условно к нашему ПО надо сервер купить, нужен такой-то, стоит столько-то. Тоже аналитики?)
Работа начинается с этапа "Анализ требований", за который отвечают аналитики. На основании этого осуществляется проектирование решения (архитектором). В случае заказной разработки, с декомпозицией работ, состава команды, сроков и рассчитываемой на этом основании цены. После чего проводится тендер и с выигрывшим подписывется контракт.
Согласно же вашему вопросу, клиент не знает что хочет, в каком составе и хочет ли вообще.
Я думаю, что скорее всего у нас в первую очередь разное понимание конкретной роли Архитектор решений. В более менее устоявшейся концепции, он как раз выполняет роль моста между бизнесом и ИТ.
Что касается именно архитектора решений, который не знает бизнес, не общается с его представителями и не понимающий домен, вряд ли сможет этому бизнесу какую-то большую пользу принести))
Спасибо, что прочитали)
Если кратко объяснить разницу именно в моем понимании. То повторюсь, архитектор решений это мост между бизнесом и ИТ. При этом уровень проектирования, который выполняет архитектор все таки концептуальный. То есть проектируя интеграцию архитектор решений, например, установит, что в конкретном случае требуется асинхронная интеграция с использованием Кафка, где будет передаваться бизнес-сущность данных "Клиент". При этом конкретный контракт API, со всеми его деталями будет прорабатывать уже системный аналитик.
Что касается бизнес аналитика, то архитектор решений с его помощью узнает детальные бизнес требования (бизнес процесс, нормативные ограничения и тд.). При этом их непосредственной проработкой будет заниматься как раз БА.
Будни архитектора решений. Или кто он такой и чем занимается каждый день?