Agile integration is a broadly scoped discussion around how to use all the services and power contained in your organization’s current architecture. While the topic is interesting in its own right, let's take a deeper look at a specific solution within the integration context: providing an omnichannel customer experience. Omnichannel is the integration and orchestration of channels to make the experience of customer engagement across all channels as efficient as engagement with 1 channel.
Webinar recording available: http://redhat.com/en/events/webinar/blueprint-omnichannel-integration-architecture
Original internal slides: https://docs.google.com/presentation/d/1dLEPLLiMADb5q9AUnmqxdp8L7UsiovzzalJ1nJPNNkw
2. Portfolio Architecture
Choose a portfolio
architecture
Requests from the field or from
product marketing. It should
have two or more successful
deployments.
Research
Start with customers reports.
Reach out to the field SAs and
consultants. Gather as much
information on the deployment
as possible.
Build out the Blueprint
Pull out the common patterns.
Determine a prescriptive
deployment. Build out the
diagrams.
How do we do this?
3. Portfolio Architecture
Logical view
High level abstractions of
services and platforms. No
networking or data flows.
Service descriptions can be
added.
Schema/Blueprint
Describes the main nodes and
services and their interactions and
network connections. Product
details can be included.
Cardinality and logical groupings
can be described.
Node or Service detail
Detailed look at one
specific service. Includes
deployment mode, storage
and networking details.
Three levels of architecture
5. Portfolio Architecture
● Data management
● Security and user access
● Multiple protocol and language support through
different integration technologies
● Distributed deployments, non-centralized
integration
● Training developers to deliver in a digital
integration architecture
● Training operations to manage and monitor a
digital integration landscape
Tackling the challenges
12. Portfolio Architecture
Application for mobile devices:
● Provides customer interface to
enterprise solutions
● Voice, video or chat features
● Contains service calls to:
○ API Gateway for:
■ Frontend Microservices
■ Process Facade Microservices
■ Other Applications (aggregated
microservices)
■ Eventual mobile specific services (push
notifications, usage analytics, etc)
DETAIL: MOBILE APPLICATION
13. Portfolio Architecture
Web sites from enterprise or third-party
sites using provided services:
● Provides customer interface to
enterprise solutions
● Third party integration sites, retail sites,
social media, and more
● Contains service calls to:
○ API Gateway for:
■ Frontend Microservices
■ Process Facade Microservices
■ Other Applications (aggregated
microservices)
DETAIL: WEB APPLICATION
14. Portfolio Architecture
Platform to manage and expose APIs for
microservices
● Provides service interfaces to
applications and other microservices
● Provides scalability, reliability and
interface usage metrics
● Exposes interfaces from:
○ Frontend Microservices
○ Process Facade Microservices
○ Other Applications (aggregated
microservices)
DETAIL: API MANAGEMENT
15. Portfolio Architecture
Retrieves resources on behalf of a client
● Resources are then returned to the
client
● Hides all visibility of resources behind
the proxy
● Manages external traffic to:
○ Frontend Microservices
○ Process Facade Microservices
○ Other Applications (aggregated
microservices)
DETAIL: REVERSE PROXY
16. Portfolio Architecture
Legacy, standalone, or service integration
applications running in containers.
● Microservices (aggregation) into more
complex services / applications
● SSO plugin into organization auth
components
● Receives calls from:
○ API Gateway
● Potential services calls to:
○ Integration (Data) Microservices
○ Applications
○ SSO Server
DETAIL: APPLICATIONS
17. Portfolio Architecture
1… n+1 CNS SSO
APPLICATION - CUSTOMER CONTACT
This service
details a
customer
interaction
and updates
the call
center
application’s
view of the
customer.
Customer
Contact
Service
Called
every time
customer
touched
18. Portfolio Architecture
Services used to access process automation
(processes):
● Provides access to deeper services within the
solution architecture
● SSO plugin into organization auth
components
● Receives calls from:
○ Frontend applications
○ Applications (microservices)
○ Frontend microservices
● Potential services calls to:
○ Process server
○ SSO server
DETAIL: PROCESS FACADE MICROSERVICES
19. Portfolio Architecture
Services used in frontend apps looking to
work with microservice infrastructure
provided:
● Provides access to deeper services within the
solution architecture
● SSO plugin into organization auth
components
● Receives calls from:
○ Frontend applications
● Potential services calls to:
○ Integration (Data) Microservices
○ Process Facade Microservices
○ SSO Server
○ Applications
DETAIL: FRONTEND MICROSERVICE
20. Portfolio Architecture
Services integrating all manner of backend
systems and 3rd-party services:
● Provides access to components within
the solution architecture
● SSO plugin into organization auth
components
● Receives calls from:
○ Frontend Microservices
○ Process Server
○ Applications
● Potential services calls to:
○ Integration Data Microservices
○ Process Facade Microservices
○ SSO Server
DETAIL: INTEGRATION MICROSERVICES
21. Portfolio Architecture
Services integrating storage components:
● Provides access to components within
the storage solution architecture
● SSO plugin into organization auth
components
● Receives calls from:
○ Frontend Microservices
○ Process Server
○ Applications
○ Integration Microservices
● Potential services calls to:
○ Storage components
○ SSO Server
DETAIL: INTEGRATION DATA MICROSERVICES
22. Portfolio Architecture
Process automation (processes) and
business logic engine:
● Engine for process automation and
business logic
● Receives calls from:
○ Process Facade Microservices
● Potential services calls to:
○ Integration (Data) Microservices
○ Applications
DETAIL: PROCESS SERVER
23. Portfolio Architecture
Services delivering on real-time data
streaming (video, voice, ect).
● Can be pipelined directly to front end
applications.
● SSO plugin into organization auth
components
● Receives calls from:
○ Integration Data Microservices
○ Frontend Microservices
● Potential services calls to:
○ Frontend Microservices
○ SSO Server
DETAIL: REAL-TIME DATA STORAGE
24. Portfolio Architecture
Single-sign-on (SSO) server solution, can be
3rd-party.
● Single Sign On server for plugging in to
organization auth components
● Receives calls from:
○ Possibly all architecture
components
● Potential services calls to:
○ Possibly all architecture
components
DETAIL: SSO SERVER
31. Portfolio Architecture
Series on Omnichannel Integration
https://dzone.com/articles/integration-key-to-experience-an-introduction-part
Learn more about Red Hat Integration
https://www.redhat.com/en/products/integration
Learn more about Red Hat Process Automation
https://www.redhat.com/en/products/process-automation
What is new with Red Hat Integration
https://www.redhat.com/en/blog/whats-new-red-hat-integration
Online workshop
https://redhatdemocentral.gitlab.io/portfolio-architecture-workshops
Agile integration is a broadly scoped discussion around how to use all the services and power contained in your organization’s current architecture. While the topic is interesting in its own right, let's take a deeper look at a specific solution within the integration context: providing an omnichannel customer experience. Omnichannel is the integration and orchestration of channels to make the experience of customer engagement across all channels as efficient as engagement with 1 channel.
How we work. Describing the research in more detail and how the blueprints come to be.
The three diagram levels found in a portfolio architecture blueprint; logical, schema, and detailed diagrams.
The basic view of creating an omnichannel customer experience. It’a about integration and orchestration of your services and infrastructure to provide a flexible environment for delivery of your digital customer experiences. Omnichannel architectures provide a seamless experience and consistent messaging across all customer channels.
There are two crucial aspects to an omnichannel design:
integrating consumer applications with backend systems
using real-time data streams from a variety of sources
An effective omnichannel deployment creates better experiences for customers, so that interactions (like customized recommendations or immediate retrieval of loyalty perks) feel personal and authentic. The single most common technology or area that crops up with omnichannel is customer relationship management services.
This leads to an interesting dichotomy between omnichannel vendors. There are more traditional software vendors like Red Hat (and Oracle, IBM, Apigee, and Mulesoft) which sell solutions which can be used to create omnichannel architectures. Then there are ones like Terfina which specifically sell services or stacks or bundles for a specific vertical (usually retail or financial services) and are focused exclusively on the customer experience aspect of omnichannel.
(Photo: free from burst.shopify.com)
Research showed that customers are consistently addressing these challenges within the ominchannel use cases:
Data management
Security and user access (through traffic management, authentication layers, etc)
Multiple protocol and language support through different integration technologies
Distributed deployments, allowing integration within specific environments and crossing environments, rather than being centralized
Training developers to deliver in this new digital integration architecture
Training operations to manage and monitor this new digital integration landscape
This starts the actual architectural blueprint covering the generic view of this solution architecture.
This is the logical view of the application integration architecture as deployed within a container-based platform cluster. Note the storage is a single logical database structure with clustering and replication. This entire setup is the load balanced across two or more container-based platform clusters. Outside the top of this image is the incoming calls from the load balancer that regulates all incoming requests. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
This architecture supports the following development and integration:
Applications - legacy, standalone, or as aggregated service users.
Frontend services - the public API interface and implementation of all the necessary business logic, workflows and orchestration calls to all backend components (process services, security services, data storage services). Includes services for interaction with mobile clients (omni-channel customer experiences).
Integration microservices - provide a level of abstraction between the Frontend services and external systems required to integrate as well as internal storage services. Allows for the potential of removing, replacing and expanding these services without an immediate impact on the business services.
Data microservices - services connecting to the various data storages.
Aggregated services - services created by leveraging multiple existing microservices.
Processes - business processes captured and available for use by microservices, applications or as standalone artifacts.
Business logic - centrally managed and available for deployment in microservices, for use by processes or by any applications.
Security and Authentication (SSO) - server providing SSO can also be tied into existing organizational directories.
Data storage - for real-time data storage and analysis, it can also be both traditional storage or cached realizations of logical storage definitions as needed by applications, processes or services.
Load balanced services - each kubernetes service balancer ensures responsive microservices, applications and data storage interactions.
This is the logical view of the application integration architecture as deployed within a container-based platform cluster. Note the storage is a single logical database structure with clustering and replication. This entire setup is the load balanced across two or more container-based platform clusters. Outside the top of this image is the incoming calls from the load balancer that regulates all incoming requests. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
This architecture supports the following development and integration:
Applications - legacy, standalone, or as aggregated service users.
Frontend services - the public API interface and implementation of all the necessary business logic, workflows and orchestration calls to all backend components (process services, security services, data storage services). Includes services for interaction with mobile clients (omni-channel customer experiences).
Integration microservices - provide a level of abstraction between the Frontend services and external systems required to integrate as well as internal storage services. Allows for the potential of removing, replacing and expanding these services without an immediate impact on the business services.
Data microservices - services connecting to the various data storages.
Aggregated services - services created by leveraging multiple existing microservices.
Processes - business processes captured and available for use by microservices, applications or as standalone artifacts.
Business logic - centrally managed and available for deployment in microservices, for use by processes or by any applications.
Security and Authentication (SSO) - server providing SSO can also be tied into existing organizational directories.
Data storage - for real-time data storage and analysis, it can also be both traditional storage or cached realizations of logical storage definitions as needed by applications, processes or services.
Load balanced services - each kubernetes service balancer ensures responsive microservices, applications and data storage interactions.
This is the logical view of the application integration architecture as deployed within a container-based platform cluster. Note the storage is a single logical database structure with clustering and replication. This entire setup is the load balanced across two or more container-based platform clusters. Outside the top of this image is the incoming calls from the load balancer that regulates all incoming requests. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
This architecture supports the following development and integration:
Applications - legacy, standalone, or as aggregated service users.
Frontend services - the public API interface and implementation of all the necessary business logic, workflows and orchestration calls to all backend components (process services, security services, data storage services). Includes services for interaction with mobile clients (omni-channel customer experiences).
Integration microservices - provide a level of abstraction between the Frontend services and external systems required to integrate as well as internal storage services. Allows for the potential of removing, replacing and expanding these services without an immediate impact on the business services.
Data microservices - services connecting to the various data storages.
Aggregated services - services created by leveraging multiple existing microservices.
Processes - business processes captured and available for use by microservices, applications or as standalone artifacts.
Business logic - centrally managed and available for deployment in microservices, for use by processes or by any applications.
Security and Authentication (SSO) - server providing SSO can also be tied into existing organizational directories.
Data storage - for real-time data storage and analysis, it can also be both traditional storage or cached realizations of logical storage definitions as needed by applications, processes or services.
Load balanced services - each kubernetes service balancer ensures responsive microservices, applications and data storage interactions.
This is the logical view of the application integration architecture as deployed within a container-based platform cluster. Note the storage is a single logical database structure with clustering and replication. This entire setup is the load balanced across two or more container-based platform clusters. Outside the top of this image is the incoming calls from the load balancer that regulates all incoming requests. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
This architecture supports the following development and integration:
Applications - legacy, standalone, or as aggregated service users.
Frontend services - the public API interface and implementation of all the necessary business logic, workflows and orchestration calls to all backend components (process services, security services, data storage services). Includes services for interaction with mobile clients (omni-channel customer experiences).
Integration microservices - provide a level of abstraction between the Frontend services and external systems required to integrate as well as internal storage services. Allows for the potential of removing, replacing and expanding these services without an immediate impact on the business services.
Data microservices - services connecting to the various data storages.
Aggregated services - services created by leveraging multiple existing microservices.
Processes - business processes captured and available for use by microservices, applications or as standalone artifacts.
Business logic - centrally managed and available for deployment in microservices, for use by processes or by any applications.
Security and Authentication (SSO) - server providing SSO can also be tied into existing organizational directories.
Data storage - for real-time data storage and analysis, it can also be both traditional storage or cached realizations of logical storage definitions as needed by applications, processes or services.
Load balanced services - each kubernetes service balancer ensures responsive microservices, applications and data storage interactions.
This is the logical view of the application integration architecture as deployed within a container-based platform cluster. Note the storage is a single logical database structure with clustering and replication. This entire setup is the load balanced across two or more container-based platform clusters. Outside the top of this image is the incoming calls from the load balancer that regulates all incoming requests. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
This architecture supports the following development and integration:
Applications - legacy, standalone, or as aggregated service users.
Frontend services - the public API interface and implementation of all the necessary business logic, workflows and orchestration calls to all backend components (process services, security services, data storage services). Includes services for interaction with mobile clients (omni-channel customer experiences).
Integration microservices - provide a level of abstraction between the Frontend services and external systems required to integrate as well as internal storage services. Allows for the potential of removing, replacing and expanding these services without an immediate impact on the business services.
Data microservices - services connecting to the various data storages.
Aggregated services - services created by leveraging multiple existing microservices.
Processes - business processes captured and available for use by microservices, applications or as standalone artifacts.
Business logic - centrally managed and available for deployment in microservices, for use by processes or by any applications.
Security and Authentication (SSO) - server providing SSO can also be tied into existing organizational directories.
Data storage - for real-time data storage and analysis, it can also be both traditional storage or cached realizations of logical storage definitions as needed by applications, processes or services.
Load balanced services - each kubernetes service balancer ensures responsive microservices, applications and data storage interactions.
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. While Red Hat Mobile Application Platform (RHMAP) is called out explicitly as it was used in the various researched customers, it’s scheduled for end Dec 2019 to EOL. Moving forward the researched customers are moving towards mobile services deployed on OpenShift Container Platform. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Example of application showcasing marketing update service to note the contact between an organization and its customers. An application that aggregates a few microservices and exposes its API in the form of a RestAPI. The microservices are an integration microservice that adds the contact date to the mainframe backend records and an integration data microservice the updates the marketing database backend. It’s also reporting back through the mobile services to the caller.
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. While in the researched customers we’ve noted Red Hat BPM Suite and/or Red Hat BRMS as the product used, moving forward these customers are moving to the new product Red Hat Process Automation Manager and/or Red Hat Decision Manager. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
The detailed view of this element provides an overview, description, technologies, and covers the calls being made to and from it. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Example of a process application deployed in a mobile applications making calls through the API Gateway to leverage both Frontend Microservices and Process Facade Microservices to access functionality in the Process Server and integration with backend systems through the Integration Microservices. Container Native Storage shown used for BPM Suite storage as an example. Not showing monitoring with CloudForms. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Example of a mobile application making calls through the API Gateway to leverage both Frontend Microservices and Mobile Services to serve data to the device and integration with backend systems through the Integration Microservices. Container Native Storage shown as the data source for mobile data consumption in this example for simplicity. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Example use of integration microservices with web ui making calls through the API Gateway to leverage Frontend Microservices that in turn call to various integration with backend systems through an Integration Microservice. SSO server shown with integration to existing company backend Active Directory Server for authentication. Not showing monitoring with CloudForms. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Example use of integration microservices with web ui making calls through the API Gateway to leverage Frontend Microservices that in turn call to various integration with a customer contact database through an Integration Data Microservice. SSO server shown with integration to existing company backend Active Directory Server for authentication. Not showing monitoring with CloudForms. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Example of a process application deployed in a mobile applications making calls through the API Gateway to leverage both Frontend Microservices and Process Facade Microservices to access functionality in the Process Server and integration with systems through the Integration Microservices. Container Native Storage shown used for BPM Suite storage as an example. Not showing monitoring with CloudForms. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
Process integration through microservices and API’s to leverage third party services hosted on PCF are not physically mapped out, but can be explained (from a process step call to an integration service which then accesses PCF service through an API).
Example use of integration microservices with web ui making calls through the API Gateway to leverage Frontend Microservices that in turn call to various integration with backend systems through an Integration Microservice. SSO server shown with integration to existing company backend Active Directory Server for authentication. Not showing monitoring with CloudForms. (Diagram file available in portfolio architecture examples repository, see readme to import into diagram tooling: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples)
This features an integration microservice connection to third party services hosted on PCF, accessed by integration microservices through API’s.
References for linking to more content and the other collateral associated with this blueprint.
Agile integration is a broadly scoped discussion around how to use all the services and power contained in your organization’s current architecture. While the topic is interesting in its own right, let's take a deeper look at a specific solution within the integration context: providing an omnichannel customer experience. Omnichannel is the integration and orchestration of channels to make the experience of customer engagement across all channels as efficient as engagement with 1 channel.
Comments and feedback welcome, Eric D. Schabell (erics@redhat.com).