Разработка ПО

Мы исходим из того, что ваша команда может эксплуатировать и под что может нанимать, что используют ваши другие системы и что должно делать ПО. Для большинства бизнес-систем это распространённый язык, такой как TypeScript, Java, C# или Python, реляционная база данных и облако, которое вы уже используете. Мы фиксируем каждый выбор и его причины.

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

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

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

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

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

Для большинства новых приложений мы используем React с Next.js, потому что он поддерживает серверный рендеринг и имеет сильные инструменты. Мы также работаем с Angular и Vue.js и продолжаем в фреймворке, который вы уже используете, когда это разумный выбор.

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

Выбирайте настольное приложение, когда работе нужна работа без сети, прямой доступ к устройствам или локальным файлам, тяжёлые данные или графика либо быстрые экраны с управлением с клавиатуры. Для большинства других задач веб-приложение проще развёртывать и обновлять. Мы рекомендуем индивидуально, и иногда правильный ответ — веб-приложение с небольшим настольным компонентом.

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

Нативные приложения дают лучшую производительность и наиболее точное соответствие каждой операционной системе. Кроссплатформенные приложения используют одну кодовую базу для Windows, macOS и Linux, что снижает стоимость создания и изменения. Мы рекомендуем нативное, когда доминирует одна платформа или работа требовательна, и кроссплатформенное, когда важны несколько платформ.

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

Да, для задач, которые это позволяют. Мы решаем с вами, какие данные нужны каждому пользователю на устройстве, храним их в зашифрованном виде и записываем изменения до возвращения сети. Когда одна и та же запись меняется в двух местах, согласованные правила решают, какое изменение победит, или просят человека выбрать.

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

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

Подробнее: Разработка приложений, платформ и композитных продуктовСсылка на этот вопрос

Нативные приложения на Swift и Kotlin дают самый полный доступ к функциям устройства. Кроссплатформенные приложения на React Native или Flutter делят большую часть кода между iOS и Android, что снижает стоимость создания и изменений. Мы рекомендуем нативные, когда приложение сильно зависит от устройства, и кроссплатформенные для большинства деловых и потребительских приложений.

Подробнее: Мобильные приложения, пространственные вычисления и цифровые двойникиСсылка на этот вопрос

Цифровой двойник — живая 3D-модель физического места или процесса, питаемая данными с его датчиков и систем. Его стоит создавать, когда решения об этом месте дорого проверять в реальности. Примеры: изменение производственной линии, планирование порта, управление районом умного города или обучение персонала редким событиям.

Подробнее: Мобильные приложения, пространственные вычисления и цифровые двойникиСсылка на этот вопрос

К тем, что описывают реальную площадку: промышленные IoT- и сенсорные платформы, системы зданий и завода, ERP и системы обслуживания активов. Мы согласуем источники данных и частоту их обновления, чтобы двойник показывал площадку как она есть.

Подробнее: Мобильные приложения, пространственные вычисления и цифровые двойникиСсылка на этот вопрос

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

Подробнее: Мобильные приложения, пространственные вычисления и цифровые двойникиСсылка на этот вопрос

Мы проектируем по WCAG 2.2 AA с первого макета: достаточный контраст, видимый фокус, логичный порядок чтения, достаточно крупные цели и метка для каждого элемента управления. Автоматические проверки выполняются при каждом изменении. Перед каждым релизом мы вручную проверяем ключевые путешествия с клавиатурой и экранными дикторами.

Подробнее: UX и автономная инженерия качестваСсылка на этот вопрос

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

Подробнее: UX и автономная инженерия качестваСсылка на этот вопрос

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

Подробнее: UX и автономная инженерия качестваСсылка на этот вопрос

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

Подробнее: Модернизация унаследованных систем с ускорением на ИИСсылка на этот вопрос

Да. Мы переводим или перестраиваем программы COBOL как облачные сервисы и переносим данные DB2 со сверкой на каждом шаге. Пакетные задания и файловые интерфейсы получают современные эквиваленты. Стабильные и дорогие для переноса части могут оставаться за слоем API до своей очереди.

