Size: a a a

Архитектура ИТ-решений

2020 May 29

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Oleg Zaharchuk
В том числе BPMS. Это платформа управления деятельностью. А если еще точнее - платформа построения и управления экосистемами предприятий. Платформа не монолит. Библиотеки сервисов могут быть распределены по разным серверам.
.NET меня лично пугает. Я за JVM решения.
источник

А

Алексей in Архитектура ИТ-решений
Leonid Vygovskiy
Я для себя так решил. По возможности технические аспекты беру на себя (протокол, вызовы и т.п.). А вот маппинг полей это уже отдаю на откуп аналитикам. Но не всегда так получается, иногда приходится все отдавать.
Когда общаешься с заказчиками бывает полезно обсудить в том числе и нюансы подключений, по крайне мере показать, что в теме и разбираешься.
Понял, спасибо за мнение
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Leonid Vygovskiy
.NET меня лично пугает. Я за JVM решения.
Норм, на самом деле. Что точно видно - это то, что на русском языке + в программном продукте доступно понимание "единой модели". Это радует, так как можно говорить про "единую модель". Например, "единая" =

1) одна (single)
2) стандартная, и через это объединяющая (unified)
3) общая в смысле "мы разные - но мы знаем, что у нас общее" (shared)
источник

OZ

Oleg Zaharchuk in Архитектура ИТ-решений
Eugene Istomin
Норм, на самом деле. Что точно видно - это то, что на русском языке + в программном продукте доступно понимание "единой модели". Это радует, так как можно говорить про "единую модель". Например, "единая" =

1) одна (single)
2) стандартная, и через это объединяющая (unified)
3) общая в смысле "мы разные - но мы знаем, что у нас общее" (shared)
Ну, если быть точным, то единая метамодель - элементы конструктора для построения уникальных моделей предприятий.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Oleg Zaharchuk
Ну, если быть точным, то единая метамодель - элементы конструктора для построения уникальных моделей предприятий.
Если говорить "формальных каркасов юридических форм и движения внутренних процессов в рамках законов РФ" - то да, это норм история.
Но всё переводить на БП ... эпик с Комундой же есть. И российский опыт BP-based ERP в 2000-е
источник

OZ

Oleg Zaharchuk in Архитектура ИТ-решений
Eugene Istomin
Норм, на самом деле. Что точно видно - это то, что на русском языке + в программном продукте доступно понимание "единой модели". Это радует, так как можно говорить про "единую модель". Например, "единая" =

1) одна (single)
2) стандартная, и через это объединяющая (unified)
3) общая в смысле "мы разные - но мы знаем, что у нас общее" (shared)
Net. - конечно устарел. Но логика отработана. Ищем возможности перевода на JVM.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Алексей
Добрый день. Подскажите пожалуйста, входит ли в обязанности солюшн архитектора проработка вопроса протоколов информационного взаимодействия между элементами проектируемой системы и для общения этой системы с какими-то внешними системами? Имею в виду проработку в части состава данных, их структуры. Или эту роль выполняет кто-то другой?
В идеале солюшен выбирает протокол (ну, если есть из чего выбирать), а детали типа состава и названия полей - это уже к аналитикам.
А по факту - где нет экспертизы (или есть какие-то принципиальные моменты) - там и закрываешь. Некому больше состав полей определить - ну ок, солюшен может и не такое)
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
однажды у меня был проект, где весь солюшен заключался в недокументированном использовании одного поля...
источник

MS

Maxim Shalomovich in Архитектура ИТ-решений
Alexey Pryanishnikov
В идеале солюшен выбирает протокол (ну, если есть из чего выбирать), а детали типа состава и названия полей - это уже к аналитикам.
А по факту - где нет экспертизы (или есть какие-то принципиальные моменты) - там и закрываешь. Некому больше состав полей определить - ну ок, солюшен может и не такое)
согласен, на практике протокол и технические аспекты без полей и сервисов особо никому не нужны. Так что в итоге если получается "спихнуть" описание бизнес-деталей на аналитиков и дать им на вход технические особенности - хорошо. Если не получается - пилишь сам
источник

I

