Поэтому пошел смотреть блог самой компании OpenAI, там в разделе ограничений (Limitations) есть пункт, что пока модель не задает вопросы, а предугадывает назначения вопроса. "Ideally, the model would ask clarifying questions when the user provided an ambiguous query. Instead, our current models usually guess what the user intended."
Так что пока "чат" этого не умеет и делается это намеренно. Но как только он научится задавать вопросы, да, полезность для решения сложных задач увеличится
Соглашусь, подобные системы могут запросто представлять угрозу, находясь внутри корпоративного контура. Но и через пару лет будет сложно игнорировать их пользу и выгоду использования. Думаю, что все равно должны появиться относительно безопасные решения. Хотя пока сложно представить, что ИБ какого-нибудь банка согласует их использование.
Полностью с Вами согласен. Взаимодействие с "чатом" пока больше напоминает общением со способным Junior-аналитиком. Но его стремительное развитие сложно отрицать.
Спасибо, что прочитали) Если кратко объяснить разницу именно в моем понимании. То повторюсь, архитектор решений это мост между бизнесом и ИТ. При этом уровень проектирования, который выполняет архитектор все таки концептуальный. То есть проектируя интеграцию архитектор решений, например, установит, что в конкретном случае требуется асинхронная интеграция с использованием Кафка, где будет передаваться бизнес-сущность данных "Клиент". При этом конкретный контракт API, со всеми его деталями будет прорабатывать уже системный аналитик. Что касается бизнес аналитика, то архитектор решений с его помощью узнает детальные бизнес требования (бизнес процесс, нормативные ограничения и тд.). При этом их непосредственной проработкой будет заниматься как раз БА.
Я думаю, что скорее всего у нас в первую очередь разное понимание конкретной роли Архитектор решений. В более менее устоявшейся концепции, он как раз выполняет роль моста между бизнесом и ИТ. Что касается именно архитектора решений, который не знает бизнес, не общается с его представителями и не понимающий домен, вряд ли сможет этому бизнесу какую-то большую пользу принести))
Кажется, что это все таки устоявшееся название и перевод это разные вещи)
Таким образом можно сказать про каждый термин.
Ну и плюсом ко всему просто для сравнения: если вбить в поиск вакансий на том же hh, то получите 130+ вакансий с упоминанием "solutions architect" против 1800+ вакансий с упоминанием "архитектор решений".
Поэтому по сколько статья написана на русском языке и предназначена для русскоязычного читателя, то считаю более корректным использовать все таки "архитектор решений"
Интересно на самом деле. Это тоже зависит от организации по большей степени.
Я лично с вопросами бюджета напрямую не сталкиваюсь вообще. С этим работает тех(ИТ) лид проекта.
+ далеко не всегда выбор реализации зависит от прямых экономических факторов. Есть также история про соответствие стандартам корп архитектуры и возникающий тех долг в случае отрицательного ответа. А тех долг в свою очередь обязателен к исправлению в рамках какого-то своего горизонта планирования. (опять же говорю про конкретный кейс)
В целом так и есть. Я относительно недавно в роли. После Вашего комментария понял, что это важно отразить для формирования контекста, что и сделал в начале статьи.
По остальным моментам тоже согласен. Спасибо, что заметили. Также внес исправления в статью.
Про TOGAF только хочется сказать, что да, это нельзя назвать паттерном. Это скорее набор "бест-практисов" и фреймворк. Просто показалось не нужным выделять их в отдельный раздел.
Отлично сформулировано! В статье я не стал сильно подробно раскрывать подноготную общения с бизнесом. В целом я это и имел в виду, когда подмечал, что очень важно уметь задавать вопросы.
По поводу времени на встречи: безусловно опыт индивидуален и зависит от многих условий, как отлично подметил @leonidv. Данные примечания я добавил в статью.
В первую очередь я отталкивался от своего опыта, а также спрашивал нескольких коллег, в том числе из других отраслей(не только банковских). Но как вы понимаете ни о какой статистической достоверности здесь речи не идет)
Если честно, не нашел такую опцию.
Поэтому пошел смотреть блог самой компании OpenAI, там в разделе ограничений (Limitations) есть пункт, что пока модель не задает вопросы, а предугадывает назначения вопроса.
"Ideally, the model would ask clarifying questions when the user provided an ambiguous query. Instead, our current models usually guess what the user intended."
Так что пока "чат" этого не умеет и делается это намеренно. Но как только он научится задавать вопросы, да, полезность для решения сложных задач увеличится
Соглашусь, подобные системы могут запросто представлять угрозу, находясь внутри корпоративного контура. Но и через пару лет будет сложно игнорировать их пользу и выгоду использования. Думаю, что все равно должны появиться относительно безопасные решения. Хотя пока сложно представить, что ИБ какого-нибудь банка согласует их использование.
Спасибо!
Полностью с Вами согласен. Взаимодействие с "чатом" пока больше напоминает общением со способным Junior-аналитиком. Но его стремительное развитие сложно отрицать.
Спасибо, что прочитали)
Если кратко объяснить разницу именно в моем понимании. То повторюсь, архитектор решений это мост между бизнесом и ИТ. При этом уровень проектирования, который выполняет архитектор все таки концептуальный. То есть проектируя интеграцию архитектор решений, например, установит, что в конкретном случае требуется асинхронная интеграция с использованием Кафка, где будет передаваться бизнес-сущность данных "Клиент". При этом конкретный контракт API, со всеми его деталями будет прорабатывать уже системный аналитик.
Что касается бизнес аналитика, то архитектор решений с его помощью узнает детальные бизнес требования (бизнес процесс, нормативные ограничения и тд.). При этом их непосредственной проработкой будет заниматься как раз БА.
Я думаю, что скорее всего у нас в первую очередь разное понимание конкретной роли Архитектор решений. В более менее устоявшейся концепции, он как раз выполняет роль моста между бизнесом и ИТ.
Что касается именно архитектора решений, который не знает бизнес, не общается с его представителями и не понимающий домен, вряд ли сможет этому бизнесу какую-то большую пользу принести))
Кажется, что это все таки устоявшееся название и перевод это разные вещи)
Таким образом можно сказать про каждый термин.
Ну и плюсом ко всему просто для сравнения: если вбить в поиск вакансий на том же hh, то получите 130+ вакансий с упоминанием "solutions architect" против 1800+ вакансий с упоминанием "архитектор решений".
Поэтому по сколько статья написана на русском языке и предназначена для русскоязычного читателя, то считаю более корректным использовать все таки "архитектор решений"
Интересно на самом деле. Это тоже зависит от организации по большей степени.
Я лично с вопросами бюджета напрямую не сталкиваюсь вообще. С этим работает тех(ИТ) лид проекта.
+ далеко не всегда выбор реализации зависит от прямых экономических факторов. Есть также история про соответствие стандартам корп архитектуры и возникающий тех долг в случае отрицательного ответа. А тех долг в свою очередь обязателен к исправлению в рамках какого-то своего горизонта планирования. (опять же говорю про конкретный кейс)
Спасибо! Опечатался. Поправил)
Спасибо за комментарий!
В целом так и есть. Я относительно недавно в роли. После Вашего комментария понял, что это важно отразить для формирования контекста, что и сделал в начале статьи.
По остальным моментам тоже согласен. Спасибо, что заметили. Также внес исправления в статью.
Про TOGAF только хочется сказать, что да, это нельзя назвать паттерном. Это скорее набор "бест-практисов" и фреймворк. Просто показалось не нужным выделять их в отдельный раздел.
Отлично сформулировано! В статье я не стал сильно подробно раскрывать подноготную общения с бизнесом. В целом я это и имел в виду, когда подмечал, что очень важно уметь задавать вопросы.
По поводу времени на встречи: безусловно опыт индивидуален и зависит от многих условий, как отлично подметил @leonidv. Данные примечания я добавил в статью.
В первую очередь я отталкивался от своего опыта, а также спрашивал нескольких коллег, в том числе из других отраслей(не только банковских). Но как вы понимаете ни о какой статистической достоверности здесь речи не идет)
Спасибо, за комментарий! Диаграмму исправил!