Service
Architecture & System Integration
Overview
Defining system architecture and integration requires a breadth of technology experience. Quoin has 25 years of hands-on work building web, mobile, and enterprise applications - often within the context of integrating applications into an enterprise architecture. Given our focus on technically challenging problems, most of our projects require significant effort to integrate with other applications or systems. Quoin engineers are therefore skilled at using the tools and techniques critical to integration, such as application services, data interchange standards, message queues, publish/subscribe channels, distributed data, and other practices.
Extensibility
We understand evolving requirements and how to build an architecture for the long term, including new applications, integrations, and emerging technologies.
Maintainability
Operations, support, and maintenance of a system are critical to the total cost of ownership and are critical requirements for the initial design.
Security
Application and system-level security cannot be an after-thought and must be considered throughout conception and implementation.
Robustness
Best practices result in high-quality software, and our approach is based on executable user-acceptance tests, test-driven development, and test automation can deliver.
Our Work
UNICEF Primero Architecture
Quoin defined the high-level system architecture for the UNICEF Primero platform and has led the transition to a full SaaS implementation for this web/mobile application for case management.
.webp)
Comporium Architecture
The system architecture depicted here integrates back-end services and front-end delivery. Defined for Comporium Communications, the architecture includes e-commerce and customer services delivered via web and mobile applications, including progressive web applications for seamless web/mobile user experience.
Our Approach
We understand that selecting an integration approach depends on a range of technology and organizational issues, and we have the experience to tailor our approach to fit the needs of a client. In general, we’d start with considering the following.
- API versus Data — Can the data be exposed via well-defined services?
- Data Distribution versus Designated System – Is one system responsible for the data or does the data reside partially in several systems?
- Scalability – Is the number of systems likely to increase?
- Latency – How fast do changes in the data need to be promulgated to other systems?
For a single application responsible for maintaining a data set and a fixed number of client applications, the simplest integration architecture would be client application access through a ‘thin’ RESTful hypermedia API. (We would not recommend direct access to the database through SQL, stored procedures, or even views, since these practices all create unnecessary dependencies between applications.) However, the need to integrate a large or extensible number of applications would require much greater attention to the design and implementation of an API. In cases where systems are distributed or there are significant requirements for timely and accurate data, the integration architecture would likely include message queue (e.g. RabbitMQ) or publish/subscribe framework (e.g., Apache Kafka), or other integration backbones. An integration architecture might also need to support some level of Quality of Service (QoS) guarantee on system latency or delivery.