Irina in Архитектура ИТ-решений
Oleg Zaharchuk
В том числе BPMS. Это платформа управления деятельностью. А если еще точнее - платформа построения и управления экосистемами предприятий. Платформа не монолит. Библиотеки сервисов могут быть распределены по разным серверам.
Платформа -монолит?
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Maxim Shalomovich
согласен, на практике протокол и технические аспекты без полей и сервисов особо никому не нужны. Так что в итоге если получается "спихнуть" описание бизнес-деталей на аналитиков и дать им на вход технические особенности - хорошо. Если не получается - пилишь сам
От масштаба ещё зависит. Если в решении участвует несколько десятков совершенно разных технически систем, то как-то наоборот, всем становится наплевать на то, под каким там конкретно названием между 21-й и 13-й системой передаётся какой-нибудь идентификатор клиента - программисты разберутся
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Irina
Платформа -монолит?
Для монолитных компаний нужны монолитные решения.
Т.е. это норм, сегмент "ВНИИФТРИ-ГК НПЦ им.Хруничева-..." работает в монолитном оргдизайне, и им нужны современные монолитные решения.
источник

I

Irina in Архитектура ИТ-решений
Eugene Istomin
Для монолитных компаний нужны монолитные решения.
Т.е. это норм, сегмент "ВНИИФТРИ-ГК НПЦ им.Хруничева-..." работает в монолитном оргдизайне, и им нужны современные монолитные решения.
На счет современности тут как-то сомнения)
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alexey Pryanishnikov
В идеале солюшен выбирает протокол (ну, если есть из чего выбирать), а детали типа состава и названия полей - это уже к аналитикам.
А по факту - где нет экспертизы (или есть какие-то принципиальные моменты) - там и закрываешь. Некому больше состав полей определить - ну ок, солюшен может и не такое)
Если не требуется оптимизация структуры данных. Есть момент определения того, когда и сколько какие данные использоваться будут. Аналитик не всегда может по этим сведениям собрать оптимальный состав полей.
Аналогично проектированию бд, думаю
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Irina
Платформа -монолит?
Другой вопрос в том, например, что СеверСталь уже лет 10 двигается в другом направлении. Как и сотни компаний.
Магнит, например, в этом году завёл топов из LaModa :)
источник

I

Irina in Архитектура ИТ-решений
Eugene Istomin
Для монолитных компаний нужны монолитные решения.
Т.е. это норм, сегмент "ВНИИФТРИ-ГК НПЦ им.Хруничева-..." работает в монолитном оргдизайне, и им нужны современные монолитные решения.
На счет утверждения что монолитным компаниям нужны монолитные решения,  тоже спорно
источник

MS

Maxim Shalomovich in Архитектура ИТ-решений
Alexey Pryanishnikov
От масштаба ещё зависит. Если в решении участвует несколько десятков совершенно разных технически систем, то как-то наоборот, всем становится наплевать на то, под каким там конкретно названием между 21-й и 13-й системой передаётся какой-нибудь идентификатор клиента - программисты разберутся
ну да, согласен. Вообще мой ответ (как и изначальный вопрос) неполон. Нужно понимать, для чего солюшн разрабатывает ПИТВ (систем внутри решения?), кто отвечает за каждую систему (т.е. кто как бы потребитель ПИТВ) и т.д. В моей практике все ПИТВ в итоге падают на программистов, для которых технические детали обычно либо уже известны (так как ПИТВ в итоге пытается учесть особенности их существующих АПИ), либо ограничиваются выбором "выставить рест/ писать в (читать из) очередь". А чтобы разработать само АПИ ,им как раз нужны поля, данные и структуры
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Irina
На счет современности тут как-то сомнения)
Банки и атомные станции с вами не согласятся :) Кобол в 2020
https://www.cnews.ru/news/top/2020-04-07_ssha_izza_koronavirusa_ponadobilis
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Алексей
Добрый день. Подскажите пожалуйста, входит ли в обязанности солюшн архитектора проработка вопроса протоколов информационного взаимодействия между элементами проектируемой системы и для общения этой системы с какими-то внешними системами? Имею в виду проработку в части состава данных, их структуры. Или эту роль выполняет кто-то другой?
Здесь помимо технологии и состава полей совместно с аналитиками должно быть проработано описание потоков данных, их назначение, сущности, которые будем передавать, использование этого взаимодействия.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Irina
На счет утверждения что монолитным компаниям нужны монолитные решения,  тоже спорно
Зависит от типа "питания": если компания является chain'ом ещё большего дотационного монолита - то гибкое решение развалит всю структуру не по тех.причине или интерфейса - заказ на изменения орг.дизайна обычно связан с эпиком, и этот эпик должен "созреть".
Например, у Сазерленда в "SCRUM. Революционный ..." с похожего эпика FBI начинает книга.
источник