Edge medical diagnosis - Example architecture with GitOps

Part 4 - Example architecture with GitOps

In our previous article from this series we talked about the example predictive analysis architecture found in an edge medical diagnosis solution for the healthcare industry.

The process was laid out how we approached the use case and how portfolio solutions are the base for researching a generic architecture. It continued by discussion how we approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Now it's time to look at one final example architecture.

This article walks you through an example architecture for using GitOps for providing a deployment and development example for edge medical diagnosis scenarios.

Edge medical diagnosis - Example predictive analysis

Part 3 - Example predictive analysis

In our previous article from this series we talked about the logical common architectural elements found in an edge medical diagnosis solution for the healthcare industry.

The process was laid out how we approached the use case and how portfolio solutions are the base for researching a generic architecture. It continued by laying out the process of how we approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.

This article walks you through an example predictive analysis scenario showing how expanding the previously discussed elements provides an example for edge medical diagnosis scenarios.

Edge medical diagnosis - Common architectural elements

Part 2 - Common architectural elements

In our previous article from this series we introduced a use case around edge medical diagnosis for the healthcare industry.

The process was laid out how we approached the use case and how portfolio solutions are the base for researching a generic architecture. 

The only thing left to cover was the order in which you'll be led through the details.

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

Edge medical diagnosis - Architectural introduction

Part 1 - Architectural introduction

The last few years we have been digging deeply into the world of architectures with a focus on presenting access to ways of mapping successful implementations for specific use cases.

It's an interesting challenge in that we have the mission of creating architectural content based on common customer adoption patterns. 

That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the chuff. 

What's that mean?

It means that it's going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures and interactions that actually have been proven to work. What's not included are any vendor promises that you'll find in normal marketing content. Those promised that when it gets down to implementation crunch time, might not fully deliver on their promises.

Enter the term Portfolio Architecture. 

Let's look at these architectures, how they're created and what value they provide for your solution designs.

Retail data framework - Example data architecture

Part 3 - Example data architecture

In our previous article from this series shared a look at the logical common architectural elements found in a retail data framework solution for retail organisations.

The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture. 

It continued by laying out the process of how we've approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.

This article walks you through an example stock control scenario showing how expanding the previously discussed elements provides an example for your own stock control scenarios.

Retail data framework - Common architectural elements

Part 2 - Common architectural elements

 In our previous article from this series we introduced a use case around the data framework for retail stores.

The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture. 

The only thing left to cover was the order in which you'll be led through the details.

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

This will start our journey into the logical elements that make up the real-time stock control architecture.

Retail data framework - An architectural introduction

Part 1 - An architectural introduction

This article launches a new series exploring a retail architecture. It's focusing on presenting access to ways of mapping successful implementations for specific use cases.

It's an interesting challenge creating architectural content based on common customer adoption patterns. That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the chuff. 

What's that mean?

It means that it's going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures and interactions that actually have been proven to work. What's not included are any vendor promises that you'll find in normal marketing content. Those promised that when it gets down to implementation crunch time, might not fully deliver on their promises.

Enter the term Portfolio Architecture. 

Let's look at these architectures, how they're created and what value they provide for your solution designs.

Real-time stock control - An architectural introduction

Part 1 - Architectural introduction

This article launches a new series exploring a retail architecture. It's focusing on presenting access to ways of mapping successful implementations for specific use cases.

It's an interesting challenge creating architectural content based on common customer adoption patterns. That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the chuff. 

What's that mean?

It means that it's going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures and interactions that actually have been proven to work. What's not included are any vendor promises that you'll find in normal marketing content. Those promised that when it gets down to implementation crunch time, might not fully deliver on their promises.

Enter the term Portfolio Architecture. 

Let's look at these architectures, how they're created and what value they provide for your solution designs.

Headless eCommerce - Example headless architectures

Part 3 - Example headless architectures

In our previous article from this series shared a look at the logical common architectural elements found in a headless e-commerce solution for retail stores.

The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture. It continued by laying out the process of how we've approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.

This article walks you through an example headless e-commerce platform scenario showing how expanding the previously discussed elements provides an example for your own headless e-commerce scenarios.

