In my previous article from this series we took a high level view at the common architectural elements that determine how your integration becomes the key to transforming your customer experience.
The process was 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) from the generic architectural overview.
Architectural details
As mentioned before, the architectural details covered here are base 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 in to 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 colours 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
When looking at external application deployments, it’s 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 the mobile phone, tablets or some sort of portable device not specifically defined. It’s what the customers are using to interact directly with a company. This can be mobile applications deployed by the company themselves or developed by third party organizations to interact with the services offered.
These applications can be created using many different languages, libraries and target diverse platforms. Research showed that integration through the use of a
mobile application platform was favoured above DIY mobile development to provide a platform for managing and maintaining mobile application development, integration and deployment.
These applications link customers to a companies solutions and can encompass voice, video, and/or chat features. They access the organizational through the API gateway using single sign on for security. Interactions go through the following microservices:
- frontend 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 application are not deployed on mobile devices, then we’re looking at
web applications.
Web applications
Web applications are the category for all other types of applications, web sites and/or services that are deployed by the company or any third party organizations to interact with the services offered.
While in the traditional sense it 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 companies solutions or provide external third party information to a companies information architecture to enrich their customers’ experiences. They access the organizational through the API gateway using single sign on for security. Interactions go through the following microservices:
- frontend 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 knowing, but 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 ominchannel customer experience use case.
An overview of the series on omnichannel customer experience portfolio architecture blueprint can be found here:
- An introduction
- Generic common architectural elements
- External application details
- Details of specific elements (api gateways, container platform, storage services)
- Application integration details
- Dissecting several specific application integration architectures
Catch up on any articles you missed by following one of the links above.
Next in this series, taking a look at the details of specific elements in an architecture for omnichannel customer experience.
| Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: Integration Key to Customer Experience – External Application Details Opinions expressed by Java Code Geeks contributors are their own. |
