Onboarding and configuration, today and after the multi-tenancy line moves

Scene 5: Onboarding and configuration today

The first layer the customer meets is onboarding: gathering requirements, mapping them to features and configuration, customising, migrating data and training people. The customer cannot use the product until onboarding is done, and enterprise implementation is still measured in months. The configuration sits in setup screens, spreadsheets and files such as JSON, YAML or XML. A schema lists the fields and their types, while the rules for valid combinations are written nowhere it can enforce, so errors often surface after go-live. For the provider, the knowledge sits with a few people, every attribute needs review, and the work repeats whenever a law, a policy or the organisation changes.

Scene 19: onboarding

The brownfield journey starts where the customer's did, with onboarding. Every step of onboarding draws on the same domain invariants, which the language can represent once and share across the whole journey. Requirements would be stated in the domain's vocabulary, and the agent would write them as a document. The validator would check the configuration against the domain's rules before anything is applied. Customisation and training would draw on the same definitions, so each step works from one description of the domain rather than its own. The same onboarding document drives the data migration, and each failure cites the record and the rule that rejected it. The product itself is untouched, because the document compiles to inputs the product already accepts. For the provider, the knowledge a few specialists held is written into the grammar, and review moves from every attribute toward judging outputs. So far, only the migration step of onboarding has been demonstrated, on test data.