Part 3 - External Application Details |
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 architecture. The only thing left to cover was the order in which you'll be led through the architecture 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
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 architecture, 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:
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:
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)
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 for the omnichannel customer experience use case.
An overview of the series on omnichannel customer experience portfolio architecture can be found here:
Catch up on any articles you missed by following one of the links above.
Catch up on any articles you missed by following one of the links above.