Skip to main content
Custom Tool Development

Off-the-shelf tools do not solve specialist problems

Automotive, medtech, aerospace: every domain has its own modelling languages, constraints and toolchain requirements. We develop custom tools that go where your experts work: as a web-based modelling environment directly in the browser, as a VS Code extension in the familiar IDE workflow, or classically as a desktop workbench, also based on Xtext and JetBrains MPS. The result: fewer media breaks, more generated artefacts, more automated processes, zero workarounds. The tool follows your process and your methodology, not the other way around. That is why every project begins with understanding your workflows before the first line of grammar is written.

Fundamentals

What is custom tool development?

Custom tool development means: we adapt the tool to your processes, not the other way around. Instead of forcing experts into the abstractions of an off-the-shelf tool, tools are created that speak exactly the concepts, rules and notations of your domain.

Individual solution instead of compromise

Standard tools and low-code platforms are designed for broad applicability. That is their strength, but also their limit. Where processes are highly specialised, expert knowledge must be represented structurally, or generic abstractions do not fit, friction, workarounds and ultimately knowledge loss arise. Custom tools eliminate these by pouring domain knowledge directly into the tool: as validated models, enforced rules, and consistent generation.

Process and methodology first: then the tool

Standard tools force process adaptation: whoever introduces a generic tool also implicitly adopts its abstraction model, and adapts workflows, roles and artefacts until they fit the tool. This is the root cause of workarounds, shadow documentation and often frustration about the tools’ missing capabilities.

The right starting point is not the tool, but the question: how do your experts work? Which concepts, steps and decision rules describe their methodology? Only once these questions are answered can it be assessed whether an off-the-shelf tool is sufficient, or whether a custom tool can represent the methodology more precisely.

Domain languages

Domain-Specific Languages: knowledge as a first-class concept

At the heart of many custom tools is a domain-specific language (DSL): a notation in which experts work in their own vocabulary. Rules and best practices are not documented but structurally enforced. Knowledge that today resides in the heads of your experts is encoded in the metamodel and thus implicitly available.

DSLs define the vocabulary and even encode the methodology itself. Which concepts exist in the language, which relationships are permitted, which constraints apply: that is the methodology, translated into executable language constructs. A well-designed DSL makes it structurally easy to work methodically correctly and structurally difficult to work incorrectly.

Domain languages can be textual, tabular or graphical — developed with specialised language workbenches such as Xtext or JetBrains MPS, or embedded into modern integration platforms such as VS Code via the Language Server Protocol.

Standard tool extensions are custom tools too

Not every custom tool starts on a greenfield. Many standard tools (e.g. Enterprise Architect, Rhapsody, Capella) offer extension mechanisms through which additional functionality can be integrated without replacing the tool. Such extensions are also custom tools: tailor-made, domain-specific, adapted to your process.

The same principle applies to the modelling language itself: generic languages such as UML do not need to be replaced by a new DSL if they can be adapted precisely enough to a methodology through profiles. Stereotypes define domain-specific concepts, tagged values structure metadata, constraints enforce methodical rules, without replacing the base tool. In an automotive tier-1 and a medtech project, we deliberately advised against a custom DSL after the domain analysis and instead used UML with a project-specific profile. The result was a methodically precise environment with minimal tool change.

When custom tools are worthwhile, and when they are not

Custom tools are not a universal remedy. They pay off where a small group of highly specialised experts works with concepts that no standard tool adequately represents. For large, heterogeneous user groups with generic requirements, standard products are usually the better choice.

The core question: do the abstractions and functions of an existing tool fit your domain well enough? If so, use it. We also recommend our own products such as itemis CREATE or itemis ANALYZE where these are a better fit than a custom tool.

In over 20 years, we have learned: not every domain needs its own language. For an automotive tier-1 supplier and a medtech company, we deliberately advised against a custom DSL after the domain analysis, as UML was sufficient. Instead, we successfully integrated the UML tool into the respective toolchain.

