ruen
Проектируем
Архитектура информационных систем и IT-решений
Архитектура определяет, из каких частей состоит система, как они взаимодействуют и как система будет жить дальше: выдерживать рост нагрузки, подключать новые сервисы, развиваться без переделки основы. Мы проектируем архитектуру под задачу и ограничения заказчика: текущий IT-ландшафт, требования безопасности, бюджет, планы развития.
Проблемы с архитектурой не видны, пока система небольшая. Они начинаются, когда под каждую новую функцию приходится переделывать основу, а рост пользователей превращается в аварии.
Какие проблемы решаем
Систему начали разрабатывать без проектных решений. Каждая новая функция усложняет систему, доработки занимают все больше времени и денег.
01
Нагрузка растет, система не справляется. Пиковые часы и сезонные всплески оборачиваются сбоями и жалобами пользователей.
02
Системы компании не связаны между собой. Обмен данными держится на ручных операциях и временных решениях.
03
Технические решения каждый разработчик принимает сам. В системе накапливаются несовместимые подходы, сопровождать ее может только автор.
04
Требования безопасности и перехода на российское ПО не учтены на старте. Проект не проходит согласование или требует переделки в конце.
05
МАСШТАБИРОВАНИЕ СИСТЕМЫ • ОТКАЗОУСТОЙЧИВОСТЬ • ВЫБОР ТЕХНОЛОГИЙ • РАЗМЕЩЕНИЕ В КОНТУРЕ • УЧЕТ ТРЕБОВАНИЙ ИБ • АРХИТЕКТУРА ДАННЫХМАСШТАБИРОВАНИЕ СИСТЕМЫ • ОТКАЗОУСТОЙЧИВОСТЬ • ВЫБОР ТЕХНОЛОГИЙ • РАЗМЕЩЕНИЕ В КОНТУРЕ • УЧЕТ ТРЕБОВАНИЙ ИБ • АРХИТЕКТУРА ДАННЫХМАСШТАБИРОВАНИЕ СИСТЕМЫ • ОТКАЗОУСТОЙЧИВОСТЬ • ВЫБОР ТЕХНОЛОГИЙ • РАЗМЕЩЕНИЕ В КОНТУРЕ • УЧЕТ ТРЕБОВАНИЙ ИБ • АРХИТЕКТУРА ДАННЫХ
МАСШТАБИРОВАНИЕ СИСТЕМЫ • ОТКАЗОУСТОЙЧИВОСТЬ • ВЫБОР ТЕХНОЛОГИЙ • РАЗМЕЩЕНИЕ В КОНТУРЕ • УЧЕТ ТРЕБОВАНИЙ ИБ • АРХИТЕКТУРА ДАННЫХМАСШТАБИРОВАНИЕ СИСТЕМЫ • ОТКАЗОУСТОЙЧИВОСТЬ • ВЫБОР ТЕХНОЛОГИЙ • РАЗМЕЩЕНИЕ В КОНТУРЕ • УЧЕТ ТРЕБОВАНИЙ ИБ • АРХИТЕКТУРА ДАННЫХМАСШТАБИРОВАНИЕ СИСТЕМЫ • ОТКАЗОУСТОЙЧИВОСТЬ • ВЫБОР ТЕХНОЛОГИЙ • РАЗМЕЩЕНИЕ В КОНТУРЕ • УЧЕТ ТРЕБОВАНИЙ ИБ • АРХИТЕКТУРА ДАННЫХ
Что изменится
01
Появится задокументированная архитектура: состав частей, их взаимодействие, данные, точки интеграции.
02
Закладываем архитектуру, которая позволяет развивать систему без дорогостоящей переработки ее основы.
03
Решения по нагрузке, безопасности и размещению приняты заранее, а не в момент аварии.
04
Новые разработчики входят в проект по схемам и описаниям, а не по устным рассказам коллег.
Среди задач, с которыми к нам обращаются:
Примеры сценариев
01проектирование новой корпоративной системы;
проектирование новой корпоративной системы;
02переработка системы, которая перестала справляться с ростом;
переработка системы, которая перестала справляться с ростом;
03планирование интеграций между системами компании;
планирование интеграций между системами компании;
04требования к размещению в контуре заказчика или переходу на российское ПО;
требования к размещению в контуре заказчика или переходу на российское ПО;
05подготовка системы к передаче на сопровождение другой команде.
подготовка системы к передаче на сопровождение другой команде.
Как реализуем
Собираем ограничения. Нагрузка, требования безопасности, текущий IT-ландшафт, требования к размещению, бюджет, планы развития на несколько лет.
01
Проектируем решение. Состав сервисов и модулей, схемы данных, интеграции, механизмы надежности и масштабирования.
02
Проверяем решения на критичных ситуациях. Пиковая нагрузка, отказ части системы, рост объемов данных: показываем, как архитектура ведет себя в каждом случае.
03
Фиксируем в документах. Схемы, описания компонентов, принятые решения с обоснованием выбора, требования к инфраструктуре.
04
Сопровождаем реализацию. Отвечаем на вопросы команды разработки, следим, чтобы реализация соответствовала принятым решениям.
05
Риски и как мы ими управляем
01
Архитектура окажется избыточной для задачи. Проектируем под реальные требования, а не с запасом на все случаи: каждый элемент решает конкретную задачу заказчика.
02
Реализация разойдется с проектом. Участвуем в разработке: консультируем команду, разбираем отклонения, решения обновляем осознанно, а не в процессе написания кода.
03
Требования изменятся в процессе. Заранее определяем точки вероятных изменений и закладываем там возможность расширения, остальное фиксируем как есть.
С чего начать
Архитектуру проектируют после аналитики или параллельно с ней: требования определяют, что система делает, архитектура как она устроена. Если требований еще нет, начинаем с аналитики, архитектурные решения принимаем следом.
Что получает заказчик
Архитектурный документ: схемы, состав компонентов, интеграции, данные.
01
Обоснования принятых решений и рассмотренные альтернативы.
02
Требования к инфраструктуре и размещению системы.
03
Поддержку команды разработки на этапе реализации.
04
Обсудить задачу
опишите систему и ограничения, предложим формат работ по архитектуре.NOOSOFT