Для монолитных компаний нужны монолитные решения. Т.е. это норм, сегмент "ВНИИФТРИ-ГК НПЦ им.Хруничева-..." работает в монолитном оргдизайне, и им нужны современные монолитные решения.
Очень плотно работали с космическими компаниями. Там проблема не в монолите, а в зрелости компании - готовности вообще переходить на АСУ.
Если не требуется оптимизация структуры данных. Есть момент определения того, когда и сколько какие данные использоваться будут. Аналитик не всегда может по этим сведениям собрать оптимальный состав полей. Аналогично проектированию бд, думаю
Да, но всё ж зависит от масштаба и количества легаси. Обычно солюшен всё же работает не с новыми ландшафтами, а с уже существующими. И даже если в рамках солюшена возникает новая система (что, вообще говоря, далеко даже не в половине случаев бывает), модель данных всей компании переделывать уже поздновато
Здесь помимо технологии и состава полей совместно с аналитиками должно быть проработано описание потоков данных, их назначение, сущности, которые будем передавать, использование этого взаимодействия.
Спасибо, более менее уже вырисовывается картина теперь
Да, но всё ж зависит от масштаба и количества легаси. Обычно солюшен всё же работает не с новыми ландшафтами, а с уже существующими. И даже если в рамках солюшена возникает новая система (что, вообще говоря, далеко даже не в половине случаев бывает), модель данных всей компании переделывать уже поздновато
Отож. Хотя с легаси тоже может быть любопытное ковыряние. У меня, помню, одна из первых задач как аналитика была такая: вот тебе три зип архива с кодом легаси систем, найди в них интерфейсы, которые выдают нужную инфу. А все потому что новая система должна была сравнивать данные и выдавать результат на их основе.
Очень плотно работали с космическими компаниями. Там проблема не в монолите, а в зрелости компании - готовности вообще переходить на АСУ.
» готовность вообще переходить на АСУ У А.И.Пригожина в "Дезорганизации" есть глава "проклятие нереализуемости", где первой причиной неосуществимости решений являются управленческие предрассудки.
ну да, согласен. Вообще мой ответ (как и изначальный вопрос) неполон. Нужно понимать, для чего солюшн разрабатывает ПИТВ (систем внутри решения?), кто отвечает за каждую систему (т.е. кто как бы потребитель ПИТВ) и т.д. В моей практике все ПИТВ в итоге падают на программистов, для которых технические детали обычно либо уже известны (так как ПИТВ в итоге пытается учесть особенности их существующих АПИ), либо ограничиваются выбором "выставить рест/ писать в (читать из) очередь". А чтобы разработать само АПИ ,им как раз нужны поля, данные и структуры
Забавно, что я при полном понимании смысла не могу подобрать расшифровку для "ПИТВ" ) Русские аббревиатуры - ужасная и беспощадная всё же вещь
Интересует некоторый обязательный набор систем и какие зоны они закрывают. Какие существуют решения и вендоры.
Да поправят меня коллеги, но обязательного набора систем может и не быть, если в требованиях ЦБ это не заложено (каюсь, не помню их в деталях) Стоит отталкиваться скорее от требований к тому, что нужно защищать, и как именно нужно защищать. А как именно это будет реализовано - есть некоторые (пусть и узкие) допустимые границы, в которых есть свобода выбора решений
Да поправят меня коллеги, но обязательного набора систем может и не быть, если в требованиях ЦБ это не заложено (каюсь, не помню их в деталях) Стоит отталкиваться скорее от требований к тому, что нужно защищать, и как именно нужно защищать. А как именно это будет реализовано - есть некоторые (пусть и узкие) допустимые границы, в которых есть свобода выбора решений
Наверняка есть некоторый условно базовый набор характерный для данной области знаний. Например антифрод система. Не важно как она реализована и кем, обычно она есть.
Вот меня как раз интересует набор подобных систем характерных для банка. При чем понятное дело, что от размера банка и его “уклона” зависит итоговый набор систем и он может быть очень разным
Тогда еще вопрос: какого, хмм, уровня абстракции, системы интересуют? Антифрод - это, условно, некая логика корректности атрибутов операций, один уровень абстракции, а, например, мониторинг событий несанкционированного доступа - другой