|
PRINCIPLES OF ARCHITECTURE OF LOAN OBJECTS 1. Our vision of the structure of
a lending-to-individuals Information System
Domain |
Definition |
Examples |
1 |
What is not specific to the lending-to-individuals business line |
Workflow, word processing… |
2 |
What, although specific to the lending-to-individuals business line, can be shared by all banks |
Calculation of a loan repayment schedule |
3 |
What most banks would like to customize |
Loan granting rules |
4 |
Processes reading large amounts of data without updating them |
Bookkeeping, Basel 2 reporting, scorecards |
2. The contribution of LOAN OBJECTS to each domain
Domain |
Our vision of the right solution in the domain |
The contribution of LOAN OBJECTS to the
solution |
1 |
Off-the-peg software packages |
Nothing |
2 |
In-house developments |
LOAN OBJECTS itself (business design of
this domain) |
3 |
Manage this domain with a "Business Rules Management System" (BRMS) |
In LOAN OBJECTS, the components of this domain are clearly identified, and
their interface (input parameters...) is described |
4 |
Specific developments with "Business Intelligence" or query tools |
LOAN OBJECTS describes all data in this
domain, including data structures to be used by "accounting interpreters" software |
3.Conclusion
To build a complete information system on the basis of LOAN OBJECTS,
you still have :
To implement all components described in LOAN OBJECTS
To interface the application thus obtained to 1 or 2 non-specific software packages
(at least a “Workflow” or “Business Process Management” and a "Word processing" software)
To interface this application to a "Business Rules Management System"(or BRMS) tool
To implement a genuine “Data warehouse” derived from the data model of sub-domain 4
(in other words, to give these data the physical shape suited to use by reporting
tools)
|