{{announcement.body}}
{{announcement.title}}

Integration Key to Experience: Common Elements (Part 2)

DZone 's Guide to

Integration Key to Experience: Common Elements (Part 2)

This article starts the real journey with a generic architecture from which we'll discuss the common architectural elements one by one.

· Integration Zone ·
Free Resource

In my previous article from this series, we introduced a use case around integration being the key to transforming your omnichannel experience.

The process was laid out how I've approached the use case and how I've used successful 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 starts the real journey with a generic architecture from which we'll discuss the common architectural elements one by one.

From Specific to Generic

Before diving into the common elements, it might be nice to understand that this is not a catch-all for every possible integration solution. It's a collection of identified elements that I've uncovered in multiple customer implementations. These 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. You're smart enough to figure out wiring integration points in your own architectures. You're capable of slotting in the technologies and components you've committed to in the past where applicable. It's my job here to describe the architectural blueprint generic components and outline a few specific cases with visual diagrams so that you're able to make the right decisions from the start of your integration projects.

Another challenge has been how to visually represent the architectural blueprint. There are many ways to represent each element, but I've chosen some 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 quick tour of the generic architecture and outline the common elements uncovered in my research.

External Applications

Starting at the top of the diagram, which is by no means a geographical necessity, there are two elements that represent external applications that interact with the architecture. Distilling the various applications discovered in customer solution research, I've come up with two common representations.

omnichannel customer experienceThe first is mobile applications, covering basically everything that customers use 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.

The second is web applications, a broad element to contain all other types of applications, websites and/or services that are deployed by the company or any third party organizations to interact with the services offered.

API Gateway and Proxyomnichannel customer experience

These elements in the common architecture are found in every solution researched. They were mentioned by name and consisted of an Application Programming Interface (API) gateway that managed access from external applications when calling internal customer solution services.

The proxy shown was a reverse proxy, a standard solution for providing a security layer between external applications calling internal services by hiding the internal addresses.

Container Platformomnichannel customer experience

Without fail, every organization engaged in omnichannel integrations has seen the value of containers and use of a container platform. The container platform provides for one consistent environment for developers and operations to manage services, applications, integration points, process integration, and security.

It's also the one way to ensure you can uniformly leverage the same container infrastructure across a hybrid multi-cloud environment. It avoids becoming locked into any private or cloud infrastructure as you have an exit strategy with a container platform that's consistent across your architecture.

The security aspect is interwoven in the container platform, as each container service, application, or process integration can be plugged into an organizations authentication and authorization mechanisms.

Storage Services

The storage services uncovered in solution research were diverse and numerous. For that reason, there is no single common architectural element shown at the highest level. Everything from container native storage to traditional block storage was used.

omnichannel customer experienceIn later articles, when more detail is shown, I'll make a point to present a few of the options chosen by customers integrating data services with processes and applications.

What's Next?

The resulting content targets the following three items.

  • A slide deck of the architectural blueprint for use telling the portfolio solution story.
  • A generic architectural diagram providing the general details for the portfolio solution.
  • A write-up of the portfolio solution in a solution brief format.

An overview of the series on omnichannel experience portfolio architecture blueprint can be found here:

  1. An introduction 
  2. Generic common architectural elements (this article)
  3. External application details
  4. API management details
  5. Container platform essentials
  6. Storage services
  7. Example process integration 
  8. Example mobile integration 
  9. More example integration blueprints

Catch up on any articles you missed by following one of the links above.

Follow along as this series takes you through the omnichannel experience blueprint story. Coming up next, taking a look at the generic common architectural elements.

Topics:
integration architecture ,integration ,containers ,container platform ,architects ,omnichannel integration

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}