Кастомизируйте метамодель — слегка

Метамодель Canopy полностью настраиваема администратором — каждый тип карточки, поле, подтип, связь и роль стейкхолдера — это данные, а не код. У Вас возникнет соблазн её переработать. Не делайте этого.

Команды, которые преуспевают, кастомизируют метамодель только когда стандартные поля не могут ответить на их вопрос. Команды, которые терпят неудачу, тратят первый месяц на переименование Application в Solution, добавление 30 пользовательских полей и так и не доходят до рабочего отчёта.

Что уже есть в метамодели

Прежде чем что-либо добавлять, узнайте, что у Вас уже имеется. Встроенный тип карточки Application поставляется со следующими полями «из коробки» (среди прочих):

Встроенное поле	Тип	Для чего оно
businessCriticality	single_select	Mission-critical / Important / Useful / Marginal
functionalSuitability	single_select	Perfect / Appropriate / Insufficient / Unreasonable
technicalSuitability	single_select	Fully Appropriate / Adequate / Unreasonable / Inappropriate
timeModel	single_select (обязательное)	Tolerate / Invest / Migrate / Eliminate — каноническая TIME-диспозиция Gartner
riskLevel	single_select	Low / Medium / High / Critical
businessValue	single_select	Управляет осью Y Portfolio Report
costTotalAnnual	cost	Суммарные годовые затраты
lifecycle.*	даты	Plan / Phase In / Active / Phase Out / End of Life

Всё, что нужно для Рационализации портфеля приложений, уже здесь, включая TIME Model. Вам не нужно добавлять поле TIME — Вы его заполняете (вручную или через вычисление, см. Ваш первый анализ). То же самое верно для functionalSuitability и technicalSuitability — двух измерений пригодности, которые классически определяют положение в TIME.

Тест из двух вопросов перед добавлением поля

Когда Вы всё-таки обнаружите, что Вам нужно поле, которого действительно нет в метамодели, спросите себя:

1. Буду ли я фильтровать, группировать или строить отчёт по этому полю? Если нет, оно принадлежит описанию или тегу — а не полю.
2. Нужен ли один и тот же ответ на каждой карточке этого типа? Если нет, это связь или вложение, а не поле.

Если Вы не можете ответить «да» на оба, не добавляйте поле.

Если Вам действительно нужно пользовательское поле

Для редкого случая, когда действительно нужно подлинно новое поле (например, флаг cloudReadiness, регуляторная классификация, маркер клиентского сегмента), последовательность действий такова:

1. Перейдите в Админ → Метамодель, кликните по типу, переключитесь на вкладку Fields.
2. Выберите секцию (или создайте новую) и нажмите + Add field.
3. Заполните:
   • Key в lower camel-case (например, cloudReadiness) — становится ключом атрибута в JSON и в формулах.
   • Label (и перевод для каждой поддерживаемой Вами локали — иначе неанглоязычные пользователи увидят сырой ключ).
   • Type — text, number, cost, boolean, date, url, single_select, multiple_select.
   • Weight — 0, чтобы исключить из Качества данных, 1+, чтобы включить и взвесить.
   • Required — оставьте выключенным при первом развёртывании; required заблокирует согласование каждой существующей карточки.
4. Для типов select добавьте опции (key + label + цвет) и переведите каждую опцию.
5. Сохраните.

Поле сразу доступно в Инвентаризации (Columns, фильтры), на карточке и в формулах Вычислений как <fieldKey>. Полная справка: Админ → Метамодель.

Вариант: выводите поле автоматически с помощью Вычисления

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

Канонический пример — вычисление TIME Model, которое выводит встроенное поле timeModel на Application из измерения бизнес-пригодности и измерения технической пригодности. Оно поставляется как одна из записей в панели Formula Reference внутри Админ → Метамодель → Вычисления при создании нового вычисления, поэтому Вы можете выбрать его прямо из панели. Target type = Application, target field = timeModel; предоставленная панелью формула воспроизведена в Админ → Вычисления → Example Formulas.

Формула предполагает два поля single_select с именами businessFit и technicalFit с опциями excellent / adequate / insufficient / unreasonable. Они не входят во встроенную метамодель — добавьте их на Application согласно шагам по пользовательским полям выше, если Вы хотите использовать это вычисление.

Don't

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

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

Альтернатива: используйте Tag Group вместо этого

Если значение информационное, а не запрашиваемое, Tag Group (Админ → Tags) легче, чем пользовательское поле — без изменения метамодели, без миграции, проще эволюционировать. Используйте Tag Group, когда:

• Значение описательное («Customer-facing», «Internal-only», «Acquired in 2024»).
• Вы можете часто добавлять новые опции.
• Вам не нужно это в фильтре-выпадашке, но чип тега с поиском по мере ввода подойдёт.

Используйте пользовательское поле, когда:

• Вам нужно значение на осях Portfolio Report (X, Y, цвет).
• Вы хотите взвесить его в Качество данных.
• Это контролируемый словарь, который не будет часто меняться.

Антипаттерны, которых следует избегать

Это самые распространённые ошибки в метамодели при первых развёртываниях:

Не переименовывайте встроенные типы карточек

Переименование Application в Solution выглядит аккуратно, но ломает концептуальное сопоставление, которое предполагают Capability Heatmap, Portfolio Report и каталоги. Если Ваша организация называет их «Solutions», установите перевод label — базовый key остаётся Application.

Не добавляйте 30 пользовательских полей в первый день

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

Не дублируйте встроенные поля

Прежде чем добавлять timeDisposition, funcFit, techFit или appBusinessValue, проверьте список существующих полей — скорее всего, эквивалентное встроенное поле уже существует (timeModel, functionalSuitability, technicalSuitability, businessValue). Дубликаты расщепляют Ваши данные и ломают отчёты.

Не делайте новые поля required в первый день

Required блокирует согласование для каждой существующей карточки, у которой нет значения. Делайте поле обязательным только после того, как заполните его для 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 используется как разобранный пример.

Далее: Ваш первый анализ: Гармонизация приложений.