В этой части цикла мы поговорим о центральном элементе GraphQL — схеме. Именно она является точкой соприкосновения клиента и сервера. И если нет схемы — то нет и API.

В этой статье мы рассмотрим, что такое GraphQL и для чего он был создан. Разберёмся, какие задачи сложно решить в REST API, и какую альтернативу предлагает GraphQL.

Системные и бизнес‑аналитики ежедневно пишут десятки требований, юскейсов и спецификаций. На каждый документ уходит 2–3 часа: собрать факты, договориться об уровне детализации, причесать стиль. Акроним КОМПОЗИТОР превращает ChatGPT, GigaChat, Deepseek и другие чат-боты на основе больших языковых моделей из капризного собеседника в штатного аналитика: он раскладывает промт на 10 чётких блоков, которые добавляются итерациями, или «слоями», и автоматически устраняют типичные ошибки — размытые формулировки, «галлюцинации» и несогласованность.

Создание больших сложных информационных систем (ИС) — это долгий, дорогой и часто непростой процесс. Иногда бывает так, что потрачено очень много денег, сил и времени, а система всё равно делает не то, что нужно. В этой статье расскажем, как аналитик может помочь избежать этого, а также... 

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

Data Vault 2.0 остаётся одним из самых популярных методов моделирования данных. Его выбирают за гибкость, масштабируемость и устойчивость к изменениям. Этот разработанный Дэном Линстедом подход помогает организациям быстро адаптироваться к новым бизнес-требованиям, легко интегрировать новые источники данных и надёжно хранить исторические данные.

Эта статья будет полезна дата-инженерам, аналитикам данных, архитекторам данных и бизнес-аналитикам. Она поможет усовершенствовать умения в моделировании данных. Мы рассмотрим ключевые принципы Data Vault 2.0 и на практическом примере покажем, как разложить сырые данные по Data Vault 2.0.

Эта статья ー вторая часть материала об интеграции информационных систем (ИС) и самых распространённых стилях и технологиях интеграции. 

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

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

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

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

В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных.

1. Указывайте количественно и качественно выраженные достижения

Это самый главный и мощный пункт.

Большинство людей пишут какие-то беспомощные аморфные функции и фразы про обязанности и участие — «состоял, привлекался, принимал участие». Это выглядит, как свидетель из Фрязино, а не мощный проектный специалист, который будет двигать проект вперёд.

Нанимающий руководитель смотрит прежде всего на результаты, а не на процесс. Если вы пишете только про поток, это в глазах читающего создаёт риски того, что вы цените процесс, а не результаты. (Процесс тоже важен, но про него отдельно).

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

Как обычно пишут:

Функции и задачи:

* разрабатывал требования, общался с клиентами, командой, отвечал на вопросы, рисовал схемы…

Как надо: ...

Анна Вичугова, CBAP, написала стартовое пособие по тому, как начать моделировать бизнес-процессы в BPMN

1. Назначение BPMN.

2. Уровни моделирования.

3. Алфавит нотации: События, Логические операторы, Артефакты.

4. Правила построения диаграмм.

5. Пример построения диаграммы по тексту.

6. Рекомендуемые инструменты.

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

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

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

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

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

Мы решили узнать, как работает старый тезис «в интернете всё есть и бесплатно, курите маны, глупцы».

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

Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.

Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.