[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"article-body-twelve-problems-not-thirty-modules":3},"\nHere is the quiet economics of enterprise software. Every vendor\nsolves the same hard problems dozens of times, and every customer\npays for every repetition. The repetition is where the cost, the\ninconsistency and the duplicated effort come from, and it is\ninvisible because the repeats wear different departmental costumes.\n\nWatch it happen. A trade compliance analyst traces an ownership\nchain, asking whether a sanctioned party controls this counterparty\nthrough stakes stacked three layers deep. An internal auditor maps\nintercompany exposure. An ethics officer checks a third party's\nbeneficial owners. A supply chain manager asks who actually sits\nbehind a struggling supplier.\n\nFour job titles, four software categories, four budgets, four\nvendor relationships. One underlying problem. Trace who owns whom,\nlayer by layer, and decide when indirect control matters. Each of\nthose four tools solved it separately, to a different standard, and\nthe customer paid four times for three redundant solutions.\n\n## The dozen problems wearing thirty costumes\n\nRun the exercise across an enterprise and the pattern generalises.\nSuperficially unrelated functions keep resolving to a short list of\nrecurring problems. Is this supplier, this counterparty and this\nhotline subject the same real-world thing? Which procedures does\nthis regulation change touch? Is this expense, this override, this\nsensor reading unusual? Which of these thousand alerts deserves an\nanalyst? What will this number be next quarter, and why did it move?\n\nAcross the thirty-odd modules of a full enterprise suite, we count\nroughly a dozen problem classes doing almost all of the real work\n(e.g. entity resolution, ownership tracing, anomaly detection,\nclassification, change-to-document conformance and alert triage).\nAlmost all of them recur in more than one function. Conventional\nsuites rebuild each one per module, because software is organised\nthe way buyers are organised, by function, and no mechanism lets\nthe audit module's anomaly detection benefit from what the finance\nmodule learnt.\n\n## The economics of building them once\n\nInvert the organisation, build the problem classes once as engine\ncapabilities and let each function configure them with its own\nvocabulary, and the economics change in three compounding ways.\n\n1. **The second module costs less than the first.** Its hard\n   problems arrive already solved, needing configuration rather\n   than construction, and the discount grows with every module\n   added.\n2. **Improvements propagate instead of repeating.** Sharpen\n   ownership tracing for the trade module and the audit, ethics\n   and supplier modules inherit the sharpening the same day. Tune\n   anomaly detection against the hardest consumer and every other\n   consumer gets the improvement free.\n3. **Quality converges upward.** Each problem class is maintained\n   to the standard of its most demanding consumer, not the budget\n   of its weakest one. In a per-module world, quality converges on\n   whatever each team could afford.\n\nA module, on this architecture, is a vocabulary and a set of\ndecisions, not a codebase. The engine has no domain vocabulary at\nall.\n\n## The test a buyer can run\n\nThe claim is checkable from outside. Ask a suite vendor what\nhappened in their audit module when their screening module improved\nits entity resolution. If the honest answer is nothing, the suite\nis thirty products sharing a login page, and you are paying for\nevery one of those separate ceilings.\n\nAsk the same question of a problem-organised platform and the\nanswer is a release note. The improvement landed everywhere the\nproblem class is used, because there is only one of it.\n\nThis architecture is why Prophesee exists in the shape it does. A\ndomain-agnostic engine holds\n[the dozen problem classes](/insights/enterprise-software-has-about-twelve-problems),\neach\nmodule configures them through vocabulary rather than code, and\nevery decision one team wires up makes the next one cheaper to\nwire. See the flywheel on your own functions.\n[Start here](/contact).\n",1786984937924]