Всем привет!
Всем, кто когда-либо реализовывал ИТ-проекты, наверняка знаком термин HLD (High Level Design) и тот факт, что без него достаточно сложно спланировать любой комплексный проект. Более того, в проектах всегда очень хочется пропустить кажущуюся ненужной трату времени на сбор и описание требований и сразу приступить к обсуждению решения, тем более, когда оно кажется очевидным.
Как и в небезызвестной сказке «Каша из топора» - когда желание перекусить есть, а продуктов для этого нет, так и архитектора часто просят проработать архитектуру решения, не давая для этого никакой информации. Далее мы пройдемся по основным «ингредиентам», которые необходимы для «приготовления» архитектуры решения, которое помогало бы по-настоящему «утолить голод».
Итак, нужна архитектура решения (HLD) или она уже есть и надо убедиться в ее правильности.
Что такое HLD? В целом все просто:
… Кубики (Информационные системы) и Стрелочки (Потоки данных или Инфопотоки),
… и чтобы было понятно, что и где надо доработать,
… и чтобы было надежно и безопасно (помним про ИБ).
Таким образом, HLD отображает системы решения, потоки данных между системами и распределение функций по системам. Раскраской обязательно подсвечивается, что должно поменяться или появиться, чтобы показать разницу текущей архитектуры (AS IS) и архитектуры TO BE, реализуемой в проекте.
Для более подробного пояснения изменений архитектуры добавляется описание в табличной форме требований к изменению потоков данных и информационных систем (функциональных и нефункциональных требований).
Если сразу начать с HLD и доработок систем без предварительных шагов анализа требований, то нет никакой гарантии, что
кажущиеся очевидными доработки достаточны (для целей проекта),
учтены все возможные side-эффекты доработок (влияние на смежные процессы и услуги),
учтены все сценарии и шаги процессов, в том числе выполняемые вручную,
учтены альтернативные и нештатные ветки процессов,
корректно выбраны системы для доработок и не дублируется уже существующая функциональность,
определены нефункциональные требования к системам.
Для того чтобы архитектор мог разобраться, какие системы и потоки данных необходимо использовать, изменять или создавать в решении, прежде всего должны быть определены нужные Функции (или функциональность), чтобы их затем разложить по системам:
это могут быть существующие Функции систем, которые надо улучшить или изменить, или
новые Функции, которые нужно реализовать в одной из существующих или новой системе.
Ингредиент № 1 — Функции
Функция — это поведение системы в ответ на определенное событие — действие пользователя, запрос или уведомление другой системы. У Функции есть результат ее выполнения, который получает в ответ пользователь или другая система.
В целях упрощения можно принять синонимами Функций такие широко используемые термины как функциональность, фичи, сервисы систем.
Функции могут описываться, например, в формате Use Cases (пользовательских или системных сценариев использования). UC — это простое пошаговое описание ожидаемого выполнения Функции с точки зрения пользователя или системы‑инициатора запроса.
При описании в формате UC уделяется внимание как основной последовательности, так и альтернативным (или нештатным) веткам работы. UC могут группироваться в пакеты — логические блоки Use Cases, объединённых общей целью, общие UC могут включаться или расширять другие UC, формируя Диаграмму Use Cases. Диаграмма UC в значительной мере помогает прорабатывать необходимые Функции, требования к функциям и контуры будущих систем.
Но как можно определить все Функции, которые нужно реализовать (автоматизировать) в решении? Ведь Функций и систем может быть очень много. Как заказчику убедиться, что все Функции выявлены и разложены по системам, ничего не забыто и все необходимое учтено в требованиях к системам?
Чтобы ответить на эти вопросы, необходимо разобраться, из‑за чего возникает потребность в создании и изменении Функций.
Ингредиент № 2 — Процессы
Функции систем не появляются просто так и прямо следуют из более общего понятия — Процессов компании, шаги которых полностью или частично они автоматизируют.
Процесс — это последовательность ручных и автоматизированных шагов (или даже полностью автоматизированных), выполняемых участниками процесса для получения определенного результата.
Участниками Процесса могут быть сотрудники компании, клиент/абонент, партнер или системы, автоматизирующие шаги процесса. На любом шаге Процесса может происходить взаимодействие участника с системой с помощью GUI или другого интерфейса (API, FTP и др.).
И снова, для упрощения можно принять синонимами Процесса такие понятия как бизнес‑процесс, CJ, услуга, пользовательский сценарий и др. Отдельно стоит выделить Услуги и Продукты:
Помимо различных Процессов, описывающих работу Услуги, обычно с ней связано много дополнительных не совсем очевидных Процессов, таких как проверки возможности подключения, подключение, изменение параметров, тарификация, отключение, решения различных вопросов и проблем, связанных с работой Услуги и др., которые нужно принимать во внимание.
Продукт может представлять собой Товар (материальный или нематериальный), Услугу или различные их сочетания, предлагаемые компанией клиенту и представляющие для него определенную ценность. При создании или изменении Продукта важно оценивать влияние на все Процессы компании, которые могут быть затронуты этим изменением.
Итак, чтобы определить все необходимые для автоматизации Функции, необходимо
всесторонне разбираться в том, как устроен текущий Процесс в целом («end‑to‑end») — понимать всех его участников, шаги и существующие автоматизации,
хорошо представлять, что необходимо изменить/автоматизировать в текущем Процессе для достижения целей проекта.
Для этого обычно в любой удобной форме (BPMN, CJ, EPC, UC и др.) описывается сначала текущая схема Процесса (AS IS). Автоматизированные шаги процесса связываются с системами, с помощью которых эти шаги уже выполняются. А затем схема Процесса TO BE, на которой указываются изменяемые ветки и шаги, включая шаги, которые необходимо автоматизировать и Функции, необходимые для автоматизации.
Чтобы разобраться в том, на какие Процессы проект будет оказывать влияние, необходимо понять причины возникновения, цели и ожидаемые результаты реализации проекта (в форме метрик). Это поможет формированию необходимого и достаточного объема требований и также поможет архитектору сбалансированно подойти к проектированию решения.
Ингредиент № 3 — Метрики
Доступность информации о текущих и планируемых (целевых) значениях изменяемых метрик (показателей) помогает архитектору в части проработки и предложения заказчику наиболее реалистичного решения, учитывая имеющиеся ограничения.
В отдельных случаях может оказаться, что невыгодно оптимизировать Процесс с помощью автоматизации или изменений в ИТ‑системах. Более подходящим решением может стать внесение изменений в сам процесс или его шаги (делать по‑другому). А это возможно понять только имея полное представление о работе Процесса и целевых метриках изменения.
Существуют различные метрики/параметры проекта, которые могут оказывать влияние на реализуемость проекта и выбор архитектурного решения:
· Метрики, с помощью которых оценивается общая привлекательность проекта, целесообразность реализации и бюджет. Все эти метрики часто сводятся в скоринговой анкете, но основе которой рассчитывается скоринговый балл планируемого изменения:
Выручка
Общие затраты (бюджет)
Влияние на (e)NPS, АБПП
Законодательные требования и риски штрафов
· Метрики, связанные с эффективностью процессов. На основе этих метрик обычно оцениваются инициативы, направленные на улучшение и оптимизацию процессов. Понимание текущих и целевых значений метрик помогает архитектору в проектировании или выдаче наиболее оптимальных рекомендаций:
TTM процесса
Трудоемкость процесса
Целевой SLA
· Метрики, характеризующие охват/масштаб проекта. На их основе архитектор может прогнозировать производительность и ожидаемую нагрузку, т.н. нефункциональные требования к системе:
Количество пользователей
Количество запросов
Время отклика/реакции
Объемы и время хранения информации и др.
Метрики, ограничивающие сроки реализации, такие как, например, действующие соглашения с партнерами, регуляторные требования, ожидаемые действия конкурентов и др.
Завершая повествование, хочется отметить, что, помимо приведенных выше «ингредиентов», существует много других не менее полезных средств проектирования, но приведенные выше общеизвестны, просты и доступны для использования. Их последовательное применение помогает не только в проектировании архитектурных решений, но и позволяет минимизировать будущие переделки и «допиливания» систем.