Blueprint for omnichannel integration architecture
•Transferir como PPTX, PDF•
1 gostou•1,121 visualizações
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
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Blueprint for omnichannel integration architecture
Semelhante a Blueprint for omnichannel integration architecture (20)
Mais de Eric D. Schabell
Mais de Eric D. Schabell (20)
Último
Último (20)
Blueprint for omnichannel integration architecture
- 1. Blueprint for omnichannel integration architecture Eric D. Schabell Portfolio Architect Director, Red Hat @ericschabell Dec 2019 Webinar
- 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
- 4. Portfolio Architecture “Omnichannel implies integration and orchestration of channels such that the experience of engaging across all the channels someone chooses to use.”
- 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
- 6. 6 Generic view of the solution architecture Architectural Blueprint
- 8. Portfolio Architecture LOGICAL DIAGRAM (DETAILS)
- 9. Portfolio Architecture LOGICAL DIAGRAM (DETAILS)
- 10. Portfolio Architecture LOGICAL DIAGRAM (DETAILS)
- 11. Portfolio Architecture LOGICAL DIAGRAM (DETAILS)
- 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
- 25. Portfolio Architecture EXAMPLE: PROCESS INTEGRATION Kubernetes Service Balancer Kubernetes Service Balancer
- 26. Portfolio Architecture EXAMPLE: MOBILE INTEGRATION Kubernetes Service Balancer Kubernetes Service Balancer
- 27. Portfolio Architecture EXAMPLE: INTEGRATION SERVICE USE Kubernetes Service Balancer Kubernetes Service Balancer
- 28. Portfolio Architecture EXAMPLE: INTEGRATION DATA SERVICE USE Kubernetes Service Balancer Kubernetes Service Balancer
- 29. Portfolio Architecture EXAMPLE: PROCESS INTEGRATION WITH THIRD PARTY SERVICES Kubernetes Service Balancer Kubernetes Service Balancer
- 30. Portfolio Architecture EXAMPLE: INTEGRATION TO THIRD PARTY SERVICE USE Kubernetes Service Balancer Kubernetes Service Balancer
- 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
- 32. 32 Eric D. Schabell Portfolio Architect Director, Red Hat @ericschabell Thank You
Notas do Editor
- 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).