Анализ и проектирование систем *

Представьте, что нужно заменить двигатель самолета прямо в полете. Примерно в такой ситуации мы оказались, когда взялись за локализацию производственных систем одного российского завода. Черный ящик вместо системы управления, запароленный доступ, отсутствие документации и невозможность останавливать производство — весь джентльменский набор подводных камней после 2022 года.

Я Иван Балашов, в интеграторе К2Тех руковожу направлением цифрового производства и внедряю цифровые решения в промышленности. В этом кейсе расскажу, как мы собирали пазл из обрывков информации о настройках систем, внедряли российскую SCADA взамен западной, мигрировали функционал MES, и все это без остановки производства.

Если вы когда-нибудь окажетесь перед задачей импортозамещения критически важных производственных систем, эта история может дать представление о типичных подводных камнях и способах их обхода.

Это первая статья из серии BPMN: Beyond the Basics – о скрытых нюансах и подводных камнях BPMN для разработчиков. В отличие от аналитиков, разработчикам надо не просто знать нотацию, но понимать, как реализован тот или иной ее элемент. А тут, как говорится, не все так однозначно.

Для начала возьмем самый простой – шлюз ИЛИ (Exclusive Gateway). На первый взгляд, всё очевидно: ставишь ромбик, рисуешь стрелочки – и вуаля! Но что происходит внутри движка? Как он выбирает путь выполнения? Что делать, если несколько условий срабатывают одновременно? А если ни одно не выполняется? В этой статье мы разберем эти вопросы и рассмотрим особенности реализации и использования этого элемента.

Разбираться будем на примерах в Jmix BPM с движком Flowable, но принципы универсальны – нотация BPMN 2.0 едина, и основные механизмы работы элементов схожи во всех движках, частности в Camunda 7. Об отличиях, если они встретятся, будем говорить особо.

Традиционный подход к разработке программных продуктов и бизнес-решений обычно фокусируется прежде всего на конечном результате: формальных моделях, спецификациях или непосредственно коде. Однако такой подход зачастую упускает из виду очень важный аспект: процесс рассуждений, которые привели к этим формальным структурам.

Каждая формальная структура — это лишь вершина айсберга. Под поверхностью скрываются многочисленные рассуждения, гипотезы и промежуточные описания различной степени формальности. Например, прежде чем прийти к чёткой структуре данных или бизнес-плана, мы обычно проходим путь от неформального наброска идеи, через промежуточные уровни формализации, постепенно уточняя наше понимание и спецификации.

Оценка систем по критериям - понятная конструкция, но как оценивать системы совершенно разного прикладного назначения, есть системы типа CRM, АБС, процессинги, интеграционные решения и т.д.? Тут следующая мысль: каждая информационная система, все же система, т.е. у них всех имеется что-то общее, что можно сравнивать.

Наша критериальная модель построена именно исходя из этого соображения. Часть критериев рассматривает техническое совершенство системы, а другая часть оценивает насколько решение соответствует требованиям, конкретной функциональной области.

Обстоятельно и подробно, на конкретных примерах рассказываю как спроектировать и реализовать API, за которое потом не будет стыдно.

В этой статье я постараюсь рассказать и показать, почему я использую подход doc-as-a-code, как помогает git системному аналитику и зачем это всё.

Продолжение цикла статей о проектировании информационных систем.

Предыдущие статьи:

Введение

В этой части рассмотрим проработку видения системы со стороны бизнес-заказчика.

Привет, Хабр! Я Павел Куницын, главный специалист по анализу данных и машинному обучению в ПГК Диджитал. Мы занимаемся разработкой цифровых продуктов в сфере железнодорожных грузоперевозок: интерактивной карты вагонного парка, оптимизатора ремонтов и других решений. В большинстве из них мы применяем машинное обучение.

О том, как мы подходим к этому, я и мои коллеги рассказываем в нашем блоге на Хабре. Например, мы работаем с MLflow, который помогает анализировать результаты и вести учет экспериментов. Но несмотря на доступную автоматизацию, на этапе экспериментов могут возникать определённые сложности. Расскажу о наиболее частых проблемах.

Каждый раз, когда меня спрашивают: «А как ты вообще пришел к этим заповедям?», я улыбаюсь и вспоминаю одну историю. Она началась не в IT, не в офисе и даже не за чашкой кофе (хотя кофе, конечно, был). Она началась там, где начинается всё важное — в голове одного человека, который однажды осознал, что его жизнь превратилась в бесконечный марафон без финишной черты.

Первый архитектурный инструмент системы принятия решений – функциональную архитектуру – мы рассмотрели, следующий по логике рассмотрения критериальная модель оценки. Перед тем как рассматривать ее нужно определиться с принципами ее построения.

