Кастомизируйте метамодель — слегка¶
Метамодель Turbo EA полностью настраиваема администратором — каждый тип карточки, поле, подтип, связь и роль стейкхолдера — это данные, а не код. У Вас возникнет соблазн её переработать. Не делайте этого.
Команды, которые преуспевают, кастомизируют метамодель только когда стандартные поля не могут ответить на их вопрос. Команды, которые терпят неудачу, тратят первый месяц на переименование Application в Solution, добавление 30 пользовательских полей и так и не доходят до рабочего отчёта.
Что уже есть в метамодели¶
Прежде чем что-либо добавлять, узнайте, что у Вас уже имеется. Встроенный тип карточки Application поставляется со следующими полями «из коробки» (среди прочих):
| Встроенное поле | Тип | Для чего оно |
|---|---|---|
businessCriticality |
single_select (обязательное) |
Критически важный / Критичный для бизнеса / Операционный / Административный |
functionalSuitability |
single_select |
Отлично / Подходящий / Недостаточный / Неприемлемый |
technicalSuitability |
single_select |
Полностью подходящий / Адекватный / Неприемлемый / Неподходящий |
timeModel |
single_select (обязательное) |
Tolerate / Invest / Migrate / Eliminate — каноническая TIME-диспозиция Gartner |
costTotalAnnual |
cost |
Общая годовая стоимость |
lifecycle.* |
даты | Plan / Phase In / Active / Phase Out / End of Life |
Всё, что нужно для Рационализации портфеля приложений, уже здесь, включая TIME Model. Вам не нужно добавлять поле TIME — Вы выводите его с помощью вычисления (см. ниже) или заполняете вручную, см. Ваш первый анализ. То же самое верно для functionalSuitability и technicalSuitability — двух измерений пригодности, которые классически определяют положение в TIME, — а также для businessCriticality, по которому группируется отчёт «Портфолио приложений».
Тест из двух вопросов перед добавлением поля¶
Когда Вы всё-таки обнаружите, что Вам нужно поле, которого действительно нет в метамодели, спросите себя:
- Буду ли я фильтровать, группировать или строить отчёт по этому полю? Если нет, оно принадлежит описанию или тегу — а не полю.
- Нужен ли один и тот же ответ на каждой карточке этого типа? Если нет, это связь или вложение, а не поле.
Если Вы не можете ответить «да» на оба, не добавляйте поле.
Если Вам действительно нужно пользовательское поле¶
Для редкого случая, когда действительно нужно подлинно новое поле (например, флаг cloudReadiness, регуляторная классификация, маркер клиентского сегмента), последовательность действий такова:
- Перейдите в Админ → Метамодель и кликните по типу. Макет карточки находится на вкладке Основное.
- Выберите раздел (или создайте его кнопкой Добавить раздел) и нажмите + Поле.
- Заполните:
- Key в lower camel-case (например,
cloudReadiness) — становится ключом атрибута в JSON и в формулах. - Label (и перевод для каждой поддерживаемой Вами локали — иначе неанглоязычные пользователи увидят сырой ключ).
- Type —
text,multiline_text,number,cost,percentage,boolean,date,url,single_select,multiple_select. - Required — оставьте выключенным при первом развёртывании; пока обязательное поле пусто, показатель Качества данных карточки зафиксирован на 0.
- Key в lower camel-case (например,
- Для типов select добавьте опции (key + label + цвет) и переведите каждую опцию.
- Сохраните.
- Необязательно: задайте, насколько поле влияет на Качество данных, на вкладке Качество данных этого типа.
Поле сразу доступно в Инвентаризации (Columns, фильтры), на карточке и в формулах Вычислений как <fieldKey>. Полная справка: Админ → Метамодель.
Вариант: выводите поле автоматически с помощью Вычисления¶
Помимо стандартного варианта, когда пользователи заполняют поле вручную, Turbo EA может вычислять значение поля автоматически из других полей той же карточки — включая встроенные — с помощью функции Вычислений. Вычисляемое поле становится только для чтения и получает бейдж «calculated», чтобы пользователи не могли отступить от правила.
Канонический пример — вычисление TIME Model, которое выводит встроенное поле timeModel на Application из двух встроенных оценок пригодности. Создайте его в Админ → Метамодель → Вычисления кнопкой Новое вычисление: Целевой тип карточки = Application, Целевое поле = Модель TIME, и вот такая формула:
# TIME Model from the built-in Functional and Technical Suitability (Gartner quadrants)
ff = MAP_SCORE(data.functionalSuitability, {"perfect": 4, "appropriate": 3, "insufficient": 2, "unreasonable": 1})
tf = MAP_SCORE(data.technicalSuitability, {"fullyAppropriate": 4, "adequate": 3, "unreasonable": 2, "inappropriate": 1})
IF(ff is None or tf is None, None, IF(ff >= 2.5, IF(tf >= 2.5, "invest", "migrate"), IF(tf >= 2.5, "tolerate", "eliminate")))
Каждая оценка превращается в балл от 4 (лучший) до 1 (худший), и два балла помещают приложение в один из четырёх квадрантов: высокая функциональная + высокая техническая = Инвестировать, высокая функциональная + низкая техническая = Мигрировать, низкая функциональная + высокая техническая = Терпеть, низкие обе = Ликвидировать. Приложение, у которого нет хотя бы одной из оценок, не получает значения TIME, поэтому пробелы остаются видимыми.
Это тот же пример TIME, который Вы найдёте в панели Справочник формул редактора вычислений, так что его можно скопировать и оттуда. Он использует только поля, которые у Application уже есть, поэтому Вам не нужно добавлять ни одного поля — и не следует (см. Не дублируйте встроенные поля ниже). Больше о синтаксисе формул: Админ → Вычисления.
После сохранения переключите вычисление в состояние Активно и нажмите Пересчитать все в его строке, чтобы каждое существующее приложение получило своё значение. Пошаговое руководство — в Ваш первый анализ → Шаг 3.
Don't
Вычисляемый TIME — это стартовая гипотеза, а не вердикт. Проверяйте каждый результат с Владельцем приложения, прежде чем доверять ему.
Гибридный паттерн, который хорошо работает на практике: держите вычисление активным, пока Вы строите инвентарь и собираете оценки пригодности; проверьте результаты на валидационном воркшопе; а если решения должны отличаться от формулы, выключите вычисление (переключатель Активно), чтобы поле снова стало редактируемым и ручные решения закрепились.
Альтернатива: используйте Tag Group вместо этого¶
Если значение информационное, а не запрашиваемое, Tag Group (Админ → Метамодель → Теги) легче, чем пользовательское поле — без изменения метамодели, без миграции, проще эволюционировать. Используйте Tag Group, когда:
- Значение описательное («Customer-facing», «Internal-only», «Acquired in 2024»).
- Вы можете часто добавлять новые опции.
- Вам не нужно это в фильтре-выпадашке, но чип тега с поиском по мере ввода подойдёт.
Используйте пользовательское поле, когда:
- Вы хотите группировать или раскрашивать по нему отчёт (например, «Портфолио приложений»).
- Вы хотите взвесить его в Качество данных.
- Это контролируемый словарь, который не будет часто меняться.
Антипаттерны, которых следует избегать¶
Это самые распространённые ошибки в метамодели при первых развёртываниях:
Не переименовывайте встроенные типы карточек
Переименование Application в Solution выглядит аккуратно, но ломает концептуальное сопоставление, которое предполагают Карта возможностей, отчёт «Портфолио приложений» и каталоги. Если Ваша организация называет их «Solutions», установите перевод label — базовый key остаётся Application.
Не добавляйте 30 пользовательских полей в первый день
Каждое пользовательское поле добавляет трения в сбор данных и разбавляет показатель Качества данных. Добавьте одно поле, используйте его месяц, затем добавьте следующее.
Не дублируйте встроенные поля
Прежде чем добавлять timeDisposition, funcFit, techFit или appCriticality, проверьте список существующих полей — скорее всего, эквивалентное встроенное поле уже существует (timeModel, functionalSuitability, technicalSuitability, businessCriticality). Дубликаты расщепляют Ваши данные и ломают отчёты.
Не делайте новые поля required в первый день
Пока обязательное поле пусто, показатель Качества данных карточки зафиксирован на 0, а баннер с предупреждением перечисляет, чего не хватает, — и это сразу на каждой существующей карточке. Делайте поле обязательным только после того, как заполните его для 80%+ популяции.
Не создавайте пользовательские типы карточек вместо пользовательских полей
«Mobile App» должен быть подтипом Application, а не новым типом карточки. Новые типы не получают сопоставление с возможностями, отчёты по портфелю или импорт из каталога бесплатно.
Другие лёгкие расширения, которые Вам могут понадобиться¶
Это распространённые расширения второго прохода, но не добавляйте их, пока они действительно не нужны:
| Потребность | Куда добавить | Тип |
|---|---|---|
| Готовность к облаку | Application | single_select (Ready / Needs refactor / Stays on-prem) |
| Флаг «обращён к клиенту» | Application | boolean |
| Регуляторная классификация | Application, DataObject | multiple_select (GDPR, PCI-DSS, …) |
| Категория риска потери | Application, IT Component | single_select (Single point of failure и т. д.) |
| Разделение затрат | Application | дополнительные поля cost для costRunTotalAnnual, costChangeTotalAnnual |
Каждое из них проходит тест из двух вопросов для аналитики портфеля. Некоторые из них также являются хорошими кандидатами на вычисляемую формулу вместо ручного ввода — что и рассмотрено на следующей странице, где сам timeModel используется как разобранный пример.