Data Flexibility Masking
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2005-Mar-21
AbstractDisclosed is a programming scheme called Data Flexibility Masking (DFM) which permits a Single Applications System offering, to support many differing business scenarios with different data. Efficiency and applicability of the system to each user is maximised by masking out unwanted system options that constitute unnecessary overhead to users particular requirements.
Data Flexibility Masking
a programming scheme called Data Flexibility
Masking (DFM) which permits a Single Applications System offering, to
support many differing business scenarios with different data.
Efficiency and applicability of the system to each user is maximised
by masking out unwanted system options that constitute unnecessary
overhead to users particular requirements.
that it allows a common package solution to be
customised for an individual user, in terms of the fundamental data
structures of his business [*]. This significantly widens the
possible market for any software package using DFM. It also allows a
user to progressively move from a simpler to a more sophisticated
environment, in data structure terms, without the need for initially
creating 'dummy' records or subsequently modifying data base tables.
Finally, it permits a 'new' system to be built to replace an 'old'
system so that the new system can be 'de-scoped' using DFM to have
the same data structures as the 'old' system. This allows
progressive replacement of the old system by the new system, with the
two running side by side for a period. Once cut-over to the new
system is complete, the masking can be removed unleashing the
potential of the new system.
inevitable that when a common application software system
such as a software package is applied to different targets, each will
find some aspect of the system which is over-elaborate, or not
required. As viewed by the user superfluous function is not merely
an unnecessary extra development cost, but a continuous operational
overhead as shown in the following examples.
In example 1
System X uses a particular algorithm to arrive at
manufacturing lot sizes, which takes into account several parameters.
Factory F finds this an over-elaborate way of determining lot sizes.
The work of maintaining some of the lot sizing parameters so as to
effectively simplify the lot sizing function are regarded as a
cost-adding but not value-adding activity.
In example 2
System X assumes that each purchase order has a
number of order lines, each one ordering a particular item. In
Factory G, purchase orders carry one item only, and hence do not have
individual order lines. Factory G would rightly regard the creation
of 'dummy' lines, 'to suit the system', as a worthless, costly,
Superfluous function is of two types:
o Over-complex process (exemplified by 1 above)
o Over-complex data structure (exemplified by 2 above)
for the two conditions are quite different;
attempting to compensate for an over-complex data structure by simply
modifying the business function of the processes is not effective.
Processes which are over-complex have to be changed, perhaps through
providing parametric control, or by substituting alternative
processes which is not the subject of this innovation.