Ensemble-Modeling-vs-Business-Oriented-Data-Modeling-Two-Paths-to-Better-Data-Models
How Ensemble Modeling and Alec Sharp’s Business-Oriented Data Modeling differ, and why combining them may be the key to resilient and business-friendly data practices.
Summary
Ensemble Modeling (ELM) and Business-Oriented Data Modeling (BODM) are two influential approaches to building logical data models.
Ensemble Modeling emphasizes agility, decomposition, and alignment with implementation patterns like Data Vault or Anchor Modeling, while Alec Sharp’s Business-Oriented Data Modeling highlights clarity, communication, and business stakeholder engagement. This article explores the principles of both, their differences, and how they can complement each other.
What Is Ensemble Modeling?
Ensemble Modeling, or the Ensemble Logical Model (ELM), is an approach developed by Hans Hultgren. At its heart, it is a business-driven, pattern-aware method for logical modeling that aims to balance semantic clarity with technical adaptability.
Key elements of Ensemble Modeling include:
- Core Business Concepts (CBCs): Identifying fundamental, stable entities like Customer, Product, or Policy.
- Natural Business Relationships (NBRs): Mapping out the inherent relationships between those concepts, often captured directly from business conversations.
- Unified Decomposition™: Breaking concepts into modular components (concepts, relationships, events) so they can evolve independently without breaking the larger model.
- Business Workshops: Using collaborative sessions to capture definitions, terms, and relationships in a way that engages business stakeholders.
- Implementation Readiness: Logical models created via ELM can be mapped to physical ensemble patterns such as Data Vault, Anchor Modeling, or Focal Point, enabling historization, flexibility, and scalability.
In short: Ensemble Modeling is designed for change and longevity. It builds models that can withstand evolving requirements while maintaining semantic integrity.
What Is Business-Oriented Data Modeling?
By contrast, Business-Oriented Data Modeling (BODM) is a method popularized by Alec Sharp. It treats data modeling first and foremost as a business communication tool, rather than a technical artifact.
Some of its hallmarks include:
- Business-Friendly Diagrams: Creating models that business people can understand, avoiding excessive normalization or technical jargon.
- Shared Vocabulary: Emphasizing definitions and clarity of terms, ensuring the model truly reflects the business.
- Workshops & Facilitation: Using collaborative techniques to align IT and business stakeholders.
- Focus on Usability: Models are designed to clarify requirements, communicate scope, and support decision-making — rather than to prescribe physical implementation patterns.
In essence: Business-Oriented Data Modeling is about alignment, understanding, and communication.
Comparing the Two Approaches
While both approaches value business engagement, their focus and outcomes differ.
When to Use Which?
- Use Ensemble Modeling when you need long-term resilience in your data architecture, and when you know you’ll be implementing in patterns like Data Vault or Anchor Modeling. It is particularly valuable in environments where business requirements change frequently.
- Use Business-Oriented Data Modeling when the priority is engagement, clarity, and alignment with stakeholders — especially at the start of an initiative or when working with diverse audiences who need to understand the big picture.
Why Not Both?
These approaches are not mutually exclusive. In fact, combining them can give you the best of both worlds:
- Start with Business-Oriented Data Modeling to establish a clear, shared understanding of business concepts, terms, and scope.
- Transition into Ensemble Modeling to decompose and structure those concepts in a way that can scale into robust physical implementations.
By layering Sharp’s communicative style on top of Hultgrens’ pattern-driven methodology, you can create models that both resonate with business users and stand the test of time in implementation.
Closing Thoughts
Ensemble Modeling and Business-Oriented Data Modeling may appear to aim at different goals — one toward technical adaptability, the other toward business clarity. But in practice, they are two sides of the same coin.
Together, they remind us that data modeling is not just about diagrams and databases. It’s about people, concepts, and the ability to adapt to change. Whether you are designing the next data platform or running a business workshop, blending these approaches can help you deliver models that are understandable, adaptable, and genuinely useful.
✨ In a future article, I’ll dive deeper into how Steve Hoberman’s Data Model Scorecard can be used alongside Ensemble Modeling and Business-Oriented Data Modeling — giving us an objective way to assess quality as we integrate these practices.