Headless eCommerce - Common architectural elements

Part 2 - Common architectural elements

 In our previous article from this series we introduced a use case around headless e-commerce for retail stores.

The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture. 

The only thing left to cover was the order in which you'll be led through the details.

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

This will start our journey into the logical elements that make up the headless e-commerce architecture.

Headless eCommerce - An architectural introduction

Part 1 - An architectural introduction

We're kicking off another series sharing a new architecture. It's focusing on presenting access to ways of mapping successful implementations for specific use cases.

It's an interesting challenge creating architectural content based on common customer adoption patterns. That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the chuff. 

What's that mean?

It means that it's going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures and interactions that actually have been proven to work. What's not included are any vendor promises that you'll find in normal marketing content. Those promised that when it gets down to implementation crunch time, might not fully deliver on their promises.

Enter the term Portfolio Architecture. 

Let's look at these architectures, how they're created and what value they provide for your solution designs.

Supply chain integration - Example store integration architecture

Part 3 - Example store integration architecture

 In our previous article from this series shared a look at the logical common architectural elements found in supply chain integration for retail stores.

The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture. 

It started with laying out the process of how we've approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.

This article walks you through an example store integration scenario showing how expanding the previously discussed elements provides an example for your own store integration scenarios.

Supply chain integration - Common architectural elements

Part 2 - Common architectural elements

 In our previous article from this series we introduced a use case around supply chain integration for retail stores.

The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture. 

The only thing left to cover was the order in which you'll be led through the architectural details.

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

This will start our journey into the logical elements that make up the supply chain integration architecture.

Supply chain integration - An architectural introduction

Part 1 - An architectural introduction

If you've been following the writing here over the last few years, you've grown accustomed to the sharing of various architectures. They're focusing on presenting access to ways of mapping successful implementations for specific use cases.

It's an interesting challenge in our mission of creating of architectural content based on common customer adoption patterns. That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the chuff. 

What's that mean?

It means that it's going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures and interactions that actually have been proven to work. What's not included are any vendor promises that you'll find in normal marketing content. Those promised that when it gets down to implementation crunch time, might not fully deliver on their promises.

Enter the term Portfolio Architecture. 

Let's look at these architectures, how they're created and what value they provide for your solution designs.

Payments architecture - Financial calculations example

Part 6 - Financial calculations

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

In the previous article in this series we covered our fraud detection physical architecture.

In this article we're exploring the final physical architecture in this architecture,  a generic financial calculations example, one based on successful customer solutions.

Payments architecture - Fraud detection example

Part 5 - Fraud detection

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

In the previous article in this series we walked through the anti-money laundering physical architecture.

In this article we're exploring the physical architecture for fraud detection, one based on successful customer solutions.

Payments architecture - Anti-money laundering Example

Part 4 - Anti-money laundering

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

In the previous article in this series we walked through the immediate payments physical architecture.

In this article we're diving into the anti-money laundering (AML) physical architecture, one based on successful customer solutions.

Payments architecture - Immediate payments example

Part 3 - Immediate payments

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

In the previous article in this series we explored the common architectural elements found in a payments logical architecture.

In this article we'll walk through an immediate payments physical architecture,  laying out what a successful payments solution looks like in practice.

Payments architecture - Common architecture elements

Part 2 - Common architectural elements

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

In part one of this series we introduced the concept of a portfolio architecture and shared the planning for this series to cover the logical, physical, and details of the solution.

In this article we'll explore the logical diagram that captures the elements of a successful payments solution.

Payments architecture - An introduction

Part 1 - An introduction

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

What's in a portfolio architecture and how are customers applying these solutions you ask? It's an interesting challenge in that we've been creating architectural content based on common customer adoption patterns. That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the marketing chuff. 

These architectures are providing you with a way to create a cloud native payment architecture focusing on the interactions, messaging, processing, and integrations proven to work. What's not included are any vendor stories that you'll find in normal marketing content. Those stories that when it gets down to implementation crunch time, might not fully deliver on their promises.

Let's look at the payments architecture and explore their value in helping your solution designs.