Подробнее: Модернизация унаследованных систем с ускорением на ИИСсылка на этот вопрос

Когда старое ядро стабильно и корректно, но труднодоступно. Современные API перед ним позволяют новым каналам, партнёрам и продуктам использовать его функции, не трогая внутренности. Замену мы рекомендуем, когда система блокирует изменения, не поддаётся защите или не может быть укомплектована людьми.

Подробнее: Модернизация унаследованных систем с ускорением на ИИСсылка на этот вопрос

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

Подробнее: Облачная инженерия, SovereignTech и гибридная миграцияСсылка на этот вопрос

Обычно того, которым вы уже пользуетесь, если нет чёткой причины менять. Решающие факторы — размещение данных, существующие договоры и навыки, нужные управляемые сервисы и то, как подключаются другие ваши системы. Мы работаем с AWS, Microsoft Azure, Google Cloud, Alibaba Cloud и региональными государственными облаками и держим код, специфичный для провайдера, только там, где это оправдано.

Подробнее: Облачная инженерия, SovereignTech и гибридная миграцияСсылка на этот вопрос

Инфраструктура описывается в открытых инструментах, таких как Terraform, OpenTofu или Pulumi, а нагрузки работают на Kubernetes или других переносимых платформах. Там, где собственный сервис провайдера — лучший выбор, мы используем его осознанно и фиксируем путь выхода. В итоге у вас есть письменная оценка того, сколько потребует перенос каждой нагрузки.

Подробнее: Облачная инженерия, SovereignTech и гибридная миграцияСсылка на этот вопрос

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

Подробнее: Облачная инженерия, SovereignTech и гибридная миграцияСсылка на этот вопрос

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

Подробнее: Облачная инженерия, SovereignTech и гибридная миграцияСсылка на этот вопрос

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

Подробнее: Облачная инженерия, SovereignTech и гибридная миграцияСсылка на этот вопрос

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

Подробнее: DevOps, платформенная инженерия и обвязки для ИИ-агентов разработкиСсылка на этот вопрос

Обычно те, что у вас уже есть. Мы работаем с Terraform, OpenTofu и Pulumi для инфраструктуры, Kubernetes для контейнеров и распространёнными сервисами CI/CD, включая GitLab CI/CD, GitHub Actions и Argo CD. Мы рекомендуем замену только когда инструмент блокирует нужное вам.

Подробнее: DevOps, платформенная инженерия и обвязки для ИИ-агентов разработкиСсылка на этот вопрос

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

Подробнее: SRE, наблюдаемость и FinOps для облака и ИИ-токеновСсылка на этот вопрос

GreenOps применяет подход FinOps к энергии и углероду. Нагрузки рассчитываются под фактическое потребление, выполняются там и тогда, где и когда электричество чище, если могут подождать, и отчитываются в терминах, нужных вашей отчётности ESG.

Подробнее: SRE, наблюдаемость и FinOps для облака и ИИ-токеновСсылка на этот вопрос

Поддержка зависит от модели и версии прошивки. Мы проверяем каждый HSM в аудите CBOM и планируем обновления или замену только там, где они нужны.

Подробнее: Постквантовая криптография и квантово-стойкое шифрованиеСсылка на этот вопрос

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

Подробнее: Постквантовая криптография и квантово-стойкое шифрованиеСсылка на этот вопрос

AWS, Microsoft Azure, Google Cloud, Alibaba Cloud и региональные государственные облака, а также ваши собственные центры обработки данных и частные GPU-кластеры. Инфраструктура определяется в Terraform, OpenTofu или Pulumi, а нагрузки работают на Kubernetes, поэтому выбор провайдера остаётся открытым.

Подробнее: Облако и инфраструктураСсылка на этот вопрос

Да. Мы оцениваем, какие сервисы привязывают вас к провайдеру, проектируем целевой ландшафт в суверенном облаке, у другого провайдера или в вашем центре обработки данных и переносим нагрузки поэтапно с путём отката для каждого. Вы решаете, как далеко идти: одни клиенты переносят всё, другие — только нагрузки, важные для их регуляторов.

Подробнее: Облако и инфраструктураСсылка на этот вопрос