The Quantiv Commerce Platform Architecture

Quantiv Configurator

The Configurator's primary purpose is as a development tool, taking the modelling output and configuring the services within the framework. However the configurations become 'maps' of the customer solution, so the configurator ensures that the Quantiv Commerce Platform is a self-documenting system, resilient to the loss of key staff and expertise. Crucially, the configurator maps the interaction between entities and processes, ensuring that the full impact of any change can be tested at the configuration stage, before any building or integration takes place.

Functional business services

The range of configurable, functional services is extensive, examples include:

• Document and Data Storage: Including persistence, comprising both the 'static' model of a business - entities and objects - and information storage and retrieval
• Workflow Management: Including the 'dynamic' model of a business - its processes and activities
• Measures and Accounting: Multicurrency facilities and support for all known accounting conventions comes as standard
• User Interface Manager: Much more than a multi-lingual Web and GUI toolkit, because when combined with other framework services it ensures UI integrity with the underlying processes
• Scorecard Management: Reporting and data warehousing against multiple points of view across complex data structures and enterprise-scale transaction volumes
• Business Rules Base: Enabling the rules which govern the operation of the business to be configured and maintained to exceptional levels of complexity

Platform services

Cross-functional Platform services are similarly comprehensive, and include:

• Transactionality: Referential integrity, transaction compensation, deadlock avoidance, distribution, integration
• Interoperability: Service broking (SOA), synchronous and asynchronous communication
• Security: Access control (including OS integrated and stand-alone role based security)
• Scalability: Load balancing, virtualisation
• Reliability: Fail-over, clustering
• Manageability: Auditing, logging, notification

Additional services and coding

While a high proportion of a solution will normally be achieved by configuration, all solutions require a small element of coding to achieve an exact fit to customer requirements. Functions which can not be configured from existing services are coded as new services, tested, and orchestrated by the framework in the same manner as other services.

Domain sector models

Experience with customers in multiple sectors has shown that there is substantial commonality across disparate solutions within the same sector. In the insurance sector, for example, requirements for a configurable rating engine and for accounting systems that generate bordereaux are pervasive. Sector-specific functionality has therefore been configured or coded into domain platforms, also under the orchestration of the Platform, thus providing sector needs while interacting with cross-sector services.