Если самым популярным вопросом о работе архитекторов является «Кто такие архитекторы и чем они занимаются?», то второй по популярности причиной провала архитектурной практики после «Не сошлись в видении с руководством» является отсутствие нормального инструмента. Под этим инструментом подразумеваются Enterprise Architecture Tool, которых на рынке представлено огромное множество, примерно такое же, как и различных framework и методологий архитектуры.

Кстати говоря о framework»ах, если выбор такого стоит остро и кроме TOGAF ничего не попадается, рекомендую книгу «The Practice of Enterprise Architecture» Святослава Котусева, которую я упоминал в публикации на тему навыков архитекторов.

Я уже много лет пользуюсь различными инструментами и какое‑то время даже занимался продажей одного из таких инструментов (на мой взгляд очень удачного, за парой исключений) и в этой публикации решил поделиться ранее накопленным опытом.

Первое и золотое правило в выборе инструмента, и EA Tool в частности:

Fools with tools are still fools.

Без понимания своей работы, потребностей и её целей, никакие инструменты вам не помогут. А даже скорее навредят, так как покупка любого инструмента приведёт к дополнительным затратам, а значит и увеличит градус ожиданий от работы архитектора. И если вместо существенного (а по-другому как правило такие инструменты не продаются) увеличения ценности от деятельности архитектора, руководство получит плохо автоматизированную бюрократию, которая только замедлила процесс развития компании — последствия могут быть самые печальные.

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

Любой инструмент, который мы используем, будь то хранилище исходных кодов, сборщик мусора, конвейер сборки исходного кода и так далее, — это автоматизация рутины. За счёт которой мы можем освобождать время команды на более полезную работу.

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

Когда вам продают EA Tool, то, как правило, называют его инструментом управления архитектурой предприятия. Звучит круто, и наличие слова «управление» сразу привлекает внимание менеджмента, ключевой компетенцией которого является управление. Но инструмент сам по себе ничем не управляет, тем более предприятием, в котором архитекторы выполняют поддерживающую функцию, безусловно важную, но всё-таки деньги это не приносит. А основа любой коммерческой организации (для которых эти инструменты и предлагаются) — это зарабатывание денег. Более честно будет называть такие продукты архитектурным репозиторием. То есть местом хранения объектов и артефактов, которые архитекторы используют в работе.

1. Inventory

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

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

Потому при выборе EA Tool в первую очередь стоит задуматься о метамодели:

1. Какие объекты вы хотите учитывать?

2. Что вы хотите о них знать (состав атрибутов)?

3. Как они связаны с другими объектами?

4. Как часто требуется менять метамодель?

5. Какие способы наполнения репозитория вам доступы? (ручные и/или автоматические)

Вот небольшой перечень вопросов, которые стоит задавать себе в начале пути выбора EA Tool.

Из этих требований ключевым должно стать — гибкость настройки метамодели.

Пример метамодели, которую я с командой строил для своей архитектурной практики:

Многие инструменты поставляются с жёстко настроенной метамоделью (например, Archimate) или её изменение требует постоянных работ на стороне поставщика, что означает постоянные расходы.

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

2. Методология

Следующий важный аспект выбора EA Tool — это методология, принятая в каждой конкретной организации, ведь методология будет определять и правила обновления информации, устанавливать сроки и предъявлять требования к финальной документации.

Архитекторы не просто работают с репозиторием объектов отдельно от всей организации. Репозиторий служит местом хранения объектов, которые извлекаются архитектором для явлению их миру в том или ином виде.

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

Но иногда требуются выгрузки списка объектов с их атрибутами или даже построение отдельных представлений прямо в репозитории.

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

В вопросах методологии следует задуматься:

1. Какие артефакты (документы) мы используем?

2. Создание каких артефактов мы автоматизируем?

3. Какие архитектурные представления нам требуются?

4. Нужен ли обратный импорт из артефактов в репозиторий?

5. Насколько сложно адаптировать инструмент под наши артефакты?

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

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

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

3. Процесс

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

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

Какие шаги из этого процесса вы автоматизируете? какие оставите за бортом? а какие будете внедрять вместе с инструментом?

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

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

С процессной точки зрения стоит задуматься над вопросами:

1. Как выглядит текущий процесс проектирования?

2. Какие есть проблемы, требующие автоматизации?

3. Как инструмент поможет в решению проблем?

4. Как изменится процесс с внедрением инструмента?

5. Кто помимо архитекторов будет использовать инструмент?

Если после ответа на эти вопросы появляются новые, а ясности не добавляется — не стоит подходить к вопросу выбора инструмента. Описание нужно сделать хотя бы на уровне крупных блоков или списка типовых проблем в виде use cases.

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

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

***

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