Structural advantages at a glance: Domain knowledge in the tool · Validation while typing · Consistent generation · Integrated simulation · No vendor roadmap dependency · Knowledge stays within the organisation

AI

AI is changing the economics of tool development

For decades the assumption was: custom software is expensive, so processes are adapted to standard tools. This calculation is shifting. AI dramatically reduces the marginal cost of custom development, and shifts the make-or-buy decision anew.

AI accelerates the development of custom tools

Grammar iteration, generator templates, test generation, automated documentation: AI intervenes in every phase of custom tool development and significantly reduces throughput times. One of our own products, which we had originally developed over several years, was rebuilt for VS Code in four weeks with AI support, including a domain-specific AI skill that understands the underlying models.

AI is merely a tool here, because at itemis architecture and domain modelling remain in human hands. Experienced architects and domain experts make the key decisions. In customer projects we have repeatedly revised AI-generated architecture decisions because the AI, lacking domain knowledge, led them in the wrong direction.

AI in the custom tool: domain knowledge as context

Custom tools with integrated AI functions are more than an LLM plugin on top. The domain semantics are structurally anchored in the tool: as precise context for every AI component. An assistant in a generic tool gives merely generic suggestions, whereas an assistant in a custom tool knows the language, rules and models of your domain and can therefore carry out its tasks in a targeted way.

The structural advantage over “generic tool + AI plugin”

The more precise the domain language, the more precise the AI support. Generic tools with AI plugins scale in breadth. Custom tools with integrated AI scale in depth: precisely where expert knowledge resides and generic suggestions are not enough.

Industries

Application in your industry

The domain determines the language. We build the tool.

Automotive: OEM & Tier-1

AUTOSAR architectures, ECU configuration, signal management: complexity is growing, generic tools are reaching their limits. We develop custom tools that integrate deeply into existing automotive toolchains.

ETAS uses itemis CREATE for integrating graphical statecharts into ASCET-DEVELOPER. With itemis support, KOSTAL significantly improved its development process including the AUTOSAR toolchain with the itemis EA-Bridge.

Finance: insurance, banks, financial services

Domain experts model business logic that must be translated directly into executable software. DSLs bridge the gap between domain knowledge and code: for actuarial mathematics, credit models and microservice configurations.

The Zurich Group generates actuarial functions directly from a DSL. Atruvia uses an itemis DSL as a framework extension for modelling and code generation. For a leading financial company (EUR 1.5bn revenue, 9,000 employees) we developed an MPS-based modelling environment for automated microservice generation.

Medical technology: quality under regulatory pressure

IEC 62304, ISO 13485, MDR: every change must be traceable, every requirement must be trackable. Custom tools integrate modelling, code generation and regulatory documentation into a consistent process.

For an internationally leading medical technology company with over 60,000 employees and EUR 9bn annual revenue, we developed a toolchain component for modelling and C++ code generation and integrated it into the existing development environment.

Embedded & industrial: firmware, sensors, automation

Formally describe configuration and behaviour, generate consistently, deploy safely to the target hardware, without manual sources of error. Custom tools create reliability here as software complexity grows.

Since 2023 we have been modernising the tool landscape for early semiconductor development for a globally leading semiconductor manufacturer (55,000 employees, EUR 15bn revenue) through a central MPS-based modelling environment. As a single source of truth, the system replaces fragmented document and tool structures and integrates an AI agent that gives end users intuitive access to the complex domain knowledge.

Approach

How itemis develops custom tools

We use proven patterns from over 20 years of experience and dozens of projects. From the initial domain analysis to ongoing maintenance, we work closely with your experts. With a clear goal: a tool that continues to run without us.

Domain analysis

We understand your domain before building a tool: in workshops, interviews and rapid prototyping sessions with your domain experts. Early feedback prevents late corrections.

Language design

