In Part 2 of this series, we took a high-level view of the common architectural elements that determine how your integration becomes the key to transforming your customer experience.
I laid out how I've approached the use case and how I've used successful customer portfolio solutions as the basis for researching a generic architectural blueprint. The only thing left to cover was the order in which you'll be led through the blueprint details.
This article takes you deeper to cover details pertaining to the specific elements (mobile and web application deployments) of the generic architectural overview.
Architectural details
As mentioned before, the architectural details covered in this series are based on real customer integration solutions using open source technologies. The elements presented here are then the generic common architectural elements that I've identified and collected into the generic architectural blueprint. It's my intent to provide a blueprint that provides guidance and not deep technical details.
This section covers the visual representations as presented, but it's expected that they'll be evolving visually over time. There are many ways to represent each element in this architectural blueprint, but I've chosen icons, text, and colors that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this post or contact me directly with your feedback.
Now let's take a look at the details in this architecture and outline the elements uncovered in my research.
Mobile applications
External application deployments are split between mobile and web applications. Both are generic broad terms used to describe the types of application deployments discovered in the researched customers.
Mobile applications are anything not specific to the web, such as an application for mobile phones, tablets, or some sort of portable device not specifically defined. It's what customers are using to interact directly with a company. This can be mobile applications deployed by the company itself or developed by third-party organizations to interact with the services offered.
These applications can be created using many different languages and libraries, and they can target diverse platforms. Research showed that integration through the use of a mobile application platform, such as Red Hat Mobile Application Platform, was favored above DIY mobile development to provide a platform for managing and maintaining mobile application development, integration, and deployment.
These applications link customers to a company's solutions and can encompass voice, video, and/or chat features. They access the organization through the API gateway using single sign-on for security. Interactions go through the following microservices:
- Front-end microservices (providing access to internal integration microservices)
- Process facade microservices (providing access to automated integration processes)
- Other applications (providing access to aggregated microservices or other internal applications)
When external applications are not deployed on mobile devices, then we're looking at web applications.
Web applications
The web applications category is for all other types of applications, for example, websites and/or services that are deployed by a company or any third-party organizations to interact with the services offered.
While in the traditional sense web applications can be anything hosted outside the company, we've encountered an internal (to the researched organization) helpdesk application that contained an interactive voice response (IVR) system integrated with email and text options. The solution treated this helpdesk application as an external web application for integration purposes and constructed the necessary microservices to interact with its API layer.
These applications link customers to a company's solutions or provide external third-party information to a company's information architecture to enrich the customers' experiences. They access the organization through the API gateway using single sign-on for security. Interactions go through the following microservices:
- Front-end microservices (providing access to internal integration microservices)
- Process facade microservices (providing access to automated integration processes)
- Other applications (providing access to aggregated microservices or other internal applications)
These details are not all-telling, but they should give you the guidance you'd need to get started in your own architectural situations.
What's next
This overview covers the external applications deployment elements that make up our architecture blueprint for the ominchannel customer experience use case.
An overview of the series on omnichannel customer experience portfolio architecture blueprint can be found here:
- Part 1: How integration is key to customer experience
- Part 2: Common architectural elements for modern integration architectures
- Part 3: Integration of external application details (this article)
- Part 4: Integration of API management details
- Part 5: Integration of container platform essentials
- Part 6: Integration of storage services
- Part 7: Application integration details
- Part 8: Dissecting several specific application integration architectures
Catch up on any articles you missed by following one of the links above.
Next in this series, we'll be taking a look at the application management details for the omnichannel customer experience.
Last updated: March 21, 2023