Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:
Про OPC UA слышали мы все, кто хоть раз работал со SCADA системами, АСУ ТП или просто в студенческие годы пытался состыковать оборудование и программы верхнего уровня.
Обещают независимый, безопасный, масштабируемый, al inclusive стандарт для промышленного Интернета вещей. Но как это работает в реальных условиях? Что происходит, когда ты ставишь OPC UA-сервер не в демо-лаборатории, а в реальных условиях на производстве, где есть полный набор динозавров из 90х, 00х и современные монстры. И мы хотим, чтобы работало, не тормозило и все вместе.
В этой статье я попробую рассказать, как мы внедряли OPC UA в нескольких проектах, на практике, в реальных условиях со всеми плюсами и минусами.
Paradox: что если заменить финансовые рынки математической моделью? В статье я смоделирую экономику блокчейн-протокола, где цена токена вычисляется по формуле, и покажу, как разные стратегии поведения влияют на доходность участников. Полный разбор механики и результатов.
Привет! Сегодня расскажу про Discovery-процесс в команде.
Discovery и Delivery процессы разделены. В Discovery-команду могут входить продакт-лид, продакт-менеджеры, продакт-аналитики, бизнес-аналитики и UX-дизайнеры/проектировщики. Если же задачи технические, то подключаются тех/тим-лиды, архитекторы и другие технические специалисты.
Что такое Disco? Discovery в первую очередь отвечает на вопросы и «Что делать?» и «Надо ли вообще делать?». Delivery - «Как делать?».
Discovery-команда занимается обоснованием и проработкой инициатив, которые затем попадают в продуктовый бэклог для последующей реализации в Delivery.
Для запуска с нуля такой команды и их процессов мы используем следующий чек-лист:
LangChain или LangGraph? Какой фреймворк для ии-агентов выбрать? А может быть LangSmith? Или LangFuse? LangFlow? Если вы сходу не отличаете все эти Lang-что-то там между собой или просто хочется побольше узнать о внутренностях LangChain и LangGraph, то добро пожаловать в эту статью, которую мне хотелось сделать фундаментальной, чтобы ответить сразу на все возникающие вокруг LangChain вопросы.
Поговорим про архитектурные различия между LangChain и LangGraph, их подходы, посмотрим как это выглядит в коде, поищем лучшие точки применения и взглянем на сформированную экосистему вокруг.
ИИ научился проектировать радиочастотные и миллиметровые чипы, создавая решения, которые инженеры не в состоянии объяснить. От генетических алгоритмов 90-х до глубокого обучения и инверсного дизайна - небольшой обзор как искусственный интеллект превратился из исследовательского инструмента в соавтора аппаратной эволюции.
Привет всем, меня зовут Черныш Татьяна, я – веб-дизайнер в компании «Северсталь» и это рубрика «Опять что-то на дизайнерском».
Сегодня мы поговорим о том, как система макетов в Figma сэкономила на нашем проекте неплохой объём времени во время редизайна и разработки. Каждая команда, чаще всего, ведёт проект по-своему, и нет единой и универсальной методики. В этой статье я хотела бы поделиться с вами своим опытом организации дизайн-макетов.
Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным.
Всем нам хочется делать больше и тратить на это меньше времени. Браться за новые задачи смелее и выполнять их эффективнее. В этом нам и помогают паттерны: они дают рабочую схему для типовых кейсов, чтобы не выдумывать решение каждый раз с чистого листа.
Продолжаем рассматривать вопросы, связанные с проработкой архитектурных решений в области цифровизации предприятий.
Сталкивались ли Вы с ситуацией, когда ИТ проект, в котором задействована сильная команда разработчиков, в конечном счете выпускает программный продукт, не удовлетворяющий потребностям бизнеса? Когда полученный вариант попросту никак не облегчает жизнь компании, не избавляет от ее болей и печалей, не переводит ее процессы на качественно новый уровень.
Чаще всего такой итог означает, что затеявшие цифровую трансформацию специалисты, не справились со своей основной задачей и просчитались, скорее всего, еще на этапе анализа. А причина тому - отсутствие экспертизы в области архитектуры бизнеса. И аргумент: «как нам заказчик объяснил, так мы и сделали», служит слабым оправданием.
Команда профи, должна была, обследовав предприятие, указать на нелогичность цепочек бизнес-процессов, нерелевантность используемых бизнес-сервисов, избыточность организационной структуры, искажения потоков ценностей и прочие упущения, присущие первоначально сложившейся архитектуре.
Квалифицированный специалист в области организации бизнеса должен гарантировать качественный инжиниринг и реинжиниринг деятельности предприятия, используя при этом профессиональные подходы, инструменты и приемы. Результат этих активностей и должен заложить основу для последующей эффективной цифровизации деятельности заказчика.
В данном аспекте важно учитывать, что на больших предприятиях цифровизацией будут заниматься множество команд, использующих разные технологические платформы, методологии, и накопленный ранее приватный опыт автоматизации. Их технические новации в свою очередь будут влиять на выстраивание бизнес-решений, определяя то, как бизнес будет меняться и развиваться. А потому, если централизовано не управлять слоем бизнес-архитектуры, то разнообразные ИТ-технологии могут привести к культивированию зоопарка управленческих, финансовых, предпринимательских и прочих бизнес-решений в общей структуре предприятия, вызывая противоречия, неконструктивную конкуренцию, затруднение в управлении и прочие кризисные предпосылки.
Привет, Хабр! Меня зовут Алексей Грохотов, я разрабатываю продукт Сфера.Архитектура в ИТ‑холдинге Т1. Перед нашей командой стояла задача перенести документы из Orbus iServer в Сфера.Архитектуру. Iserver — это набор инструментов для описания, поддержки и трансформации архитектуры предприятия. Он в значительной степени интегрирован с Microsoft Office, например, все схемы в этом инструментарии создаются в Visio.
Я должен был проанализировать схемы Visio и извлечь необходимую информацию из этих документов. Объекты, соответствующие «прямоугольничкам и стрелочкам» Visio, уже хранились у нас в базе. Мне нужно было соотнести их с фигурами и стрелками схемы, записать для этих объектов геометрическое и текстовое содержание фигур, а также некоторые их специфические свойства. Ещё нужно было определить порты — «стыковочные места» по периметрам фигур, к которым присоединяются стрелки, а также найти надписи у стрелок и фигур. И после этого сохранить в базу данных всю найденную информацию.
Давайте честно: большинство советов про «ИИ для бизнеса» либо слишком общие, либо слишком технические, чтобы быть полезными. Пока мы готовили курс «AI for Process», я поговорил с десятками участников BPMInstitute.org — аналитиками, архитекторами и руководителями процессов, — которые уже экспериментировали с генеративным ИИ. Кто-то только начинал, кто-то копал глубоко, но все пытались сделать ИИ полезным в повседневной процессной работе.
Эти 10 техник стали лучшими. Если вы только начинаете, используйте этот список как трамплин. Каждая из них — это реальные уроки, реальная польза и понятный путь к тому, чтобы уже завтра работать умнее.
Теория — это прекрасно, но мое "расследование" не могло закончиться на простом понимании проблемы, ведь конечная цель любого инженера — построить работающую и надежную систему. К счастью, проверенные решения существуют.
Эти решения можно разделить на две большие группы: реактивные и превентивные.
Кажется, что РЖД — это такой «вечный двигатель», вне кризиса и перемен.
Годы шли, и железная дорога жила «по контракту»: вози, обновляй, оптимизируй, мониторь, не ломай то, что работает. Но последние пару лет даже у этого монолита начались сбои: индустрия в кризисе, инфраструктура в дудосе от избытка вагонов, ключевые узлы перегружены. Выясняется, что даже у вечной системы есть точки отказа, и иногда их становится опасно много.
Попробуем разобраться, как одна из крупнейших корпораций в стране докатилась до сегодняшней турбулентности. Постараемся максимально избежать скучной статистики (один график я все-таки вставил, не удержался, но только один) и применим системный подход, чтобы понять, как ошибочные решения менеджмента, принятые почти два десятилетия назад, могут подрубить ноги колоссу сегодня и почему важно понимать архитектуру отраслевых гигантов не только сквозь призму их побед и отчётов, но и через цепочку допущенных ошибок, удачных (или неудачных) экспериментов и долгосрочных последствий управленческих ходов.
Это первая из запланированных статей по внедрению практики использования языка Archimate для различных ИТ-ролей. Конкретно этот материл будет полезен прежде всего бизнес-аналитикам для повышения уровня компетенций и дополнения используемых инструментов моделирования бизнес-процессов (подробней про апгрейд роли было здесь).
Многоагентная архитектура открывает несколько мощных паттернов. Здесь я начну с основ и опишу, как с помощью Temporal сделать создание многоагентных систем простым, надёжным и увлекательным.
Предыдущая статья: Часть 3: А при чём здесь The Thundering Herd Problem?
Thundering Herd — это о бесполезной трате CPU на пробуждение “лишних” процессов, которые не смогут выполнить работу.
Dogpile Effect — это о бесполезной нагрузке на внешний ресурс (например, БД) из-за многократного выполнения одной и той же работы.
В уже далеком 2000 году посчастливилось мне побывать на всероссийском слете экологов в Пушкиногорье. Много интересного там приключилось, но остановлюсь на одном воспоминании.
Во время маршрутного учета птиц нашли мы в озере пластинку загадочного красного цвета с записями сказок А.С. Пушкина. Группа лиц по предварительному сговору нашла на турбазе швейную иголку, лист бумаги и карандаш. После чего полчаса все, кроме одного, наслаждались завораживающими сюжетами в исполнении приятного бархатного голоса. Тот один с помощью естественного интеллекта крутил пластинку на карандаше с нужной скоростью и аккуратно прижимая иглу, воткнутую в рупор из бумаги, к дорожкам. Видеозаписей того момента история не сохранила, но люди достаточно регулярно воспроизводят сию технологию.(https://www.youtube.com/watch?v=A81V-F4q7iQ)
Так и родилась убежденность в преимуществе физических носителей перед цифровыми в части сохранности и удобства воспроизведения. Отложилось это крепко, и сейчас понравившиеся книги покупаю, читаю и ставлю на полку, а хорошую, запавшую в душу музыку ищу в записи на пластинке.
А по поводу долговечности приведу пример пластинок, которым около ста лет и больше (Рис. 1). До сей поры можно легко воспроизвести то, что создал человеческий гений 5 поколений назад.
Всем привет. Недавно пришлось решать проблему идентификации пользователя по номеру телефона в маленьком стартапе, позволяющим оформлять и оплачивать заказы онлайн. Почему именно номер телефона, а не электронная почта, например, или авторизация через соц. сети? Телефон сейчас, как мне кажется, де-факто стандарт для таких кейсов - это во-первых, а во-вторых, используя телефонный номер, можно подключать разные варианты его подтверждения: от смс до звонков с дальнейшим вводом либо кода из смс, либо последних цифр звонившего номера. Думаю, тут всем знакомы подобные механики.
Изначально я сразу и предложил использовать механику с СМС-шлюзом, но так как я тут имею дело со стартапом без инвестиций, то меня попросили придумать как на первоначальном этапе можно сэкономить (в идеале обойтись на этом этапе совсем без затрат), так как основной целью запуска было тестирование бизнес-идеи.
По предварительным исследованиям целевая пользовательская аудитория продукта является пользователями мессенджера Telegram. Вот в эту сторону я и начал думать. “Коробочный” механизм авторизации через виджет Telegram не отдает номер телефона пользователя, а нам именно он и нужен. Городить велосипед по получению номера телефона по id пользователя идея не самая лучшая, поэтому я решил сделать своего ТГ-бота для механики авторизации. Я на паре сайтов уже видел подобные решения, быстрый поиск по примерам реализации этой механики не дал внятных результатов. При поиске “авторизация telegram” я наткнулся на сайт, который был первым в поисковой выдаче. Пошел смотреть как у них все устроено, рассмотрим по шагам:
Поводом написания этой статьи послужил подслушанный диалог:
— А на чем у вас агенты написаны?
— У нас на MCP!
Для меня MCP всегда был просто протоколом, то есть именно способом отправки и обработки запросов. А когда я слушал выступления или читал некоторые статьи о том, как плох/хорош MCP, меня не покидало ощущение чего-то странного. Но все же решил, что это от незнания, и я чего-то не понимаю. А когда не понимаешь, но очень хочешь понимать, то самый лучший способ — это взять и разобраться.
Именно это предлагаю и сделать в статье, а также замерить MCP, чтобы ответить на вечный вопрос: сколько сжирает MCP, подключать ли его вообще или и так сойдет?
Меня зовут Анастасия Сабирова и я работаю аналитиком в MONS (входит в ГК «КОРУС Консалтинг»). В прошлой статье мы поговорили о сборе требований и даже составили список рекомендаций, которые должны сделать этот процесс наиболее эффективным. Сегодня же мы попробуем разобраться с приоритизацией требований и разберём алгоритм, который может помочь начинающим аналитикам в расстановке приоритетов.