From the process and methodology analysis, a language design emerges: a notation that feels natural to your experts while structurally enforcing the methodology: textual, tabular or graphical, iteratively developed with your domain experts. Validation rules in the tool replace manual pages.

Implementation

We develop agilely and in short cycles. One of our finance projects has been in productive use for eight years, made possible by consistent agility and an architecture that has grown with the requirements.

Quality assurance

DSLs and generators are tested systematically: unit tests for language rules, integration tests for generators, specification by example. Reliability even as complexity grows.

Toolchain integration

Custom tools unfold their potential in the toolchain: integrated into CI/CD pipelines, PLM and ALM systems, requirements management. Artefacts are generated and processed fully automatically. → Toolchain Integration & Tool Selection

Training & knowledge transfer

We do not just deliver the tool. For end users we develop training materials, click guides and videos. We work daily alongside developers on the customer side, so that the know-how for further development stays with the customer.

Maintenance & evolution

The source code belongs to our customers. We build on an open-source basis (EPL, Apache) and avoid proprietary formats and vendor lock-in. Some of our custom tools have been running for years without our involvement. That is the goal.
Technology

Technology stacks at a glance

Custom tool development is not a single-stack topic. The choice depends on two questions: which tool is suitable for designing the domain language? And where should the tool run: in the IDE, in the browser, as an extension of an existing tool? We think both axes together.

Language workbenches: the foundation of language design

Language workbenches provide everything needed for building a domain language: editor support, validation, code generation and model processing. Two paradigms dominate:

Xtext stands for textual DSLs: the models exist as text, are therefore diff- and merge-able and can be seamlessly integrated into CI/CD pipelines. itemis is part of the founding community of Xtext (since 2006) and provides active committers.

Langium is the more modern, TypeScript-native route to textual DSLs: without a Java stack, designed from the ground up for the Language Server Protocol and therefore able to run directly in VS Code and its derivatives as well as in the browser.

JetBrains MPS enables projectional editing: notations that cannot be represented in a text format: tables, mathematical expressions, graphical elements. Particular strength: multiple domain languages can be cleanly combined. itemis is the main maintainer of central MPS extensions (iets3, mbeddr) and a JetBrains partner with 10 years of experience with this technology.

Deployment context: where the tool runs

VS Code & Language Server Protocol: lightweight, modern, low barrier to entry. The language server runs independently of the editor and can be integrated into any LSP-capable environment. Our recommended stack for greenfield projects.

Web & cloud — for distributed teams and browser-based collaboration: fully featured modelling environments in the browser, e.g. built on the established cloud-IDE framework Eclipse Theia or with Modelix (both open source).

Eclipse RCP: proven for extending existing Eclipse-based toolchains and migration projects. However, not recommended for greenfield projects.

Extensions of standard tools: EA, Rhapsody, Capella: many standard tools offer extension mechanisms (add-in APIs, plugin frameworks) through which custom tools are integrated without replacing the existing tool. itemis has developed its own product with the EA-Bridge for processing Enterprise Architect models.

Which stack fits when?

RequirementRecommendation
Textual DSL, IDE integrationXtext + VS Code/Langium
Complex language composition, formal notationJetBrains MPS
Browser-based modelling, distributed teamsWeb platform + Modelix
Extend existing Eclipse toolchainEclipse RCP
Extend UML tool without replacing it / e.g. EATool-specific plug-ins / MDG + EA-Bridge
Migration Eclipse to modern environmentXtext/MPS + VS Code/Langium
Frequently asked questions

FAQ on Custom Tool Development

