OK, Merriwell, next example in the row here.
So here's what I call kind ridging information, rigid information systems.
And I'm not saying that even if you might have a specific service in mind when I'm taking this example,
I'm not saying that they should have done this.
I'm just saying that, yes, this is like a generic example that you probably can apply to multiple
other situations.
So here's the scenario.
So you have a couple of people and they are setting up the foundations for a new idea.
Let's build a social network service where you can follow other people's short sales messages.
That sounds like a great thing.
Let's call it accounts because it doesn't have to be a person.
Right?
Could be anything.
Post those short messages.
Yeah.
And messages could mention an account and also create categories on the fly.
And that sounds like a great idea.
Yeah.
What do you think about something like this?
So we have a short message.
An account is creating a sort of short message.
An account could be actually followed by other accounts and a short message could mention other accounts.
And you can actually create let's call it a hash tag so you can create categories on the fly when you're
typing your message.
And then other people can use that hashtag as well in their messages.
Powerful.
Great.
So the model is encoded into an I.T. system and a database, of course, and the service becomes extremely
popular and the lottery grows.
However, the harder it becomes to actually change the structure.
And that's quite common in large companies.
I see.
So when you're getting the complexity of actually getting real roles in getting real customers, actually
using the service is becoming harder and harder to actually change the service.
So let's say there are a couple of years after they start thinking about that.
Wouldn't be good to have other types of relationships than just followers between accounts.
Yeah.
What do you say about maybe like a close network of friends so you can have, like, subgroups?
Yeah, let's fix it.
How can it be so something like that is what we would like to have.
So an account could be involved in multiple account relationships and it could actually play different
roles in that account relationship.
So you could have, for example, earn first account here, who's the follower in a followership?
And the account too is the following account in the same followership, an account who is also a friend
in a friendship would account three.
So have they both jointly have the role of a friend, whereas the in the other account relationship
one was a follower on the other one was two followed.
So maybe that's the addition to the conceptual model.
We will need to get that flexibility to have both the follower and a follower thing that we have in
the original one, but also have other types of relationships.
But making this change now might result in updates of billions of roles in a database and multiple software
component might need to be updated and so on, depending, of course, how we do to change.
But I think you see the point and the system needs to be up and running for 24/7 and adding this model
volubility modified ability from the beginning, as you've seen already, would be a very small thing.
But after the complexity of actually having billions and billions and billions of short messages and
customers, it gets a real pain to actually do the structurally structural changes that might be needed.
And that is also kind of waste, because I said adding the addition to the conceptual model from the
very beginning is a very simple thing.
And using a tool for this to actually model your conceptual domains early on is a way to find those
types of modify village areas where you might need to include other things in the future.
Very good.
That was the end of that example.
So let's go into the next to the next one.
I think it's the fifth one.