EA Tool для ИТ-Архитектора
Инструмент проектирования архитектуры
Если самым популярным вопросом о работе архитекторов является «Кто такие архитекторы и чем они занимаются?», то второй по популярности причиной провала архитектурной практики после »Не сошлись в видении с руководством» является отсутствие нормального инструмента. Под этим инструментом подразумеваются Enterprise Architecture Tool, которых на рынке представлено огромное множество, примерно такое же, как и различных framework и методологий архитектуры.
Кстати говоря о framework«ах, если выбор такого стоит остро и кроме TOGAF ничего не попадается, рекомендую книгу »The Practice of Enterprise Architecture» Святослава Котусева, которую я упоминал в публикации на тему навыков архитекторов.
Я уже много лет пользуюсь различными инструментами и какое-то время даже занимался продажей одного из таких инструментов (на мой взгляд очень удачного, за парой исключений) и в этой публикации решил поделиться ранее накопленным опытом.
Первое и золотое правило в выборе инструмента, и EA Tool в частности:
Fools with tools are still fools.
Fools with tools are still fools
Без понимания своей работы, потребностей и её целей, никакие инструменты вам не помогут. А даже скорее навредят, так как покупка любого инструмента приведёт к дополнительным затратам, а значит и увеличит градус ожиданий от работы архитектора. И если вместо существенного (а по-другому как правило такие инструменты не продаются) увеличения ценности от деятельности архитектора, руководство получит плохо автоматизированную бюрократию, которая только замедлила процесс развития компании — последствия могут быть самые печальные.
Инструмент не волшебная палочка, которая одним взмахом решит все ваши проблемы в скорости разработки, повышения производительности, созданию единой точки правды и так далее.
Магии в инженерии не существует
Любой инструмент, который мы используем, будь то хранилище исходных кодов, сборщик мусора, конвейер сборки исходного кода и так далее, — это автоматизация рутины. За счёт которой мы можем освобождать время команды на более полезную работу.
Инструменты только автоматизируют рутину
Второй принцип выбора любого инструмента — если он не освобождает время, а создаёт дополнительные трудности, это плохой инструмент.
Когда вам продают EA Tool, то, как правило, называют его инструментом управления архитектурой предприятия. Звучит круто, и наличие слова «управление» сразу привлекает внимание менеджмента, ключевой компетенцией которого является управление. Но инструмент сам по себе ничем не управляет, тем более предприятием, в котором архитекторы выполняют поддерживающую функцию, безусловно важную, но всё-таки деньги это не приносит. А основа любой коммерческой организации (для которых эти инструменты и предлагаются) — это зарабатывание денег. Более честно будет называть такие продукты архитектурным репозиторием. То есть местом хранения объектов и артефактов, которые архитекторы используют в работе.
1. Inventory
EA Tool в первую очередь Inventory для значимых объектов учёта
Пожалуй, самой важной функцией EA Tool является возможность паспортизировать важнейшие элементы архитектуры, которые подвергаются изменениям в результате работы с ними архитектора.
Какие элементы нужно паспортизировать, сильно зависит от каждого конкретного случая. От предприятия к предприятию зоны ответственности архитекторов могут сильно разниться. Например, если инфраструктура предоставляется как сервис, вряд ли вы хотите знать имя каждой машины, её кластер или IP доступа в админку. А вот если вы используете собственную инфраструктуру или её арендуете, вопросы учёта инфраструктуры будут для вас не праздными.
Потому при выборе EA Tool в первую очередь стоит задуматься о метамодели:
Какие объекты вы хотите учитывать?
Что вы хотите о них знать (состав атрибутов)?
Как они связаны с другими объектами?
Как часто требуется менять метамодель?
Какие способы наполнения репозитория вам доступы? (ручные и/или автоматические)
Вот небольшой перечень вопросов, которые стоит задавать себе в начале пути выбора EA Tool.
Из этих требований ключевым должно стать — гибкость настройки метамодели.
Пример метамодели, которую я с командой строил для своей архитектурной практики:
Пример метамодели
Многие инструменты поставляются с жёстко настроенной метамоделью (например, Archimate) или её изменение требует постоянных работ на стороне поставщика, что означает постоянные расходы.
Жёсткость не равно плохо, но выбирая готовую метамодель, нужно быть готовым подстроить и архитектурную практику под заложенную логику, что, по моему опыту, не всегда возможно, и такой выбор приводит к появлению различных bypass, что в свою очередь противоречит логике выбора инструмента с защитой метамоделью.
2. Методология
Методология устанавливает требования к документированию
Следующий важный аспект выбора EA Tool — это методология, принятая в каждой конкретной организации, ведь методология будет определять и правила обновления информации, устанавливать сроки и предъявлять требования к финальной документации.
Архитекторы не просто работают с репозиторием объектов отдельно от всей организации. Репозиторий служит местом хранения объектов, которые извлекаются архитектором для явлению их миру в том или ином виде.
Наиболее типовое представление — это диаграмма решения, которая демонстрирует связанные между собой объекты архитектурного учёта и отражает суть предлагаемых изменений, в редких случаях демонстрирует существующую проблему.
Но иногда требуются выгрузки списка объектов с их атрибутами или даже построение отдельных представлений прямо в репозитории.
Например, построение деревовидных иерархий или узловых графов, которые отражают декомпозицию сложной системы на составные части или показывают протекание информации по ИТ-ландшафту.
В вопросах методологии следует задуматься:
Какие артефакты (документы) мы используем?
Создание каких артефактов мы автоматизируем?
Какие архитектурные представления нам требуются?
Нужен ли обратный импорт из артефактов в репозиторий?
Насколько сложно адаптировать инструмент под наши артефакты?
Эти вопросы помогут вам определить, насколько выбранный инструмент соответствует вашим методологическим требованиям и сможет ли он эффективно поддерживать вашу архитектурную практику.
Инструмент должен помогать создавать нужные вам артефакты
Неправильный выбор инструмента может оказать вам медвежью услугу, когда порождаемые артефакты с помощью EA Tool будут дорабатываться вручную, а затем утилизироваться за ненадобностью. За такой инструмент спасибо вам точно не скажут, да и сами вы не будете рады такой автоматизации.
Наиболее яркими примерами такой автоматизации являются госорганы, когда заполнение заявки происходит сначала в электронном виде, предъявление в бумажном, а исправление ошибок требуется делать в электронном виде, на основании того, что вам обозначат на бумажном носителе.
3. Процесс
Без чёткого процесса инструмент создаст больше проблем, чем пользы
В любой организации человеческой деятельности процесс существует сам по себе, вне зависимости от того, описали его аналитики или нет. Этот факт всегда нужно учитывать в работе, особенно когда речь идёт об автоматизации деятельности, для которой, как я и писал выше,
При выборе EA Tool нужно очень глубоко задуматься, как работа в новом инструменте впишется в ваш текущий процесс проектирования.
Какие шаги из этого процесса вы автоматизируете? какие оставите за бортом?, а какие будете внедрять вместе с инструментом?
Например, в моей практике был случай, что вместе с внедрением инструмента все ИТ-активы получили уникальный ID из репозитория. Все запросы на согласование бюджета на доработки должны были содержать ID актива. Это позволяло членам бюджетного комитета обратиться к репозиторию и посмотреть, что это за актив. Если актив отсутствовал в репозитории или информация о нём была недостаточна — запрос на доработку отклонялся.
Автоматизация хаоса — породит автоматизированный хаос
Крайне наивно и опасно полагать, что с внедрением EA Tool вы сможете выстроить процесс проектирования, которого ранее не существовало. С большой долей вероятности в великий рандом принятия решения вы внесёте пару таких же случайных шагов — как внести информацию в репозиторий, получить информацию из репозитория.
С процессной точки зрения стоит задуматься над вопросами:
Как выглядит текущий процесс проектирования?
Какие есть проблемы, требующие автоматизации?
Как инструмент поможет в решению проблем?
Как изменится процесс с внедрением инструмента?
Кто помимо архитекторов будет использовать инструмент?
Если после ответа на эти вопросы появляются новые, а ясности не добавляется — не стоит подходить к вопросу выбора инструмента. Описание нужно сделать хотя бы на уровне крупных блоков или списка типовых проблем в виде use cases.
Одной из задач, которую нам недавно довелось решать, — это огромные трудозатраты на поиск информации об инфраструктуре, на которой развёрнута та или иная система. Каждый раз это приходилось делать вручную, с помощью выгрузок с нескольких сред виртуализации, а потом сводить воедино через головы нескольких специалистов.
В процессе создания единого реестра инфраструктуры и попытки связать это с системами автоматически обнаружился целый ряд проблем в смежных с архитектурой процессах. А для решения задачи инвентаризации потребовалось даже изменение внутреннего регламента службы эксплуатации.
***
Специфицированный по шагам процесс
Публикация охватила только основные аспекты выбора инструмента, и всё равно получилась достаточно объёмной. Выбор подходящего инструмента может потянуть на полноценную главу книги или диссертации, но основные моменты я постарался изложить тут.