|
Software Patent Abstract
Banking software application development includes defining a plurality
of banking object terms, each of these terms relating to components
of a banking relationship. Additionally, the software is developed
by defining a plurality of responsibility area terms, each of these
terms relating to banking activities, wherein each of the responsibility
area terms includes at least one of the banking object terms. From
the defined relationships, the software is developed by generating
a solution foundation for at least one of the responsibility area
terms by defining relationships between the plurality of business
object terms. Therefore, the banking software application is developed
based on the solution foundation.
Software Patent Claims
1. A method for banking software application development, the method
comprising:defining a plurality of banking object terms, each of
these terms relating to components of a banking relationship;defining
a plurality of responsibility area terms, each of these terms relating
to banking activities, wherein each of the responsibility area terms
includes at least one of the banking object terms; andgenerating
a solution foundation for at least one of the responsibility area
terms by defining relationships between the plurality of business
object terms such that banking software application is developed
based on the solution foundation.
2. The method of claim 1 further comprising:generating solution
foundations for each of the responsibility area terms by defining
relationships of the business objects terms; andgenerating an aggregate
relationship definition across the responsibility area terms.
3. The method of claim 2 further comprising:generating the solution
foundation based on the aggregate definition relationship.
4. The method of claim 1 further comprising:defining a plurality
of responsibility layers that relate to different responsibility
areas of the banking software application.
5. The method of claim 4 wherein the responsibility layers include
an infrastructure layer, a banking object layer, a process layer
and a user interface layer.
6. The method of claim 5 wherein the responsibility layers are
independent from each other and are accessible through at least
one independent interface.
7. The method of claim 1 wherein the responsibility areas include
customer sales and service area, an execution and operations area
and an analytics area.
8. The method of claim 1 wherein the step of generating the solution
foundation includes modeling the relationships to generate the solution
foundation and the step of assembling the banking software application
includes generating a runtime implementation of the modeled relationships.
9. An apparatus for generating a software development model for
a banking software application, the apparatus comprising:a memory
device having executable instructions stored therein; anddefine
a plurality of banking object terms, each of these terms relating
to components of a banking relationship;define a plurality of responsibility
area terms, each of these terms relating to banking activities,
wherein each of the responsibility area terms includes at least
one of the banking object terms; andgenerate a solution foundation
for at least one of the responsibility area terms by defining relationships
between the plurality of business object terms such that banking
software application is developed based on the solution foundation.
10. The apparatus of claim 9, the processing device, in response
to the executable instructions, is further operative to:generate
solution foundations for each of the responsibility area terms by
defining relationships of the business objects terms; andgenerate
an aggregate relationship definition across the responsibility area
terms.
11. The apparatus of claim 10, the processing device, in response
to the executable instructions, is further operative to:generate
the solution foundation based on the aggregate definition relationship.
12. The apparatus of claim 9, the processing device, in response
to the executable instructions, is further operative to:define a
plurality of responsibility layers that relate to different responsibility
areas of the banking software application.
13. The apparatus of claim 12 wherein the responsibility layers
include an infrastructure layer, a banking object layer, a process
layer and a user interface layer.
14. The apparatus of claim 13 wherein the layers are independent
from each other and are accessible through at least one independent
interface.
15. The apparatus of claim 9 wherein the responsibility areas include
customer sales and service area, an execution and operations area
and an analytics area.
16. The apparatus of claim 9 when the processing device is operative
to generate the solution foundation, the processing device is further
operative to model the relationships to generate the solution foundation
and when the processing device is operative to assemble the banking
software application, the processing device is further operative
to generate a runtime implementation of the modeled relationships.
17. A method for generating banking software application guidelines,
where the guidelines are used to generate a banking software application,
the method comprising:defining a plurality of responsibility layers,
including a banking object layer;defining a plurality of responsibility
areas for each of the responsibility layers;defining a plurality
of banking object terms in the banking object layer;defining relationships
between each of the plurality of banking object terms in the banking
object layer; andcomparing a banking application solution relative
to the defined relationships in the banking object layer to determine
the effectiveness of the banking software application.
18. The method of claim 17 further comprising:for each of the plurality
of responsibility layers, defining a plurality of banking object
terms and defining relationships between each of the plurality of
banking terms in each responsibility layer;generating an aggregate
model; andcomparing the banking application solution to the aggregate
model.
Software Patent Description
COPYRIGHT NOTICE
[0001]A portion of the disclosure of this patent document contains
material that is subject to copyright protection. The copyright
owner has no objection-to the facsimile reproduction by anyone of
the patent document or patent disclosure as it appears in the Patent
and Trademark Office patent file or records, but otherwise reserves
all copyright rights whatsoever.
BACKGROUND
[0002]The present invention relates generally to processing and
data routine developments for a software application and more specifically
to modeling and defining functional relationships in designing and
developing banking related software applications.
[0003]Software applications can be developed in many different
techniques. One such technique is to use a modeling technique to
define the underlying guidelines. Modeling techniques provide for
the initial definition of various components of the problems to
be solved. From these definitions, interrelations between the components
define a framework. These guidelines then, through the framework,
provide the for the software encoding, where the encoded software
attempts to embody the modeled features. This general technique
allows for the development of various types of software applications
based on the underlying modeling operations.
[0004]One such area for software development relates to banking
software applications. The banking applications include features
directed to one or more of the various aspects of the banking business,
such as but not limited to front end user interfacing, mid-level
processing applications, back end financial transactions, among
others. In existing techniques for the development of software applications
relating to banking, modeling techniques have a very fine level
of granularity. As the banking application includes numerous levels
of applications, the application and underlying modeling technique
provides for many various levels of solutions to specific components
or elements of the banking transactions.
[0005]For example, one area of a banking software application may
include transactions relating to customer interface with an online
or Internet-based banking access portal. The existing modeling techniques
provide strategic and specific guidelines for solutions relating
to this business activity. In some modeling techniques, the model
may include specifically related aspects, such as back-end interface
between the portal itself and the resident banking system. But,
the modeling technique is very limited to this specific activity
and therefore does not and cannot address concerns beyond the matter
at hand, such as issues that might arise with a transaction closing
portion of the banking application, for example.
[0006]The existing modeling technique is a very static solution
offering limited flexibility. Another shortcoming of the existing
modeling technique is the requirement of the model to be a time
specific view of the banking application. Consistent with the static
shortcoming of existing techniques, the modeling application requires
the predefinition of a specific scenario and thus models a framework
from that scenario. Based on the fine granularity level of the model,
all extraneous components of the application need to be statically
defined. This "snap in time" model requires developers
to define how an application or banking scenario would look and
then define the model around this definition. This static technique
provides a short-sighted solution to an individually defined component
but fails to provide a framework model for the full banking software
application.
[0007]Additionally, this technique requires multiple modeling operations
to each individual component to create the full the framework. This
technique can be very cumbersome and prone to errors. As each component
is individually modeled, this requires not only a large amount of
individual computation, but a large degree of static definitions
for modeling terms and significant amounts of integration to generate
a final framework. Additionally, any minor adjustments to the multiple
models can have a significant negative effect on other related and
un-related models as this may change predefined terms of these other
modeling operations. Therefore, the existing technique is difficult
to use to develop a full banking software application and does not
lend itself to a dynamic modeling approach based on the fine level
granularity used to model individual components.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008]FIG. 1 illustrates a chart of the dimensions of responsibilities
applicable to banking software applications;
[0009]FIG. 2 illustrates a block diagram of a banking business
object;
[0010]FIG. 3 illustrates a graphical representation of a separation
of concerns regarding areas of business responsibility;
[0011]FIG. 4 illustrates a graphical representation of one embodiment
of a meta model of the areas of responsibility;
[0012]FIG. 5 illustrates a graphical representation of one embodiment
of the areas of responsibility as it relates to customer sales and
service;
[0013]FIG. 6 illustrates a graphical representation of one embodiment
of the areas of responsibility as it relates to execution and operations;
[0014]FIG. 7 illustrates a graphical representation of one embodiment
of the areas of responsibility as it relates to analytics;
[0015]FIG. 8 illustrates one embodiment of an aggregate model of
the areas of responsibility;
[0016]FIG. 9 illustrates a block diagram of a processing environment;
[0017]FIG. 10 illustrates the steps of one embodiment of a method
for developing a banking software application; and
[0018]FIG. 11 illustrates the steps of one embodiment of a method
for generating backing software application guidelines.
DETAILED DESCRIPTION
[0019]Through the use of a modeling approach, a directed banking
software application may be developed. By addressing specific issues
directed to various levels of operational aspects of the intended
usage of the banking application, the framework defines customized
development for the software to provide desired solution.
[0020]FIG. 1 illustrates graphical representation 100 of a chart
of layers of responsibility 102 relative to areas of responsibility
104. In banking application development, a target solution addresses
the requirements from user's perspective including areas affecting
system flexibility. The requirements include the areas of business
responsibility 104 and the layers of responsibility 102 in the operating
environment of the banking application.
[0021]These responsibility components can lead to different solution
life cycles depending on the size and complexity of the specific
customer situation. Many banks, as the primary user of the banking
software application, structure processing landscapes in a level
of coarse granularity, also referred to domains. These domains implement
end to end processes with costly levels of redundancy. Banks need
a higher granularity and lower redundancy within their processing
landscape to achieve the required flexibility. Lowest redundancy
is provided if there is approximately one owner per business task.
Highest flexibility is achieved if granularity is on a business
object level. Additionally, the banking software application is
directed to various segments of the banking industry including,
among others, retail banking, wholesale banking, private banking,
investment banking and wealth management.
[0022]As illustrated in the chart of FIG. 1, there are four layers
of responsibility 102. The layers includes an infrastructure layer
106, a banking business object layer 108, a banking processing/integration
layer 110 and a banking user interface layer 112. The infrastructure
layer 106 may be the lowest level of responsibility layer, including
the levels of the user's processing equipment. The banking business
objects layer 108 is discussed in further detail below. The banking
process/integration layer 110 is directed to the ability for the
user to integrate the application or solution to an existing system.
The banking user interface layer 112 is directed to the front end
system allowing users' customers and personnel to access the system,
such as bank tellers or office workers.
[0023]The responsibility areas provides direction as to how the
various services are constructed from a banking software perspective.
The solutions then support the value drivers in the associated areas
of responsibility through the banking software application. Different
value drivers result in different architectural guiding principles
per area of responsibility.
[0024]Within each of the layers 102 of FIG. 1, there includes individual
areas of responsibility 104. As business object granularity may
provide a bank wide understanding of operating tasks, FIG. 2 illustrates
the separation of the tasks within the areas of responsibility of
the business banking object 108. These areas include sales and service
120, operations and executions 122 and analytics 124.
[0025]The business objects 108 represent different responsibility
areas for users utilizing the banking software and thereby different
solution responsibilities for the software itself. FIG. 3 illustrates
a table of the areas of responsibilities of the banking business
objects 108.
[0026]The sales and customer service area 120 includes the front
end processing components and aspects related to customer sales
and service concerns. The main responsibilities include, but are
not limited to, customer overview advice and product offering and/or
personalization and sales and service activities.
[0027]The operations and executions area 122 includes the processing
operations of the banking system and the execution of operations
across the various banking levels, such as a between front end data
entry to the back end account processing operations. The main responsibilities
include, but are not limited to, managing the lifecycle of the contractions/accounts
and products and fulfilment of payments and orders.
[0028]The analytics area 124 includes the processing of operation
data and analyzes of system operations to determine various levels
of system efficiency. The main responsibilities include, but are
not limited to, analytical processing of customer activities and
the calculation, valuation, monitoring and assessment of the bank
activities.
[0029]FIG. 4 illustrates a graphical representation of a meta model
of the areas of responsibilities. As visible in FIG. 4, the meta
model 130 represents a generalized solution for all of the responsibility
areas of customer sales and service 120, execution and operation
122, and analytics 124. It is noted that each specific responsibility
area is discussed in further detail below.
[0030]The model 130 includes numerous business objects and relationships
therebetween. The bank object 132 represents an entity performing
the banking operations. The party object 134 represents the parties
with whom the bank conducts business or other banking relations.
The agreement object 136 represents an agreement or a contract with
two involved parties, both having agreed to the terms and conditions,
including different types of agreement, e.g. written, verbal, implied,
etc. The need object 138 describes things that people or customers
must have, such as for example customer requests or benchmarks for
customer success or performance.
[0031]The goal object 140 is a desired state of affairs of the
bank, such as financial goals of the bank. The business events 142
can be classified into two categories, operational events and analytical
events. Operational events can originate from operational systems,
produced during business activities or whenever there is a change
in the business environment relevant to the analytical world or
created during online transaction at the same time as data is keyed
into the banking system. Analytical events can be time-related,
possibly triggering a re-evaluation process.
[0032]The business rules 144 describe the specific working instructions
of the bank including how the act on business events. The operator
146 is an object representing a person or entity acting on behalf
of the bank or customer during sales or execution. The object field
148 describes objects belonging to a party or that are a part of
an underlying agreement between the party 134 and the bank 132.
The object 148 may refer to the assets which are financed by the
agreement, such as a mortgage loan, or the asserts which are the
foundation for a collateral agreement. The result object 150 can
be information generated for a business object, such as an agreement
or business event, based on available business information relevant
in the context of the bank's goal. The product object 152 can describe
the banks' standardized offering to customers, including the associated
rights and liabilities.
[0033]The meta model 130 illustrates the interrelation between
the various meta objects. Additionally, the model includes the restrictions
that there is no link between party 134 and product 152, but rather
the link always goes via the agreement 136 and that agreements without
a related product are possible, for example that there can be a
pure money transfer order.
[0034]FIG. 5 illustrates a model 160 of the customer sales and
service responsibility area. In this area, the major responsibilities
include communication and collaboration with customers (Party),
acquisition of new customers, generate new businesses and to serve
customer requests. To fulfill the responsibility the business logic
in an underlying banking software application should: personalize
processes, events and information-needs; interact realtime proactive
across processing channels; process customer inquiries including
breaks and restarts without recapturing of data; offer tailored
products to the customer including individualized pricing; and generate
new and customer tailored sales products flexible and time to market.
[0035]The processes in this area are responsible for market and
customer contact activities. These processes include, among others:
acquisition of new customers including campaigns and events/originate
new agreements; financial advices; serve customer inquiries and
orders; customer retention/loyalty programs; personalization of
customer contact and interactive usage of information; definition
and launch of sales products; and delegation of orders and agreements
to Execution & Operations
[0036]Illustrated in FIG. 5, The model 160 includes designated
business objects. The party objects 162 may be customers and/or
legal entities entering into different types of banking contracts.
The bank objects 164 may be the bank in the banking contracts. The
operator object 166 includes a customer side and a bank side. On
the customer side, these operators are involved in doing contract
origination. On the bank side, these operators are involved in doing
contract origination, acting on behalf of the bank.
[0037]The sales and services agreements 168 can be the real, legally
relevant signed or otherwise consented agreements. The Sales &
Service Business rules 170 describe the way bank operators are allowed
to engage, such as: authorization guidelines and tolerances. Sales
& Service Event 172 is a change in the properties of the party
(e.g. bankruptcy, death, marriage, financial conditions) or the
sales agreement (e.g. due date of offer, missing document).
[0038]Sales & Service Product 174 is anything that can be offered
to a party that might satisfy a need. However it is much more than
just the agreement and the exchange of financial flows. It is the
complete bundle of benefits or satisfactions that buyers perceive
they will obtain if they purchase the product. The objects 176 belong
to a party and play a role in the sales agreement, which may refer
to the assets which are financed by the sales agreement (mortgage
loan) or the assets which are the foundation for a collateral agreement.
Results 178 are information available for decision support, such
as pricing results, information on customer profitability, customer
segmentation, where this information may be provided in the analytics
area.
[0039]The model 160 of FIG. 5 includes designated relationships
between the objects, as indicated by corresponding relational text.
These designated relationships define the framework of the model
itself. For example, in a modeling scenario, the operation 166 may
act on behalf of a bank 164 that is involved in a sales and service
agreement 168. A sales and service product 174 may target a particular
need, which is a motivation for a sales and service agreement 168
or the product 174 may be the basis for an agreement 168. In another
example, the bank 164 may implement a strategy in the form of a
business rule 170 or a sales and service event 172 may be caused
by a party 162 that is involved in the agreement 168. The model
160 illustrates various representative defined relationships in
the customer sales and service area of responsibility.
[0040]FIG. 6 illustrates a model framework 180 for the execution
and operations area of responsibility. Responsibility of execution
and operation includes execution and/or collaboration fulfilment
for financial contract obligations. Responsibilities in this area
are to execute and monitor agreements, orders and transactions,
automate processes, and handle exceptions. Key business requirements
include: automated process and handle exceptions; flexible execution
for new agreements; low `transaction` costs; scale for high volume
business-performance; and product line independence allowing e.g.
easy bundling of products.
[0041]Within this area of responsibility, processes relate to events
over a full lifecycle scope. The processes include, among other
things: capture and authorize in- and outgoing financial transactions;
monitor due dates and initiate expected business events on the agreements;
define execution products; settlement of execution agreements; manage
and distribute bundles of agreements; and delegate customer contacts
to customer sales and service.
[0042]The framework 180 for the execution and operation area of
responsibility include some of the same or similar objects from
the previous framework 160, including party 162, bank 164, and operator
166. Additionally, in this framework 180, the operation agreement
182 may be information relevant to execute a specific loan or other
operation, and these objects may differ per different execution
engines for different banking operations.
[0043]The operation events 184 may originate from either operational
systems, produced during business activities, whenever there is
a change in the business environment relevant to the analytical
world, or are created during online transactions at the same time
as data is keyed directly into the system. Operational events 184
can accommodate actual or future events and can refer to actual
or future changes. These events 184 are data-driven such that there
are no operational events without data.
[0044]Operational rules 186 may be rules describing the way the
bank operator is allowed to execute various transactions, for example
authorization guidelines for a particular lending transaction. The
operational product 188 is also illustrated in the framework 180,
but in a detached manner indicating that the execution and operation
responsibility area concentrates on the processing of financial
instruments and knowledge of the particular product or asset 188
and the framework 180 does not necessarily include information as
the product or asset itself.
[0045]As illustrated in FIG. 6, the framework 180 includes corresponding
relationships between the objects. For example, the bank 164 implements
a strategy in the form of operational rules 186 that give guidance
for an operational event 184. An operational event 184 may be caused
by a party 162 that is involved in an operational agreement 182.
The model 180 illustrates various representative defined relationships
in the customer sales and service area of responsibility.
[0046]FIG. 7 illustrates a framework 200 for the analytics area
of responsibility. This area include the calculation and valuation
of events and/or contracts based on the execution and operation,
as described above. The analytics area includes key business requirements
of providing different types of information. The providing of this
information may include taking the specifics of financial products
into account, providing information based on a consolidated information
base for all customer service and sales as well as execution and
operation business objects. The information may be taken on a fine
granularity and on an aggregated level. The information should also
be easy to adapt to changing information needs, such as new products
and/or new regulations. Additionally, the information should be
for decision support (fast) as well as for reporting (comprehensive)
and on a consistent basis across analytical engines, products, locations.
[0047]Analytics may include various types of processes. For example,
a financial product valuation, for value chain related processes,
may include calculation/valuation based on business events, which
may further take into account legal and business concerns. The financial
product valuation may also be based on business date, such as for
appreciation or depreciation calculations. Operational valuation
processes may provide business support. Enterprise wide reporting
and strategic management operations may provide various levels of
analysis, including areas such as financial reporting, regulatory
reporting, balance scorecard calculations, among others. Decision
support processes are also available, such as calculations, valuations
and/or result based on business requests or typical processes such
as pricing operations during contract origination, customer overview,
online availability check regarding risk limits and pre-deal simulation
for portfolio management, among others. Analytics may also include
customer behaviour analysis and customer investment performance
operations.
[0048]The framework 200 for the execution and operation area of
responsibility includes some of the same or similar objects from
the previous framework 160, including bank 164, sales and service
agreement 168, party 162, object 172, result 178, operational agreements
182 and operational events 184. The framework 200 also includes
the objects goals 202, analytical rules 204 and analytical events
206.
[0049]The framework 200 also includes the objects goals 202, analytical
rules 204 and analytical events 206. The goal object 202 may be
the desired state of affairs of the bank, which may include profit
motive and/or regulatory goals. The analytical rule object 204 may
include valuation and calculation rules. For instance, contract
valuation rules by dependent on different jurisdictions or accounting
principles. The analytical events 206 are time-related events having
a semantic and trigger re-evaluation processes. In these events,
results may differ from previous analysis based on different factors,
including a change in master data, change in market data, changed
or new relationships or a change in time factors.
[0050]In one embodiment of a model framework, FIG. 8 illustrates
an inter-object relationship between various objects aggregated
across all three designated areas of responsibility. The framework
includes the objects illustrated and discussed in the models 160,
180 and 200 above, with respect of FIGS. 5-7. The framework also
shows one embodiment of the related interdependency therebetween.
[0051]FIG. 9 illustrates an apparatus 240 including a processing
device 242, a memory 244 and executable instructions 246. The processing
device may be one or more processing elements operative to perform
various operations in response to the executable instructions 246.
The memory device 244 may be one or more storage devices operative
to store and thereupon provide the executable instructions 246 to
the processing device 242. The apparatus 240, processing device
242 and memory 244 may be disposed on a single computing system
or disposed across one or more systems in a networked processing
environment.
[0052]FIG. 10 illustrates the steps of one embodiment of a method
for banking software application development. These steps may be
performed on a processing device, such as the device 242 of FIG.
9. In one embodiment, the method begins, step 260, by defining a
plurality of banking object terms, each of these terms relating
to components of a banking relationship. As discussed above, the
banking object term may be the banking objects illustrated in the
models of FIGS. 5-8, where each of the objects described above relate
to one or more components of a banking relationship.
[0053]In one embodiment, the next step, step 262, is defining a
plurality of responsibility area terms, each of these terms relating
to banking activities, wherein each of the responsibility area terms
includes at least one of the banking object terms. For example,
as described above there are four layers of responsibility, including
the banking business object, as illustrated in FIG. 1. This layer
includes the responsibility areas of customer service and sales
120, execution and operations 122 and analytics 124. Each of these
areas includes numerous banking object terms, as illustrated in
FIGS. 5-7.
[0054]In one embodiment, the next step, step 264, is generating
a solution foundation for at least one of the responsibility area
terms by defining relationships between the plurality of business
object terms such that banking software application is developed
based on the solution foundation. By way of example, FIG. 5 illustrates
one embodiment of the various defined relationships between the
plurality of business object terms. These interdependent relationships
generate a framework upon which subsequent banking business applications
may be developed. Thereupon, in this embodiment, the method is complete.
[0055]Although, the above-described method may include additional
steps in alternative embodiments. For example, an additional step
may include generating solution foundations for each of the responsibility
area terms by defining relationships of the business objects terms
and generating an aggregate relationship definition across the responsibility
area terms. For example, a solution foundation may include the aggregate
relationships illustrated in FIGS. 5, 6 or 7, where these are across
corresponding responsibility area terms. In another embodiment,
the method may include generating the solution foundation based
on the aggregate definition relationship.
[0056]In another embodiment, the step of generating the solution
foundation may include modeling the relationships to generate the
solution foundation and the step of assembling the banking software
application includes generating a runtime implementation of the
modeled relationships. This embodiment may include performing the
modeling operations in accordance with known modeling techniques
using the newly developed framework described above. In the generation
of the runtime implementation, this includes codifying the components
of the framework such that the generated application performs as
determined by the relationships.
[0057]FIG. 11 illustrates a flowchart of the steps of one embodiment
of a method for generating banking software application guidelines,
where the guidelines are used to generate a banking software application.
In one embodiment, the method begins, step 280, by defining a plurality
of responsibility layers, including a banking object layer. The
next step, step 282, is defining a plurality of responsibility areas
for each of the responsibility layers. For example, FIG. 1 illustrates
four different responsibility layers and FIG. 2 illustrates 3 areas
of responsibility of one of the layers.
[0058]The next step, step 284, is defining a plurality of banking
object terms in the banking object layer, such as the objects illustrated
in FIGS. 5-8 and discussed above. Thereupon, the method further
includes, step 286, defining relationships between each of the plurality
banking object terms in the banking object layer. In this embodiment,
the final step, step 288, is then comparing a banking application
solution relative to the defined relationships in the banking object
layer to determine the effectiveness of the banking software application.
This step may include testing the application through various operation
scenarios. By way of example, FIG. 5 illustrates the defined relationship
between different objects, processing scenarios may perform steps
or functions in accordance with banking software application and
the generated solution is then comparable to an expected result.
This then provides a secondary approach to analysis of a banking
software application using the object framework described above.
[0059]Through the modeling framework, a banking business application
may be properly and more efficiently developed. The definition of
the business object terms and defined relationships builds the model
framework. This framework incorporates various areas of responsibility
in the banking environment. The modeling allows for defined relationships
between objects in different responsibilities areas, thus allowing
a greater degree of granularity in application design. Additionally,
the definition of business objects and the relationships therebetween
adds a level of flexibility to allow the framework to be easily
adjusted to changes in the banking environment. Improved banking
software applications are therein development through this framework.
[0060]Although the preceding text sets forth a detailed description
of various embodiments, it should be understood that the legal scope
of the invention is defined by the words of the claims set forth
below. The detailed description is to be construed as exemplary
only and does not describe every possible embodiment of the invention
since describing every possible embodiment would be impractical,
if not impossible. Numerous alternative embodiments could be implemented,
using either current technology or technology developed after the
filing date of this patent, which would still fall within the scope
of the claims defining the invention.
[0061]It should be understood that there exist implementations
of other variations and modifications of the invention and its various
aspects, as may be readily apparent to those of ordinary skill in
the art, and that the invention is not limited by specific embodiments
described herein. It is therefore contemplated to cover any and
all modifications, variations or equivalents that fall within the
scope of the basic underlying principals disclosed and claimed herein |