Enterprise systems like a bank-in-a-box CBS are huge software systems & run for several decades. They face continuous change & over time become complex & expensive to maintain & run. They increase costs continuously and entail huge costs for change. Replacement is almost impossible and if attempted organizations and its end customers go thru a very difficult period. The reason is, systems do not have exit provisions at enterprise or module levels.
Entity Oriented Design provides an alternative approach.
Enterprise applications deal with & design entities & support life cycles of multiple entities. CBS has entities like individual customers, organizational customers, deposits, loans, bills, letter of credits, Guarantees, Payments, Transactions, etc.
In Entity Oriented Design, each entity is designed as a separate module with its own information model (database) and is completely loosely coupled with other entity modules. The only way Entities interact is by using service contracts between themselves. Each entity fully supports the life cycle requirements of the entity & operates independently. Each entity can be changed independently and can manage change by providing versions of services (new and old) to other entities and these entities can change gradually at their own pace to adopt changes. An Entity can be fully replaced, if existing services of the entities can be supported by the new module without any enterprise level risk for the organization.
Entity Oriented Design is different from Module Oriented design. Modules are not designed for entities and are mostly designed using functional accumulation or reuse. And Module Databases are not fully separated and sometimes other modules directly access the data of other modules. This is not allowed in fully separated Entity Oriented Design.
This approach provides for concurrent changes at multiple entity levels, reduces cost of change and provides for gradual exist at entity level. Entity units can also be deployed and run independently, making them ideal for cloud-based deployments. Entities that have higher loads can have higher number of entity service instances.
Further, each entity can be designed using aspect-oriented design. Entities can be designed with provision to bring in new aspects (with their own information model and services) to an entity. This aspect-oriented approach is much more sophisticated than the usual ‘n’ number of user defined fields provided for change in most of the products.
At Patterns we try to understand the shortcomings in our earlier designs and we continuously try to improve our banking software designs to increase value and reduce costs to our customers.
Dec
10
