Composable ERP has become one of the most overused phrases in enterprise software, but in practice only a small subset of organizations are truly ready to pursue it as a strategic path rather than a slideware vision. The difference rarely starts with technology choices; it shows up in architecture discipline and governance habits long before the first “composable” pilot goes live.
In this Q&A, Sanjay Vijay Mhaskey, lead principal consultant for eOne Infotech LLC, expands on his previous article by discussing how to looks for specific signals in how CIOs manage APIs, data, security and integration patterns that separate aspirational talk from executable strategy and whether composability will reduce complexity or quietly amplify it.
Question: In your client work, what early architectural or governance signals tell you an organization is genuinely ready to pursue composable ERP strategically?
Sanjay Vijay Mhaskey: Early signals of readiness for composable ERP include established architectural governance, design principles for loose coupling, API and data model standards, integration patterns, and service registry mechanisms. Organizations also show clear strategic alignment, strong monitoring frameworks, and a unified security model with role-based access control. These elements demonstrate maturity in managing modular, interoperable systems crucial for successful implementation.
Q: How do you help executives distinguish healthy incremental modernization from dangerous “accidental composability” that increases fragmentation and operational risk?
SVM: The difference lies in intentionality and governance. Healthy modernization follows a deliberate architecture, with each addition meeting a standard. Accidental composability occurs when units adopt tools independently without enforced APIs or data governance. I would advise executives to audit their landscape: if components can’t communicate via governed interfaces or data ownership is unclear, they accrue technical debt rather than build composability. The key question: Does architecture lead or follow?
Q: What practical steps can CIOs take in the first 12 to 18 months to build API and data standards without stalling business innovation?
SVM: Start with an API style guide and enforce it on all new integrations — don’t retrofit legacy systems immediately. Appoint a master data owner per domain within the first 90 days. Run two or three “composable pilots” on high-friction areas like demand planning or warehouse management, using these as governance proving grounds. The key principle: standards should allow speed, not prevent it. Governance that hinders innovation loses support and quietly fades away.
Q: Where do you typically see the first governance breakdowns in composable ERP programs, and how can organizations preemptively design around those failure points?
SVM: The first breakdown is almost always master data — multiple modules claiming ownership of the same supplier or product record. Second is API versioning discipline; teams deprecate without notice, breaking downstream consumers. Third is the fragmentation of security models across components from different vendors. The preemptive design answer: establish data domain ownership before the first module goes live, mandate semantic versioning contractually and implement a unified identity layer early.
Q: How should ERP and supply chain leaders prioritize which modules to modernize first when balancing business value, technical risk, and organizational readiness?
SVM: Prioritize areas where monolithic constraints cause significant business friction, where clean API boundaries reduce extraction risk, and where the team has proven integration capability. Typically, demand planning, warehouse management, and transportation surface first due to high value and bounded scope. Finance and procurement follow, given their transactional risk and organizational dependencies. The sequence is influenced more by organizational readiness than purely technical factors.
Q: What organizational capability gaps around APIs, microservices and integration design most frequently stall programs, and how can leaders systematically close those gaps?
SVM: The critical gap isn’t technical — it’s architectural judgment. Teams deploy APIs but can’t design them for longevity. Microservices are built without domain-boundary discipline, creating distributed monoliths. Integration gets treated as plumbing, not strategy. Three fixes: embed integration architects — not just developers — early; establish internal API design standards with peer review; Run composability pilots that intentionally develop organizational strength alongside technical implementation. Capability and architecture should evolve together.
Q: How can companies realistically assess whether their AI ambitions align with their current ERP architecture maturity, especially in heavily customized legacy environments?
SVM: The diagnostic is straightforward: can your ERP expose clean data through governed APIs without manual extraction? If not, AI ambitions outpace architectural reality. In heavily customized legacy environments, customizations often block clean API surfaces, making AI integration at best a decision-support layer that consumes exported data — not embedded intelligence. The honest assessment framework: map AI use cases against architectural maturity tiers—monolithic, API-layered, or microservices-based. AI readiness and composable ERP readiness are the same question.
Q: In your experience, what metrics or KPIs best capture “controlled adaptability” as organizations move from monolithic ERP towards more composable architectures?
SVM: Key KPIs for measuring “controlled adaptability” in the shift to composable ERP include deployment frequency, time to implement new capabilities, and integration cycle time, which reflect agility. System stability metrics such as change failure rate and mean time to recovery (MTTR) capture control. Organizations should also track module reuse rate, API adoption, and percentage of decoupled services, indicating modularity and interoperability—core characteristics enabling scalable, flexible ERP modernization without disrupting core operations.
Q: How do you advise CIOs to negotiate and structure vendor relationships to reduce new forms of lock-in around integration platforms and cloud providers?
SVM: Composable architecture shifts lock-in from ERP vendors to integration platforms and cloud providers — risk migrates, not disappears. Three principles: contractually mandate open API standards and data portability clauses before signing; architect integration layers using vendor-neutral standards to reduce switching costs; regularly audit provider dependency — if one vendor controls more than 40% of your integration fabric, concentration risk is real. Scrutinize your integration layer with the same rigor as the ERP itself.
Q: Looking five years ahead, how do you expect the balance between ERP core stability and edge innovation to evolve in large enterprises?
SVM: The ERP core will stay stable in functional scope but gain strategic importance as the transactional backbone and record keeper, amid a growing ecosystem of modular, AI-driven layers. Edge innovation will surge with mature low-code tools and API marketplaces. Governance challenges will increase. In five years, competitive edge won’t stem from ERP choices but from how quickly and intentionally organizations orchestrate surrounding capabilities.
