Комментарии 24
А есть какой-то чек-лист примерный по техническим скилам на solution architect? Было бы очень полезно почитать.
Мне кажется, все достаточно относительно. Но СУБД и навыки программирования это святое. И ещё конечно навыки подготовки диаграмм, это ведь тоже технический навык ))
Умение мыслить категориями бизнеса, базовый навык, без которого технические навыки бесполезны
Представьте ситуацию, что вы как архитектор не взаимодействуете с бизнесом, но при этом под вашей ответственностью интеграционные механизмы с огромными объёмами передаваемых данных. То, что вы не взаимодействуете с бизнесом, не говорит же о том, что вы не архитектор. Вы solution architect интеграционного решения, а бизнесом в данном случае выступают другие технические заказчики.
Я к тому, что не просто мыслить категориями бизнеса, а заменить термин Бизнес на термин Заказчик. Умение осознать потребность Заказчика.
Спасибо, очень правильный комментарий!
Интересные факты
Про то, что АС Супермаркет данных - это помойка, полная мусора и неконсистентных данных, от которой плюются большинство бизнес-потребителей, вынужденных работать с ней, в статье скромно умалчивается :)) Ну да ладно, а какие вообще в сбердате удачные внедрения за последние года 3? Семантический слой хоть на чем-то сделали?) или снова облажались?
Хотите продолжать работать в сбере?
По мне - вы просто хвастаетесь, что вы тот, кто вы сейчас. Никакой конкретики. Но себя-вознесение до небес в каждом слове.
создаёт продукт-автоматизированную систему, опираясь на концептуальную архитектуру. У такого специалиста должен быть богатый технический бэкграунд.
И это после кучи 'прошел курс' - вы серьёзно считаете это богатый технический бэкграунд?
Получить роль - это надо ещё подтвердить. Никогда ещё не слышал, чтобы с громкостью мемуаров кто-либо о своей должности с таким пафосом писал. Особенно мне бросается в глаза описания, что свою карьеру вы не сами отчасти строили. Нет. Это всегда было 'мне предложили'. Явный признак выдать желаемое за действительное. Но. Имеете полное право.
Довольно странно, не так я представлял себе путь до архитектора.
Сначала довольно специфический 1С ну да ладно 2010, "выживали как могли". Потом "стал углублённо изучать различные технологии, которые были нужны мне тогда, а также могли понадобиться в будущем" - не понимаю смысла этой абстрактой фразы, 0 информации. Программа антикризисного управления, внедрение лизинга. Что-то все совершенно разные сферы. Дальше перечень, который можно назвать "что-то на джуновском" - куча курсов разных, наверное все так в начале изучения программирования метались и изучали все, что под руку попадалось, чтобы, так скажем, в общий контекст войти, понять куда дальше идти. Странновато, особенно пункты, что разработчик с 10-летним опытом, переходящий в архитекторы вдруг до паттернов добрался и начал их изучать, "познакомился с noSQL" и т.д. Тут я стал бабкой из мема "wat?".
В целом ситуация, которая могла случиться не только с архитектором и не только в Сбере. Позиция в компании есть, жёсткого перечня требований нет. Нашёлся кандидат, который устроил внутреннего заказчика вакансии. Виноват ли сам кандидат, что его приняли? Нет. В принципе можно ли оперировать термином "вина"? Только если по итогу этот найм будет признан неудачным.
Так что пока можно пожелать удачи герою статьи и пускай всё получится.
Я скорее вижу позитивный посыл в статье: инвестиции в себя оправдались. Это мотивирует.
Но такое на публику ведь не глаголят. Это есть плохой стиль. Хвастаться собой. Переведи всё это в третье лицо, сделай немного нейтральнее, опиши как требования или условия для архитектора - и всё, нормальное повествование. А тут только бахвальство. При этом, всем в этой теме понимающим - нелогическое.
Возможно да, некоторые пункты можно обсудить, а пути же разные могут быть. Вот вы как себе представляли путь архитектора? Закончил институт, 10 лет работал программистом, потом 5 лет работал админом, потом набирался опыта в девопс, а потом решил стать архитектором, но вдруг отметил 65 лет и ушёл на пенсию? Поэтому и приходится опыт получать в конкретной сфере, а со многими вещами, технологиями знакомиться уже без прикладного опыта, а только на уровне необходимого и достаточного.
Вы что думаете, какие пути бывают по вашему представлению?
Ну конечно же пути бывают разные. Бывают таланты как Стив Возниак - ему никакие курсы не нужны были. Он каждый транзистор и резистор по имени знал ;) и придумывал, создавал и архитектуру и софт и hardware. Иногда и по знакомству вообще без тех. навыков становятся - встечал такое на моём пути. Чел даже не понимал диаграммы. От слова никакие. Ни систем, ни процессов, ни data flow, ни UML, ни базы данных итд. А 'свои' рисовал в paint.
Мне кажется вы не совсем поняли собеседника, которому отвечали. Само по себе посещение курсов есть правильно, но указывать их в одной строчке с 'богатым техническим бекграундом' - как-то не подтверждающе. А про конкретные свои задачи - 'работаю с требованиями и документацией' - так и вообще вы как архитект сказали, что ничего сказать не можете. Об этом речь была.
Тема сисек на раскрыта. Пятихатку то платят сисархам в сбере?
"...
Если вы ещё студент, обязательно учитесь и не пропускайте много занятий. Это не просто слова, а личный опыт. Дело в том, что недавно мне пришлось повторять в рабочих целях институтский курс по модели OSI — это про 7 уровней работы протоколов..."
Вы до того как стали Архитектором с сетью не работали ? Как системы строили ? Все внутри кспд ?
Не было такой необходимости. Работа с сетью это довольно специализированная работа, как правило имеющая мало общего с решением бизнес-задач. На мой взгляд это сугубо технический навык. И как правило при построении систем работа идёт с протоколами http или tcp (7 и 4 уровни соответственно). Что происходит на канальном уровне - зачем бы это было нужно.
Работа с сетью это довольно специализированная работа, как правило имеющая мало общего с решением бизнес-задач.
Не согласен с вами. Для специалиста из маркетинга это не важно. Для архитектора при разработки систем, тем более в такой среде как банк - это жизненно важно.
Тогда предлагаю вернуться к статье, и в принципе к разделению обязанностей. Если как было сказано архитекторы бывают Enterprise, Solution, System - все ли они должны работать с канальным, сетевым и физическим уровнями? В чем заключается жизненная важность?
Solution Architect — создаёт продукт-автоматизированную систему, опираясь на концептуальную арархитектуру.
и чем конкретно вы занимаетесь. Понимаете , что под этими словами стоит ничего. Звучит круто, но самом деле - кто-то создал по настоящему до вас что-то сложное и концептуальное как архитектуру, а вы 'создаёте '... что вы создаёте?
Как думаете, есть разница между концептупльной архитектурой и детальной архитектурой
без понимания 'детальной' архитектуры невозможно заниматься концептуальной. Я вижу вы хотите передёргивать, и да коструктор ракеты не в каждой области специалист. Но понимает каждую область сильно, потому что постоянно информируется, участвует в дискуссиях, и интегрирует инсайты из каждой области в общую кострукцию.
Как работает Сбер я не знаю, но за 30 лет работы в Германии я имел дело с разными отраслями. В их числе и банковсккий сектор. Хотя это для понимания работы solution архитектора не играет никакой роли. Здесь вы опять передёргиваете. Мол, если я каким образом не знаю Сбер, то и сказать мне типа нечего. Хотя разговор ведётся о роде деятельности, которая в принципе универсальна. А вот на мой вопрос, чем конкретно вы занимаетесь, кроме общих фраз в статье ' вы не ответили. Тактично вопросом на вопрос увильнули. Вы хитрый.
Но поверьте, мир полон разных людей. И если вы добрались до позиции архитектора, то может быть стоит не сильно кричать на весь мир, какой вы крутой, и что вы там-то и там-то. А то можете нечаянно нарваться на 'мальчика из сказки, который закричит, что король-то голый'.
Хочу отметить, что до позиции архитектора не нужно добираться, нужно просто выбрать эту специализацию как программисты выбирают программирование, аналитики анализ, а дизайнеры дизайн, так и архитекторы выбирают архитектуру. Чтобы работать с концептуальной не нужно перед этим обязательно работать с детальной, тут не может быть иерархии или обязательной последовательности, а должна быть только матрица распределения обязанностей. Конечно же как Enterprise понимает что делает Solution так и наоборот. Только первый работает с абстракциями более верхнего уровня, а второй уже с командами разработки - участвует во встречах по проектированию нового функционала, является транслятором между командами АС и смежными подразделениями, готовит документацию своего уровня абстракции. Т.е. каждый из архитекторов просто выбрал свою специфику.
Верю, что есть такие люди, для которых данный материал оказался полезным.
Как я стал Solution Architect в Сбере: карьерный путь длиной в 12 лет