Lucidchart decision tree how to#

For instance, in the example below we use a coloring scheme to describe whenever a certain service is available in the customer environment. Two more things need to be mentioned before coming to the process. And finally, integrations will help you to build the architecture in a quick and easy way. SLA and HA / DR references will allow you to understand the best options you have there. Limits on data storage, retention and memory will give you a good idea on how your processing will look like. Read and write profiles will give you the rough throughput and latency figures as well as define some item sizes. Some limitations in implementations, functional and non-functional requirements.Ī good thing is that most of that is already somehow reflected in Albero, so you can use it as the main reference point. Absence of obvious way to integrate different solutions.ģ. Read and write mismatch (in terms of data sizes, latencies, throughputs, etc.)Ģ. The problem is that combining our non-Lego blocks into something viable (the process which is often and quite falsely referred to as “architecting”) may become a bit complex due to several factors:ġ. Azure services support various data types, formats and it’s usages. With this approach we can use the best features and capabilities of each service.

Lucidchart decision tree how to#

Azure services support various data types, formats and it’s usages. But how to choose the right service? With this approach we can use the best features and capabilities of each service.

We often use a Polyglot Persistence concept of using different storage technologies by the same solution. The one type of relational database is no longer a solution for everything. We still have such companies, but in modern ages we have more freedom for decisions.

If, for example, ORACLE is a corporate standard you can have ORACLE as a first choice even if it doesn’t suit the requirements, it’s just because “We are the company which uses ORACLE”. This time is not too far from current times. In good old times most companies used a single data product depending on their corporate standards for all their data solutions. It means we probably need more than one technology (and the Captain Obvious Strikes back).Ī quick look from the theory perspective: However, we all know it is a very rare case for such solutions to be implemented using a single technology (due to differences in read and write pattern).

As you know, the main goal of Albero is helping you and your customers in selecting the best data architecture for the solution you are trying to build.