Comments 17
Статья архитектора решений о том, какая хорошая роль/профессия архитектор решений.
А книжечки для развития, какие посоветуете?
Быть глубоко погруженным три десятка комплексных уникальных проектов одновременно?
Моё почтение)
Позиция Solution Architect появилась в индустрии сравнительно недавно — пять-шесть лет назад.
Забавно. С десяток лет назад был на проекте в этой роли в команде из полдюжины таких же олдфагов и мы оказывается тогда не существовали. ;-) Не в России.
Самой специализации лет 20 минимум только в РФ, в мире и все 40 лет будет, так как роль (и позиция) возникает довольно быстро в любой компании, занимающейся внедрением сложных продуктов. Автор просто довольно плохо разбирается в этой теме.
На мой взгляд, вопрос таксономии архитекторов не раскрыт ) Даже быстрый просмотр статьи википедии дает понимание, что единого мнения/определения нет. Да что уж там, в разных компаниях одной отрасли эта роль часто может иметь разный набор обязанностей)) Отсюда и недопонимание о сроках возникновения роли кмк.
О чём и речь, с этого бы начать статью.
Проблема в расплывчатости определения позиции Архитектор в ИТ:
Software, Solution, Pre-Sales, Network, Cloud, все в куче, Amazon добавляет мути со своими сертификациями начальных уровней.
Кто-то цепляется за знание togaf/zauman, умение рисовать красивые диаграмки для C*O и клиентов и умение забалтывать умными словами.
Я всегда думал, что это специалист с глубоким техническим знанием (уровня CCA) во множестве областей, способный поддерживать целостную картину проекта (продаваемого, разрабатываемого или поддерживаемого), разговаривать на одном языке с тех спецами и бизнесом, с реализацией оного в легких для понимания диаграммам с разным уровнем детализации (от 1 page high level до насколько возможно) и четкими связями для планирования долгосрочного развития.
Ну шоб не развивался хаотический зоопарк из случайных технологий - видел один долгоиграющий проект, состоящий из кусков кода на разных языках от VBasic до asm, который было совершенно невозможно поддерживать.
Так кто же он, мифический Архитектор в ИТ?
Описание как поставлена работа с заказчиком, про аккаунт-менеджеров и пресейлов, конечно, поразила. Удивительно читать такое странное про одну из крупнейших компаний в ИТ.
Язык статьи тяжёлый, в итоге кусками почитал. Много канцелярита, предложения никак не могут закончиться и начинаются повторы.
В статье получается, что SA, несмотря на название, ещё и бизнесовое решение придумывает. Хотя чего удивляться, см. как у них устроена продажа решений
Касаемо участия солюшнов в пресейлах и помощи в продаже - могу сказать по своему опыту что для вендоров это вполне обычная практика. Собсно, а почему бы и нет? Если у человека хорошо получается, то флаг в руки имхо.
Возможно, тут я плохо понимаю, кто такой пресейл.
В моём розовом мире:
1. У потенциального заказчика решения возникла потребность/задача
2. Выдвигается бизнес-аналитик, с заказчиком полностью понимает что надо по бизнесу
3. И только тут подключается SA. Прикидывает архитектуру для данной задачи.
Все дружно считают проект (деньги, людей, ...) и пресейл(?) идёт к заказчику.
Дальше уже итерационно
Такой вариант возможен и даже работает, но не всегда ) Условно, заказчик с БА решают что надо пользователю уведомления слать через пуши. Требования отдают солюшну, тот рисует квадратик "пуш гейта", sdk в прикладе и счастливо отдает в реализацию. Только вот проблема что нет и гейта, ни sdk. И надо выбирать, внедрять, адаптировать.
На этом месте наверняка захочется сказать - да делов то, на файрбейсе сейчас приляпаем за пару дней. Однако хотел бы напомнить, что это просто пример создания IT capability с нуля, который может быть трудоемок прежде всего процессом согласования.
Возвращаемся к нашему сценарию. Итак, мы потратили 2-3 месяца чтобы все это сделать, внедрили. И тут оказалось что бизнес-гипотеза не сработала и все наши месяцы работы не окупяться в ближайшее время, мы в минусе.
А как можно по другому? А можно было на этапе обсуждения клиентского пути вместе с заказчиком и БА сказать: "Гайз, короче пушей сейчас нет, делать их примерно вот столько времени и денег. Но можем взять email уведомления с диплинками. Это уже сейчас работает. Да, клиентский опыт чуть хуже, но зато базовые параметры гипотезы позволит проверить без больших затрат. И уже только если гипотеза выстрелила - сделать нормально.
Важно! В данном случае не сам солюшн может придумать обходной маневр, это может предложить любой участик обсуждения. Важно чтобы заказчик и БА понимали "зрелость" ит решений и подстраивали итоговый клиентский путь с их учетом. Понимая цены риска каждого из вариантов реализации и выбирая вместе оптимальный.
Если позволите, немного обратной связи от коллеги)
Вы справедливо заметили что навыки презентации и продажи чертовски важны для роли SA. Но сама статья по структуре получилось рыхлая - без вводной, проблематизации, тезисов и поддержки, краткого резюме. Визуал имхо не очень подкрепляет материал. Нет акцентов по тексту, структура сливается в поток мыслей.
В качестве верхней булки "бутерброда" - опыт интересный, спасибо. Продолжайте делиться, удачи на вечном пути к совершенству формы и содержания)
Универсальный дирижер проекта: что стало с ролью Solution Architect и как она меняет IT