Case Study

Pragmatic Disaggregation and Loose Coupling

How did IdentityE2E realise our Client’s target to disaggregate their mission-critical biometric solutions, maintain system performance, whilst enforcing a principal of loose-coupling between sub-systems and components?

Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Pragmatic Disaggregation and Loose Coupling
Back
Keith Dolan
Author
Keith Dolan
IdentityE2E
Writer
Identity

Pragmatic Disaggregation and Loose Coupling

February 7, 2024

How did IdentityE2E realise our Client’s target to disaggregate their mission-critical biometric solutions, maintain system performance, whilst enforcing a principal of loose-coupling between sub-systems and components?

Mission-critical biometric solutions tend to be highly complex and cover a wide range of biometric functions:  

·      Image encoding services.

·      Template comparison and matching services.

·      Automated workflow and management of non-biometric data.

·      Biometric error correction and result determination by expert users.

·      External interfaces /APIs.

Historically, such solutions have been delivered by a single biometric supplier delivering a range of products within their product stack to meet the Client’s requirements. Whilst single supplier solutions will often deliver to the functional requirements, they can lead to issues with vendor “lock-in”, commercial challenges and issues with technical refresh. This is typically caused by biometric suppliers preferring to utilise proprietary biometric template formats, proprietary data structures and proprietary or bespoke interactions between their products.

IdentityE2E enterprise architects defined a “roadmap for disaggregation” within our clients biometric matching solutions. Systems, subsystems and component were defined with an outline of their responsibilities within the architecture and ownership of the data domains within the data model. A key architectural principal was to ensure loose-coupling between components and sub-systems so that they can be easily replaced, without causing a ripple of change throughout the solution.IdentityE2E solution and biometric architects modelled interactions and messaging between component and sub-systems as the basis for introducing and selecting the most appropriate non-proprietary biometric standards and industry standard messaging protocols.

IdentityE2E have a wide breadth of experience using various standardised industry integration patterns, with specialised knowledge relating to biometric industry standards. For example, IdentityE2E were able to propose the most appropriate industry standard biometric template format to allow the correct subset of biometric template data to be manipulated by biometric expert users in the expert workstation UIs and carried back through the workflow into the core template comparison and matching API. The expert UI was decoupled from the back-end matching services and, as a result, can now be delivered by different products and / or different suppliers.

Breaking the model and understanding the trade-offs.

Whilst advocating good-architecture principles, such as loose-coupling,IdentityE2E architects are mindful of the trade-offs involved. For example, repeated image encoding into proprietary template formats or repeated data conversion between proprietary and industry standard formats can lead to system performance overheads that can cause problems meeting KPIs or else a degraded user-experience.

Having established a basis for a fully de-coupled solution, IdentityE2E architects made controlled and assured architecture decisions to loosen the constraints. The proprietary template formats were permitted to be carried more widely within the solution, provided that we could ensure appropriate handling, and where there was significant performance benefit in doing so.

IdentityE2E architects established principles for handling proprietary templates within the wider solution components and subsystems. For example, any proprietary templates were simply transported as a block of binary data with no inspection or logic based on the proprietary template (binary data) contents.Proprietary templates were always carried alongside an equivalent industry-standard (open-format) template to maintain the loose-coupling across the solution.