Boomi Licensing & Editions for Pre-Sales

The Core Levers of Boomi Pricing

Unlike some platforms that primarily use a compute-based model (like MuleSoft's vCores), Boomi's pricing is a more modular, consumption-based model. It's designed to scale with a customer's needs, from simple point-to-point integrations to a comprehensive, enterprise-wide connectivity fabric.

To effectively architect and position a Boomi solution, you need to understand four primary levers that influence the final subscription cost.

As the reading highlights, the cost of a Boomi subscription is primarily determined by:

1. Number of Connectors/Endpoints: This is the most fundamental metric in Boomi's licensing. A license grants the right to connect to a certain number of unique application endpoints (e.g., one Salesforce org, one SAP instance). The more systems you need to integrate, the higher the license tier.
2. Product Modules Chosen: The Boomi platform is a suite of services. The core Integration service is the foundation, but customers can add other capabilities.

As we'll see, modules like API Management, Master Data Hub, and B2B/EDI Management are often licensed based on their own specific metrics (e.g., API traffic, number of trading partners).

3. Deployment Model: The choice of runtime architecture—a single Atom, a clustered Molecule for high availability, or using the Boomi Atom Cloud—directly impacts licensing and cost. Higher-tier editions are required to enable on-premise clustering (Molecules).
4. Add-ons & Support Levels: Advanced features like enhanced security, compliance capabilities, and premium support tiers are also factored into the overall cost.

Your experience with AWS, where costs are granularly tied to usage (EC2 instances, S3 storage, data transfer), provides a good parallel. Boomi applies a similar "pay for what you use" philosophy, but the primary unit of consumption is the connection rather than raw compute power.

Understanding the Integration Editions

With the pricing levers in mind, let's look at how Boomi bundles these capabilities into its subscription tiers, known as Integration Editions. The official documentation provides the most accurate breakdown of what is included in each tier.

Let's distill that detailed table into key architectural considerations for a pre-sales discussion.

Tier Breakdown and Typical Use Cases

As an architect, your job during discovery is to map customer requirements to these tiers. A question like "Do you require failover and load balancing for your on-premise integrations?" directly translates to "Do you need the Enterprise edition to support a Molecule?"

Key Feature Differentiators

• Connectors: The number of included Production and Test connectors is the most obvious differentiator. Note the distinction between Standard and Enterprise connectors (e.g., SAP, Oracle E-Business Suite), which are often unlocked or included only in higher tiers.
• Runtime & Scalability:
  • Runtime clusters: This feature, which enables Molecules, is typically available as a paid add-on in Pro tiers but is included in Enterprise editions. This is a crucial distinction for any HA/DR conversation.
  • Atom Workers: These provide additional parallel processing threads within the Boomi Public Cloud. The number included increases with the edition.
  • Parallel Processing: The Flow Control shape, which allows for advanced parallel execution management, is only available from Professional edition upwards.
• Advanced Integration Patterns:
  • Services Enablement: The ability to expose integration processes as web services (the foundation of Boomi's API Management) is not available in the Base edition.
  • Message Queuing: Native, brokerless queuing for event-driven patterns is generally an Enterprise-level feature.

Licensing Other Platform Services

Beyond core integration, Boomi licenses its other major services based on metrics relevant to their function. This is important when designing a solution that goes beyond simple A-to-B process automation.

As the table shows, when a customer wants to add other capabilities, the cost model expands:

• API Management: Priced based on API traffic (number of calls). This is very similar to how AWS API Gateway or Kong pricing works.
• Master Data Hub (MDH): Priced based on the volume of data being managed (e.g., number of golden records).
• B2B/EDI Management: Priced based on the volume of transactions and/or the number of trading partners.
• Flow: Priced based on usage and complexity, often by the number of "runs" of a Flow.

In a pre-sales context, you would start by sizing the core integration needs to determine the base edition, and then add the costs for these other modules based on the specific requirements of the solution.

Comparative Positioning Against MuleSoft

Given your background, one of the most useful things to understand is how Boomi's licensing philosophy compares to that of MuleSoft. This is a common pre-sales question.

The fundamental difference is Connector-based vs. Core-based licensing.

• Boomi's model is primarily about the breadth of connectivity. The main cost driver is how many different systems you are connecting to.
• MuleSoft's model is primarily about the volume of processing. The main cost driver is how much compute capacity (vCores) you allocate to run your APIs and integrations.

This leads to different TCO arguments:

• Boomi's value proposition is often stronger for organizations that have many systems to connect but where individual transaction volumes are not extreme. The low-code platform also promises a lower TCO through reduced development and maintenance costs, requiring less specialized (and expensive) developers.
• MuleSoft's value proposition can be more compelling for organizations building a high-volume, performance-intensive API network where the cost is tied to the processing power required, and they have the skilled development teams to leverage its more code-intensive framework.

The FAQ in the Sage IT article directly addresses this.

Conclusion

In this lesson, we've deconstructed Boomi's commercial model to prepare you for solution design and pre-sales conversations. You now have a framework for analyzing customer requirements and mapping them to the appropriate Boomi edition and modules.

Key Takeaways:

• Boomi's pricing is driven by four main levers: number of connectors, product modules, deployment model, and support tier.
• The core Integration Editions (Base, Professional, Pro Plus, Enterprise) are bundles of capabilities that scale with customer maturity.
• Architectural requirements like High Availability (Molecules), advanced security, and native message queuing are key differentiators for higher tiers like Enterprise.
• Unlike MuleSoft's core-based model, Boomi's connector-based licensing focuses on the number of connected endpoints, leading to a different TCO calculation that often favors Boomi in scenarios with broad but less volume-intensive integration needs.

Now that we've covered the platform's services, UI, and licensing, we are ready to dive deeper into the technical architecture. In the next lesson, we will explore the Boomi Atom in detail, understanding its role as the lightweight runtime engine and how it communicates with the AtomSphere platform—a critical piece of knowledge for any solution architect.