Skip to content

Customise the Metamodel — Lightly

Turbo EA's metamodel is fully admin-configurable — every card type, field, subtype, relation, and stakeholder role is data, not code. You will be tempted to redesign it. Don't.

The teams that succeed customise the metamodel only when the default fields can't answer their question. The teams that fail spend their first month renaming Application to Solution, adding 30 custom fields, and never get to a working report.

What's already in the metamodel

Before adding anything, know what you already have. The built-in Application card type ships with these fields out of the box (among others):

Built-in field Type What it's for
businessCriticality single_select (required) Mission Critical / Business Critical / Business Operational / Administrative
functionalSuitability single_select Perfect / Appropriate / Insufficient / Unreasonable
technicalSuitability single_select Fully Appropriate / Adequate / Unreasonable / Inappropriate
timeModel single_select (required) Tolerate / Invest / Migrate / Eliminate — the canonical Gartner TIME disposition
costTotalAnnual cost Total Annual Cost
lifecycle.* dates Plan / Phase In / Active / Phase Out / End of Life

Everything an Application Portfolio Rationalisation needs is already there, including TIME Model. You don't need to add a TIME field — you derive it with a calculation (below) or fill it in by hand, see Your First Analysis. The same is true for functionalSuitability and technicalSuitability, the two suitability dimensions that classically drive a TIME placement, and for businessCriticality, which groups the Application Portfolio report.

The two-question test before adding a field

When you do find yourself needing a field that's genuinely not in the metamodel, ask yourself:

  1. Will I filter, group, or report on this field? If no, it belongs in the description or a tag — not a field.
  2. Is the same answer needed on every card of this type? If no, it's a relation or an attachment, not a field.

If you can't answer "yes" to both, don't add the field.

If you really do need a custom field

For the rare case where a genuinely new field is needed (e.g., a cloudReadiness flag, a regulatory classification, a customer-segment marker), the workflow is:

  1. Go to Admin → Metamodel and click the type. The card layout is on the Main tab.
  2. Pick the section (or create one with Add Section) and click + Field.
  3. Fill in:
    • Key in lower camel-case (e.g., cloudReadiness) — becomes the attribute key in JSON and in formulas.
    • Label (and a translation for every locale you support — non-English users will see the raw key otherwise).
    • Type — text, multiline_text, number, cost, percentage, boolean, date, url, single_select, multiple_select.
    • Required — leave off for the first rollout; while a required field is empty, the card's Data Quality score is pinned to 0.
  4. For select types, add the options (key + label + colour) and translate each option.
  5. Save.
  6. Optional: set how much the field counts towards Data Quality in the type's Data quality tab.

The field is immediately available in Inventory (Columns, filters), on the Card Detail, and in Calculations formulas as <fieldKey>. Full reference: Admin → Metamodel.

Option: derive a field automatically with a Calculation

Beside the standard option of having users fill a field manually, Turbo EA can compute a field value automatically from other fields on the same card — including the built-in ones — using the Calculations feature. The computed field becomes read-only and carries a "calculated" badge so users can't drift from the rule.

The canonical example is the TIME Model calculation, which derives the built-in timeModel field on Application from the two built-in suitability ratings. Create it in Admin → Metamodel → Calculations with New Calculation: Target Card Type = Application, Target Field = TIME Model, and this formula:

# 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")))

Each rating is turned into a score from 4 (best) to 1 (worst), and the two scores place the application in one of the four quadrants: high functional + high technical = Invest, high functional + low technical = Migrate, low functional + high technical = Tolerate, low on both = Eliminate. An application missing either rating gets no TIME value, so the gaps stay visible.

It is the same TIME example you'll find in the Formula Reference panel of the calculation editor, so you can also copy it from there. It reads only fields Application already has, so you don't need to add any field — and you shouldn't (see Don't duplicate built-in fields below). More formula syntax: Admin → Calculations.

After saving, switch the calculation Active and click Recalculate all on its row so every existing application gets its value. The step-by-step walkthrough is in Your First Analysis → Step 3.

Don't

A calculated TIME is a starting hypothesis, not a verdict. Review every result with the Application Owner before trusting it.

The hybrid pattern that works well in practice: keep the calculation active while you're building the inventory and collecting suitability ratings; review the results in the validation workshop; and if decisions need to depart from the formula, turn the calculation off (the Active switch) so the field becomes editable again and the manual decisions stick.

Alternative: use a Tag Group instead

If the value is informational rather than queryable, a Tag Group (Admin → Metamodel → Tags) is lighter than a custom field — no metamodel change, no migration, easier to evolve. Use a Tag Group when:

  • The value is descriptive ("Customer-facing", "Internal-only", "Acquired in 2024").
  • You may add new options frequently.
  • You don't need it in a filter dropdown but a search-as-you-type tag chip is fine.

Use a custom field when:

  • You want to group or colour a report by it (for example the Application Portfolio).
  • You want it weighted into Data Quality.
  • It's a controlled vocabulary that won't change often.

Anti-patterns to avoid

These are the most common metamodel mistakes in first rollouts:

Don't rename built-in card types

Renaming Application to Solution looks tidy but breaks the conceptual mapping that the Capability Map, the Application Portfolio report, and the catalogues all assume. If your organisation calls them "Solutions", set the label translation — the underlying key stays as Application.

Don't add 30 custom fields on day one

Each custom field adds friction to data collection and dilutes the Data Quality score. Add one field, use it for a month, then add the next.

Don't duplicate built-in fields

Before adding timeDisposition, funcFit, techFit, or appCriticality, check the existing field list — chances are an equivalent built-in field already exists (timeModel, functionalSuitability, technicalSuitability, businessCriticality). Duplicates split your data and break reports.

Don't make new fields required on day one

While a required field is empty, the card's Data Quality score is pinned to 0 and a warning banner lists what is missing — on every existing card at once. Make a field required only after you've filled it in for 80%+ of the population.

Don't create custom card types instead of custom fields

"Mobile App" should be a subtype of Application, not a new card type. New types don't get capability mapping, portfolio reports, or catalogue imports for free.

Other lightweight extensions you may want

These are common second-pass extensions, but don't add them until you actually need them:

Need Where to add Type
Cloud readiness Application single_select (Ready / Needs refactor / Stays on-prem)
Customer-facing flag Application boolean
Regulatory classification Application, DataObject multiple_select (GDPR, PCI-DSS, …)
Risk-of-loss category Application, IT Component single_select (Single point of failure, etc.)
Cost split Application additional cost fields for costRunTotalAnnual, costChangeTotalAnnual

Each one passes the two-question test for portfolio analytics. Several of them are also fine candidates for a calculated formula instead of manual entry — which is what the next page covers, using timeModel itself as the worked example.

Next: Your first analysis: Application Harmonisation.