Hi all, I know I’m joining this discussion a bit late, but I wanted to share some thoughts based on my experience speaking with various enterprise teams.
Today, most organizations follow a *best-of-breed architecture* rather than relying on one monolithic system to handle all business processes end-to-end. In nearly every enterprise I’ve interacted with, the technology landscape looks more like this: - A separate platform for *eCommerce* - A separate system for *PIM* - A dedicated *OMS* - A dedicated *WMS* - A financial system - Often additional tools for marketing, CRM, etc. Very few organizations adopt Apache OFBiz as a single unified solution for all these areas. Instead, they evaluate Apache OFBiz for *one specific domain*—for example only PIM, or only WMS, or only OMS. This is where one of the biggest challenges appears: Even if a company wants to use Apache OFBiz only for PIM (Catalog Manager), they still see hundreds of tables belonging to WMS, Accounting, Manufacturing, etc. The same issue arises in the reverse direction. This creates confusion and gives the impression of unnecessary complexity. Many tech teams get overwhelmed the moment they encounter 750+ tables, even when they only need a small subset. Additionally, enterprise engineering teams increasingly want *modular systems with independent development lifecycles*. Even if an organization wants both PIM *and* WMS from Apache OFBiz, they do *not* want them as one monolithic deployment. They prefer: 1. Separate microservices 2. Separate codebases 3. Separate release pipelines 4. Separate deployment cycles 5. Separate teams working independently This independence gives them agility, reduces coupling, and aligns with how modern engineering organizations operate.Because of these real-world expectations, the idea of restructuring Apache OFBiz into: 1. A lightweight core framework, and 2. Independent business applications packaged as separate plugins or microservices makes a lot of sense. Under such a model: *Each application/plugin can represent a microservice boundary* 1. Self-contained functionality 2. Clear domain ownership 3.Smaller, independent codebases *Each plugin can have its own DB schema or DB subset* 1. Schema isolation 2. Easier upgrades 3. Easier domain-driven design 4. Ability to scale components independently *Deployment becomes API-driven rather than monolithic* 1. Each application exposes its own APIs 2. Can be deployed independently 3. Can evolve at different speeds 4. Aligns with enterprise microservice best practices This approach would naturally position Apache OFBiz toward *MACH-compliant architecture* (Microservices-based, API-first, Cloud-native, Headless). Many CIOs and enterprise architects explicitly look for MACH principles when evaluating modern platforms. A MACH-aligned Apache OFBiz would open doors to new categories of adopters. I believe this evolution could unlock a much broader audience for Apache OFBiz. Regards -- Divesh Dutta On Thu, Oct 23, 2025 at 5:34 PM Deepak Dixit <[email protected]> wrote: > Hi Team, > > I would like to propose restructuring the OFBiz architecture by moving core > applications out of the main OFBiz framework — similar to how plugins are > currently managed. > > This change would enable developers to build *custom ERP solutions* without > being tied to all the default applications and their associated 750+ > database tables. By decoupling applications from the framework, we can > provide a lighter and more modular foundation for building domain-specific > or microservice-based solutions. > > I strongly believe this approach will *significantly increase OFBiz > adoption* and flexibility, allowing users to leverage the framework purely > as an enterprise-grade development platform rather than being constrained > by bundled modules. > > > Thanks & Regards > > -- > > Deepak Dixit >
