We’ve been telling you about how INTOUCH® is the first completely new customer communications management (CCM) solution in years, with its exceptionally business-user-friendly UI and UX and its services-based architecture built using containers and microservices. In this article, we present an overview of that architecture.
Above is a container-level diagram of the INTOUCH architecture (here’s a larger version you can download). Looking at the diagram, there are four main categories of components, which are designed to work together through the INTOUCH application user interface or can be accessed independently by a third-party developer via the API Gateway:
- Cloud-related functional components
- Communication composition microservices
- Communication generation microservices
- Communication history microservices
Let’s take a closer look at the role of the containers in each category. Don’t worry, we won’t go into the specific technologies in each container; we’ll save that for a white paper.
Cloud-Related Functional Components
Business users access INTOUCH through a secure web browser connection, represented by the HTTPS icon. NGINX is the front door server to the INTOUCH application, and TLS is the secure protocol used to communicate between our cloud application and the user’s browser. AWS is our cloud platform provider for the INTOUCH SaaS CCM product.
Any time you have a cloud-based application, there are things that have to be included, like the Authorization, Authentication and Configuration tools. Those components provide for the security and administration of the application and make sure only people who have the right to access the application have the ability to access it. Note the diamond that says “REST API” attached to each of these containers. Those give developers the ability to integrate INTOUCH’s security functions with your organization’s existing security tools and methodologies. For more info on security, request our security white paper.
You can also see on the diagram that there’s a PostgreSQL database so that INTOUCH can keep a list of who can access what, and what they’re allowed to see and do while they’re there (e.g., only content editors are allowed to edit templates or layouts, while other users may only be allowed to use interactive communications tools).
The API Gateway allows third-party developers access to the REST APIs in each of the containers in the architecture. The REST APIs give developers access to all of INTOUCH’s underlying functionality so they can “pull strings” and customize the software to integrate seamlessly with your existing customer experience architecture and leverage its tools exactly the way your organization needs.
Communication Composition Microservices
On the communication composition side, there are containers for the Content Management System (or CMS), CMIS (an open standard for connecting content stores and centralizing content management) and Repository. Those containers are where assets that you create are defined (as content, template, layout, etc.) and stored.
Communication Generation Microservices
The most robust microservices in INTOUCH have to do with creating or generating communications. They include Communication Assembly, Data Retrieval, and Logic and Formatting. Then, depending on what type of final-format communication you are generating (i.e., web, email or print), there are also Email Assembly, Channel Delivery, Rendering and PDL Output in this category.
All of those services go into the process of retrieving customer data for personalization, employing business logic, and arranging or formatting the content for delivery through various channels. Then the renderer, email assembly, PDL output and channel delivery mechanisms are involved in determining and delivering the final-format communication.
Communication History Microservices
And finally, you need to be able to track every single communication that is created and sent to customers AND see exactly what each communication looked like in the final format in which it was delivered. You need to be able to call up this history at any time, for any customer or group of customers, for tracking, auditing and accountability purposes.
Logging and Audit, Encrypted Search and either CMIS or the Repository make up the history functionality. That is the transcript of the “life” of each communication and where it can be found. With these tools, you can see everyone that was ever part of a particular communication’s journey from creation through delivery. This is also where the final-format image record of each communication can be found, either in the INTOUCH Repository or, using CMIS, in an external repository.
INTOUCH Simplifies the Complex
We’re heavily oversimplifying, of course, as there’s some serious technology and attention to detail built into every one of those containers. There are compliance measures in place and encryption to keep data secure while at rest, in use, in transit. There are forward-thinking integration tools and user experience capabilities that make INTOUCH ready for the CX architecture you’ll have in five years – long before you even have it. But by simplifying things this way, (hopefully) it becomes clear how INTOUCH makes complex functions extremely easy for end users to perform while not sacrificing a bit of the power and versatility of traditional CCM.
If you have any questions about the INTOUCH architecture that aren’t addressed in the diagram, please reach out to us. And, of course, don’t forget to subscribe to the blog to nerd out with us about INTOUCH and the world of customer experience management.
