Непростая задача: выбор целевой архитектуры решений 1С
Руководитель практики ИТ и сервисов ALP Group Валерий Лямо рассказывает, как подобрать оптимальные программные продукты в проектах комплексной автомати��ации на базе 1С.
Что такое архитектура в ИТ?
В моем понимании, ИТ-архитектура вообще — это описание структуры некой модели, состоящей из элементов и взаимосвязей между ними. В свою очередь, архитектура информационных систем предприятия — это совокупность программных продуктов (программного обеспечения), интерфейсов взаимодействия между ними, а также совокупность программно-аппаратных средств, методик и стандартов, обеспечивающих эффективное функционирование приложений как единого целого.
В проектах комплексной автоматизации, когда автоматизируется сразу большое количество разных бизнес-процессов в компании, проектирование архитектуры — ответственный этап, от которого может зависеть успех или провал всего проекта. Вариантов продуктов и их сочетаний — множество, и задача опытного ИТ-архитектора — собрать идеальную устойчивую и гармоничную структуру, которая пройдет испытание временем и не создаст бизнесу проблем в будущем.
Приведу один пример. Представим, что нам нужно автоматизировать бухгалтерию в промышленной компании. Кажется, есть смысл не «плодить сущности» и вести все расчеты прямо в ERP-системе, где ведется учет производства. Но что, если речь идет о полноценном холдинге, где разные дочерние компании занимаются разными направлениями деятельности? Тогда мы можем выделить одну большую бухгалтерскую базу и вести расчеты в специально предназначенной для этого кастомной системе. Но удобно ли смешивать всю бухгалтерию по группе компаний? И что делать, если топ-менеджеры хотят видеть максимально детализированный бухучет по всем бизнес-процессам? Стоит ли впадать в крайность и использовать для каждой функции отдельные автоматизированные решения?
Оказывается, задача выбора целевой архитектуры уже не так проста!
Как к этому процессу подходят в ALP Group, я расскажу ниже.
Пять шагов на пути к оптимальной архитектуре
1. Собираем вводные данные.
Чтобы правильно определить целевую архитектуру, для начала необходимо выяснить:
- как выглядит текущая архитектура;
- какие недостатки и проблемы вызвали необходимость внедрения/модернизации/реинжиниринга ИТ-ландшафта;
- как устроены текущие бизнес-процессы в компании;
- как выглядит общая бизнес-стратегия заказчика;
- какие требования и ожидания есть у всех ключевых подразделений заказчика, включая спецификации по информационной безопасности.
2. Анализируем данные и отвечаем на вопросы.
После получения информации из первого шага нам необходимо понять:
- Является ли внедряемое решение новым этапом развития автоматизации или речь идет о замене легаси-решения?
- Если это замена, то вся ли текущая архитектура требует замены/перевнедрения или только какая-то ее часть?
- Если речь о новом витке автоматизации, то как внедряемое решение или комплекс решений впишется в общую ИТ-архитектуру заказчика?
- Что произойдет с текущими интеграционными потоками?
- Есть ли необходимость в перестроении каких-либо бизнес-процессов или бизнес-логики?
3. Подбираем решения.
Далее пытаемся подобрать программный продукт или комплекс программных продуктов, максимально удовлетворяющий требованиям и ожиданиям заказчика. При этом нужно понимать, что не всегда функциональность какого-то блока единой системы может полноценно «покрывать» предъявляемые требования и что зачастую есть специализированные программные продукты с более богатой функциональностью, которая в большей степени подойдет заказчику.
Параллельно с этим не забываем про показатели доступности, отказоустойчивости, катастрофоустойчивости и быстродействия как системы в целом, так и отдельных ее подсистем, блоков и сервисов: не всегда единый программный продукт, разрабатываемый вендором как максимально универсальная настраиваемая система, может соответствовать предъявляемым требованиям по указанным параметрам.
4. Продумываем интеграции.
После выбора максимально подходящего продукта или комплекса программных продуктов определяемся с их местом в интеграционной схеме, корректными потоками данных и необходимыми интеграционными механизмами.
5. Тестируем выбранную архитектуру.
Собираем тестовый стенд прототипа системы на базе существующих продуктов от вендора с минимально возможной кастомизацией и настройками, которые приближают «коробочные» решения к требованиям, бизнес-процессам и методикам заказчика. Проводим демонстрацию функциональности на заранее подготовленных бизнес-кейсах. Если всех всё устраивает, то выполняем нагрузочное тестирование системы, а затем определяем функциональные разрывы для необходимых доработок. При таком подходе мы до начала ведения непосредственной разработки понимаем, будет ли выбранная архитектура соответствовать всем ожиданиям заказчика.
А как вы определяете идеальную целевую архитектуру решений? Пожалуйста, поделитесь своим опытом в комментариях ⬇