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

Fools with tools are still fools

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

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

Магии в инженерии не существует

Магии в инженерии не существует

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

Инструменты только автоматизируют рутину

Инструменты только автоматизируют рутину

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

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

1. Inventory

EA Tool в первую очередь Inventory для значимых объектов учёта

EA Tool в первую очередь 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.

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

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

***

Специфицированный по шагам процесс

Специфицированный по шагам процесс

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

© Habrahabr.ru