← All use cases

Business & conceptual modeling

ADL works above the SQL layer too. Model business capabilities, domain concepts, and architectural decisions — in the same tool, the same metadata, the same git repository as the implementation that follows.

Who this is for

Data modelers, enterprise architects, business analysts, and the stakeholders who own the meaning of data rather than its implementation. Anyone who works in capability maps, domain models, conceptual designs — and wants those designs to be more than slide decks that go stale.

The pain we hear most often: "The business architecture lives in diagrams that nobody updates. The engineering team builds from a separate source of truth. Six months in, the two have drifted, and nobody can reconcile them." Conceptual and physical designs use different tools, different formats, different governance — and the seams between them leak information.

How ADL is configured for this

Because ADL's metadata is methodology-neutral and platform-neutral, the same structure that describes a Snowflake warehouse can describe a business capability hierarchy. The difference is in which classifications you apply and which templates you wire up. No SQL generation required.

In practice

A common scenario: an enterprise architect needs to document the business capabilities of a financial-services organization. The capabilities are real; they shape investment, governance, and prioritization decisions. But they're currently scattered across slides and wiki pages.

1. Install the NBility starter. NBility is a business capability reference model that ships with ADL — install it from the Marketplace to see a worked example. Or install the Metadata Architecture sample for conceptual-modeling guidance.
2. Capture your capabilities. Create Data Objects for each capability (e.g., Customer Onboarding, Risk Assessment, Settlement). Use the conceptual classifications to tag them. Relationships express dependencies between capabilities.
3. Configure an architecture persona. The graph view filters to your conceptual model — clean, presentable, stakeholder-ready. No staging tables or stored procedures clutter the picture.
4. Generate documentation. Run a documentation template against the conceptual layer. Output: a Markdown report describing each capability, its purpose, and its dependencies — for the governance board, the investment committee, or onboarding new architects.
5. Connect to implementation when you're ready. If a capability later needs a physical implementation, the conceptual model is already in the repo. Add Data Objects at the logical and physical levels; classify them; wire up templates. The bridge between business architecture and warehouse implementation lives in one place.

What ships today

• Conceptual / Logical / Physical classifications — ship in the Global classifications sample. Three tiers of expression, pre-tagged for common entity types.
• NBility starter solution — a business capability reference model. Install it as a worked example of capability modeling in ADL. See the NBility sample.
• Metadata Architecture starter solution — a conceptual design example, focused on the metadata layer itself rather than any specific platform. Useful as a teaching tool for how ADL organizes pre-physical metadata. See the Metadata Architecture sample.
• BusinessModel sample — a starter that demonstrates business-model-level metadata before physical implementation. Install from the Marketplace.
• Markdown documentation generation — templates can emit .md files alongside (or instead of) SQL. The conceptual model becomes the source for documentation that other teams actually read.

Try it

Install NBility or Metadata Architecture from the Marketplace. Open the project, switch to the graph view, and explore the conceptual classifications already in place. Then add a Data Object of your own and see how it joins the picture.

Try the app — free in public preview