When is a domain-specific language worth it over a standard notation?
A DSL is worthwhile when a domain is clearly bounded, many people with different technical backgrounds work on the same type of specification, or error classes should be ruled out through the language structure. Generic notations such as UML are better when tool compatibility and standardisation take priority, or the domain is not yet stable enough for its own language.
What is the difference between Xtext, Langium and JetBrains MPS?
Xtext creates textual languages with their own editor, syntax highlighting, validation and code completion, based on Eclipse and the Eclipse Modeling Framework. Langium offers the same feature set based on VS Code and the Language Server Protocol. MPS, by contrast, works projectionally: users edit the Abstract Syntax Tree directly, not text, which enables hybrid notations (text, tables, graphics) in one language. Xtext and Langium are closer to the classic editor paradigm; MPS offers more flexibility for non-textual languages.
How long does DSL development take?
A typical DSL project with editor, validation and generator takes 3 to 12 months depending on domain complexity. A language prototype covering the core concepts is usually realisable in 2 to 6 weeks. Effort increases with the number of target users, notation complexity and the maturity of domain knowledge documentation.
Can custom tools be integrated into existing tools such as Enterprise Architect or Rhapsody?
Yes. itemis develops add-ins and extensions for Enterprise Architect, Rhapsody, CATIA Magic and other commercial modelling tools, without replacing them. Typical extensions include domain-specific validation, reporting, generation and synchronisation with requirements tools such as DOORS or Polarion.
Which industries benefit most from custom tools?
Custom tools deliver the greatest value wherever specialised domain knowledge needs to be formalised: automotive (AUTOSAR configuration, diagnostic descriptions), aerospace (ARINC, DO-178C traceability), medical devices (IEC 62304 traceability), financial services (tariff models, rule logic) and industrial automation (PLC-adjacent configuration languages).
Our Experts
Dr. Patrick Könemann

Principal Engineer & Consultant · itemis AG

Dr. Patrick Könemann is Principal Engineer and Consultant at itemis and has specialised in model-driven software development, tool development and integration since 2011. He holds a doctorate from the Technical University of Denmark and brings 15 years of experience in the automotive domain and 5 years in the medical domain, serving as a project lead, software architect and requirements engineer. He also has extensive expertise in UML tools — particularly Enterprise Architect — as well as Eclipse, VS Code and AI in the development process.
Dr. Klaus Birken

Principal Expert · itemis AG

Dr. Klaus Birken is Principal Expert at itemis, focusing on custom modelling tools and variant management. After a decade as a software architect in the infotainment domain, he has been shaping projects around model-based tools and DSLs (primarily with JetBrains MPS) since 2012, sharing his knowledge as a conference speaker. His current focus is on the value-creating connection between AI agents and model-based development.
Get started

Develop a custom tool

Schedule a call with Dr. Patrick Könemann and Dr. Klaus Birken.

Expertise

Insights on Custom Tool Development

AI Agents Meet Projectional Editing: Portalon for MPS
Blog Custom tools

AI Agents Meet Projectional Editing: Portalon for MPS

How the Portalon plugin connects AI coding agents like Claude to the live model of a JetBrains MPS project via MCP — structurally safe edits, validation, and language-engineering skills, on your current MPS version.

Read Article
Dr. Klaus Birken Dr. Klaus Birken 10 min read
Variant Management: More Than Feature Strings
Blog Custom tools

Variant Management: More Than Feature Strings

Loosely coupling feature models to development artifacts is convenient – but it has hidden risks. This article shows the advantages of tight integration: early error detection, implicit variation points, and automatic consistency checks.

Read Article
Dr. Klaus Birken Dr. Klaus Birken 6 min read
State Machine Origami
Blog Custom tools

State Machine Origami

How Franca IDL and itemis CREATE can be integrated to validate embedded software components against interface contracts interactively during development.

Read Article
Dr. Klaus Birken Dr. Klaus Birken 9 min read
Automatic Generation of a Design-FMEA – Whitepaper
Whitepapers Functional safety

Automatic Generation of a Design-FMEA

A design FMEA is mandatory under ISO 26262 — and expensive to create and maintain by hand. This whitepaper shows how the algorithmic nature of the FMEA method enables full automation from existing engineering work products.

Download Whitepaper
References

From practice