In the last 50 or we started talking about an imaginary insurance company remember we had said that
we would have a customer who would fill out some form handoff to our form receiver the form receiver
would make a copy of that form and hand one individual copy of the form to each of our different departments.
And so then our departments would somehow inspect that form and decide how to process the form internally.
Now in this video we're going to continue with this analogy a little bit more.
Remember the idea here is that once you understand this analogy will then be able to apply every step
inside this flow to our different parts of this redux cycle thing over here.
And trust me at the end of the day it's going to make this process a lot more clear.
So let me tell you a little bit more about this analogy here.
We're going to develop it a little bit further.
Now I want to start to think about what would happen when a form or a copy of a form is taken and handed
off to some very specific department like let's say in this case the policies Department.
So here's probably what would happen internally a form would come in that maybe has the intent of signing
up for a new policy.
So remember the customer gave us this thing the former receiver made a copy of it and then handed off
to the policy department.
Well chances are that internally the policies Department has a list of everyone who has a policy.
That's their job.
They're supposed to maintain a list of all customers who hold an active policy.
So we would imagine that the policies department would take in this form see that this customer is trying
to sign up for a new policy and then maybe add them onto this list right here of people who hold a policy.
So they would say All right we've got another person who just signed up for a policy and will say that
Juliet Juliet now holds a policy in addition to Fred Jane.
Alex in Alexandria.
Now this right here definitely makes a lot of sense.
We are saying that the policies Department maintains a list internally of everyone who has a policy
but I'm going to throw a little wrench in this flow right here.
All right.
I'm going to put in a little odd piece.
Let's imagine that we have some management team at our company and for some reason this management team
always comes knocking on the door of the policies department and they always come around and say hey
tell me a list who has a policy right now.
Maybe the management team needs to know who has a policy so that they can collect some metrics about
how many policies are active and how the number of policies are changing over time.
So management eventually starts to get a little bit frustrated with having to go knock on the door or
the policies department all the time because they're tired of having to walk over there or knock on
the door or say hey give me this list.
Get the list and then tape record some metric using it.
So in order to address the fact that the management team doesn't want to have to go knock on the door
or the policies department all the time.
We're going to make a little change to where our list of customers with policies is stored.
We're going to say that rather than the policies Department internally having like a big binder or a
big sheet of paper that lists all these customers they're going to instead store that list of policies
inside of a central repository of company data that is stored outside of their department.
So in this separate repository of data is going to be all of the information about who currently has
a policy and a list of all the claims that have ever been filed and maybe a list of all of our money
or what the current balance of the company is and how much cash we have on hand.
So now the management team can very easily go and get a list of policies and see who has a policy and
record some metrics around that management team can also now very easily look at the claims history
or all the accounting information and the management team can do that with having without having to
go and knock on the door of each of these different departments.
However now we're in a little bit of a bind because at some point in time the policies Department is
going to get some form that says hey I want to sign up for a new policy.
So they are probably going to need to somehow update this list of policies right here.
So we'll say that any time that the form receiver makes a copy as a form and hands it off to the policy
department.
This former senior person is also going to go to the central repository of data peer for the entire
company.
They're going to find the list of policies and they're going to hand it in to the policies Department
along with that form.
And so the former CEO right here is essentially saying hey we just got a new form.
I need you to process this thing.
And by the way here's a list of all of our current policies.
So now the policies Department will look at that form.
They'll update the list of policies and then when they are done doing that update they're going to go
and pass it back to this central repository appear.
So now the idea here is that the management team can very easily see all the data.
And any time that the policies department needs to update that data they're going to get their list
of policies they're going to update the list of policies and then update the central repository list
of policies right here as well.
All right.
So I know that this analogy is getting really intense and very intense.
But I just got one or two more steps to go through and then we're going to be able to apply all this
information back to a redux cycle.
So another quick pause and we're going to develop this analogy just a little bit more in the next video.