Research Cases
INSODEMA does not only investigate systems used by other organisations. Its own ecosystem is a research environment. It shows which capabilities we deliberately build, which remain external, which are integrated and which questions are still being researched.
This page does not document a finished universal answer. It presents selected evidence from an ongoing research process with different maturity levels and deliberately different dependency decisions.
Internal Research Case
How much of a typical operational SaaS landscape does an organisation actually need — and what changes when the required parts of several products can be brought together in a controlled architecture?
DOS did not begin with the goal of building “an ERP” or “a platform”. It grew from recurring operational needs: steering projects, tracing decisions, controlling approvals, managing contacts and organisations consistently, connecting technical systems, handling commercial processes, controlling access and bringing information across products together.
Many of these capabilities are traditionally sourced through separate SaaS products. DOS investigates which parts INSODEMA actually needs, which belong together in its own architecture and which specialised external systems should deliberately remain.
The result is not a thesis that building in-house is always better. The evidence lies in the ability to assess dependencies individually and make different decisions.
System Sovereignty is not the absence of dependencies. It is the ability to choose them deliberately.
Research in Practice
Not everything in the INSODEMA ecosystem has the same maturity. Some capabilities are already in use while others remain active research or development. Those differences remain visible rather than being flattened into one product presentation.
Operational and Active Research describe different evidence and maturity states — not different quality standards.
Operational Evidence
The following examples are capabilities already used within the INSODEMA ecosystem or backed by a meaningful operational foundation. They are evidence, not instructions for every organisation to make the same decision.
DOS brings organisations, people, contacts and communication context into one authority, including structured public contact requests and shared communication context.
Rather than operating isolated tools for contact management, forms and communication context, DOS investigates which required capabilities make more sense in one controlled model.
Decision: Build / Integrate
Projects, modules, releases, decisions, trackers, repositories and product handoffs are managed in DOS within a shared context.
The research value is not rebuilding every project-management or issue-tracking product. It is identifying the parts actually needed and whether a shared authority creates more value than isolated interfaces.
Decision: Build
DOS brings operational decisions, approvals, reviews and cross-product handoffs into a shared control context.
These capabilities overlap with task, approval, portfolio and management tools without attempting to copy any one of them completely.
Decision: Build
Product catalogue, pricing, subscriptions, invoice logic, payment allocation and commercial master data are controlled inside DOS, while external accounting is not broadly replaced.
INSODEMA builds the commercial capabilities it actually needs and retains a controlled DATEV-oriented transition into external accounting as an integration path.
Decision: Build + Integrate
INSODEMA needed a central analytics capability for websites and public web surfaces. Its actual scope was narrower than large external analytics platforms and could be defined more deliberately inside its own governance.
Analytics shows that an external platform may be technically available without automatically being the most appropriate authority for the data and rules actually required.
Decision: Build
OPS needs specialised place, mapping and routing capabilities. That dependency is not replaced merely because INSODEMA builds other capabilities itself.
Where external infrastructure provides specialised value reliably and integration creates more value than rebuilding it, retaining the dependency can be the more sovereign decision.
Decision: Retain / Integrate
ATLAS provides a shared geography and address authority for INSODEMA systems. Country, postal-area, locality and street context can therefore be structured more consistently and reused across system boundaries.
Address identity and spatial context do not need to be reinvented in every product. Reusable operational areas and shared geographic references are part of that direction.
Decision: Build + Integrate / Reuse
Active Research
Some of the most interesting INSODEMA questions are deliberately still under active development. They are shown as research directions, not finished universal answers.
NEXUS is the central knowledge, context and connection layer of the INSODEMA ecosystem. It is intended to relate approved information, detect patterns and inconsistencies, mark hypotheses, revisit earlier findings and pursue research paths within defined boundaries.
Research focus: The research focus is an architecture in which AI can explain and assist without automatically taking operational or strategic authority.
Decision: Build / provider-neutral / policy-controlled AI
Sentinel investigates which fundamental capabilities for infrastructure observation, operational events and technical evidence are useful to keep under direct organisational control.
Research focus: The research value lies in deliberately separating owned observation capability from specialised external infrastructure or monitoring services.
Decision: Build + deliberate external infrastructure
ShopperMatch investigates activity, reachability, qualification, regional availability and Freshness rather than relying on registration counts alone. The research question is when a record still reflects operational reality and when it has become historical inventory.
Research focus: The focus is a data model that can distinguish currently usable capacity from historical inventory.
Decision: Build / continuously refreshed operational data model
Dependency Decisions
The examples above do not lead to a blanket “build everything” strategy. INSODEMA evaluates capabilities individually: some are built, some integrated, some retained, some replaced, and some kept interchangeable or policy-controlled.
Deterministic engine
Rules, states, scoring, permissions, workflows and domain logic can represent sophisticated operational intelligence while remaining testable, reproducible and auditable.
AI may explain a decision without owning the decision.
DOS invoicing capabilities are designed around the relevant invoicing and documentation requirements and are intended to remain connectable to external accounting / DATEV-oriented processes. This is not a certification or legal guarantee.
Research Partnerships
INSODEMA Research Cases therefore do not begin with a product decision. They begin with a real problem, a dependency, a system break or a question whose answer is not yet fixed.