|
Application design
>>>>...
1
2
To
put this into perspective, it would seem rather pointless to have
lengthy discussions about the inclined valve angle on a one litre
petrol engine which we are fitting into a three ton vehicle - we
should be asking about power to weight ratios and what sort of
engine we need to propel this vehicle at the required speed. The
same is true of our biometric system. We must consider the system as
a whole, together with our business related objectives for
implementing such a system.
So
far, we have discussed some of the issues inherent in a typical
systems supplier / client situation. In certain cases, the end user
(or retained systems house) may wish to buy in the component
technology on an OEM basis and develop their own custom application
according to precise requirements. In the early days of biometrics
this would have been quite difficult with many of the proprietary
products available. These days life is a lot easier for the
application development team as several of the leading device
manufacturers have taken the trouble to make available a Software
Development Kit (SDK) for use with their product. This usually takes
the form of a set of DLL's which the developer may call from his
application in order to access various functions of the device. This
allows the developer to concentrate on the user interface and
program logic without having to get too involved with the low level
coding detail.
This
is certainly a step forward and is to be welcomed. However, it is a
little device specific in the sense that if you decided later on to
use a different front end biometric device, then you would need to
rewrite your application accordingly. This may be acceptable in some
instances, but what if you wish to use more than one type of
biometric device on your system? This is not unreasonable. You may
wish to use a dual biometric for high security reasons, or to use
different biometrics in different areas for environmental reasons.
This can complicate matters somewhat. It would be nice perhaps if
there were a universally accepted biometric Application Programming
Interface (API) which developers could use in order to mix biometric
methodologies within a single system. In fact, there has been much
work undertaken in this context and by the time you read this paper
at least one such API should be freely available. The question is,
will the biometric manufacturers be happy to comply with and support
such an initiative? I hope that they will, but suspect that this may
take a while to become embedded in biometric culture.
What
of the future? The is no doubt that biometric technology is mature
and eminently useable across a wide variety of advanced personal ID
related applications. Both the systems integrator and the end user
have a wider choice than ever of front end biometric components and
it is easier than it has ever been to integrate these components
into bespoke systems. Individual unit cost is still relatively high
for biometric products, but this too is changing and several
manufacturers are introducing lower cost OEM modules to the market
place.
In
short, if you have an operational problem that biometrics might
solve there is no reason to sit on the fence any longer - biometrics
are alive and well and available off the shelf at a location near
you!
>>>>...
1
2
|
