Building Blocks
In this course you will learn about the building blocks (baselines, profiles, recipes) that IBM DevOps Solution Workbench is built on and how they work together in the Workbench.
Outline
Every project in IBM DevOps Solution Workbench starts from a Baseline - a complete configuration package that combines the modeling vocabulary with the patterns for turning model items into code. That combination of building blocks is what makes AI coding assistants scalable across the enterprise, and it enables design-driven development in a single integrated workflow.
First an overview of the building blocks:
- Open Modeling Language (OML) defines what can be modeled in projects. OML uses modeling configurations composed of versioned, shareable OML profiles.
- OML Profiles are a cohesive set of vocabulary for specific domains, e.g., C4, DDD, Event Storming. Each profile defines element types, relationship types, and properties.
- Design Recipes bundle skills (specialized expertise you give the Design Assistant) and commands (shortcuts into the chat) that reflect your terminology, workflow, and typical design tasks.
- Coding Assistant Recipes define the implementation guidance including coding guidelines, technology definitions, implementation patterns, commands, and workflows.
- Project Baselines package complete modeling environment for projects, including OML configurations, system definitions, Coding Assistant recipes, Design recipes, and documentation.
You can learn more details about the building blocks from the Product Documentation: Building Blocks
Design-Driven Development with the Workbench
The Workbench enables design-driven development through an integrated workflow that transforms architectural intent into machine-readable specifications, powering AI-assisted delivery.
Project Baselines
In the middle of this development are project baselines. They package modeling vocabulary, a set of OML profiles, and recipes, providing support for coding assistants and AI-assisted architectural design. Baselines serve as a starting point for projects, which are containers with the entire design, modeling and implementation of an organizational unit, representing e.g. a microservice, a frontend application, an architectural design, or a complete system composition.
OML Profiles
The Open Modeling Language (OML) is the meta-model behind modeling profiles: it defines how a modeling vocabulary is described — the element types, relationship types, properties, and validations a profile may contain — so that every profile, shipped with the Workbench or create on your own, is expressed in the same structured, type-safe way.
An OML Profile is therefore a versioned, shareable vocabulary for one modeling approach. Each one supplies the element types (e.g., c4.container, ddd.aggregate), relationship types (e.g., uses, contains), property groups, text templates, status enumerations, the link types for external resources (documentation, repository, issue-tracker, …), the organizational roles (owner, watcher, participant), and validations for that approach. With the Workbench shipped profiles cover C4, Domain-Driven Design, Implementation Design, Basic Shapes, Basic Collaboration, Risks & Tech Debt, Event Storming, and Architecture Principles — use them as-is, copy and customize them, or write your own from scratch.
To learn more about creating custom OML Profiles please refer to How-To: Create and edit customer OML Profiles.
The OML configuration inside a baseline
A baseline's OML configuration lists which profiles it includes — one or more, each pinned to a version — and defines the set of layers (business, application, data, knowledge, …) that apply across all of them. This makes the configuration the single source of truth for which vocabulary the baseline speaks.
Coding Assistant Recipes
Recipes govern the coding assistant working in the coding environment on the generated project repository - they are the rules, patterns, and shortcuts that shape how code is produced when implementation is generated from the model. They can be included in baselines and are copied into project repositories on project creation. They consist of skills, commands, and rules that help guide implementation and enforce standards in the coding environment.
To learn how to create your own recipes please refer to How-To: Use Custom Recipes and Baselines for Code Generation.
Commands and rules prefixed with k5- will be automatically managed by the workbench, ensuring they stay synchronized with baseline updates.
For further information on the topic visit Product Documentation: Coding Assistant Recipes.
Design Recipes
Design Recipes tailor the Design Assistant - the natural-language chat built into the Workbench that you use to explore and change your model itself, before any code exists. They bundle skills (specialized expertise for the assistant) and commands (shortcuts that pre-fill a prompt) that reflect your terminology and typical design tasks, so the assistant can do more on your behalf with less repetitive prompting. Unlike Coding Assistant Recipes, Design Recipes never reach the generated code or project repository at all - they exist purely to configure how the Design Assistant behaves while you work on the model in the Workbench.
To learn how to create your own Design Recipes please refer to How-To: Create custom Design Recipes.
For more information on the topic visit Product Documentation: Design Recipes.
Although not a Building Block, the possibility to connect with external systems via MCP server should nevertheless be mentioned. With this it is possible to connect to external systems and give the Design Assistant access to further context information, e.g., from your issue tracking tool, enterprise knowledge systems etc.
For further information see Product Documentation - MCP support.
Baseline Lifecycle
Baselines are distributed as ZIP archives and follow a dedicated lifecycle:
- draft: under development, can be modified and re-uploaded
- published: released, immutable, available for project creation
- deprecated: no longer recommended, still available for existing projects
System baselines ship with the Workbench and serve as starters and examples. They can be downloaded, customized, and evolved into organization-specific versions - see Product Documentation: Customization for details. Currently published:
| Baseline | Purpose |
|---|---|
| architecture | Architecture & design visualization with C4 |
| java-basic-springboot | Basic service with Java/Spring Boot |
| java-ddd-springboot | Domain service with Java/Spring Boot (DDD) |
| java-int-springboot | Integration service with Java/Spring Boot |
| node-bff-nestjs | Backend for Frontend with Node/NestJS |
| node-int-nestjs | Integration service with Node/NestJS |
What happens on project creation
- The system creates the repository in Git
- Commits the Coding Assistant recipes (skills, commands, rules) from the selected baseline
- Places the README.md at the project root
- References the baseline in the project's k5-project.yaml
Projects move to newer baseline versions through assisted upgrades.
Want to go further? Continue with Navigating Workbench to learn about how to find your way within Workbench.