В этой части мы разберем постановку задачи на проектирование критериальной модели оценки. Какие «пользователи» будут у модели, какие у них требования к ней (точнее интересы) какие конфликты этих интересов могут случится и как их «разрулить»?

Эта статья - первая из цикла, в котором я постарался собрать свой опыт в проектировании и создании информационных систем. Статьи изначально предназначены для коллег, но я решил попробовать поделиться ими с вами.

В предыдущей статье мы начали обсуждать, что компании (всё еще) хотят разделить монолиты на микросервисы. Если спросить их, что они этим изменят — услышите, что с микросервисами рассчитывают решить проблему «большого комка грязи» или сократить time-to-market.

Далее мы обсудили, что изменения в монолитном приложении не решат вопрос «большого комка грязи», потому что реальные проблемы кроются в организации, процессах и людях, но не в технологии.  Во второй статье мы рассмотрим вопрос  time-to-market, а затем подведем итоги.

Представим себе такой сценарий.

Пользователь устно и/или в чате поручает ИИ-агенту найти и приобрести нужный товар с заданными параметрами.

ИИ-агент в разговоре уточняет у пользователя задание, составляет описание товара и на его основе формирует запрос к поисковой системе... а затем ищет товар в базах данных поставщиков.

Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Для работы с требованиями существует большое количество различных подходов и инструментов, которые позволяют аналитику работать с ними на различных этапах. Один из таких инструментов – матрица трассировки требований. Она помогает установить взаимосвязь между различными видами требований, их реализацией в системе и тестированием.

В этой статье я расскажу про назначение матрицы трассировки требований, ее ключевые элементы, алгоритм построения, а также рассмотрю использование в практическом примере

Продолжаем наращивать базу знаний по System Design. В этот раз освятим использование BLOB Storage, CDN, Message Broker. Посмотрим на основные концепции и области применения этих важных компонентов при проектирование высокодоступных отказоустойчивых систем.

Аналитический центр red_mad_robot перевёл исследование McKinsey о применении GenAI для банковского сектора. Помимо нового уровня автоматизации, AI поможет сделать банки более интеллектуальными, эффективными и финансово устойчивыми. Собрали для вас основные принципы построения AI-First банка, в конце вас ждёт пара полезных артефактов — ставьте лайки, если материал пригодится.

Мы планируем оперировать системами в ИТ-ландшафтах , тут возникает желание расчертить площадку, по которой будем «двигать» наши системы – фигуры или другими словами задать систему координат. Причем важно заметить, что система координат для организаций одного типа ожидаемо должны быть подобны.

Очевидно нам нужно выделить слабосвязанные области, унифицированные по возможности для разных типов организаций – эти области и станут те ми клеточками, по которым мы и будет расставлять фигуры – gрупповые информационные системы.

Важная мысль, которая была поднята в «Кодексе архитектора» - для того чтобы добиться успеха нужно, чтобы все отработали как надо, один не доработает – и успех уже не так гарантирован. Это очевидная штука, но как с более тонкими моментами? В связке «архитектор» - «владелец продукта» не то чтобы не «косячить», как тянуть в одну сторону?

Архитектор работает с владельцем через требования, т.е. от иногда надевает «шапку владельца продукта», чтобы понимать, что делает и как это будет использоваться в будущем. Я хочу предложить владельцу продукта «шапку» архитектора.

В предыдущей части мы сформулировали постановку задачи тиражирования решений и систем в федеративной структуре. Мы рассмотрели ключевой конфликт интересов между централизацией и локализацией – который является, на мой взгляд, имманентным свойством всех таких структур. В этих условиях нужно обеспечить балансировку этих интересов, с целью повышения эффективности Gруппы в целом с помощью системы принятия решений, обеспечивающий эту самую балансировку. Система принятия решений видится подобной системе «дестрастных» дифференциальных уравнений с начальными и граничными условиями.

В этой части мы рассмотрим элементы этой системы принятия решений, которые детализируем в следующих частях и в конце цикла, соберем всю систему из готовых компонентов.

Снова и снова клиенты просят меня и моих коллег разделить свой монолит на микросервисы и спрашивают, как это лучше всего сделать. Они уверены, что разделение монолита на микросервисы решит серьезные проблемы, с которыми они сталкивались долгое время.

Часто они не хотят обсуждать, поможет ли это решить проблему, которую, по их мнению, микросервис устранит. Они просто хотят получить советы по техническому проектированию и реализации.

Я нахожу этот подход озадачивающим — по моему опыту, микросервисы редко решают проблемы, которые, по мнению большинства, они должны разрешить. Особенно, если внедрять их без других изменений. Я написал серию постов, в которых обсуждаю распространенные заблуждения о микросервисах. В этой серии разберем, какие проблемы не решают микросервисы, а какие — могут решить (если всё сделать правильно). А также, что мы можем сделать, если микросервисы — это не то, что нам нужно.