The Big Picture

the difference DCM makes to enterprise software landscape

On the example of a financial organisation running a (post) trade processing business

A financial institution (a bank) that runs a trade processing business usually has the following functional areas to deal with :

  • Position administration

  • Account administration

  • Trading (market access, etc)

  • Settlement

  • Custody

  • Borrowing and Lending (BnL)

  • Corporate Actions processing (CA)

  • Reporting (regulatory and to clients)

  • Fees

  • and more (tax, etc)

The Traditional way

The traditional way of implementing a software system for such an institution is to buy or build separate stand-alone systems for each functional area and then try to integrate them to make everything work together. This is an example of cutting the whole into pieces and attempting to connect the pieces to function as a whole—a Humpty Dumpty problem.

Inevitably, this results in a lot of duplication—not just of code, but also of functionality—because there must be some overlap in functional areas for the systems to be glued together, such as each having its own accounting system. Functional components that are represented multiple times across different systems will end up constituting their own realities, which then need to be reconciled across systems to maintain alignment and avoid internally conflicting facts (the “split-brain” problem)..

Furthermore, each system comes with its own specific encoding of the same shared concepts, where one encoding has one set of constraints and another has its own, resulting in yet more purely technical limitations imposed on the business as a whole.

with DCM

A more efficient approach is to recognize that all these functional areas share the same conceptual core—the same foundation—which can be defined directly in DCM. Then, all these functions can be expressed in terms of this shared core, at the same conceptual level, without reducing them to programming language encodings that lose their semantics.

Having this shared core removes much of the overhead associated with replicating the implementation of that core in each system (the “split-brain” problem). Most of the logic that these systems would need to incorporate if built in isolation can instead be inferred via natural semantics; it does not need to be “programmed manually” at all—just as pixels on a screen are inferred from the rules of geometry when drawing a circle from its formula.

Thus, a far more efficient way to solve these problems is to follow this natural path: to build solutions “on the same shared foundation.”

This is what DCM is aiming at.

Note that the transition from a traditional heterogeneous landscape to a DCM-based landscape can happen incrementally: first by building the core, and then by replacing legacy component systems with their DCM counterparts.

Each time, the legacy system is “sucked in” or subsumed by a set of frames added to the DCM code base. In most cases, much of the subsumed content will already exist within the DCM code base—for example, once the notion of Trade is defined, it becomes directly usable across all business functions, simply because its semantics are preserved and no technical noise is introduced.

Each such transition reveals how much of the legacy software has no real meaning in the business domain. As a result, the transition is size-compressing—the DCM code will be orders of magnitude smaller than the PL code of the decommissioned component.

With DCM, your business software becomes radically smaller and simpler.

The result: a system that’s lighter, more reliable, easier to govern, and instantly adaptable to change.

The size of a DCM solution will be orders of magnitude smaller because its code operates at the level of business description itself, preserving semantics and leveraging the large inferential potential of deep models. This drastic reduction in the size of the software that implements business logic across all functional areas (the software that actually runs the business) makes the business itself far more reliable, governable, agile, and adaptable to changes or new challenges.